مفهوم مستند SRS:
مستند مواصفات متطلبات النظام (System Requirements Specification) أو مستند مواصفات متطلبات البرمجية (Software Requirements Specification)، المعروف بمستند الـ (SRS)، هو مستند أو مجموعة من الوثائق التي تصف ميزات وسلوك النظام أو التطبيق، بحيث يتضمن مجموعة متنوعة من العناصر والتي تحاول تحديد الوظيفة المقصودة والمطلوبة من قبل العميل لإرضاء مستخدميه المختلفين.
بالإضافة إلى تحديد الطريقة التي يجب أن يتصرف بها النظام، فإن المواصفات تحدد أيضًا على مستوى عالٍ العمليات التجارية الرئيسية التي سيتم دعمها، وما هي الافتراضات المبسطة التي تم إجراؤها، وما هي متطلبات الأداء الرئيسية التي يجب أن يستوفيها النظام.
العناصر الرئيسية في مستند SRS:
سيختلف مستوى الشكليات والتفاصيل في مستند الـ (SRS) اعتمادًا على المنهجية المستخدمة، ولكن بشكل عام يجب أن يتضمن مستند (SRS) وصفًا للمتطلبات الوظيفية، ومتطلبات النظام، والمتطلبات الفنية، والقيود والافتراضات ومعايير القبول، كل من هؤلاء موصوف بمزيد من التفصيل أدناه:
دوافع العمل:
يصف هذا القسم الأسباب التي تجعل العميل يتطلع إلى بناء النظام، حيث أن الأسباب المنطقية لبناء النظام الجديد مهمة؛ لأنها ستوجه القرارات التي يتخذها محللو الأعمال ومهندسو النظام والمطورون، سبب مقنع آخر لتوثيق الأسباب المنطقية لدوافع وراء بناء نظام وهو أنه يجوز للعميل تغيير الموظفين أثناء المشروع، إذ ستساعد الوثائق التي تحدد بوضوح أسباب العمل على نظام في الحفاظ على الدعم للمشروع إذا انتقل الراعي الأصلي.
قد تتضمن الدوافع كلاً من المشاكل (أسباب عدم كفاية الأنظمة و العمليات الحالية)، والفرص (نماذج الأعمال الجديدة التي سيتيحها النظام)، عادة ما تكون هناك حاجة إلى مجموعة من المشاكل والفرص لتوفير الدافع لنظام جديد.
نموذج العمل:
يصف هذا القسم نموذج العمل الأساسي للعميل الذي سيحتاج النظام إلى دعمه، يتضمن ذلك عناصر مثل السياق التنظيمي، ومخططات الحالة الحالية و الحالة المستقبلية، وسياق الأعمال، ووظائف العمل الرئيسية، ومخططات تدفق العمليات، يتم إنشاء هذا القسم عادة أثناء مرحلة التحليل الوظيفي.
المتطلبات الوظيفية والنظامية:
يتكون هذا القسم عادةً من تنظيم هرمي للمتطلبات، حيث تكون متطلبات العمل ومتطلبات الوظيفية في أعلى مستوى، ومتطلبات النظام التفصيلية مدرجة كعناصر فرعية، بشكل عام، تتم كتابة المتطلبات على هيئة عبارات مثل “يحتاج النظام إلى قدرة على تنفيذ (شيء معين)” مع التفاصيل الداعمة والمعلومات المتضمنة عند الضرورة.
حالات استخدام الأعمال والنظام:
يتكون هذا القسم عادةً من مخطط حالة استخدام (UML)، إذ يوضح الكيانات الخارجية الرئيسية التي ستتفاعل وحالات الاستخدام (الأهداف) المختلفة التي سيحتاجون إلى تنفيذها، لكل حالة استخدام سيكون هناك تعريف رسمي للخطوات التي يجب تنفيذها لأداء هدف العمل، جنبًا إلى جنب مع أي شروط مسبقة وشروط لاحقة ضرورية.
متطلبات تقنية:
يستخدم هذا القسم لسرد أي من المتطلبات “غير الوظيفية” التي تجسد بشكل أساسي البيئة التقنية التي يحتاج المنتج للعمل، وتشمل القيود التقنية التي يحتاجها للعمل في ظلها، تعتبر هذه المتطلبات الفنية حاسمة في تحديد كيفية تقسيم المتطلبات الوظيفية ذات المستوى الأعلى إلى متطلبات نظام أكثر تحديدًا.
جودة النظام:
يستخدم هذا القسم لوصف المتطلبات غير الوظيفية التي تحدد جودة النظام، ويتضمن هذا القسم عناصر مثل: الموثوقية والتوافر وإمكانية الخدمة والأمان وقابلية للتوسع وقابلية للصيانة، وعلى عكس المتطلبات الوظيفية (التي عادة ما تكون سردية في الشكل)، تتكون جودة النظام عادةً من جداول مقاييس محددة يجب أن يفي بها النظام حتى يتم قبولها.
القيود والافتراضات:
سيحدد هذا القسم أي قيود تصميم تم فرضها على تصميم النظام من قبل العميل، وبالتالي إزالة خيارات معينة من النظر فيها من قبل المطورين، أيضًا سيحتوي هذا القسم على أي افتراضات تم إجراؤها بواسطة فريق هندسة المتطلبات عند جمع المتطلبات وتحليلها، إذا تبين أن أيًا من الافتراضات خاطئ، فسيلزم إعادة تقييم مواصفات متطلبات النظام للتأكد من أن المتطلبات التي قد تم توثيقها لا تزال صالحة.
معايير القبول:
سيصف هذا القسم المعايير التي سيوقِّع العميل من خلالها على النظام النهائي، اعتمادًا على المنهجية قد يحدث هذا في نهاية مرحلة الاختبار وضمان الجودة، وفي المنهجية رشيقة يحدث في نهاية كل تكرار، ستشير المعايير عادةً إلى الحاجة إلى إكمال جميع اختبارات قبول المستخدم وتصحيح جميع العيوب والأخطاء البرمجية التي تفي بأولوية محددة مسبقًا أو تحد الخطورة.
البدائل:
في المنهجيات الرشيقة، عادةً ما يتم تجنب التوثيق الثابت مثل مواصفات متطلبات البرامج (SRS) وتفضيل توثيق المتطلبات الأكثر خفة الوزن (أي عن طريق سيناريو المستخدم واختبارات القبول)، إذ يتطلب هذا النهج سهولة الوصول إلى العميل لتقديم توضيح بشأن المتطلبات أثناء التطوير ويفترض أيضًا أن أعضاء الفريق المسؤولين عن كتابة سيناريوهات المستخدم مع العميل سيكونون المطورين الذين يقومون ببناء النظام، قد تكون هناك حاجة إلى نهج أكثر رسمية إذا تعذر الوصول إلى العميل أو سيقوم فريق منفصل من محللي الأعمال بتطوير المتطلبات.
