وثيقة مواصفات النظام (SRS): العقد غير الرسمي بين الأعمال والتطوير

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

"هذا ليس ما طلبناه" هي الجملة الأشيع في مشاريع تطوير فشلت في التواصل، وسببها المباشر غالباً غياب وثيقة مرجعية واضحة كتب عليها الطرفان واتفقا. وثيقة مواصفات متطلبات النظام (Software/System Requirements Specification - SRS) هي هذا المرجع، وتوثيقها الجيد يقي من نزاعات مكلفة لاحقاً.

ما الذي يجب أن تحتويه وثيقة SRS جيدة

• نطاق النظام (Scope): ما الذي يفعله النظام، وبنفس الأهمية، ما الذي لا يفعله — تحديد النطاق يمنع "زحف النطاق" (Scope Creep) لاحقاً.
• المتطلبات الوظيفية: كل وظيفة موصوفة بدقة كافية ليفهمها المصمم والمطور دون تخمين.
• المتطلبات غير الوظيفية: الأداء، الأمان، قابلية التوسع، وعدد المستخدمين المستهدف.
• القيود (Constraints): ميزانية محددة، تقنيات إلزامية، مواعيد نهائية غير قابلة للتفاوض.
• معايير القبول (Acceptance Criteria): كيف يُحدَّد أن الوظيفة "تعمل بشكل صحيح" ومتى تُعتبر مكتملة رسمياً.

لماذا تحمي وثيقة واحدة الطرفين معاً

بالنسبة للعميل، الوثيقة تضمن أن النظام النهائي يطابق ما تم الاتفاق عليه، ولا يفاجَأ بوظائف ناقصة عند التسليم. بالنسبة لفريق التطوير، الوثيقة تحمي من طلبات إضافية غير مدفوعة تُقدَّم لاحقاً باسم "كان هذا مفهوماً ضمناً". أي طلب جديد بعد اعتماد الوثيقة يصبح تعديلاً رسمياً على النطاق، لا جزءاً بديهياً من الاتفاق الأصلي.

مستوى التفصيل المناسب

وثيقة مقتضبة جداً تترك مساحة للتفسيرات المتضاربة. وثيقة مفرطة التفصيل قد تستغرق وقتاً طويلاً لكتابتها ومراجعتها دون قيمة إضافية حقيقية، خصوصاً في مشاريع تعتمد منهجية مرنة (Agile). التوازن الصحيح: تفصيل كافٍ لكل وظيفة رئيسية بحيث يمكن اختبارها بوضوح لاحقاً مقابل الوثيقة نفسها.

SRS في المنهجيات المرنة

حتى في مشاريع Agile التي لا تعتمد وثيقة ضخمة واحدة، مبدأ SRS يبقى قائماً على مستوى أصغر: كل "قصة مستخدم" (User Story) يجب أن تحمل معايير قبول واضحة قبل البدء بتنفيذها. الفكرة الجوهرية واحدة: لا تنفيذ دون اتفاق مكتوب وواضح على ماذا يعني "الانتهاء".

الخلاصة

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