دليل شامل لتطوير وإدارة متطلبات البرمجيات
المطلب هو تعبير عن السلوك المطلوب الذي يركز على احتياجات العميل، وليس على الحل أو التنفيذ. تحدد المتطلبات السلوك المطلوب دون تحديد كيفية تحقيق هذا السلوك.
عملية تحديد الخدمات التي يحتاجها العميل من النظام والقيود التي يعمل ويتم تطويره تحت ظلها. متطلبات النظام هي أوصاف خدمات النظام والقيود التي يتم إنشاؤها أثناء عملية هندسة المتطلبات.
قد تصل تكلفة إصلاح خطأ في المتطلبات بعد التسليم إلى ١٠٠ ضعف تكلفة إصلاح خطأ في التنفيذ. التحقق المبكر أمر بالغ الأهمية.
المتطلبات الواضحة والموثقة جيدًا هي أساس نجاح المشروع وتكون الأساس للتصميم والتطوير.
تضمن المتطلبات أن يكون لدى جميع أصحاب المصلحة فهم مشترك لما يجب أن يفعله النظام وكيف يجب أن يعمل.
الجمهور: العملاء والمستخدمون النهائيون
التنسيق: لغة طبيعية بالإضافة إلى الرسوم البيانية
الغرض: وصف الخدمات التي يقدمها النظام وقيود التشغيل بمصطلحات مفهومة لأصحاب المصلحة غير التقنيين
الجمهور: المطورون والفريق التقني
التنسيق: وثيقة منظمة بأوصاف مفصلة
الغرض: تحديد ما يجب تنفيذه؛ قد تكون جزءًا من عقد بين العميل والمقاول
متطلب المستخدم:
"يجب أن يولد نظام الرعاية النفسية تقارير إدارة شهرية توضح تكلفة الأدوية الموصوفة من كل عيادة خلال ذلك الشهر."
مواصفات متطلبات النظام:
المتطلبات الوظيفية هي عبارات عن الخدمات التي يجب أن يقدمها النظام، وكيف يجب أن يتفاعل النظام مع مدخلات معينة، وكيف يجب أن يتصرف النظام في مواقف معينة. قد تنص أيضًا على ما يجب ألا يفعله النظام.
المتطلبات غير الوظيفية تحدد خصائص النظام والقيود مثل الموثوقية، ووقت الاستجابة، ومتطلبات التخزين. قد تكون أكثر أهمية من المتطلبات الوظيفية - إذا لم يتم الوفاء بها، قد يكون النظام عديم الفائدة.
| الفئة | الوصف | أمثلة |
|---|---|---|
| متطلبات المنتج | تحدد أو تقيد سلوق التشغيل للبرنامج | سرعة التنفيذ، الموثوقية، الأمان، قابلية الاستخدام |
| متطلبات المؤسسة | نتيجة لسياسات وإجراءات المؤسسة | متطلبات عملية التطوير، لغات البرمجة، المعايير التشغيلية |
| المتطلبات الخارجية | تنشأ من عوامل خارجية للنظام وتطويره | المتطلبات التنظيمية، المتطلبات التشريعية، المتطلبات الأخلاقية |
متطلب المنتج:
"يجب أن يكون نظام الرعاية النفسية متاحًا لجميع العيادات خلال ساعات العمل العادية (الاثنين-الجمعة، ٠٨:٣٠-١٧:٣٠). يجب ألا يتجاوز وقت التوقف خلال ساعات العمل العادية خمس ثوانٍ في أي يوم."
متطلب المؤسسة:
"يجب أن يقوم مستخدمو نظام الرعاية النفسية بالمصادقة باستخدام بطاقة هوية السلطة الصحية الخاصة بهم."
المتطلب الخارجي:
"يجب أن ينفذ النظام أحكام خصوصية المرضى كما هو منصوص عليه في HStan-03-2006-priv."
متطلبات المجال هي قيود على النظام من مجال التشغيل. تعكس خصائص وقيود مجال التطبيق.
أي شخص أو مؤسسة تتأثر بالنظام بطريقة ما ولديها مصلحة مشروعة فيه.
الأشخاص الذين سيتفاعلون مباشرة مع النظام ويستخدمونه
المسؤولون عن إدارة تشغيل النظام
المؤسسات أو الأفراد الذين يمتلكون النظام ويمولونه
الهيئات التنظيمية، الشركاء، والأطراف الأخرى المتأثرة
تختلف العمليات المستخدمة في هندسة المتطلبات على نطاق واسع اعتمادًا على مجال التطبيق، والأشخاص المشاركين، والمؤسسة. ومع ذلك، هناك أنشطة عامة مشتركة لجميع العمليات. في الممارسة، هندسة المتطلبات هي نشاط تكراري حيث تتشابك هذه العمليات.
العمل مع أصحاب المصلحة لاكتشاف وفهم متطلباتهم. يتضمن ذلك جمع معلومات حول مجال التطبيق، وأنشطة العمل، والخدمات والميزات المطلوبة، ومتطلبات الأداء، وقيود الأجهزة.
فحص وتصنيف وتنظيم المتطلبات. يتضمن ذلك تجميع المتطلبات ذات الصلة في مجموعات متماسكة، وتحديد أولويات المتطلبات، وحل التعارضات بين احتياجات أصحاب المصلحة المختلفين.
التأكد من أن المتطلبات تحدد فعلاً النظام الذي يريده العميل حقًا. يتضمن ذلك إثبات صحة واتساك واكتمال وواقعية المتطلبات.
إدارة المتطلبات المتغيرة أثناء عملية هندسة المتطلبات وتطوير النظام. يتضمن ذلك تتبع المتطلبات الفردية والحفاظ على الروابط بين المتطلبات المعتمدة على بعضها لتقييم تأثير التغييرات.
عملية جمع المعلومات حول النظم المطلوبة والموجودة واستخلاص متطلبات المستخدم والنظام من هذه المعلومات. يتضمن التفاعل مع أصحاب المصلحة في النظام من المديرين إلى المنظمين الخارجيين.
التفاعل مع أصحاب المصلحة لاكتشاف متطلباتهم. يتم أيضًا اكتشاف متطلبات المجال في هذه المرحلة.
تجميع المتطلبات ذات الصلة وتنظيمها في مجموعات متماسكة.
تحديد أولويات المتطلبات وحل تعارضات المتطلبات بين أصحاب المصلحة.
يتم توثيق المتطلبات وإعدادها كمدخل للمرحلة التالية من التطوير.
التحدث مع الأشخاص حول ما يفعلونه. هذه هي تقنية الاستخلاص الأكثر شيوعًا حيث يجري مهندسو المتطلبات مقابلات منظمة أو غير منظمة مع أصحاب المصلحة لفهم احتياجاتهم وسير عملهم وتوقعاتهم.
الأفضل لـ: فهم وجهات النظر الفردية، واستكشاف مخاوف محددة، وجمع معلومات مفصلة عن عمليات العمل.
مراقبة الأشخاص أثناء أداء عملهم لمعرفة الأدوات التي يستخدمونها، وكيف يستخدمونها، وفهم سياق عملهم. تساعد هذه التقنية في الكشف عن المتطلبات الضمنية التي قد لا يصرح بها أصحاب المصلحة في المقابلات.
الأفضل لـ: فهم ممارسات العمل الفعلية، وتحديد المتطلبات غير المعلنة، والتعرف على السياق الاجتماعي والتنظيمي لاستخدام النظام.
أمثلة من الحياة الواقعية لكيفية استخدام النظام. تصف القصص والسيناريوهات كيف يمكن استخدام النظام لمهام معينة. لأنها تعتمد على مواقف عملية، يمكن لأصحاب المصلحة الارتباط بها وتقديم ملاحظات ذات معنى.
الأفضل لـ: جعل المتطلبات ملموسة، وتسهيل النقاش مع أصحاب المصلحة، وضمان الفهم المشترك لحالات استخدام النظام.
السياق: صلاح معلم مدرسة ابتدائية يخطط لمشروع صفي حول صناعة صيد الأسماك.
"يجب على الطلاب جمع وتبادل الذكريات القديمة من الأقارب، واستخدام أرشيفات الصحف وجمع الصور القديمة المتعلقة بصيد الأسماك ومجتمعات الصيادين في المنطقة. يستخدم الطلاب ويكي لجمع قصص الصيد ويستخدمون SCRAN (موقع مصادر تاريخية) للوصول إلى أرشيفات الصحف والصور. أحتاج أيضًا إلى موقع لمشاركة الصور لأنني أريد من الطلاب التقاط والتعليق على صور بعضهم البعض وتحميل صور ممسوحة ضوئيًا للصور القديمة التي قد تكون لدى عائلاتهم."
يوجد لدى مستخدم أو مجموعة من المستخدمين صورة رقمية واحدة أو أكثر محفوظة على جهاز لوحي أو كمبيوتر محمول. لقد سجلوا الدخول إلى النظام بنجاح.
يختار المستخدم "تحميل الصور" ويتم مطالبتهم باختيار الصور من جهاز الكمبيوتر الخاص بهم واسم المشروع. يمكن للمستخدمين إدخال كلمات مفتاحية لكل صورة. يتم تسمية الصور المرفوعة بدمج اسم المستخدم مع اسم الملف. عند الانتهاء، يرسل النظام بريدًا إلكترونيًا إلى مشرف المشروع ويعرض رسالة تأكيد للمستخدم.
قد يكون المشرف مسجل الدخول وقد يوافق على الصور أثناء تحميلها.
المستخدم مسجل الدخول. تم تحميل الصور المختارة وتم تعيين حالة "بانتظار الموافقة". الصور مرئية للمشرف والمستخدم الذي قام بالتحميل.
عملية كتابة متطلبات المستخدم والنظام في وثيقة المتطلبات. يجب أن تكون متطلبات المستخدم مفهومة من قبل المستخدمين النهائيين والعملاء دون خلفيات تقنية. متطلبات النظام أكثر تفصيلاً وقد تتضمن معلومات تقنية. قد تكون المتطلبات جزءًا من عقد لتطوير النظام، لذا فإن الاكتمال أمر بالغ الأهمية.
| التدوين | الوصف | أفضل حالات الاستخدام |
|---|---|---|
| اللغة الطبيعية | المتطلبات المكتوبة باستخدام جمل مرقمة بلغة طبيعية. تعبر كل جملة عن مطلب واحد. | متطلبات المستخدم، التوثيق العام |
| اللغة الطبيعية المنظمة | المتطلبات المكتوبة على نموذج قياسي أو قالب. يوفر كل حقل معلومات عن جانب من المطلب. | متطلبات النظام ذات التنسيق المتسق |
| لغات وصف التصميم | لغة تشبه البرمجة بميزات مجردة لتحديد المتطلبات عن طريق تحديد نموذج تشغيلي. | مواصفات الواجهة (نادرًا ما تستخدم الآن) |
| التدوينات الرسومية | نماذج رسومية مكملة بتعليقات نصية (مثلاً، مخططات UML لحالات الاستخدام والتسلسل). | تصور المتطلبات الوظيفية |
| المواصفات الرياضية | تعتمد على مفاهيم رياضية مثل آلات الحالات المحدودة أو المجموعات. غير غامضة ولكن قد لا يفهمها العملاء. | الأنظمة الحرجة التي تتطلب التحقق الرسمي |
غالبًا ما تُكتب المتطلبات بلغة طبيعية لأنها تعبيرية وبديهية وعالمية. وهذا يضمن أن تكون المتطلبات مفهومة من قبل المستخدمين والعملاء الذين قد لا يكون لديهم خلفيات تقنية.
المتطلب ٣.٢:
"يجب أن يقيس النظام مستوى السكر في الدم ويوصف الأنسولين، إذا لزم الأمر، كل ١٠ دقائق."
السبب المنطقي: التغيرات في مستوى السكر في الدم بطيئة نسبيًا، لذا فإن القياس الأكثر تواترًا غير ضروري؛ قد يؤدي القياس الأقل تواترًا إلى مستويات سكر غير ضرورية مرتفعة.
المتطلب ٣.٦:
"يجب أن يشغل النظام روتين الفحص الذاتي كل دقيقة مع الشروط التي يجب اختبارها والإجراءات المرتبطة بها المحددة في الجدول ١."
السبب المنطقي: يمكن لروتين الفحص الذاتي اكتشاف مشكلات الأجهزة والبرامج وتنبيه المستخدم إلى حقيقة أن التشغيل الطبيعي قد يكون مستحيلاً.
وثيقة متطلبات البرمجيات هي البيان الرسمي لما هو مطلوب من مطوري النظام. يجب أن تتضمن كل من تعريف متطلبات المستخدم ومواصفات متطلبات النظام.
هام: ليست وثيقة تصميم. يجب أن تحدد ما يجب أن يفعله النظام قدر الإمكان بدلاً من كيفية فعله.
تجادل العديد من الأساليب الرشيقة بأن إنتاج متطلبات نظام مفصلة هو مضيعة للوقت لأن المتطلبات تتغير بسرعة كبيرة، مما يجعل وثيقة المتطلبات دائمًا قديمة.
النهج الرشيق: استخدام هندسة متطلبات تدريجية والتعبير عن المتطلبات كـ "قصص المستخدم"
عملي لـ: أنظمة الأعمال ذات المتطلبات سريعة التغير
مشكل لـ:
يهتم بإثبات أن المتطلبات تحدد النظام الذي يريده العميل حقًا. تكاليف خطأ المتطلبات مرتفعة، لذا فإن التحقق من الصحة مهم جدًا - قد تصل تكلفة إصلاح خطأ في المتطلبات بعد التسليم إلى ١٠٠ ضعف تكلفة إصلاح خطأ في التنفيذ.
هل يصف المتطلب حقًا الوظائف التي تدعم بشكل أفضل احتياجات العميل؟
هل تم فهم المتطلب بشكل صحيح من قبل جميع أصحاب المصلحة؟
هل هناك أي تعارضات أو تناقضات في المتطلبات؟
هل تم تضمين جميع الوظائف المطلوبة من قبل العميل؟
هل يمكن تنفيذ المتطلبات بالنظر إلى الميزانية والتكنولوجيا المتاحة؟
هل يمكن التحقق من المتطلبات؟ هل يمكن اختبار المتطلب بشكل واقعي؟
هل تم ذكر أصل المتطلب بوضوح؟
هل يمكن تغيير المتطلب بدون تأثير كبير على المتطلبات الأخرى؟
التحليل اليدوي المنهجي للمتطلبات. يجب عقد مراجعات منتظمة أثناء صياغة المتطلبات. يجب أن يشارك كل من موظفي العميل والمقاول. قد تكون المراجعات رسمية (بمستندات مكتملة) أو غير رسمية. يمكن أن يحل التواصل الجيد بين المطورين والعملاء والمستخدمين المشكلات في مرحلة مبكرة.
استخدام نموذج قابل للتنفيذ من النظام للتحقق من المتطلبات. تساعد النماذج الأولية أصحاب المصلحة على تصور النظام وتحديد المتطلبات المفقودة أو غير الصحيحة مبكرًا في عملية التطوير.
تطوير اختبارات للمتطلبات للتحقق من قابلية الاختبار. إذا كان من الصعب تصميم اختبارات لمتطلب، فقد يكون المتطلب غير مكتمل أو غامضًا جدًا ويجب مراجعته.
عملية إدارة المتطلبات المتغيرة أثناء عملية هندسة المتطلبات وتطوير النظام. تظهر متطلبات جديدة أثناء تطوير النظام وبعد بدء استخدامه.
تتبع المتطلبات الفردية طوال دورة حياة التطوير، والحفاظ على هوية واضحة ومعلومات الحالة.
الحفاظ على الروابط بين المتطلبات المعتمدة على بعضها لتقييم تأثير تغييرات المتطلبات عبر النظام.
إنشاء عملية رسمية لاقتراح التغييرات وربطها بمتطلبات النظام، وضمان التطور المنضبط.