استخلاص المتطلبات

في هندسة المتطلبات ، يُعرف استخلاص المتطلبات بأنه عملية البحث والاكتشاف لمتطلبات النظام من المستخدمين والعملاء وأصحاب المصلحة الآخرين. ^{[ 1 ]} ويُشار إلى هذه العملية أحيانًا باسم " جمع المتطلبات ".

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

قبل تحليل المتطلبات أو نمذجتها أو تحديدها، يجب جمعها من خلال عملية استخلاص المعلومات، وهي خطوة أساسية مبكرة في هندسة المتطلبات.

من عمليات استخلاص المعلومات الشائعة اجتماعات أو مقابلات أصحاب المصلحة. ^{[ 2 ]} على سبيل المثال، قد يكون الاجتماع الأول المهم بين مهندسي البرمجيات والعملاء حيث يناقشون وجهة نظرهم بشأن المتطلبات.

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

في عام 1992، حدد كريستل وكانغ المشكلات التي تشير إلى التحديات التي تواجه استخلاص المتطلبات: ^{[ 3 ]}

1. " مشاكل النطاق" . حدود النظام غير محددة بشكل جيد أو أن العملاء/المستخدمين يحددون تفاصيل فنية غير ضرورية قد تؤدي إلى تشويش أهداف النظام العامة بدلاً من توضيحها.
2. مشاكل الفهم . العملاء/المستخدمون ليسوا متأكدين تمامًا مما هو مطلوب، ولديهم فهم ضعيف لإمكانيات وقيود بيئة الحوسبة الخاصة بهم، وليس لديهم فهم كامل لمجال المشكلة، ويواجهون صعوبة في توصيل الاحتياجات إلى مهندس النظام، ويحذفون معلومات يُعتقد أنها " بديهية "، ويحددون متطلبات تتعارض مع احتياجات عملاء/مستخدمين آخرين، أو يحددون متطلبات غامضة أو غير قابلة للاختبار.
3. مشاكل التقلب . تتغير المتطلبات بمرور الوقت. ويُشار أحيانًا إلى معدل هذا التغيير بمستوى تقلب المتطلبات.

يمكن تحسين جودة المتطلبات من خلال هذه الأساليب: ^{[ 4 ]}

1. التصور . استخدام الأدوات التي تعزز فهمًا أفضل للمنتج النهائي المطلوب مثل التصور والمحاكاة.
2. استخدام لغة متسقة . استخدام تعريفات بسيطة ومتسقة للمتطلبات الموصوفة بلغة طبيعية واستخدام المصطلحات التجارية السائدة في المؤسسة.
3. إرشادات . يتم اتباع الإرشادات التنظيمية التي تصف أساليب جمع البيانات وأنواع المتطلبات المطلوب جمعها. ثم تُستخدم هذه الإرشادات بشكل متسق في جميع المشاريع.
4. الاستخدام المتسق للقوالب . إنتاج مجموعة متسقة من النماذج والقوالب لتوثيق المتطلبات.
5. توثيق التبعيات . توثيق التبعيات والعلاقات المتبادلة بين المتطلبات.
6. تحليل التغييرات . إجراء تحليل للأسباب الجذرية للتغييرات في المتطلبات واتخاذ الإجراءات التصحيحية.

في عام 1997، اقترح سومرفيل وسوير مجموعة من المبادئ التوجيهية لاستخلاص المتطلبات، لمعالجة المخاوف مثل تلك التي حددها كريستيل وكانغ: ^{[ 5 ]}

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

في عام 2004، اقترح جولدسميث "هرم المشكلة" المكون من "ست خطوات يجب تنفيذها بالتسلسل": ^{[ 6 ]}

1. حدد المشكلة أو الفرصة أو التحدي الحقيقي
2. حدد الإجراء (الإجراءات) الحالية التي تُظهر أن المشكلة حقيقية
3. حدد مقياس (مقاييس) الهدف لإظهار معالجة المشكلة وقيمة تحقيقها
4. حدد السبب (الأسباب) الكامنة وراء المشكلة، لأن الحل يكمن في معالجة الأسباب وليس المشكلة نفسها.
5. حدد "رغبات" العمل التي يجب تلبيتها لتحقيق الهدف (الأهداف)
6. حدد تصميم المنتج الذي يلبي متطلبات العمل الحقيقية

لكن غولدسميث يشير إلى أن تحديد المشكلة الحقيقية "أمر في غاية الصعوبة". ^{[ 6 ]}

في عام 2008، اقترح ألكسندر وبيوس دوكيتش مجموعة من الأساليب التكميلية لاكتشاف المتطلبات: ^{[ 7 ]}

• تحديد أصحاب المصلحة
• أهداف النمذجة
• سياق النمذجة
• اكتشاف السيناريوهات (أو حالات الاستخدام )
• اكتشاف "الصفات والقيود" ( المتطلبات غير الوظيفية )
• الأساس المنطقي للنمذجة والافتراضات
• كتابة تعريفات المصطلحات
• تحليل القياسات (معايير القبول)
• تحليل الأولويات

اقترح ألكسندر وبيوس دوكيتش أنه يمكن إجراء هذه الأساليب مع الأفراد (كما هو الحال في المقابلات )، أو مع المجموعات (كما هو الحال في الاجتماعات المركزة المعروفة باسم ورش العمل، أو عبر أنظمة الاجتماعات الإلكترونية )، أو من "الأشياء" (القطع الأثرية) مثل النماذج الأولية . ^{[ 7 ]}

في عام ٢٠٠٩، اقترحت ميلر مجموعة من أكثر من ٢٠٠٠ سؤال لاستخلاص المتطلبات غير الوظيفية. ^{[ ٨ ]} يتمثل نهجها في بناء ملف تعريف لأصحاب المصلحة ثم إجراء مقابلات معمقة معهم. تُصنف الأسئلة في ثلاثة أقسام، تركز جميعها على احتياجات المستخدم: ^{[ ٨ ]}

1. العملية: ما مدى جودة استخدام [يحتاج إلى تعديل]؟
2. مراجعة: ما مدى سهولة تصحيح الأخطاء وإضافة الوظائف؟
3. الانتقال: ما مدى سهولة التكيف مع التغييرات في البيئة التقنية؟

في عام 2013، اقترح مورالي شيموتوري استخدام متطلبات الوظائف المساعدة بدلاً من المتطلبات غير الوظيفية، لأن مصطلح "غير وظيفي" يوحي بأنه "غير وظيفي على الإطلاق". ثانياً، تلبي هذه المتطلبات في الواقع بعض المتطلبات الداعمة لمتطلبات الوظائف الرئيسية أو الأساسية. ^{[ 9 ]}

• ألكسندر، إيان ف.؛ بيوس-دوكيتش، ليركا (مارس 2009). اكتشاف المتطلبات: كيفية تحديد المنتجات والخدمات . جون وايلي. ISBN 978-0-470-71240-5.
• جولدسميث، روبن ف. (2004). اكتشاف متطلبات العمل الحقيقية لنجاح مشاريع البرمجيات . دار أرتيك هاوس. ISBN 1-58053-771-5.
• ميلر، روكسان إي. (2009). البحث عن متطلبات البرمجيات: أسئلة استقصائية لتسليط الضوء على المتطلبات غير الوظيفية؛ تقنيات مُثبتة لضمان مشاركة أصحاب المصلحة المناسبين . دار مافن مارك للنشر. رقم ISBN 978-1-59598-067-0.
• سومرفيل، إيان ؛ سوير، بيت (مايو 1997). هندسة المتطلبات: دليل الممارسات الجيدة . جون وايلي. ISBN 0-471-97444-7.
•  غوبوف، دينيس، هوتشينكو، إينا. (2020) . تقنيات استخلاص المتطلبات لمشاريع البرمجيات في مجال تكنولوجيا المعلومات الأوكرانية: دراسة استكشافية. http://dx.doi.org/10.15439/2020F16

• التوسع التدريجي