مستخدم:لؤي القاضي/ملعب

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

نظرة عامة

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

تحديد أصحاب المصلحة

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

مقبلات أصحاب المصلحة

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

متطلبات التنمية

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

قوائم الشرط

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

نقاط القوة

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

أنواع المتطلبات

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

المراجع

Systems Engineering Fundamentals Defense Acquisition University Press, 2001

^ Kotonya, G. and Sommerville, I. 1998. Requirements Engineering: Processes and Techniques Chichester, UK: John Wiley and Sons. ^ Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis (الناشر). Guide to the software engineering body of knowledge (الطبعة 2004). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7. اطلع عليه بتاريخ 2007-02-08. ^ Murali Chemuturi, Requirements Engineering and Management for Software Dvelopment Projects [1].