التحول الرقمي

كراسة الشروط والمواصفات لمشروع برمجي: دليل كتابة المتطلبات مع نموذج

كراسة الشروط والمواصفات لمشروع برمجي وثيقة يكتبها صاحب العمل قبل طلب العروض، تشرح الهدف والمستخدمين والميزات مرتبة بالأولوية، ثم شروط الأداء والأمان والعربية والاستضافة والملكية ومعايير القبول. فائدتها أن كل الشركات تسعر الشيء نفسه فتصبح المقارنة عادلة ويقل الخلاف بعد التوقيع. وإن كانت لديك فكرة فقط فابدأ بجلسة اكتشاف تحولها إلى نطاق مكتوب.

غلاف دليل كتابة كراسة الشروط والمواصفات لمشروع برمجي يوضح أقسام وثيقة متطلبات المشروع قبل طلب العروض
غلاف دليل كتابة كراسة الشروط والمواصفات لمشروع برمجي يوضح أقسام وثيقة متطلبات المشروع قبل طلب العروض

كراسة الشروط والمواصفات لمشروع برمجي هي وثيقة مكتوبة يشرح فيها صاحب المشروع ما يريد بناءه، ولمن، ولماذا، قبل أن يطلب عروض الأسعار من الشركات. تكتبها بلغتك أنت لا بلغة المبرمجين: الهدف، والمستخدمون، والميزات مرتبة حسب الأولوية، والشروط غير الوظيفية مثل الأمان والعربية والاستضافة والملكية، ثم معايير القبول التي تحكم بها على التسليم.

آخر تحديث: أكتوبر 2026

هذا الدليل موجه لصاحب العمل الذي يريد موقعا أو تطبيقا أو نظاما خاصا، ولا يريد أن يتلقى ثلاثة عروض لا يمكن مقارنتها ببعضها. ستجد فيه نموذجا جاهزا تنسخه وتملؤه.

ما هي كراسة الشروط والمواصفات لمشروع برمجي؟

هي المرجع المكتوب الذي يصف المشروع من زاوية صاحبه: المشكلة التي يحلها، ومن سيستخدمه، وما يجب أن يفعله، وما الشروط التي لا يقبل التنازل عنها. يسميها المختصون أيضا «وثيقة متطلبات المشروع»، وهي أبسط من وثيقة مواصفات متطلبات البرمجيات (Software Requirements Specification) واختصارها SRS، التي تكتب لاحقا مع الشركة المنفذة؛ والفكرة في الحالتين اتفاق مكتوب قبل البدء.

المرجع الدولي المعروف في هندسة المتطلبات هو المعيار ISO/IEC/IEEE 29148، وإصداره الساري صدر عام 2018، ويجري إعداد إصدار جديد منه. يحدد المعيار خصائص المتطلب الجيد ومحتوى وثائق المتطلبات. لست مضطرا لتطبيقه حرفيا في مشروع صغير، لكن روحه مفيدة: كل متطلب يجب أن يكون واضحا، وقابلا للتحقق، وضروريا فعلا.

الفرق بين أنواع وثائق المتطلبات

تتداخل المسميات كثيرا، وهذا الجدول يوضح الفرق العملي بينها:

الوثيقةمن يكتبها عادةما تركز عليهمتى تحتاجها
وثيقة متطلبات مختصرة لصاحب العملصاحب المشروعالهدف والمستخدمون والميزات والأولوياتقبل طلب العروض من الشركات الخاصة
وثيقة متطلبات الأعمال (BRD)الإدارة أو محلل الأعمالالمشكلة التجارية والنتائج المطلوبةفي الشركات التي تحتاج موافقة داخلية قبل الصرف
وثيقة مواصفات المتطلبات (SRS)محلل أنظمة مع الشركة المنفذةسلوك النظام بالتفصيل والقيود التقنيةبعد اختيار المنفذ وقبل التطوير
كراسة الشروط والمواصفات الحكوميةالجهة الحكوميةنطاق العمل والمواصفات وشروط التعاقد والتقييمعند طرح منافسة على منصة اعتماد

في القطاع الحكومي السعودي تنشر وزارة المالية نموذج كراسة الشروط والمواصفات (تقنية المعلومات)، وتطرح الجهات منافساتها على منصة اعتماد (Etimad). النموذج الحكومي طويل لأنه يشمل الضمانات والغرامات والمحتوى المحلي، لكن قلب كراسة الشروط والمواصفات الحكومية قسمان يهمانك: «نطاق العمل المفصل» و«المواصفات». وهذان القسمان هما ما يحتاجه صاحب المشروع الخاص فعلا.

لماذا توفر وثيقة المتطلبات المال والوقت؟

لأنها تجعل كل الشركات تسعر الشيء نفسه. بدون وثيقة، تفهم كل شركة فكرتك بطريقتها، فتصلك عروض متباعدة لا تعرف سببها. ومع كراسة الشروط والمواصفات تصبح المقارنة عادلة، ويقل الخلاف بعد التوقيع حول ما كان «مشمولا» وما لم يكن. والنتيجة عمل أقل يعاد، وقرار أسرع.

عند تخطيط أي مشروع نسأل دائما ثلاثة أسئلة قبل أي حديث عن التقنية: من سيستخدم النظام يوميا؟ ما القرار أو العمل الذي سيصبح أسهل بعده؟ وكيف ستعرف أنه نجح؟ الإجابة المكتوبة عن هذه الأسئلة توفر أسابيع من الاجتماعات المتكررة.

  • عروض قابلة للمقارنة: الشركات تجيب عن نفس البنود، فترى الفرق الحقيقي بينها.
  • نطاق لا يتضخم: كل إضافة لاحقة تظهر كتغيير واضح، لا كمفاجأة في الفاتورة.
  • إعادة عمل أقل: أغلب الإعادة سببها متطلب لم يكتب أو كتب بغموض.
  • تسليم يمكن الحكم عليه: معايير القبول تحدد متى يعتبر الجزء منتهيا.
  • حماية لك: الوثيقة تصبح ملحقا بالعقد، فتحفظ حقك في ما اتفق عليه.

ماذا تكتب في كراسة الشروط والمواصفات؟ الأقسام بالترتيب

تتكون الوثيقة الجيدة من تسعة أقسام: نبذة وهدف، ومستخدمون وأدوار، وميزات مكتوبة كقصص مستخدم، وأولويات، وتكاملات، ومحتوى ولغات، ومتطلبات غير وظيفية، وملكية وصيانة، ثم معايير قبول. لا يشترط أن تكون طويلة؛ صفحات قليلة واضحة أفضل من ملف ضخم لا يقرؤه أحد.

قائمة تحقق بأقسام كراسة الشروط والمواصفات لمشروع برمجي
قائمة تحقق سريعة: إن غاب قسم منها فتوقع سؤالا أو مفاجأة لاحقا.

1. نبذة عن المشروع وهدفه

اكتب في فقرة واحدة ما المشكلة الحالية، ومن يعاني منها، وما النتيجة التي تريدها. مثال: «نستقبل الحجوزات عبر الهاتف والواتساب، ونخسر مواعيد بسبب التداخل. نريد نظام حجز يرى فيه الجميع الجدول نفسه».

أضف مقياسا للنجاح يمكن ملاحظته، مثل اختفاء الحجوزات المتداخلة، أو قدرة المدير على رؤية تقرير يومي دون أن يطلبه من أحد.

2. المستخدمون والأدوار والصلاحيات

اذكر كل فئة ستدخل النظام وما يحق لها: العميل، والموظف، والمشرف، والمدير. هذا القسم يحدد حجم المشروع أكثر مما يتوقع كثيرون، لأن كل دور يعني شاشات وصلاحيات مختلفة.

3. الميزات مكتوبة كقصص مستخدم

قصة المستخدم (User Story) جملة قصيرة بصيغة: «بصفتي [دور]، أريد [فعل]، حتى [فائدة]». مثال: «بصفتي عميلا، أريد إلغاء موعدي من الجوال، حتى لا أضطر للاتصال». هذه الصيغة تجبرك على ذكر السبب، والسبب هو ما يساعد المنفذ على اقتراح حل أبسط.

4. الأولويات بطريقة MoSCoW

صنف كل ميزة في واحدة من أربع فئات وفق طريقة MoSCoW كما يشرحها اتحاد الأعمال الرشيقة (Agile Business Consortium):

  • ضروري (Must): بدونه يفشل المشروع.
  • مهم (Should): مهم، لكن يوجد بديل مؤقت.
  • مرغوب (Could): له قيمة، لكنه ليس لازما.
  • ليس هذه المرة (Won't): مستبعد عمدا من هذه المرحلة.

هذا التصنيف هو أهم ما يساعد الشركة على اقتراح إصدار أول معقول، بدل تسعير كل الأحلام دفعة واحدة.

5. التكاملات مع الأنظمة الأخرى

اذكر كل نظام يجب أن يتصل به المشروع: بوابة الدفع، أو نظام المحاسبة، أو الفوترة الإلكترونية، أو الرسائل النصية، أو نظام قائم لديك. وحدد هل لدى الطرف الآخر واجهة برمجية (API) موثقة، لأن غيابها قد يغير طريقة التنفيذ كلها.

6. المحتوى واللغات

من سيكتب النصوص ويوفر الصور؟ هل الموقع بالعربية فقط أم بالعربية والإنجليزية؟ وهل تحتاج لوحة تحكم تعدل منها المحتوى بنفسك؟ هذه أسئلة تبدو صغيرة، لكنها تؤخر الإطلاق كثيرا إذا تركت للنهاية.

7. المتطلبات غير الوظيفية

هي الشروط التي تصف جودة النظام لا ميزاته، وتهمل غالبا رغم أنها تصنع الفرق في التجربة:

  • الأداء: عدد المستخدمين المتوقع في الوقت نفسه، وسرعة فتح الصفحات على شبكة الجوال.
  • الأمان: نوع البيانات التي ستحفظ، ومن يطلع عليها، والتحقق بخطوتين للوحة التحكم، والنسخ الاحتياطي.
  • العربية واتجاه الكتابة من اليمين لليسار (RTL): اطلب صراحة أن تكون الواجهة مصممة للعربية أصلا، لا مترجمة من قالب إنجليزي، وأن تعمل الأرقام والتواريخ والبحث بالعربية بشكل صحيح.
  • الاستضافة: أين تستضاف البيانات، وهل لديك اشتراط بأن تكون داخل المملكة، ومن يدفع ويتابع الخادم.

8. الملكية والصيانة

اكتب بوضوح أن الكود المصدري والحسابات والنطاقات تسجل باسمك وتسلم لك. ثم حدد ما تتوقعه بعد الإطلاق: مدة الدعم، ومن يصلح الأعطال، وكيف تطلب التعديلات الجديدة.

9. معايير القبول

معيار القبول جملة يمكن اختبارها بنعم أو لا. مثال: «عند إلغاء العميل موعده يختفي من الجدول، ويصل إشعار للموظف المختص». بدون هذه المعايير يصبح السؤال «هل انتهى العمل؟» مسألة رأي.

كيف تكتب متطلبات المشروع البرمجي خطوة بخطوة؟

ابدأ من المشكلة لا من الشاشات: اكتب الهدف، ثم اسأل الموظفين الذين سيستخدمون النظام، ثم حول كل احتياج إلى قصة مستخدم، ثم رتبها بالأولوية، ثم أضف الشروط غير الوظيفية ومعايير القبول، وأخيرا راجع الوثيقة مع شخص لم يشارك في كتابتها.

خطوات كتابة متطلبات المشروع البرمجي الست من الهدف إلى معايير القبول
ست خطوات تحول فكرتك إلى وثيقة متطلبات يمكن لأي شركة أن تسعرها بدقة.
  1. اكتب الهدف في جملتين. إن لم تستطع، فالفكرة تحتاج نقاشا قبل أي عرض سعر.
  2. اجمع الاحتياجات من أصحابها. اجلس مع من سيستخدم النظام فعلا؛ موظف الاستقبال يعرف عن الحجوزات أكثر من المدير.
  3. ارسم الرحلة الحالية. اكتب خطوات العمل كما تحدث اليوم، ثم علم المواضع التي يضيع فيها الوقت.
  4. حول الاحتياجات إلى قصص مستخدم. قصة لكل احتياج، دون ذكر حلول تقنية.
  5. رتب بالأولوية. صنف كل قصة بطريقة MoSCoW، وكن صارما في فئة «ضروري».
  6. أضف الشروط ومعايير القبول. الأداء والأمان والعربية والاستضافة والملكية، ثم معيار قبول لكل ميزة ضرورية.

كيف تعرف أن الوثيقة جاهزة للإرسال؟

اعرض كراسة الشروط والمواصفات على شخص لم يشارك في كتابتها، واطلب منه أن يشرح لك المشروع بكلماته. إذا وصف شيئا يختلف عما في ذهنك، فالوثيقة تحتاج توضيحا قبل أن تصل إلى أي شركة.

واختبرها بثلاثة أسئلة سريعة: هل لكل ميزة ضرورية معيار قبول؟ هل ذكرت من يملك الكود والحسابات؟ وهل كتبت ما هو مستبعد في هذه المرحلة؟ إذا كانت الإجابات كلها نعم، فوثيقتك أفضل من أغلب ما تستقبله الشركات.

نصيحة من الميدان: أرفق صورا أو رسومات يدوية لما تتخيله، حتى لو كانت على ورقة. ولا تتردد في إرفاق روابط مواقع أو تطبيقات تعجبك مع ذكر ما يعجبك فيها تحديدا.

نموذج جاهز لوثيقة متطلبات المشروع تنسخه وتملؤه

انسخ الجدول التالي إلى ملف نصي، واملأ العمود الثالث بلغتك البسيطة. إذا لم تعرف إجابة بند ما، اكتب «غير محدد» ولا تحذفه؛ فالبند المفتوح سؤال مشروع تطرحه الشركة عليك، والبند المحذوف مفاجأة لاحقة. وحين تنتهي، تكون قد كتبت النسخة الأولى من وثيقتك.

القسمالسؤال الذي تجيب عنهإجابتك
اسم المشروع ونوعهموقع، تطبيق جوال، نظام داخلي، أو مزيج منها؟
المشكلة والهدفما المشكلة اليوم، وما النتيجة المطلوبة؟
مقياس النجاحكيف ستعرف أن المشروع نجح؟
المستخدمون والأدوارمن يدخل النظام، وماذا يحق لكل دور؟
الميزات الضروريةقصص المستخدم التي لا ينطلق المشروع بدونها
الميزات المهمة والمرغوبةما يمكن تأجيله إلى مرحلة لاحقة
المستبعد هذه المرةما لن يبنى في هذه المرحلة
التكاملاتالدفع، المحاسبة، الفوترة، الرسائل، أنظمة قائمة
المحتوى واللغاتعربي فقط أم ثنائي اللغة؟ ومن يوفر المحتوى؟
الأداءعدد المستخدمين المتوقع في وقت واحد
الأمان والبياناتما البيانات الحساسة، ومن يصل إليها؟
الاستضافةأين تستضاف البيانات، ومن يدير الخادم؟
الملكيةالكود والحسابات والنطاقات باسم من؟
الدعم والصيانةماذا تتوقع بعد الإطلاق؟
معايير القبولمتى تعتبر كل ميزة ضرورية منتهية؟
الميزانية والموعدنطاق تقريبي للميزانية، وموعد مرتبط بحدث تجاري إن وجد

ذكر نطاق تقريبي للميزانية ليس ضعفا في التفاوض. هو يساعد الشركة الجادة على اقتراح ما يناسبك فعلا، بدل عرض مثالي لا تستطيع تنفيذه.

ما أخطاء كتابة كراسة الشروط والمواصفات الشائعة؟

أكثر الأخطاء شيوعا: كتابة الحلول بدل المشكلات، وجمل غامضة لا يمكن اختبارها، وغياب الأولويات، ونسيان الشروط غير الوظيفية والملكية. كل خطأ منها يظهر لاحقا في صورة عروض غير قابلة للمقارنة، أو تكلفة إضافية، أو خلاف بعد التسليم حول ما كان مطلوبا.

  • كتابة الحل بدل المشكلة: «نريد تطبيقا مثل التطبيق الفلاني» لا يشرح ما تحتاجه أنت. اكتب ما يجب أن يحققه.
  • كلمات لا تقاس: «سهل» و«سريع» و«حديث» تعني شيئا مختلفا لكل قارئ. استبدلها بوصف يمكن اختباره.
  • كل شيء ضروري: إذا صنفت كل الميزات في فئة «ضروري»، فأنت لم ترتب شيئا.
  • نسيان الأدوار: شاشة واحدة لمدير وموظف وعميل غالبا تعني ثلاث شاشات.
  • إهمال العربية: افتراض أن أي قالب سيعمل من اليمين لليسار دون مشكلات.
  • السكوت عن الملكية: عدم ذكر من يملك الكود والنطاق والحسابات حتى تقع المشكلة.
  • وثيقة لا تتحدث: تغير قرارك ولا تعدل الوثيقة، فتعمل الشركة على نسخة قديمة.

كيف ترسل الوثيقة للشركات وتقارن العروض؟

أرسل الوثيقة نفسها لعدد محدود من الشركات، واطلب منها أن تجيب بندا بندا، وحدد موعدا واحدا لاستلام الأسئلة وموعدا لاستلام العروض. ثم قارن ما يغطيه كل عرض فعلا، لا الرقم الأخير فقط، واسأل عن كل افتراض لم تكتبه أنت في الوثيقة.

  1. اختر قائمة قصيرة. ثلاث إلى خمس شركات تكفي للمقارنة. يساعدك دليل اختيار شركة البرمجة المناسبة في السعودية في تكوين هذه القائمة.
  2. أرسل كراسة الشروط والمواصفات نفسها للجميع. وأي إجابة عن سؤال من شركة شاركها مع البقية، كما تفعل الجهات الحكومية في المنافسات.
  3. اطلب صيغة رد موحدة. لكل بند: هل هو مشمول، وكيف سينفذ، وما الافتراضات.
  4. قارن الافتراضات قبل الأسعار. العرض الأرخص كثيرا ما يكون قد افترض نطاقا أصغر.
  5. اسأل عن طريقة التسليم. هل ترى عملا يعمل على مراحل، أم تنتظر حتى النهاية؟

ماذا ترفق مع الوثيقة عند الإرسال؟

أضف في رسالتك موعد استلام الأسئلة، وموعد استلام العروض، والصيغة التي تريد بها الرد. واطلب من كل شركة أن تذكر ما لم يشمله عرضها صراحة، وأن توضح من سيعمل على المشروع من فريقها.

وإذا كانت في كراسة الشروط والمواصفات معلومات حساسة عن عملك، فاطلب توقيع اتفاقية سرية قبل إرسال النسخة الكاملة، واكتف بنسخة مختصرة في المرحلة الأولى.

مقارنة بين عرض واضح وعرض غامض عند الرد على وثيقة متطلبات المشروع
قارن ما يغطيه كل عرض وافتراضاته قبل أن تنظر إلى السعر.

علامة الشركة الجيدة أنها تعود إليك بأسئلة. الشركة التي ترسل رقما بعد ساعة من استلام وثيقة متطلبات المشروع دون أي سؤال إما لم تقرأها، وإما ستكتشف التفاصيل على حسابك لاحقا. وإذا أردت فهما أوسع لرحلة المشروع كاملة، فاقرأ دليل إنشاء مشروع إلكتروني في السعودية من الفكرة إلى الإطلاق.

ماذا تفعل إذا كانت لديك فكرة فقط؟

لا تحتاج وثيقة كاملة لتبدأ. اكتب الهدف والمستخدمين وثلاث ميزات ترى أنها ضرورية، ثم اطلب جلسة اكتشاف مع شركة برمجة. في هذه الجلسة تتحول الفكرة إلى نطاق مكتوب، وتظهر الأسئلة التي لم تخطر ببالك قبل أن تتحول إلى تكلفة أو تأخير.

جلسة الاكتشاف حوار منظم يسأل فيه فريق التنفيذ عن عملك وعملائك وطريقة عملك اليوم، ثم يقترح أبسط نسخة تحقق الهدف. والمخرج الأهم منها مسودة كراسة الشروط والمواصفات يمكنك أن تعرضها على أي شركة أخرى إن أردت.

في سيرا الشموخ نقدم جلسة فهم مجانية لهذا الغرض، ويصلك بعدها عرض مكتوب خلال 24 ساعة يوضح ما فهمناه وما نقترحه. وخلال التنفيذ يصلك تسليم يعمل كل 14 يوما، ويليه بعد الإطلاق 90 يوما من الدعم المجاني، والكود والحسابات والنطاقات ملك لك.

إذا كان مشروعك نظاما داخليا لإدارة عملياتك، فصفحة برمجة الأنظمة الخاصة للشركات تشرح ما يشمله هذا النوع من المشاريع. وإن كان موقعا تعريفيا أو خدميا، فابدأ من صفحة تصميم المواقع. ولمشاريع الأنظمة الكبيرة، يفيدك مقال ما الذي يحدد تكلفة تنفيذ نظام ERP في السعودية لفهم أثر النطاق على العرض.

الخلاصة

كراسة الشروط والمواصفات الجيدة لا تحتاج خبرة تقنية، بل وضوحا: هدف مكتوب، ومستخدمون محددون، وميزات مرتبة بالأولوية، وشروط للأمان والعربية والاستضافة والملكية، ومعايير قبول تحسم الخلاف. اكتبها مرة، وأرسلها للجميع بالصيغة نفسها، وقارن الافتراضات والبنود المشمولة قبل الأسعار.

وإن كانت لديك فكرة فقط ولا تعرف من أين تبدأ، احجز جلسة فهم مجانية ونساعدك على تحويلها إلى وثيقة متطلبات واضحة، ثم يصلك عرضنا المكتوب لتقارنه بحرية مع غيره.

Frequently asked questions

ما الفرق بين كراسة الشروط والمواصفات ووثيقة SRS؟

كراسة الشروط والمواصفات في المشاريع الخاصة يكتبها صاحب العمل بلغته ليشرح الهدف والمستخدمين والميزات والشروط قبل طلب العروض. أما وثيقة مواصفات متطلبات البرمجيات (SRS) فأكثر تفصيلا وتقنية، ويكتبها عادة محلل أنظمة مع الشركة المنفذة بعد اختيارها، لتصف سلوك النظام بدقة قبل بدء التطوير.

هل أحتاج خبرة تقنية لكتابة متطلبات المشروع البرمجي؟

لا. المطلوب منك وصف المشكلة والنتيجة المطلوبة ومن سيستخدم النظام وما يجب أن يفعله، بلغتك اليومية. التفاصيل التقنية مثل لغة البرمجة وقاعدة البيانات مسؤولية الشركة المنفذة. الأهم أن تكون كل جملة واضحة ويمكن اختبارها، وأن ترتب الميزات حسب أولويتها، وأن تذكر شروط العربية والأمان والملكية صراحة.

كم صفحة يجب أن تكون وثيقة متطلبات المشروع؟

لا يوجد طول ثابت. لمشروع موقع أو تطبيق صغير تكفي صفحات قليلة تغطي الهدف والمستخدمين والميزات المرتبة بالأولوية والشروط غير الوظيفية ومعايير القبول. الوثيقة الواضحة القصيرة أفضل من ملف طويل لا يقرؤه أحد، والمهم ألا تحذف بندا لا تعرف إجابته بل تكتب أنه غير محدد.

هل أذكر الميزانية في كراسة الشروط والمواصفات؟

يفضل ذكر نطاق تقريبي للميزانية. فهو يساعد الشركة الجادة على اقتراح إصدار أول يناسب إمكاناتك بدل عرض مثالي لا تستطيع تنفيذه، ولا يضعف موقفك التفاوضي لأن المقارنة ستكون على البنود المشمولة والافتراضات، وليس على الرقم وحده. ويمكنك أن تطلب من كل شركة توضيح ما ستؤجله إن تجاوز النطاق الميزانية.

ماذا أفعل إذا كانت لدي فكرة فقط ولا أستطيع كتابة وثيقة كاملة؟

اكتب الهدف والمستخدمين وثلاث ميزات تراها ضرورية، ثم اطلب جلسة اكتشاف مع شركة برمجة. في الجلسة تتحول الفكرة إلى نطاق مكتوب وتظهر الأسئلة المهمة مبكرا. في سيرا الشموخ جلسة الفهم مجانية، ويصلك بعدها عرض مكتوب خلال 24 ساعة يمكنك مقارنته بحرية.

Your next step

Have a project in mind?

The Sira team is ready to turn your idea into a complete digital product.

Get started