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