تحليل المتطلبات

راجع قسم تحليل أصحاب المصلحة لمناقشة الأفراد أو المنظمات (الكيانات القانونية مثل الشركات وهيئات وضع المعايير) التي لها مصلحة مشروعة في النظام. وقد يتأثرون به بشكل مباشر أو غير مباشر.

كان التركيز الرئيسي الجديد في التسعينيات على تحديد أصحاب المصلحة . ومن المسلّم به على نحو متزايد أن أصحاب المصلحة لا يقتصرون على المنظمة التي يعمل بها المحلل، بل يشملون أيضاً:

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

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

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

إحدى الطرق التقليدية لتوثيق المتطلبات هي قوائم المتطلبات على غرار العقود. في الأنظمة المعقدة، قد تصل هذه القوائم إلى مئات الصفحات.

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

تعتبر أفضل الممارسات قائمة المتطلبات مجرد مؤشرات، وتطرح باستمرار سؤال "لماذا؟" حتى يتم اكتشاف الأهداف التجارية الحقيقية. عندها، يمكن لأصحاب المصلحة والمطورين وضع اختبارات لقياس مدى تحقيق كل هدف حتى الآن. تتغير هذه الأهداف بوتيرة أبطأ من قائمة طويلة من المتطلبات المحددة غير القابلة للقياس. بمجرد تحديد مجموعة صغيرة من الأهداف الحاسمة والقابلة للقياس، يمكن البدء في النمذجة السريعة ومراحل التطوير التكرارية القصيرة لتحقيق قيمة حقيقية لأصحاب المصلحة قبل وقت طويل من اكتمال نصف المشروع.

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

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

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

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

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

بيانات عن أهداف العمل على مستوى الشركة، دون الإشارة إلى الوظائف التفصيلية. وعادةً ما تكون هذه البيانات عبارة عن قدرات عالية المستوى (برمجيات و/أو أجهزة) ضرورية لتحقيق نتائج العمل.

بيانات الحقائق والافتراضات التي تحدد توقعات النظام من حيث أهداف المهمة، والبيئة، والقيود، ومقاييس الفعالية والملاءمة. العملاء هم أولئك الذين يؤدون الوظائف الأساسية الثمانية لهندسة النظم، مع التركيز بشكل خاص على المشغل باعتباره العميل الرئيسي. ستحدد المتطلبات التشغيلية الحاجة الأساسية، وستجيب، كحد أدنى، على الأسئلة المطروحة في القائمة التالية: ^{[ 1 ]}

• التوزيع أو النشر التشغيلي : أين سيتم استخدام النظام؟
• نبذة عن المهمة أو السيناريو : كيف سيحقق النظام هدف مهمته؟
• الأداء والمعايير ذات الصلة : ما هي معايير النظام الحاسمة لإنجاز المهمة؟
• بيئات الاستخدام : كيف سيتم استخدام مكونات النظام المختلفة؟
• متطلبات الفعالية : ما مدى فعالية أو كفاءة النظام في أداء مهمته؟
• دورة الحياة التشغيلية : ما هي المدة التي سيستخدم فيها المستخدم النظام؟
• البيئة : ما هي البيئات التي يُتوقع أن يعمل فيها النظام بطريقة فعالة؟

توضح المتطلبات المعمارية ما يجب القيام به من خلال تحديد بنية الأنظمة الضرورية للنظام .

توضح المتطلبات السلوكية ما يجب القيام به من خلال تحديد السلوك الضروري للنظام.

توضح المتطلبات الوظيفية ما يجب القيام به من خلال تحديد المهمة أو الإجراء أو النشاط الضروري الذي يجب إنجازه. وسيتم استخدام تحليل المتطلبات الوظيفية كوظائف أساسية للتحليل الوظيفي. ^{[ 1 ]}

المتطلبات غير الوظيفية هي متطلبات تحدد المعايير التي يمكن استخدامها للحكم على تشغيل النظام، بدلاً من السلوكيات المحددة.

يُقاس مدى ضرورة تنفيذ مهمة أو وظيفة ما عمومًا من حيث الكمية والجودة والتغطية والتوقيت والجاهزية. خلال تحليل المتطلبات، تُطوَّر متطلبات الأداء (مدى جودة التنفيذ المطلوب) بشكل تفاعلي عبر جميع الوظائف المحددة بناءً على عوامل دورة حياة النظام، وتُوصَف من حيث درجة اليقين في تقديرها، ودرجة أهميتها لنجاح النظام، وعلاقتها بالمتطلبات الأخرى. ^{[ 1 ]}

تُعبّر حزم البيانات الفنية والأدلة الفنية عن متطلبات "التصميم وفقًا لـ" و"البرمجة وفقًا لـ" و"الشراء وفقًا لـ" للمنتجات ومتطلبات "كيفية التنفيذ" للعمليات. ^{[ 1 ]}

المتطلبات التي تُستنتج ضمنيًا أو تُحوّل من متطلبات أعلى مستوى. على سبيل المثال، قد يؤدي شرط المدى الطويل أو السرعة العالية إلى شرط تصميمي يتمثل في الوزن الخفيف. ^{[ 1 ]}

يتم تحديد المتطلبات بتقسيم أو تخصيص متطلب رئيسي إلى عدة متطلبات فرعية. مثال: قد ينتج عن عنصر يزن 100 رطل ويتكون من نظامين فرعيين متطلبات وزن تبلغ 70 رطلاً و30 رطلاً للعنصرين الفرعيين. ^{[ 1 ]}

تشمل نماذج تصنيف المتطلبات المعروفة FURPS و FURPS+، والتي تم تطويرها في شركة هيوليت-باكارد .

يشرح ستيف ماكونيل، في كتابه "التطوير السريع" ، عدداً من الطرق التي يمكن للمستخدمين من خلالها عرقلة عملية جمع المتطلبات:

• لا يفهم المستخدمون ما يريدونه أو ليس لديهم فكرة واضحة عن متطلباتهم
• لن يلتزم المستخدمون بمجموعة من المتطلبات المكتوبة
• يصر المستخدمون على متطلبات جديدة بعد تحديد التكلفة والجدول الزمني
• التواصل مع المستخدمين بطيء
• غالباً ما لا يشارك المستخدمون في كتابة التقييمات أو يكونون غير قادرين على القيام بذلك.
• المستخدمون غير ملمين بالجوانب التقنية
• لا يفهم المستخدمون عملية التطوير
• لا يعرف المستخدمون عن التكنولوجيا الحالية

قد يؤدي هذا إلى حالة تستمر فيها متطلبات المستخدم في التغير حتى بعد بدء تطوير النظام أو المنتج.

المشاكل المحتملة التي يسببها المهندسون والمطورون أثناء تحليل المتطلبات هي:

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

تمثلت إحدى المحاولات لحل مشاكل الاتصالات في توظيف متخصصين في تحليل الأعمال أو النظم.

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

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

• ألواح بيضاء إلكترونية لرسم مخططات تدفق التطبيقات واختبار البدائل
• القدرة على استيعاب منطق الأعمال واحتياجات البيانات
• القدرة على إنشاء نماذج أولية عالية الدقة تحاكي التطبيق النهائي بشكل دقيق
• التفاعلية
• إمكانية إضافة متطلبات سياقية وتعليقات أخرى
• إمكانية تشغيل المحاكاة والتفاعل معها من قبل المستخدمين عن بُعد والموزعين