المتطلبات Requirements
ماذا تعني المتطلبات (Requirements) في هندسة البرمجيات...؟!! ما أهمية تحديد المتطلبات في تطوير البرمجيات..؟؟!! وكيف يتم تحديد المتطلبات بشكل دقيق و منهجي ..؟؟!!
تحديد المتطلبات هي أحد المراحل الهامة في عملية تطوير البرمجيات. إنها المرحلة التي يتم فيها تحديد وتوثيق المتطلبات والمواصفات اللازمة لتصميم وتطوير النظام البرمجي. يعتبر فهم وتحديد المتطلبات بدقة أمرًا بالغ الأهمية لضمان نجاح المشروع وتلبية احتياجات المستخدمين. في هذا المقال نتعرف على طريقة المتطلبات في هندسة البرمجيات.لنبدأ...
في هذا المقال نتعرف على:
المتطلبات Requirements
في مقال مقدمة الى هندسة البرمجيات تعرفنا على المراحل التي يمر بها البرنامج في دورة حياة تطوير البرمجيات، حيث تتعمد المراحل الأولى من هذه الدورة (مرحلتي تحديد المشكلة والتخطيط) على المتطلبات Requirements ، ففي هذه المراحل يتم تعريف النظام البرمجي مع تحليل للمتطلبات والتكلفة لجميع المتطلبات.
في هندسة البرمجيات، المتطلبات هي المواصفات والوظائف التي يجب أن تتوفر في النظام البرمجي المراد تطويره. وبما أن المتطلبات هي وصف لخدمات النظام والقيود التي يتم إنشاؤها أثناء تطوير البرمجيات يتم تحديد المتطلبات يتم في مرحلة مبكرة من عملية تطوير البرمجيات .وتعدد أنواع من المتطلبات في هندسة البرمجيات ، فيما يلي بعض أمثلة على أنواع المتطلبات في هندسة البرمجيات:
- المتطلبات الوظيفية (Functional Requirements): تصف المتطلبات الوظيفية الأنشطة والعمليات التي يجب أن يقوم بها النظام البرمجي. على سبيل المثال، يمكن أن تشمل المتطلبات الوظيفية وصف عمليات التسجيل وتسجيل الدخول وإضافة المستخدمين وإدارة البيانات وما إلى ذلك.
- المتطلبات غير الوظيفية (Non-Functional Requirements): تشير إلى الخصائص والمتطلبات التي لا تتعلق بالوظائف المحددة للنظام البرمجي، ولكنها تؤثر على كيفية عمل النظام وأدائه. يمكن أن تشمل المتطلبات غير الوظيفية الأمان، الأداء، الاستجابة، التوافق، سهولة الاستخدام، التوثيق، وغيرها.
- المتطلبات التشغيلية (Operational Requirements): تصف المتطلبات التشغيلية البيئة التي سيتم تشغيل النظام فيها، والمتطلبات المتعلقة بالأجهزة والبرمجيات والشبكات والتكوينات اللازمة. تشمل المتطلبات التشغيلية عادةً متطلبات النظام الأساسية والتوافقية.
- المتطلبات القانونية والتنظيمية (Legal and Regulatory Requirements): تشمل المتطلبات القانونية والتنظيمية القوانين واللوائح التي يجب أن يتوافق معها النظام البرمجي. قد تتعلق هذه المتطلبات بحماية البيانات، حقوق المستخدم، الأمان السيبراني، وغيرها.
- المتطلبات ذات الصلة بالأداء والتوفير (Performance and Scalability Requirements): تحدد المتطلبات ذات الصلة بالأداء العمليات الزمنية المقبولة وقدرة النظام على التوسع والتكيف مع زيادة الحمولة وعدد المستخدمين.
هذه مجرد بعض الأمثلة على أنواع المتطلبات في هندسة البرمجيات. يجب أن تكون عملية تحديد المتطلبات شاملة وتشمل جميع الجوانب المهمة للنظام البرمجي المراد تطويره.
أهمية تحديد المتطلبات
إن لتحديد المتطلبات في عملية تطوير البرمجيات أهمية كبيرة في التعرف على الصورة العامة النظام و وظائفه بشكل مفصل. لهذا يعد تحديد المتطلبات في تطوير البرمجيات مهم جداً، وفيما يلي بعض الأسباب التي تبرز أهميتها:
- فهم احتياجات المستخدمين: يساعد تحديد المتطلبات في فهم احتياجات المستخدمين ومتطلباتهم الفعلية من النظام البرمجي. من خلال جمع المتطلبات وتحليلها بدقة، يمكن لفريق التطوير توفير حلول ملائمة وتصميم نظام يلبي تلك الاحتياجات بشكل أفضل.
- تحقيق الرضا والتوافق: بواسطة تحديد المتطلبات بدقة، يمكن تفادي سوء التفاهم وتبادل المعلومات غير الدقيقة. يساعد ذلك في تحقيق رضا المستخدمين وتوافق النظام مع توقعاتهم وتطلعاتهم.
- تحديد نطاق المشروع: يعمل تحديد المتطلبات على تحديد نطاق المشروع بشكل واضح ودقيق. يساعد في تحديد الميزات والوظائف التي يجب تضمينها في النظام البرمجي وتحديد حجم العمل المطلوب والجهود المطلوبة لإكمال المشروع.
- توجيه التصميم والتطوير: يعمل تحديد المتطلبات كدليل لعملية التصميم والتطوير. يمكن لفريق التطوير استخدام المتطلبات الموثقة لاتخاذ القرارات المناسبة في تصميم وبناء النظام البرمجي.
- تقليل المخاطر والتكلفة: بفضل تحديد المتطلبات الدقيقة، يمكن تقليل المخاطر المحتملة أثناء تطوير البرمجيات وتجنب الأخطاء والعيوب التي قد تنشأ بسبب عدم فهم المتطلبات بشكل صحيح. كما يمكن تقليل الهدر والتكاليف الناجمة عن إعادة العمل أو التعديلات الكبيرة في مراحل متأخرة من عملية التطوير.
إذن يمكن القول في مرحلة تحديد المتطلبات في تطوير البرمجيات مرحلة أساسية تؤدي إلى نجاح المشروع وتقديم نظام برمجي يلبي الاحتياجات والتوقعات المطلوبة.
تحديد المتطلبات
يتضمن تحديد المتطلبات العديد من الأنشطة والمهام التي يقوم بها فريق التطوير مع العملاء تسمى في مجملها عملية هندسة المتطلبات Requirements Engineering وهي إنشاء الخدمات التي يطلبها العميل من النظام والقيود التي يعمل في ظلها النظام. .و من الأنشطة والمهام الخاصة بمرحلة تحديد المتطلبات التالي :
- تعريف المتطلبات الوظيفية وغير الوظيفية (Functional and Non-functional Requirements).
- إنشاء وثيقة متطلبات البرمجيات (The Software Requirements Document).
- تحديد مواصفات المتطلبات (Requirements Specification).
- عمليات هندسة المتطلبات (Requirements Engineering processes).
- استنباط والمتطلبات وتحليلها(Requirements Elicitation and Analysis).
- التحقق من صحة المتطلبات (Requirements Validation).
- إدارة متطلبات (Requirements Management).
تذكر أن هذه الأنشطة تعتبر إرشادًا عامًا ويمكن تخصيصها وتعديلها وفقًا لاحتياجات ومتطلبات كل مشروع برمجي. أيضًا، يمكن استخدام منهجيات محددة مثل Agile أو Waterfall لتحديد المتطلبات وتطوير البرمجيات.
تعريف المتطلبات الوظيفية وغير الوظيفية (Functional and Non-Functional Requirements)
المتطلبات الوظيفية Functional Requirements
تعرف المتطلبات الوظيفية أنها وصف الوظائف أو خدمات النظام. وهي تعتمد ذلك على نوع البرنامج والمستخدمين المتوقعين ونوع النظام الذي يتم استخدام البرنامج فيه. قد تكون متطلبات المستخدم الوظيفية عبارة عن بيانات عالية المستوى لما يجب أن يفعله النظام.
يجب أن تصف متطلبات النظام الوظيفية خدمات النظام بالتفصيل.بمعنى أنها تشرح بيانات الخدمات التي يجب أن يقدمها النظام، أي كيف يجب أن يتفاعل النظام مع مدخلات معينة وكيف يجب أن يتصرف النظام في مواقف معينة. وقد يذكر ما لا ينبغي للنظام أن يفعله.
فمثلاً في نظام المستشفى يستطيع المستخدم البحث في قوائم المواعيد لجميع العيادات. ويقوم النظام بإنشاء قائمة يومية لكل عيادة بأسماء المرضى الذين من المتوقع حضورهم للمواعيد في ذلك اليوم. كما يجب تحديد هوية كل موظف يستخدم النظام بشكل فريد من خلال رقم الموظف المكون من 8 أرقام.
المتطلبات غير الوظيفية ( Non-Functional Requirements)
هذه المتطلبات تحدد هذه خصائص النظام والقيود على سبيل المثال الموثوقية و زمن الاستجابة ومتطلبات التخزين. والقيود هي قدرة جهاز الإدخال/الإخراج، وتمثيل النظام، وما إلى ذلك. ويمكن أيضًا تحديد متطلبات العملية التي تتطلب IDE أو لغة برمجة أو طريقة تطوير معينة.
وقد تكون المتطلبات غير الوظيفية أكثر أهمية من المتطلبات الوظيفية. إذا لم يتم استيفاء هذه الشروط، فقد يصبح النظام عديم الفائدة. ويمكن تصنيف المتطلبات الغير وظيفية الى عدة فئات كما يتضح معنا في الشكل التالي:
بحيث :
- متطلبات المنتج (Product requirements) : هي المتطلبات التي تحدد أن المنتج الذي تم تسليمه يجب أن يتصرف بطريقة معينة، على سبيل المثال. سرعة التنفيذ والموثوقية وما إلى ذلك.
- المتطلبات التنظيمية (Organisational requirements): وهي المتطلبات التي هي نتيجة للسياسات والإجراءات التنظيمية، على سبيل المثال. معايير العملية المستخدمة ومتطلبات التنفيذ وما إلى ذلك.
- المتطلبات الخارجية (External requirements): وهي المتطلبات التي تنشأ من عوامل خارجية للنظام وعملية تطويره، على سبيل المثال. متطلبات التشغيل البيني، والمتطلبات التشريعية، وما إلى ذلك.
مع تعريف المتطلبات الوظيفية وغير الوظيفية للنظام لابد أيضاً من تعريف:
متطلبات المجال (Domain Requirements )
بيمنا تعرف المتطلبات غير الوظيفة بالقيود على خدمات النظام تعرف الـ Domain requirements بالقيود المفروضة على النظام من مجال التشغيل، فالمجال التشغيلي للنظام قد يفرض متطلبات على النظام. على سبيل المثال، في نظام التحكم في القطار يتم تشغيل المكابح بحسب الظروف الجوية المختلفة.
كما يمكن أن نعرف متطلبات المجال أنها متطلبات وظيفية جديدة، أو قيود على المتطلبات الحالية أو تحديد حسابات محددة. وهي المتطلبات التي إذا لم يتم استيفائها فقد يكون النظام غير قابل للعمل. وهذا لأن هذه المتطلبات قد تواجه بعض المشاكل مثل :
- القابلية للفهم : يتم التعبير عن المتطلبات بلغة مجال التطبيق غالبًا ما لا يفهم مهندسو البرمجيات الذين يقومون بتطوير النظام هذا الأمر.
- ضمنية الاختصاص: يفهم متخصصو المجال المجال جيدًا لدرجة أنهم لا يفكرون في جعل متطلبات المجال واضحة.
وثيقة متطلبات البرمجيات The Software Requirements Document
وثيقة متطلبات البرنامج (software requirements document) هي البيان الرسمي لما هو مطلوب من مطوري النظام. ينبغي أن يتضمن كلاً من تعريف متطلبات المستخدم ومواصفات متطلبات النظام. إنها ليست وثيقة تصميم. وينبغي قدر الإمكان أن يحدد ما يجب على النظام أن يفعله وليس كيف ينبغي أن يفعله.
و وثيقة متطلبات البرنامج متغيرة فالمعلومات الواردة في وثيقة متطلبات البرنامج تعتمد على نوع النظام وأسلوب التطوير المستخدم.عادةً ما تحتوي الأنظمة التي يتم تطويرها تدريجيًا على تفاصيل أقل في وثيقة المتطلبات. وتنطبق وثيقة المتطلبات في الغالب على متطلبات مشاريع هندسة الأنظمة الكبيرة. بحيث تكون الوثيقة شرح مفصل للنظام فيما يلي الأقسام التي تكون وثيقة النظام :
- التمهيد Preface : يجب أن تحدد القراء المتوقعين للوثيقة ووصف تاريخ إصدارها، بما في ذلك الأساس المنطقي لإنشاء نسخة جديدة وملخص للتغييرات التي تم إجراؤها في كل إصدار.
- مقدمة Introduction : يجب أن يصف هذا الجزء الحاجة إلى النظام. وينبغي أن يصف بإيجاز وظائف النظام ويشرح كيف سيعمل مع الأنظمة الأخرى. ويجب أن يصف أيضًا كيفية تناسب النظام مع الأعمال العامة أو الأهداف الإستراتيجية للمؤسسة التي تقوم بتكليف البرنامج.
- قائمة المصطلحات Glossary: يجب أن يحدد هذا المصطلحات الفنية المستخدمة في الوثيقة. يجب ألا تضع افتراضات حول تجربة القارئ أو خبرته.
- تعريف متطلبات المستخدم User Requirements Definition: هنا يتم وصف الخدمات المقدمة للمستخدم. يجب أيضًا وصف متطلبات النظام غير الوظيفية في هذا القسم. قد يكون هذا الوصف بلغة مكتوبة أو رسومًا بيانية أو رموزًا أخرى مفهومة للعملاء. كما يجب تحديد معايير المنتج والعملية التي يجب اتباعها.
- بنية النظام System architecture: يجب أن يقدم هذا الفصل نظرة عامة رفيعة المستوى على بنية النظام المتوقعة، موضحًا توزيع الوظائف عبر وحدات النظام. وينبغي تسليط الضوء على المكونات المعمارية التي يعاد استخدامها.
- مواصفات متطلبات النظام System requirements specification: يجب أن يصف هذا المتطلبات الوظيفية وغير الوظيفية بمزيد من التفصيل. إذا لزم الأمر، يمكن أيضًا إضافة المزيد من التفاصيل إلى المتطلبات غير الوظيفية. كما يمكن تعريف واجهات الأنظمة الأخرى.
- نماذج النظام System models: وتشمل نماذج النظام الرسومية التي توضح العلاقات بين مكونات النظام والنظام وبيئته. ومن أمثلة النماذج المحتملة نماذج الكائنات، أو نماذج تدفق البيانات، أو نماذج البيانات الدلالية.( المزيد في مقال عن نمذجة النظم Systems Modelling)
- تطور النظام System evolution: يجب أن يصف هذا الافتراضات الأساسية التي يستند إليها النظام، وأي تغييرات متوقعة نتيجة لتطور الأجهزة، وتغير احتياجات المستخدم، وما إلى ذلك. يعد هذا القسم مفيدًا لمصممي النظام لأنه قد يساعدهم على تجنب قرارات التصميم التي من شأنها تقييد التغييرات المستقبلية المحتملة على النظام.
- الملحقات Appendices : ينبغي أن توفر هذه المعلومات معلومات مفصلة ومحددة تتعلق بالتطبيق الجاري تطويره على سبيل المثال، أوصاف الأجهزة وقاعدة البيانات. تحدد متطلبات الأجهزة الحد الأدنى والتكوينات المثالية للنظام. تحدد متطلبات قاعدة البيانات التنظيم المنطقي للبيانات التي يستخدمها النظام والعلاقات بين البيانات.
- فِهرِس Index : ويمكن تضمين عدة فهارس للوثيقة. بالإضافة إلى الفهرس الأبجدي العادي، قد يكون هناك فهرس للرسوم البيانية، وفهرس للوظائف، وما إلى ذلك.
تحديد مواصفات المتطلبات Requirements Specification
تحدد مواصفات المتطلبات (Requirements Specification) للنظام في وثيقة حيث يتم كتابة متطلبات المستخدم والنظام في وثيقة المتطلبات، تختلف هذه الوثيقة عن وثيقة متطلبات النظام بأنها وثيقة مختصرة تحدد مواصفات النظام ومتطلباته بشكل عام و تستخدم وثيقة المتطلبات هذه مع المشاريع الصغيرة أو الكبيرة.
في وثيقة مواصفات متطلبات يجب أن تكون متطلبات مفهومة من قبل المستخدمين النهائيين والعملاء الذين ليس لديهم خلفية تقنية. كما لابد أن يكون الوصف للمتطلبات النظام أكثر تفصيلاً و تتضمن المزيد من المعلومات التقنية. ومن المعلومات التي تتضمنها وثيقة المتطلبات:
- تعريف الوظائف في النظام أو الكيان.
- وصف المدخلات لكل وظيفة في النظام ومن أين أتت.
- وصف المخرجات لكل إجراء وأين تذهب.
- ماهي المعلومات اللازمة للحساب والكيانات الأخرى المستخدمة.
- وصف الإجراء المطلوب اتخاذه.
- الشروط المسبقة واللاحقة (إذا كان ذلك مناسبا).
- الآثار الجانبية (إن وجدت) للوظيفة.
قد تكون المتطلبات جزءًا من العقد لتطوير النظام، ولذلك فمن المهم أن تكون وثيقة مواصفات المتطلبات كاملة قدر الإمكان. وهنالك عدة طرق لكتابة مواصفات متطلبات النظام Requirements specification منها التالي:
- الكتابة العادية (Natural language) : استخدام الكلمات في شرح المتطلبات حيث تتم كتابة المتطلبات باستخدام جمل مرقمة و يجب أن تعبر كل جملة عن مطلب واحد.
- الطريقة القياسية (Structured natural language): تتم كتابة المتطلبات باللغة العادية في نموذج أو قالب قياسي. يوفر كل حقل معلومات حول جانب من المتطلبات.
- لغات وصف التصميم (Design description languages): يستخدم هذا النهج لغة مثل لغة البرمجة، ولكن مع المزيد من الميزات المجردة لتحديد المتطلبات من خلال تحديد نموذج تشغيلي للنظام. نادرًا ما يتم استخدام هذا الأسلوب الآن .
- المخططات الرسومية (Graphical notations): تُستخدم النماذج الرسومية، المكملة بالشروح النصية، لتحديد المتطلبات الوظيفية للنظام، يتم استخدام مخطط وصف الوظائف الـ Use Case و مخطط تسلسل العمليات Sequence Diagram اي مخططات الـ UML وتستخدم هذه الطريقة بشكل شائع.
- المواصفات الرياضية (Mathematical Specifications): تعتمد هذه الطريقة على استخدام رموز المفاهيم الرياضية مثل آلات أو مجموعات الحالة المحدودة. على الرغم من أن هذه المواصفات الواضحة يمكن أن تقلل من الغموض في مستند المتطلبات، إلا أن معظم العملاء لا يفهمونها ، بالتالي لا يمكنهم التحقق من أنه يمثل ما يريدون و يترددون في قبوله كعقد للنظام.
ذكرنا أن وثيقة المتطلبات يجب ان تكون واضحة ودقيقة ، ومن النصائح التي يمكن اتباعها لهذا الغرض:
- ابتكار تنسيق قياسي واستخدامه لجميع المتطلبات.
- استخدام اللغة بطريقة متسقة.
- يجب تمييز المتطلبات الإلزامية، وإيضاح للمتطلبات المرغوبة.مثل استخدم تمييز النص لتحديد الأجزاء الرئيسية من المتطلبات.
- تجنب استخدام مصطلحات البرمجة و أو غير المفهومة للعملاء.
- قم بتضمين شرح (أساس منطقي) لسبب ضرورة هذا المطلب.
تعد وثيقة متطلبات البرنامج بيانًا متفقًا عليه لمتطلبات النظام. يجب أن يتم تنظيمه بحيث يمكن لعملاء النظام ومطوري البرامج استخدامه.
عمليات هندسة المتطلبات Requirements Engineering Processes
تختلف العمليات المستخدمة في هندسة المتطلبات بشكل كبير اعتمادًا على مجال التطبيق والأشخاص المعنيين والمؤسسة التي تقوم بتطوير المتطلبات. ومع ذلك، هناك عدد من الأنشطة العامة المشتركة بين جميع العمليات:
- استنباط المتطلبات .
- تحليل المتطلبات.
- التحقق من المتطلبات.
- إدارة متطلبات.
من الناحية العملية، تعد هندسة المتطلبات نشاطًا تكراريًا يتم فيه فلترة هذه العمليات. بعد جمع المتطلبات، يتم تحليلها وفحصها لضمان أنها غير متعارضة و متوافقة وقابلة للتنفيذ.
والهدف من أنت تكون عملية هندسة المتطلبات تكرارية لتضمن استنباط المتطلبات والمواصفات والتحقق من صحتها.يتم تحديد الأولويات وتحديد الأهداف الرئيسية للمشروع، ومن ثم توثيق المتطلبات في شكل وثيقة تحدد بالتفصيل كل ما يجب تضمينه في النظام البرمجي.
إستنباط المتطلبات وتحليلها Requirements Elicitation and Analysis
يُطلق عليها أحيانًا استنباط المتطلبات (Requirements Elicitation ) اكتشاف المتطلبات (Requirements Discovery). كما يعمل مهندسو البرمجيات مع مجموعة من أصحاب المصلحة Stakeholders في النظام للتعرف على مجال التطبيق، والخدمات التي يجب أن يوفرها النظام، وأداء النظام المطلوب، وقيود الأجهزة، والأنظمة الأخرى، وما إلى ذلك. هذه المراحل هذه المراحل تتم بشكل تكراري كما يتضح معنا في الشكل التالي:
كما نرى يعد استنباط المتطلبات وتحليلها عملية متكررة يمكن تمثيلها على شكل دوامة من الأنشطة وهي :
- اكتشاف المتطلبات (Requirements Discovery): التواصل الفعال مع الـ Stakeholders لاكتشاف متطلباتهم.(أي جمع المتطلبات من خلال إجراء المقابلات أو إجراء استطلاعات الرأي) يتم أيضًا اكتشاف متطلبات المجال (Domain Requirements ) في هذه المرحلة.
- تصنيف المتطلبات وتنظيمها (Requirements classification and organisation): تجميع المتطلبات ذات الصلة وتنظيمها في مجموعات.
- تحديد الأولويات والتفاوض بشأن المتطلبات (Prioritisation and negotiation): تحديد أولويات المتطلبات وحل تعارض المتطلبات.
- مواصفات المتطلبات (Requirements specification): يتم توثيق المتطلبات وإدخالها في الدورة التالية .
ملاحظة : يشمل مصطلح أصحاب المصلحة (stakeholders) الموظفين الفنيين الذين يعملون مع العملاء للتعرف على مجال التطبيق والخدمات التي يجب أن يوفرها النظام والقيود التشغيلية للنظام. وقد يشمل المستخدمين النهائيين، والمديرين، والمهندسين المشاركين في الصيانة، وخبراء المجال، والنقابات العمالية، وما إلى ذلك. ويطلق على هؤلاء أصحاب المصلحة (stakeholders).
التحقق من صحة المتطلبات Requirements Validation
تهتم عملية التحقق من صحة المتطلبات (Requirements Validation) بإظهار أن المتطلبات تحدد النظام الذي يريده العميل حقًا. فتكاليف خطأ المتطلبات مرتفعة لذا فإن التحقق من الصحة مهم جدًا.فقد يكلف إلا خطأ المتطلبات بعد التسليم ما يصل إلى 100 ضعف تكلفة إصلاح خطأ التنفيذ. وتشمل عملية التحقق من صحة المتطلبات التحقق مما يلي :
- فعالية النظام (Validity) :هل يوفر النظام الوظائف التي تدعم احتياجات العميل بشكل أفضل؟
- التناسق (Consistency): هل هناك أي تعارض في المتطلبات؟
- الاكتمال (Completeness) : هل يتم تضمين كافة الوظائف المطلوبة من قبل العميل؟
- الواقعية (Realism): هل يمكن تنفيذ المتطلبات في ضوء الميزانية والتكنولوجيا المتاحة؟
- إمكانية التحقق (Verifiability): هل يمكن التحقق من المتطلبات؟
هناك ايضاً بعض التقنيات المستخدمة مع عملية التحقق من صحة المتطلبات منها :
- مراجعات المتطلبات Requirements Reviews : التحليل اليدوي المنهجي للمتطلبات.
- النماذج الأولية Prototyping : استخدام نموذج قابل للتنفيذ للنظام للتحقق من المتطلبات.
- توليد حالة الاختبار (Test-case Generation) : تطوير اختبارات لمتطلبات التحقق من القابلية للاختبار.
ولتحقيق تحقق دقيق من للمتطلبات تجري عملية تقييم مستمر وتكرر على المتطلبات طوال فترة تطوير الـ Software ، الشكل التالي يوضح خطوات عملية تقيم المتطلبات:
إدارة المتطلبات Requirements Management
يكون تغيير المتطلبات نتيجة لتغيير البيئة التجارية والتقنية للنظام دائمًا بعد التثبيت. قد يتم إدخال أجهزة جديدة، وقد يكون من الضروري ربط النظام بأنظمة أخرى، وقد تتغير أولويات العمل (مع الحاجة إلى تغييرات لاحقة في دعم النظام)، وقد يتم إدخال تشريعات ولوائح جديدة يجب على النظام الالتزام بها بالضرورة.
كما أنه من النادر ما يكون الأشخاص الذين يدفعون مقابل النظام ومستخدمي هذا النظام هم نفس الأشخاص. فيفرض عملاء النظام متطلبات بسبب القيود التنظيمية وقيود الميزانية. وقد تتعارض هذه مع متطلبات المستخدم النهائي، وبعد التسليم، قد يلزم إضافة ميزات جديدة لدعم المستخدم إذا كان النظام سيحقق أهدافه.
وعادةً ما تحتوي الأنظمة الكبيرة على مجتمع مستخدمين متنوع، حيث يكون لدى العديد من المستخدمين متطلبات وأولويات مختلفة قد تكون متعارضة أو متناقضة. أي أن متطلبات النظام النهائية هي حتماً حل وسط بينهما، ومع الخبرة، غالباً ما يتم اكتشاف أنه يجب تغيير توازن الدعم المقدم لمستخدمين مختلفين.
عملية إدارة المتطلبات هي عملية إدارة المتطلبات المتغيرة أثناء عملية هندسة المتطلبات وتطوير النظام. قد تظهر متطلبات جديدة أثناء تطوير النظام أو بعد دخوله حيز الاستخدام. فتحتاج إلى متابعة المتطلبات الفردية والحفاظ على الروابط بين المتطلبات التابعة حتى تتمكن من تقييم تأثير تغييرات المتطلبات. وقد تحتاج إلى إنشاء عملية رسمية لتقديم مقترحات التغيير وربطها بمتطلبات النظام.
وتمر عملية ادارة المتطلبات المتغيرة بعدة خطوات وهي :
- تحديد ما إذا كان ينبغي قبول تغيير المتطلبات.
- تحليل المشكلة وتغيير المواصفات (Problem analysis and change specification ) : خلال هذه المرحلة، يتم تحليل المشكلة أو مقترح التغيير للتأكد من صحته. يتم إرسال هذا التحليل مرة أخرى إلى طالب التغيير الذي قد يستجيب باقتراح تغيير متطلبات أكثر تحديدًا، أو يقرر سحب الطلب.
- تحليل التغيير والتكلفة (Change analysis and costing ) : يتم تقييم تأثير التغيير المقترح باستخدام معلومات التتبع والمعرفة العامة بمتطلبات النظام. بمجرد الانتهاء من هذا التحليل، يتم اتخاذ قرار بشأن المضي قدمًا في تغيير المتطلبات أم لا.
- تنفيذ التغيير (Change implementation ) : يتم تعديل وثيقة المتطلبات، وعند الضرورة، تصميم النظام وتنفيذه. ومن الناحية المثالية، ينبغي تنظيم الوثيقة بحيث يمكن تنفيذ التغييرات بسهولة.
ويوضح الشكل التالي خطوات إدارة المتطلبات المتغيره :
من المهم أيضًا إشراك العملاء وأصحاب المصلحة في عملية تحديد المتطلبات. يجب أن يكون هناك تفاعل وتواصل مستمر بين فريق التطوير والعملاء لضمان فهم متطلبات النظام بشكل صحيح وتجنب أي سوء تفاهم. يمكن تحقيق ذلك من خلال ورش العمل والاجتماعات الدورية والعروض التوضيحية. في ختام مرحلة تحديد المتطلبات، يجب أن يتم الحصول على موافقة جميع الأطراف المعنية على المتطلبات الموثقة. يعتبر هذا الاتفاق على المتطلبات نقطة انطلاق حقيقية لبدء عملية التصميم والتطوير الفعلية.