وثيقة متطلبات البرمجيات (SRS)

وثيقة متطلبات البرمجيات (SRS)

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

تُعدّ وثيقة SRS في آنٍ واحد عقداً ودليل مرجعي ومخططاً للاختبار وخطاً أساسياً للتخطيط. إتقان هيكلها، ومعرفة من يقرأ أي قسم، والحفاظ على تحديثها طوال دورة حياة المشروع — ثلاث مهارات من أثمن ما يمكن لمحلل الأنظمة تطويره.

لماذا تهم وثيقة SRS في الواقع العملي

تخيّل شركة لوجستية تُكلف بإنشاء منصة جديدة لتتبع الشحنات. بدون وثيقة SRS رسمية، يتخيل راعي الأعمال تحديثات GPS الفورية كل 30 ثانية؛ يفترض قائد التطوير أن مزامنة الدُفعات الليلية مقبولة؛ يتوقع فريق المالية الفوترة متعددة العملات من اليوم الأول؛ وفريق الموبايل لم يسمع بالفوترة أصلاً. يبني كل فريق الجزء الخاص به استناداً إلى محادثات شفهية وشرائح عرض. بعد اثني عشر أسبوعاً تبدأ مرحلة التكامل — وتظهر الفجوات.

وثيقة SRS محكمة الصياغة ومُحافَظ عليها تُزيل هذه الفجوات. حين يكتب محلل الأعمال "يجب على النظام تحديث موقع الشحنة في بوابة العميل خلال 60 ثانية من استقبال إشارة GPS"، يوافق الجميع — العمل والتطوير والجودة والقانون — على تلك الجملة الواحدة. تصبح مصدر الحقيقة لهذه الميزة.

الهيكل المعياري لوثيقة SRS

يوفر معيار IEEE 830 (وخلفه ISO/IEC/IEEE 29148) القالب الأوسع انتشاراً الذي تُكيّفه معظم المنظمات لسياقها. تحتوي وثيقة SRS المكتملة على الأقسام الرئيسية التالية:

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

في الممارسة العملية، تُضيف المشاريع الكبيرة قسمين إضافيين لم يرد ذكرهما في قالب IEEE الكلاسيكي لكنهما باتا معياراً في الصناعة:

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

من يقرأ وثيقة SRS — وما الذي يهمه

أحد أهم الرؤى المتعلقة بوثيقة SRS أنها تخدم جماهير متعددة في آنٍ واحد، يقرأ كل منها بغرض مختلف. خطأ شائع يرتكبه المحللون هو كتابة الوثيقة بأسلوب واحد — تقني جداً لرعاة الأعمال، وغامض جداً للمطورين. فهم جمهورك يتيح لك توزيع المعلومات بشكل ملائم.

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

صيانة وثيقة SRS على مدار دورة حياة المشروع

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

الصيانة الفعّالة تتطلب ثلاثة انضباطات:

• الإصدارات. كل نسخة منشورة من وثيقة SRS يجب أن تحمل رقم إصدار (مثلاً: v1.0 = الخط الأساسي المعتمد الأول، v1.1 = توضيحات طفيفة، v2.0 = تغيير جوهري في النطاق). يُسجّل سجل المراجعات ما تغيّر ومن طلبه ومن وافق عليه ومتى. في مشروع متجر إلكتروني، قد يصف v1.0 تدفق الدفع عبر PayPal فقط؛ بينما يُضيف v1.2 Stripe بعد قرار تجاري بعد ثلاثة أشهر.
• التحكم في التغييرات. لا يجب إضافة أي متطلب أو حذفه أو تعديله دون طلب تغيير رسمي تُقيَّم تأثيراته على التكلفة والجدول الزمني والمتطلبات المرتبطة. مجلس التحكم في التغييرات (CCB) — حتى في المشاريع الرشيقة، ولو كان خفيفاً — يمنع الزحف المتسلل للنطاق من تضخيم الوثيقة خلسةً.
• صيانة التتبع. لكل متطلب معرّف (مثلاً FR-AUTH-001). حين يتغيّر متطلب، يجب تحديث مصفوفة التتبع التي تربطه بقرارات التصميم وحالات الاختبار ووحدات الكود. حالة اختبار يتيمة تُشير إلى متطلب محذوف هي عيب ينتظر الظهور.

مثال ملموس: مقتطف من وثيقة SRS لنظام حجز عيادة

لإضفاء الملموسية على الهيكل، إليك مخططاً لما يبدو عليه القسم 3 في وثيقة SRS حقيقية لنظام حجز عيادة. قد يُقرأ المتطلب الوظيفي FR-BOOK-003 على النحو التالي:

لاحظ كيف يُجيب هذا المتطلب الواحد على سؤال المطور ("ما الذي يجب أن يفعله النظام؟")، وسؤال المختبر ("كيف أتحقق من هذا؟")، وسؤال المحلل ("ما هي الحالات الطرفية؟") — كل ذلك في شكل مضغوط ومنظّم.