متطلبات

ينبغي أن تكون جميع المتطلبات قابلة للتحقق. والطريقة الأكثر شيوعًا هي الاختبار. إذا لم يكن الأمر كذلك، فينبغي استخدام طريقة تحقق أخرى (مثل التحليل، أو العرض التوضيحي، أو الفحص، أو مراجعة التصميم).

بعض المتطلبات، بحكم بنيتها، غير قابلة للتحقق. تشمل هذه المتطلبات تلك التي تنص على أن النظام يجب ألا يُظهر خاصية معينة مطلقًا أو دائمًا . يتطلب الاختبار السليم لهذه المتطلبات دورة اختبار لا نهائية. لذا، يجب إعادة صياغة هذه المتطلبات لتكون قابلة للتحقق. وكما ذُكر سابقًا، يجب أن تكون جميع المتطلبات قابلة للتحقق.

يجب الاحتفاظ بالمتطلبات غير الوظيفية، التي لا يمكن التحقق منها على مستوى البرمجيات، كتوثيق لغرض العميل. ومع ذلك، يمكن ربطها بمتطلبات عملية تُعتبر طريقة عملية لتلبيتها. على سبيل المثال، يمكن تلبية متطلب غير وظيفي يتمثل في خلو النظام من الثغرات الأمنية عن طريق استبداله بمتطلب عملية يتمثل في استخدام البرمجة الثنائية . أما المتطلبات غير الوظيفية الأخرى، فترتبط بمكونات النظام الأخرى ويتم التحقق منها على ذلك المستوى. على سبيل المثال، غالبًا ما يتم التحقق من موثوقية النظام من خلال التحليل على مستوى النظام. يجب أن تتبع برمجيات إلكترونيات الطيران، بمتطلبات السلامة المعقدة الخاصة بها، عملية تطوير DO-178B .

الأنشطة التي تؤدي إلى استخلاص متطلبات النظام أو البرمجيات. قد تشمل هندسة المتطلبات دراسة جدوى أو مرحلة تحليل مفاهيمي للمشروع، واستخلاص المتطلبات (جمع وفهم ومراجعة وتوضيح احتياجات أصحاب المصلحة ) ، وتحليل المتطلبات ، ^{[ 10 ]} والتحقق من اتساقها واكتمالها، وتحديدها (توثيقها)، والتحقق من صحتها (التأكد من صحة المتطلبات المحددة). ^{[ 11 ] [ 12 ]}

تُعدّ المتطلبات عرضةً لمشاكل الغموض والنقص والتناقض. وقد أثبتت تقنيات مثل التدقيق الدقيق فعاليتها في معالجة هذه المشاكل. عادةً ما تكون تكلفة تصحيح الغموض والنقص والتناقضات التي يمكن حلها في مرحلة تحديد المتطلبات أقل بكثير من تكلفة تصحيحها عند اكتشافها في مراحل لاحقة من تطوير المنتج. ويسعى تحليل المتطلبات إلى معالجة هذه المشاكل.

هناك مفاضلة هندسية يجب مراعاتها بين المتطلبات الغامضة للغاية، وتلك المفصلة لدرجة أنها

• يستغرق إنتاجها وقتاً طويلاً - أحياناً لدرجة أنها تصبح قديمة بمجرد اكتمالها
• تقييد خيارات التنفيذ المتاحة
• إنتاجها مكلف

تطورت المناهج الرشيقة كوسيلة للتغلب على هذه المشاكل، من خلال وضع خط أساس للمتطلبات على مستوى عالٍ، وتفصيل التفاصيل في الوقت المناسب أو في اللحظة الأخيرة المسؤولة .

توجد آراء متضاربة حول ماهية المتطلبات وكيفية إدارتها واستخدامها. ومن أبرز الهيئات في هذا المجال معهد مهندسي الكهرباء والإلكترونيات (IEEE) والمعهد الدولي لتحليل الأعمال (IIBA). ولكلتا الهيئتين تعريفات مختلفة ولكنها متشابهة لماهية المتطلبات.

لقد نجحت العديد من المشاريع مع وجود اتفاق ضئيل أو معدوم على المتطلبات. ^{[ 13 ]} وتشير بعض الأدلة أيضًا إلى أن تحديد المتطلبات قد يقلل من الإبداع وأداء التصميم. ^{[ 14 ]} تعيق المتطلبات الإبداع والتصميم لأن المصممين ينشغلون بشكل مفرط بالمعلومات المُقدمة. ^{[ 15 ] [ 16 ] [ 17 ]} وبشكل عام، تشير بعض الأبحاث إلى أن متطلبات البرمجيات ما هي إلا وهم ناتج عن تحريف قرارات التصميم على أنها متطلبات في حالات لا توجد فيها متطلبات حقيقية واضحة. ^{[ 18 ]}

في الوقت نفسه، تشكك معظم منهجيات تطوير البرمجيات الرشيقة في ضرورة وصف متطلبات البرمجيات بدقة مسبقًا، إذ تعتبرها هدفًا متغيّرًا. على سبيل المثال، يصف البرمجة المتطرفة المتطلبات بشكل غير رسمي باستخدام قصص المستخدم (ملخصات قصيرة يمكن كتابتها على بطاقة فهرسة تشرح جانبًا واحدًا مما يجب أن يفعله النظام)، وتعتبر من واجب المطور طلب التوضيح مباشرةً من العميل. أما المنهجيات الرشيقة فتسعى إلى جمع المتطلبات من خلال سلسلة من اختبارات القبول الآلية .

قد يحدث توسع نطاق المشروع نتيجة لتغير المتطلبات بمرور الوقت. في إدارة المتطلبات، يُسمح بتعديلها، ولكن إذا لم يتم تتبعها بشكل كافٍ، أو لم تُضبط الخطوات السابقة (أهداف العمل ثم متطلبات المستخدم) من خلال إشراف إضافي، أو لم تُعالج باعتبارها تكلفة وفشلًا محتملًا للبرنامج، فإن تغييرات المتطلبات تصبح سهلة ومحتملة الحدوث. من السهل أن تحدث تغييرات المتطلبات بسرعة تفوق قدرة المطورين على إنجاز العمل، مما يُصعّب عملية التراجع .

توجد تصنيفات متعددة للمتطلبات، وذلك بحسب الإطار الذي يتم العمل ضمنه (على سبيل المثال، المعايير الرسمية لمعهد مهندسي الكهرباء والإلكترونيات، أو نهج معهد محللي الأعمال الدولي، أو نهج وزارة الدفاع الأمريكية). وقد يؤدي اختلاف اللغة والإجراءات في مختلف السياقات أو حتى في الكلام غير الرسمي إلى حدوث ارتباك وانحراف عن المسار المطلوب.

إن أي عملية يديرها البشر عرضةٌ للعيوب البشرية في الحوكمة، حيث قد تؤدي المصالح الشخصية أو الرغبات أو الاعتبارات السياسية إلى استثناءات أو حتى تقويض العملية بشكل صريح، وانحرافات عن المسار الصحيح الذي من المفترض أن تسير عليه. ومن الأمثلة على ذلك:

• لا تحظى العملية التي تفتقر إلى الدقة بالتقدير - إذا كانت الاستثناءات أو التغييرات شائعة، مثل أن المنظمة التي تديرها لا تتمتع باستقلالية أو سلطة تذكر أو أنها غير موثوقة وشفافة في سجلاتها، فقد يؤدي ذلك إلى تجاهل العملية برمتها.
• اللاعبون الجدد الذين يرغبون في إعادة العمل - على سبيل المثال، الميل الطبيعي للأشخاص الجدد إلى الرغبة في تغيير عمل سلفهم لإظهار قوتهم أو ادعاءاتهم بالقيمة، مثل الرئيس التنفيذي الجديد الذي يرغب في تغيير تخطيط الرئيس التنفيذي السابق، بما في ذلك أهداف العمل، لشيء ما (مثل حل برمجي) قيد التطوير بالفعل، أو مكتب تم إنشاؤه حديثًا يعترض على التطوير الحالي لمشروع ما لأنه لم يكن موجودًا عند صياغة متطلبات المستخدم، لذلك يبدأون في بذل جهد للتراجع وإعادة وضع خط الأساس للمشروع.
• التلوين خارج الخطوط - على سبيل المثال، لا يقوم المستخدمون الذين يرغبون في مزيد من التحكم بإدخال الأشياء التي تلبي تعريف إدارة المتطلبات لـ "متطلبات المستخدم" أو مستوى الأولوية، ولكنهم يقومون بإدخال تفاصيل التصميم أو خصائص البائع المفضل كمتطلبات للمستخدم أو كل ما يقوله مكتبهم كأعلى أولوية ممكنة.
• التأخر عن الحضور - على سبيل المثال، عدم بذل جهد يُذكر في تحديد المتطلبات قبل بدء التطوير. قد يعود ذلك إلى اعتقادهم بأنهم سيحصلون على الفائدة نفسها بغض النظر عن مشاركتهم الفردية، أو أنه لا جدوى من ذلك إذا كان بإمكانهم ببساطة إضافة المتطلبات في مرحلة الاختبار والإصدار التالي، أو تفضيلهم أن يكونوا على صواب دائمًا من خلال انتظار النقد بعد انتهاء العمل.

في إطار عملية وزارة الدفاع الأمريكية، تتضمن بعض الأمثلة التاريخية لمشاكل المتطلبات ما يلي:

• قضايا مركبة إم-2 برادلي المتعلقة بحركة المتطلبات غير الرسمية التي تم تصويرها في حروب البنتاغون ؛
• إن تطور طائرة إف-16 من مفهوم المقاتلة الخفيفة لمافيا المقاتلات ، والذي يُعزى إلى برنامج إف-15 الذي يحاول تخريب المنافسة أو المكاتب الفردية التي تضع رغبات محلية تقوض مفهوم كونها خفيفة الوزن ومنخفضة التكلفة.
• أدى الحماس الذي ظهر في عام 1998 تقريبًا لمفهوم "الجاهزية للشبكة" إلى تفويضه كمعيار أداء رئيسي من مكتب "الجاهزية للشبكة"، خارج نطاق عملية تحديد المتطلبات في المكتب، وهو أمر لا يتوافق مع العملية المحددة مسبقًا لهذا المكتب، أو تعريفهم لماهية معيار الأداء الرئيسي، أو أن بعض الجهود قد لا تكون مناسبة أو قادرة على تحديد ما يشكل "الجاهزية للشبكة".