وثيقة متطلبات البرمجيات (SRS) هي العقد بين ما تحتاجه المنشأة وما يسلّمه المطورون أو المورّدون. والوثيقة الجيدة تمنع معظم الخلافات وطلبات التغيير قبل أن تبدأ.
مخطط عملي لوثيقة SRS
- الغرض والأهداف والنطاق (ما يدخل فيه وما يخرج عنه)
- المستخدمون والأدوار
- سير الإجراءات الحالي والمستقبلي
- المتطلبات الوظيفية مرقّمة ومرتّبة حسب الأولوية
- قواعد العمل والاستثناءات
- التقارير ولوحات المؤشرات
- التكامل وتبادل البيانات مع الأنظمة الأخرى
- احتياجات ترحيل البيانات
- المتطلبات غير الوظيفية: السرعة، والتوافر، والأمان، واللغات (مثل دعم العربية والإنجليزية)
- معايير القبول لكل متطلب رئيسي
اكتب متطلبات قابلة للاختبار
يجب أن يكون كل متطلب واضحًا ومفردًا وقابلًا للاختبار. عبارة «يجب أن يكون النظام سهل الاستخدام» لا يمكن اختبارها، أما «يستطيع الكاشير إتمام عملية بيع من ثلاثة أصناف في أقل من 30 ثانية» فيمكن اختبارها.
وثّق الاستثناءات في متطلبات النظام
المسارات المعتادة سهلة، أما الاستثناءات فهي التي تكلّف المال. اسأل في كل إجراء: ماذا عن المرتجعات، والإلغاءات، والكميات الجزئية، والموافقات التي تتجاوز حدًا معينًا، والفروع المختلفة؟
رتّب الأولويات بطريقة MoSCoW
صنّف كل متطلب إلى: ضروري (Must)، أو مهم (Should)، أو مرغوب (Could)، أو مؤجل هذه المرة (Won't). هذا يركّز الميزانية ويجعل المقارنة بين المورّدين عادلة.
احصل على الاعتماد الصحيح للوثيقة
يجب أن يعتمد مسؤول كل إدارة الأقسام التي تخصّه. فالاعتماد يحوّل وثيقة SRS إلى مرجع أساسي للاختبار وضبط التغييرات.
الخلاصة
إذا لم يكن المتطلب قابلًا للاختبار فأعد كتابته. وإذا لم يُكتب الاستثناء فافترض أنه لن يُنفَّذ.
