وثيقة متطلبات النظام (SRS): ما هي، وماذا تتضمن، ونموذج بالعربي لمشروعك البرمجي

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

ما وثيقة متطلبات النظام (SRS)، وما الفرق بينها وبين وثيقتي BRD وPRD؟

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

يصف المعيار الدولي لهندسة المتطلبات ISO/IEC/IEEE 29148:2018 أربع وثائق: مواصفات متطلبات الأعمال (BRS)، ومتطلبات أصحاب المصلحة (StRS)، ومتطلبات النظام (SyRS)، ومتطلبات البرمجيات (SRS). ولا وجود لـ«PRD» بينها؛ فهي عُرف في إدارة المنتجات تصوغه كل شركة على طريقتها. في الشركات الناشئة أدمج عادةً الـBRD والـPRD في موجز منتج قصير، وأضع الجهد الحقيقي في الـSRS، فهي التي تُسعَّر وتُبنى وتُختبر.

ملاحظة على التسمية: الشائع عربيًا أن تُسمّى الـSRS «وثيقة متطلبات النظام»، بينما يفرّق المعيار بين متطلبات النظام ككل (SyRS) ومتطلبات البرمجيات (SRS). وفي مشاريع التطبيقات والمنصات البرمجية يتقارب المستويان، لذلك أستخدم التسمية الشائعة في هذا الدليل.

ماذا تحتاج شركة البرمجة في الوثيقة لتعطيك سعرًا حقيقيًا؟

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

لهذا لا جواب دقيقًا عن سؤال «كم تكلفة عمل تطبيق؟» قبل وجود هذه الوثيقة. ومن الفجوات المعتادة بين العروض: عرض يحتسب لوحة تحكم إدارية وآخر لا يحتسبها؛ وعرض يفترض العربية والإنجليزية وآخر الإنجليزية وحدها. قبل أن ترسلها، تأكد أنها تجيب عن كل بند مما يلي:

• المنصات وترتيبها: iOS وAndroid والويب ولوحة التحكم، وأيها يُطلق أولًا.
• الأدوار والصلاحيات: مصفوفة توضح من يرى ماذا ومن يفعل ماذا، من العميل ومقدّم الخدمة إلى العمليات والمالية والدعم.
• الميزات: متطلبات مرقّمة، كلٌّ منها مصنّف: ضروري، أو مرغوب، أو لاحقًا.
• التكاملات: بوابة الدفع، والرسائل النصية ورمز التحقق لمرة واحدة (OTP)، والخرائط، والمحاسبة أو نظام تخطيط موارد المؤسسة (ERP)، والفوترة الإلكترونية، ومن يملك كل حساب.
• البيانات: ما الذي ستخزّنه، وتقديرك أنت لأحجام السنة الأولى، وما سيُرحَّل من نظام قديم.
• مستهدفات الجودة: الأداء، ونسبة التشغيل دون انقطاع، والأمان، واللغات، ولكلٍّ منها رقم.
• خارج النطاق: ما لن يفعله هذا الإصدار عن قصد.
• ما تقدّمه أنت: التصاميم، والمحتوى، وملفات الهوية، وحسابات المطوّر لدى Apple وGoogle، وحساب التاجر.
• القبول: كيف يُتحقَّق من كل متطلب، ومن يوقّع على الاستلام.

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

ما أقسام وثيقة SRS؟ نموذج بالعربي تستطيع نسخه

استخدم المخطط التالي؛ بنيتُه على بند محتوى الـSRS في المعيار ISO/IEC/IEEE 29148 واختصرته ليناسب شركة ناشئة. وحافظ على الترقيم، حتى تستطيع الإشارة إلى كل متطلب برقمه في العقد والمهام وحالات الاختبار.

1. الغرض والنطاق: المشكلة، وهذا الإصدار، وقائمة صريحة بما هو خارج النطاق.
2. منظور المنتج: التطبيقات، والجانب الإداري، وكل نظام خارجي يتعامل معه المنتج.
3. المستخدمون والأدوار: من يستخدمه وفي أي ظرف (مندوب التوصيل الذي يمسك جواله تحت الشمس ليس محاسبًا على مكتبه)، ومصفوفة الصلاحيات.
4. الافتراضات والاعتماديات والقيود: مثل نظام تخطيط موارد قائم يجب أن يبقى، أو موقع استضافة قررته، أو لغات الإطلاق.
5. المتطلبات الوظيفية: مجمّعة حسب الوحدة ومرقّمة (FR-BOOK-01 وFR-PAY-03)، ولكلٍّ منها أولوية ومعايير قبول.
6. الواجهات الخارجية: الدفع، والرسائل، والخرائط، والمحاسبة، والمنصات الحكومية؛ ولكلٍّ منها مالك الحساب وبيئة الاختبار.
7. متطلبات البيانات: الكيانات الرئيسية، وجرد البيانات الشخصية، وقواعد الاحتفاظ والحذف، والتقارير.
8. المتطلبات غير الوظيفية: الأداء، والتشغيل والاستعادة بعد الأعطال، والأمان، وسهولة الاستخدام وإمكانية الوصول، والتعريب؛ ولكلٍّ منها مستهدف وطريقة قياس.
9. الامتثال: حماية البيانات الشخصية، والفوترة الإلكترونية، وأي اشتراطات قطاعية، مكتوبة على هيئة متطلبات، لا ملاحظات جانبية.
10. التحقق والقبول: منهجية الاختبار، والبيئات، ومن يُجري اختبار قبول المستخدم، وتعريف «المنجَز».
11. الملاحق: مسرد مصطلحات ثنائي اللغة، وروابط النماذج الأولية للشاشات، والأسئلة المفتوحة مع مالك وموعد لكل سؤال.

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

كيف تكتب معايير القبول بحيث لا تحتمل الجدل؟

اكتب كل معيار فحصًا نتيجته «نجح» أو «فشل»: بافتراض حالة بداية معيّنة، عندما يقع حدث ما، تظهر نتيجة محددة يمكن ملاحظتها (Given/When/Then). وغطِّ مسارات الفشل مع مسار النجاح، وضع رقمًا في كل موضع كنت ستكتب فيه «سريع».

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

FR-PAY-03 (ضروري): يدفع العميل عربون الحجز ببطاقة مدى أو عبر Apple Pay قبل تأكيد الحجز.

1. بافتراض وجود عميل لديه حجز غير مدفوع، عندما يدفع ببطاقة مدى وينجح تحقق البنك عبر بروتوكول الحماية ثلاثي الأبعاد (3D Secure)، فإن الحجز يصبح «مؤكدًا»، ويصل العميلَ تأكيد بالعربية عبر الإشعار والرسالة النصية خلال دقيقة واحدة.
2. بافتراض أن تحقق البنك فشل أو أن العميل تخلّى عنه، عندما يعود إلى التطبيق، فإن الحجز يبقى «بانتظار الدفع»، ويُحجز له الموعد عشر دقائق، وتظهر رسالة عربية تعرض إعادة المحاولة.
3. بافتراض أن بوابة الدفع أكدت العملية لكن التطبيق فقد الاتصال قبل وصول ردّها، عندما تعمل مهمة المطابقة، فإن الحجز يُؤكَّد، ولا يُخصم المبلغ من العميل مرتين أبدًا.
4. بافتراض أن الصالون ألغى حجزًا مؤكدًا، عندما يُحفظ الإلغاء، فإن النظام يبدأ استرداد المبلغ كاملًا إلى وسيلة الدفع الأصلية، ويظهر الحدث في سجل التدقيق بلوحة التحكم.

تسمّي هذه المعايير الحالات والتوقيت واللغة، وتحوّل ثلاثة خلافات مكلفة (فشل تحقق البنك، وضياع ردّ البوابة، والاسترداد) إلى بنود يضع المختبِر أمامها علامة. قيمتا الدقيقة والدقائق العشر افتراضيتان؛ المهم أن يكون صاحب العمل هو من اختار الرقم.

ما المتطلبات غير الوظيفية التي تهم التطبيقات في السعودية والخليج؟

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

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

أي معيار تتبعه الوثيقة: IEEE 830 أم ISO/IEC/IEEE 29148؟

المعيار ISO/IEC/IEEE 29148. فقد حلّ إصداره الأول 29148:2011 محل الممارسة الموصى بها IEEE 830-1998، ثم حلّ الإصدار الثاني 29148:2018 محل إصدار 2011. وقد أكدت المنظمة الدولية للتوحيد القياسي (ISO) إصدار 2018 في 2024، ثم قررت تنقيحه في 2026، ويُتوقع أن يحل محله خلال الأشهر المقبلة إصدار جديد هو الآن مسودة (ISO/IEC/IEEE DIS 29148).

وحتى إن لم تعتمده رسميًا، فهو يمنحك:

• مفردات تفصل بين متطلبات الأعمال وأصحاب المصلحة والنظام والبرمجيات، فيتوقف الجدل حول معنى «المتطلبات».
• خصائص المتطلب الفردي الجيد ومجموعة المتطلبات الجيدة، ومعايير للغة صياغة المتطلبات.
• مخططًا نموذجيًا لوثيقة SRS، والمحتوى المطلوب في كل قسم.

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

ما الأخطاء التي تُفسد وثيقة المتطلبات؟

أكثر الأخطاء التي أراها ثلاثة: تفاصيل تصميم في موضع وصف السلوك، واختيارات تقنية بلا أسباب، وغياب قائمة «خارج النطاق». وكلٌّ منها ينتهي إما قيدًا لا تستطيع الشركة تسعيره، وإما فجوةً ستسعّرها مرتفعة.

• تصميم على مستوى البكسل. الخطوط والألوان والمسافات مكانها ملفات التصميم. الوثيقة تصف السلوك وتشير إلى الشاشات برموزها، وإلا صار كل تعديل في التصميم طلب تغيير.
• تقنية بلا أسباب. عبارة «يجب استخدام الخدمات المصغّرة (Microservices)» أو «يجب البناء بإطار Flutter» تلغي حكم الشركة المهني وقدرتك على مقارنة العروض. وإن وُجد قيد حقيقي، كتقنيات فريقك الحالي أو منطقة سحابية مشروطة، فاكتبه مع سببه.
• لا شيء خارج النطاق. دون عبارة «لن يتضمن هذا الإصدار…» يتمدد النطاق مع كل افتراض. اكتبها صراحة: لا تطبيق ويب للعملاء في الإصدار الأول، ولا برنامج ولاء، ولوحة تحكم بالإنجليزية فقط.
• كل شيء ضروري. إن لم يكن تأجيل أي شيء ممكنًا، فلن تستطيع الشركة أن تعرض عليك إصدارًا أول أصغر.
• نسيان الجانب الإداري. الاسترداد والنزاعات ومراجعة المحتوى والتقارير ميزات، وفريق العمليات يحتاجها من اليوم الأول.

كيف تتغير وثائق المتطلبات مع أدوات البرمجة بالذكاء الاصطناعي في 2026؟

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

مثال واضح: مجموعة أدوات Spec Kit مفتوحة المصدر التي أعلنتها GitHub في سبتمبر 2025. يمر فيها العمل بأربع مراحل: التحديد ثم التخطيط ثم المهام ثم التنفيذ (Specify وPlan وTasks وImplement)، وتعمل مع وكلاء برمجة مثل GitHub Copilot وClaude Code وGemini CLI، ويقول إعلان GitHub صراحة إن المواصفات تصبح «مصدر الحقيقة المشترك». ما أغيّره عمليًا:

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

ولا شيء من ذلك يلغي الحاجة إلى شخص خبير يحسم المفاضلات ويتحمّل مسؤوليتها. الوكيل يكتب الشيفرة التي تصفها المواصفات، لكنه لا يستطيع أن يخبرك هل تصف المواصفات ما يحتاجه عملك فعلًا.