وثيقة متطلبات النظام SRS (Software Requirements Specification) تصف ما يجب أن يفعله البرنامج وكيف يجب أن يعمل، بتفصيل يكفي المطورين للتنفيذ والمختبرين للفحص. تضم المتطلبات الوظيفية مثل تسجيل الدخول، وغير الوظيفية مثل السرعة والأمان. كتابتها قبل طلب العروض تجعل الأسعار قابلة للمقارنة وتقلل تجاوز الميزانية.
ما هي وثيقة متطلبات النظام SRS؟
وثيقة SRS هي المرجع المكتوب المتفق عليه بين صاحب المشروع وشركة البرمجة لكل ما سيُبنى. أي ميزة غير مذكورة فيها تُعامل كطلب إضافي خارج النطاق.
توجد معايير دولية لهيكلة الوثيقة. المعيار IEEE 830 هو المرجع التقليدي، وحلّ محله المعيار ISO/IEC/IEEE 29148 الذي يغطي هندسة المتطلبات على نطاق أوسع. المشروع الصغير لا يحتاج إلى تطبيق المعيار حرفياً، واتباع هيكله يمنع نسيان أقسام أساسية.
ما الفرق بين BRD وPRD وSRS؟
الوثائق الثلاث تتدرج من سبب المشروع إلى تفاصيل تنفيذه. وثيقة BRD تجيب عن سبب بناء المشروع وفائدته للعمل، ووثيقة PRD تحدد الميزات التي يحتاجها المنتج، ووثيقة SRS تصف عمل النظام بالتفصيل للمطورين.
| البند | وثيقة متطلبات الأعمال BRD | وثيقة متطلبات المنتج PRD | وثيقة متطلبات النظام SRS |
|---|---|---|---|
| السؤال الأساسي | لماذا نبني المشروع؟ | ماذا يقدم المنتج للمستخدم؟ | كيف يعمل النظام بالتفصيل؟ |
| من يكتبها | الإدارة أو محلل الأعمال | مدير المنتج | محلل الأنظمة مع الفريق التقني |
| القارئ الأساسي | الإدارة والممولون | فريق المنتج والتصميم | المطورون والمختبرون |
| المحتوى | الأهداف، المشكلة، العائد المتوقع، النطاق العام | الميزات، رحلات المستخدم، الأولويات | متطلبات وظيفية وغير وظيفية، واجهات، قيود |
| مستوى التفصيل | عام | متوسط | تفصيلي قابل للاختبار |
في المشاريع الصغيرة والمتوسطة يدمج الفريق الوثائق الثلاث عادة في وثيقة SRS واحدة تبدأ بقسم أهداف العمل.
ماذا تتضمن وثيقة متطلبات النظام SRS؟
الوثيقة الجيدة تتبع هيكلاً ثابتاً يبدأ بالسياق وينتهي بالتفاصيل القابلة للاختبار. هذا هيكل مختصر مبني على المعيار ISO/IEC/IEEE 29148:
- المقدمة: الغرض من النظام، النطاق، التعريفات والمختصرات.
- الوصف العام: المستخدمون وأدوارهم، بيئة التشغيل (ويب، Android، iOS)، القيود والافتراضات.
- المتطلبات الوظيفية: كل وظيفة برقم تعريفي مثل FR-01، مع وصفها وشروط قبولها.
- المتطلبات غير الوظيفية: الأداء، الأمان، التوافر، سهولة الاستخدام، دعم العربية واتجاه RTL.
- الواجهات الخارجية: بوابات الدفع، الرسائل النصية، الخرائط، الأنظمة المحاسبية.
- البيانات: الكيانات الأساسية مثل المستخدم والطلب والفاتورة، ومدة الاحتفاظ بكل منها.
- المتطلبات التنظيمية: حماية البيانات الشخصية، الفوترة الإلكترونية.
- الملاحق: نماذج الشاشات، مخططات سير العمل.
ما الفرق بين المتطلبات الوظيفية وغير الوظيفية؟
المتطلب الوظيفي يصف ما يفعله النظام، والمتطلب غير الوظيفي يصف جودة أدائه لهذا الفعل. كلاهما يجب أن يكون قابلاً للقياس والاختبار.
| النوع | صياغة ضعيفة | صياغة قابلة للاختبار |
|---|---|---|
| وظيفي | النظام يرسل إشعارات | يرسل النظام رسالة نصية للعميل قبل موعده بـ 24 ساعة |
| وظيفي | المدير يرى التقارير | يصدّر المدير تقرير الحجوزات الشهري بصيغة Excel |
| غير وظيفي | الموقع سريع | تظهر الصفحة الرئيسية خلال 2.5 ثانية أو أقل على شبكة 4G |
| غير وظيفي | النظام آمن | يخزن النظام كلمات المرور مشفرة، ويقفل الحساب بعد 5 محاولات دخول فاشلة |
كيف تكتب قصص المستخدم وترتب الأولويات بطريقة MoSCoW؟
قصة المستخدم جملة قصيرة تصف حاجة مستخدم محدد بصيغة: «بصفتي [دور] أريد [هدف] حتى [فائدة]». مثال: «بصفتي مريضاً أريد إلغاء موعدي من التطبيق حتى لا أضطر إلى الاتصال بالعيادة».
طريقة MoSCoW ترتب كل متطلب في واحدة من أربع فئات:
- Must (ضروري): المنتج لا يعمل بدونه، ويدخل في الإصدار الأول.
- Should (مهم): قيمته عالية، ويحتمل التأجيل لفترة قصيرة.
- Could (مرغوب): يُضاف إن سمح الوقت والميزانية.
- Won't (مؤجل): خارج هذا الإصدار، وتذكره الوثيقة صراحة لمنع الخلاف لاحقاً.
هذا الترتيب يحدد نطاق النسخة الأولى MVP ويخفض تكلفتها، لأن متطلبات فئة Must وحدها تدخل في التنفيذ الأول.
كيف تبدو متطلبات تطبيق حجز مواعيد مكتوبة بصيغة SRS؟
المثال التالي يوضح شكل المتطلبات المرقمة لتطبيق حجز مواعيد في عيادة، مع أولوية MoSCoW لكل متطلب:
- FR-01 (Must): يسجّل المريض حساباً برقم الجوال ورمز تحقق يصله برسالة نصية.
- FR-02 (Must): يعرض التطبيق المواعيد المتاحة لكل طبيب خلال 30 يوماً قادمة.
- FR-03 (Must): يحجز المريض موعداً ويتلقى تأكيداً فورياً داخل التطبيق.
- FR-04 (Should): يرسل النظام تذكيراً قبل الموعد بـ 24 ساعة.
- FR-05 (Should): يلغي المريض موعده حتى 6 ساعات قبل وقته.
- FR-06 (Could): يدفع المريض رسوم الكشف مسبقاً داخل التطبيق.
- NFR-01: يدعم التطبيق العربية من اليمين إلى اليسار والإنجليزية.
- NFR-02: تظهر شاشة المواعيد خلال ثانيتين أو أقل.
- NFR-03: يخزن النظام بيانات المرضى مشفرة، ويلتزم بقانون حماية البيانات الشخصية في بلد التشغيل.
- Won't: الربط مع شركات التأمين مؤجل إلى الإصدار الثاني.
لمعرفة الميزات الكاملة لأنظمة العيادات، راجع دليل برنامج إدارة عيادات.
كيف تجعل وثيقة SRS عروض الأسعار قابلة للمقارنة؟
عندما ترسل الوثيقة نفسها إلى كل شركة، تسعّر الشركات النطاق نفسه، فيظهر الفرق في السعر والمدة والجودة. بدون وثيقة، تفترض كل شركة نطاقاً مختلفاً، فتقارن أرقاماً تصف مشاريع مختلفة.
الوثيقة تقلل تجاوز الميزانية بثلاث طرق:
- تحدد النطاق بدقة، فتظهر أي إضافة كطلب تغيير مكتوب بسعر منفصل.
- تكشف التكاملات المكلفة مبكراً، مثل بوابات الدفع أو الربط مع نظام محاسبي.
- تعطي المختبرين معايير قبول واضحة، فتقل جولات التعديل بعد التسليم.
في المناقصات الحكومية والمؤسسية يسمي أصحاب المشاريع الوثيقة المعتمدة «كراسة الشروط والمواصفات»، وتضم المتطلبات الفنية مع الشروط التعاقدية والمالية. القسم الفني من الكراسة يؤدي دور وثيقة SRS. دليل كيف تختار بين شركات البرمجة في الأردن يشرح كيف تقارن العروض بعد استلامها.
ما الأخطاء الشائعة في كتابة وثيقة المتطلبات؟
أكثر الأخطاء تكلفة هي المتطلبات الغامضة التي لا يمكن اختبارها. تجنب ما يلي:
- كلمات مثل «سريع» و«سهل» و«حديث» بلا رقم أو معيار.
- وصف الحل التقني بدل الحاجة، مثل فرض قاعدة بيانات بعينها دون سبب.
- إغفال المتطلبات غير الوظيفية، خصوصاً الأمان والأداء.
- نسيان أدوار المستخدمين وصلاحيات كل دور.
- إغفال قائمة ما هو خارج النطاق.
- ترك المتطلبات بلا أرقام، فيصعب الرجوع إليها في العقد والاختبار.
- كتابة الوثيقة مرة واحدة وإهمال تحديثها بعد كل تغيير متفق عليه.
كيف تساعدك Need Code في كتابة وثيقة المتطلبات؟
تقدم Need Code خدمة الاستشارات التقنية لتحليل احتياجك وصياغته في وثيقة متطلبات قابلة للتسعير والاختبار. تعمل الشركة منذ 2016 في تطوير البرمجيات الخاصة والمواقع وتطبيقات الجوال وأنظمة ERP وCRM لعملاء في الأردن والسعودية والولايات المتحدة.
تبني Need Code عرض السعر المكتوب على نطاق متفق عليه، ووثيقة SRS هي الأساس الذي يحدد هذا النطاق. تواصل معنا عبر صفحة التواصل لمناقشة مشروعك.
الأسئلة الشائعة
من يكتب وثيقة متطلبات النظام SRS؟
يكتبها محلل أنظمة أو محلل أعمال بالتعاون مع صاحب المشروع والفريق التقني. صاحب المشروع يقدم الأهداف وحالات الاستخدام، والمحلل يصوغها متطلبات مرقمة قابلة للاختبار.
كم يجب أن يكون طول وثيقة SRS؟
الطول يتبع عدد الوظائف والأدوار والتكاملات في النظام. المعيار أن تستطيع الشركة فهم كل متطلب وتسعيره واختباره دون أسئلة إضافية.
هل أحتاج BRD وPRD وSRS معاً؟
المشاريع الكبيرة تستفيد من الوثائق الثلاث منفصلة. المشاريع الصغيرة والمتوسطة تكتفي عادة بوثيقة SRS واحدة تبدأ بأهداف العمل وقائمة الميزات.
ما الفرق بين وثيقة SRS وكراسة الشروط والمواصفات؟
كراسة الشروط والمواصفات وثيقة مناقصة تجمع المواصفات الفنية مع الشروط التعاقدية والمالية. وثيقة SRS تركز على المتطلبات الفنية، وتصلح قسماً فنياً داخل الكراسة.
هل تتغير وثيقة SRS بعد بدء التطوير؟
نعم، عبر طلب تغيير مكتوب يحدد أثره على المدة والتكلفة. كل تغيير معتمد يدخل الوثيقة برقم إصدار جديد.