مرحلة إنتاج متطلبات عملية تطوير البرمجيات مواصفات متطلبات البرمجيات (SRS) (وتسمى أيضًا أ وثيقة المتطلبات ). يضع هذا التقرير الأساس لأنشطة هندسة البرمجيات ويتم إنشاؤه عندما يتم استنباط المتطلبات بأكملها وتحليلها. SRS هو تقرير رسمي يعمل بمثابة تمثيل للبرنامج الذي يمكّن العملاء من مراجعة ما إذا كان (SRS) متوافقًا مع متطلباتهم. كما أنها تشتمل على متطلبات المستخدم للنظام بالإضافة إلى المواصفات التفصيلية لمتطلبات النظام.
SRS هي مواصفات لمنتج أو برنامج أو مجموعة تطبيقات معينة تؤدي وظائف معينة في بيئة معينة. إنه يخدم عدة أهداف اعتمادًا على من يكتبه. أولاً، يمكن كتابة SRS بواسطة عميل النظام. ثانياً، يمكن كتابة نظام SRS بواسطة مطور النظام. تخلق الطريقتان مواقف مختلفة تمامًا وتحددان أغراضًا مختلفة للمستند تمامًا. الحالة الأولى، SRS، تستخدم لتحديد احتياجات وتوقعات المستخدمين. الحالة الثانية، SRS، مكتوبة لأغراض مختلفة وتكون بمثابة وثيقة عقد بين العميل والمطور.
خصائص SRS الجيدة
فيما يلي ميزات مستند SRS الجيد:
1. الصواب: يتم استخدام مراجعة المستخدم لتوفير دقة المتطلبات المنصوص عليها في SRS. يُقال إن SRS يكون مثاليًا إذا كان يغطي جميع الاحتياجات المتوقعة حقًا من النظام.
2. الاكتمال: يعتبر SRS مكتملاً فقط إذا كان يتضمن العناصر التالية:
(1). جميع المتطلبات الأساسية، سواء كانت تتعلق بالوظيفة أو الأداء أو التصميم أو القيود أو السمات أو الواجهات الخارجية.
لماذا واجهة العلامة في جافا
(2). تحديد استجاباتهم للبرنامج لجميع فئات البيانات المدخلة القابلة للتحقيق في جميع فئات المواقف المتاحة.
ملاحظة: من الضروري تحديد الاستجابات لكل من القيم الصالحة وغير الصالحة.
(3). التسميات والمراجع الكاملة لجميع الأشكال والجداول والرسوم البيانية في SRS وتعريفات جميع المصطلحات ووحدات القياس.
3. الاتساق: يكون SRS متسقًا فقط في حالة عدم وجود مجموعة فرعية من المتطلبات الفردية الموصوفة في تعارضها. هناك ثلاثة أنواع من الصراع المحتمل في SRS:
(1). قد تتعارض الخصائص المحددة لكائنات العالم الحقيقي. على سبيل المثال،
(أ) يمكن وصف شكل تقرير المخرجات في أحد المتطلبات على أنه جدولي وفي آخر على أنه نصي.
(ب) قد ينص أحد الشروط على أن تكون جميع الأضواء خضراء بينما ينص شرط آخر على أن تكون جميع الأضواء زرقاء.
(2). قد يكون هناك تعارض معقول أو زمني بين الإجراءين المحددين. على سبيل المثال،
(أ) قد يحدد أحد المتطلبات أن البرنامج سيضيف مدخلين، وقد يحدد آخر أن البرنامج سوف يقوم بمضاعفتهما.
(ب) قد ينص أحد الشروط على أن 'أ' يجب أن يتبع دائمًا 'ب'، بينما يتطلب شرط آخر أن يحدث 'أ' و'ب' معًا.
(3). قد يحدد متطلبان أو أكثر نفس الكائن في العالم الحقيقي ولكن يستخدم مصطلحات مختلفة لذلك الكائن. على سبيل المثال، قد يُطلق على طلب البرنامج لإدخال المستخدم اسم 'مطالبة' في أحد المتطلبات و'إشارة' في متطلبات أخرى. إن استخدام المصطلحات والأوصاف القياسية يعزز الاتساق.
4. عدم الغموض: SRS لا لبس فيه عندما يكون لكل متطلبات ثابتة تفسير واحد فقط. يشير هذا إلى أن كل عنصر يتم تفسيره بشكل فريد. في حالة استخدام طريقة ذات تعريفات متعددة، يجب أن يحدد تقرير المتطلبات الآثار المترتبة على نظام البحث العلمي بحيث يكون واضحًا وسهل الفهم.
5. الترتيب من حيث الأهمية والاستقرار: يتم تصنيف SRS من حيث الأهمية والاستقرار إذا كان لكل متطلب فيه معرف للإشارة إلى أهمية أو استقرار هذا المتطلب المعين.
عادة، جميع المتطلبات ليست على نفس القدر من الأهمية. قد تكون بعض المتطلبات الأساسية ضرورية، خاصة للتطبيقات الحيوية للحياة، في حين قد يكون بعضها الآخر مرغوبًا فيه. وينبغي تحديد كل عنصر لجعل هذه الاختلافات واضحة وصريحة. هناك طريقة أخرى لترتيب المتطلبات وهي التمييز بين فئات العناصر باعتبارها أساسية ومشروطة واختيارية.
إعدادات متصفح الإنترنت
6. قابلية التعديل: يجب أن تكون خدمة SRS قابلة للتعديل قدر الإمكان ويجب أن تكون قادرة على إجراء تغييرات على النظام بسرعة إلى حد ما. يجب أن تكون التعديلات مفهرسة بشكل مثالي ومرجعية ترافقية.
7. التحقق: يكون SRS صحيحًا عندما يمكن التحقق من المتطلبات المحددة باستخدام نظام فعال من حيث التكلفة للتحقق مما إذا كان البرنامج النهائي يلبي تلك المتطلبات. يتم التحقق من المتطلبات بمساعدة المراجعات.
8. التتبع: يمكن تتبع نظام SRS إذا كان أصل كل متطلبات واضحًا وإذا كان يسهل الرجوع إلى كل شرط في وثائق التطوير أو التحسين المستقبلية.
هناك نوعان من إمكانية التتبع:
1. التتبع العكسي: يعتمد هذا على كل متطلب يشير بوضوح إلى مصدره في المستندات السابقة.
2. التتبع الأمامي: يعتمد هذا على أن يكون لكل عنصر في SRS اسم فريد أو رقم مرجعي.
تعد إمكانية التتبع الأمامي لنظام SRS أمرًا بالغ الأهمية بشكل خاص عندما يدخل منتج البرنامج في مرحلة التشغيل والصيانة. نظرًا لتعديل وثيقة التعليمات البرمجية والتصميم، فمن الضروري أن تكون قادرًا على التأكد من المجموعة الكاملة من المتطلبات التي قد تتعلق بهذه التعديلات.
9. استقلال التصميم: يجب أن يكون هناك خيار للاختيار من بين بدائل التصميم المتعددة للنظام النهائي. وبشكل أكثر تحديدًا، يجب ألا يحتوي نظام SRS على أي تفاصيل للتنفيذ.
10. قابلية الاختبار: يجب كتابة SRS بطريقة تجعل من السهل إنشاء حالات اختبار وخطط اختبار من التقرير.
11. مفهومة من قبل العميل: قد يكون المستخدم النهائي خبيرًا في مجاله الصريح ولكن قد لا يكون مدربًا على علوم الكمبيوتر. ومن ثم، ينبغي تجنب الغرض من التدوينات والرموز الرسمية قدر الإمكان. يجب أن تظل اللغة بسيطة وواضحة.
12. المستوى الصحيح من التجريد: إذا تم كتابة SRS لمرحلة المتطلبات، فيجب شرح التفاصيل بوضوح. في حين أنه بالنسبة لدراسة الجدوى، يمكن استخدام عدد أقل من التحليلات. وبالتالي، فإن مستوى التجريد يتغير وفقًا لهدف SRS.
خصائص وثيقة SRS جيدة
الخصائص الأساسية لوثيقة SRS الجيدة هي التالية:
مختصرا: يجب أن يكون تقرير SRS موجزًا وفي نفس الوقت لا لبس فيه ومتسقًا وكاملًا. الأوصاف المطولة وغير ذات الصلة تقلل من سهولة القراءة وتزيد أيضًا من احتمالات الخطأ.
منظم: يجب أن تكون منظمة بشكل جيد. الوثيقة جيدة التنظيم سهلة الفهم والتعديل. ومن الناحية العملية، تخضع وثيقة SRS لعدة مراجعات لمواكبة متطلبات المستخدم. في كثير من الأحيان، تتطور متطلبات المستخدم على مدى فترة من الزمن. لذلك، لتسهيل إجراء التعديلات على مستند SRS، من الضروري جعل التقرير منظمًا بشكل جيد.
عرض الصندوق الأسود: يجب أن يحدد فقط ما يجب على النظام فعله والامتناع عن ذكر كيفية القيام بذلك. وهذا يعني أن وثيقة SRS يجب أن تحدد السلوك الخارجي للنظام وليس مناقشة مشكلات التنفيذ. يجب أن يعرض تقرير SRS النظام الذي سيتم تطويره على أنه صندوق أسود ويجب أن يحدد سلوك النظام المرئي خارجيًا. ولهذا السبب، يُعرف تقرير SRS أيضًا بمواصفات الصندوق الأسود للنظام.
التكامل المفاهيمي: يجب أن يُظهر التكامل المفاهيمي حتى يتمكن القارئ من فهمه فقط. الاستجابة للأحداث غير المرغوب فيها: يجب أن تميز الاستجابات المقبولة للأحداث غير المرغوب فيها. وتسمى هذه استجابة النظام للظروف الاستثنائية.
يمكن التحقق منه: يجب أن تكون جميع متطلبات النظام، كما هي موثقة في وثيقة SRS، صحيحة. وهذا يعني أنه ينبغي أن يكون من الممكن تحديد ما إذا كان قد تم استيفاء المتطلبات في التنفيذ أم لا.
خوارزمية البحث الثنائي