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

نظر تحليل أصحاب المصلحة للمناقشة مع الأشخاص أو المنظمات )كيانات قانونية مثل شركات وهيئات) التي لها مصلحة في النظام. قد تتأثر بذلك أما مباشرة أو غير مباشرة. كان التركيز الرئيسية في التسعينات على تحديد هوية أصحاب المصلحة. هو اعتراف متزايد أن أصحاب المصالح لا تقتصر على تنظيم توظيف المحلل.وسوف تشمل أصحاب المصلحة الآخرين:

•شخص يعمل النظام (عوامل التشغيل العادي والصيانة)

• أي شخص يستفيد من هذا النظام(المستفيدين الوظيفية والسياسية، والمالية والاجتماعية)

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

• المنظمات التي تنظم جوانب النظام (المالية، السلامة، والهيئات التنظيمية الأخرى)

• ألاشخاص أو المنظمات المعارضة للنظام (أصحاب المصلحة السلبية)

• المنظمات المسؤولة عن النظم الذي واجهة مع النظام في إطار التصميم

• هذه المنظمات الذين تتكامل أفقياً مع المنظمة الذين يقومون بتصميم النظام

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

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

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

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

• توفير قائمة متطلبات.

• تقديم عقد مبرم بين المقدمين المشروع والمطورين.

• النظام كبير يمكن أن تقدم وصفاً رفيع مستوى يمكن أن تستمد منها متطلبات المستوى الأدنى

• يمكن تشغيل هذه القوائم لمئات صفحات. غير أنها معدّة لتكون بمثابة وصف للقارئ للتطبيق المطلوب.

• مجردة مثل قوائم الاحتياجات كافة المتطلبات، وحتى لا يكون هناك القليل من السياق. محلل الأعمال قد تتضمن سياق للمتطلبات في تصميم الوثائق المرافقة.

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

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

• القائمة لا يحل محل الحاجة إلى استعراض المتطلبات بعناية مع أصحاب المصلحة من أجل اكتساب فهم مشترك أفضل للآثار المترتبة بالنسبة التصميم النظام المطلوب/التطبيق.

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

• ويمكن إنشاء هذه القوائم شعور زائف بالتفاهم المتبادل بين أصحاب المصلحة والمطورين؛ محللي الأعمال ذات الأهمية الحاسمة لعملية الترجمة.

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

كبديل للشرط يستخدم قوائم " برمجية تطوير" قصص المستخدم لتشير إلى شرط في كل لغة اليوم.

المقال الرئيسي: هدف النمذجة

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

المقال الرئيسي: النماذج البرمجيات

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

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

المقال الرئيسي: حالات الاستخدام

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

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

ناتج عملية تحليل متطلبات مواصفة متطلبات.

Steve McConnell ، في يوكتاب له "التطور السريع"، تفاصيل عدد من مستخدمي الطرق يمكن أن تحول دون جمع المتطلبات:

• المستخدمين لا يفهمون ما يريدون أو المستخدمين ليس لديهم فكرة واضحة عن احتياجاتها

• المستخدمين سوف لا نلتزم بمجموعة من الشروط المكتوبة

• المستخدمين الإصرار على المتطلبات الجديدة بعد أن تم إصلاح التكلفة والجدول الزمني

• بطيء للاتصال مع المستخدمين

• المستخدمين غالباً ما لا يشاركون في المراجعات أو غير قادرين على القيام بذلك

• المستخدمين غير متطورة تقنيا

• المستخدمين لا يفهمون في عملية التنمية

• المستخدمين لا يعرفون التكنولوجيا الحالية

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

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

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

• قد يكون المفردات المختلفة للموظفين التقنيين والمستخدمين النهائيين. ونتيجة لذلك، أنهم قد يعتقدون خطأ ففي اتفاق مثالي حتى يتم توفير المنتج النهائي.

• المهندسين والمطورين قدمو محاولات لجعل المتطلبات احتواء النظام القائم، أو نموذج، بدلاً من وضع نظام محدد لاحتياجات العميل.

• يمكن غالباً إجراء تحليل بالمهندسين أو المبرمجين، بدلاً من العاملين بمجال المعرفة فهم احتياجات العميل بشكل صحيح.

قد تم حل محاولة واحدة لمشاكل الاتصالات توظيف متخصصين في الأعمال التجارية أو تحليل النظام.

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

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

• ألواح الكتابة الإلكترونية رسم تدفقات تطبيق واختبار البدائل

• القدرة على التعرف على احتياجات المنطق وبيانات الأعمال

• القدرة على إنشاء نماذج عالية الدقة أن يقلد عن كثب التطبيق النهائي التفاعل

• القدرة على إضافة متطلبات السياقية وتعليقات أخرى

• القدرة للمستخدمين البعيد والموزعة تشغيل وتتفاعل مع المحاكاة