متطلبات التحليل: الفرق بين النسختين

اذهب إلى التنقل اذهب إلى البحث
تم إضافة 47 بايت ، ‏ قبل 6 سنوات
ط
WPCleaner v1.34b - باستخدام وب:فو (عناوين تبدأ برمز "=" واحد - تدرج العناوين)
ط (تهذيب، إضافة/إزالة وسوم صيانة، أضاف وسوم يتيمة، مقالات غير مصنفة، ويكي)
ط (WPCleaner v1.34b - باستخدام وب:فو (عناوين تبدأ برمز "=" واحد - تدرج العناوين))
}}</ref> المتطلبات ينبغي أن تكون موثقة وقابلة للتنفيذ وقابلة للقياس، قابل للاختبار، يمكن تتبعها،وهي ذات صلة باحتياجات الأعمال المحددة أو فرص والمعرفة إلى مستوى تفصيل كافية لتصميم نظام.
 
== نظره عامة ==
من الناحية المفاهيمية، تحليل متطلبات تتضمن ثلاثة أنواع من الأنشطة:
 
•توثيق التبعيات. توثيق التبعيات والعلاقات المتبادلة بين الاحتياجات، فضلا عن أي من الافتراضات.
 
== مواضيع متطلبات التحليل ==
=== تحديد أصحاب المصلحة ===
نظر تحليل أصحاب المصلحة للمناقشة مع الأشخاص أو المنظمات )كيانات قانونية مثل شركات وهيئات) التي لها مصلحة في النظام. قد تتأثر بذلك أما مباشرة أو غير مباشرة. كان التركيز الرئيسية في التسعينات على تحديد هوية أصحاب المصلحة. هو اعتراف متزايد أن أصحاب المصالح لا تقتصر على تنظيم توظيف المحلل.وسوف تشمل أصحاب المصلحة الآخرين:
 
• هذه المنظمات الذين تتكامل أفقياً مع المنظمة الذين يقومون بتصميم النظام
 
=== مقابلات مع أصحاب المصلحة ===
 
مقابلات مع أصحاب المصلحة تقنية شائعة المستخدمة في تحليل الاحتياجات. وتكون القابله على وجهات النظر والاحتياجات المتصورة لأصحاب المصلحة، غالباً ما هذا القصور من منظور لها ميزة عامة للحصول على فهم أكثر ثراء بكثير من العمليات التجارية فريدة من نوعها لأصحاب المصلحة وقواعد الأعمال التجارية ذات الصلة بالمقرر والاحتياجات المتصورة. ونتيجة لذلك يمكن أن تكون هذه التقنية كما هو غالباً مالم تحظ وسيلة للحصول على المعرفة تركيزاً عاليا في الدورات "المشتركة متطلبات التنمية"، حيث ان أصحاب المصالح مضطرون لتحمل عمليه سياقا أكثر التبادلية، والرغبة في تجنب الجدل قد يحد من رغبة أصحاب المصلحة للمساهمة. وعلاوة على ذلك، طبيعة الشخص في المقابلات التي توفر بيئة أكثر استرخاء حيث يمكن استكشاف خطوط الفكر مطولاً.
=== متطلبات التنمية (جرد) ===
 
غالباً ما يكون متطلبات الآثار التبادلية الغير معروفة لأصحاب المصلحة الفردية، وغالباً ما تكون محددة بشكل غير كامل أثناء المقابلات التي أجريت مع أصحاب المصلحة. يمكن أثارت هذه الآثار الفنية بإجراء جرد دورات في بيئة تسيطر عليها المدربين (محلل للأعمال)، حيث يشارك أصحاب المصالح في المناقشات الحصول على الاحتياجات، وتحليل التفاصيل الخاصة بهم، والكشف عن الآثار الفنية. وينبغي أن تكون المناقشات تؤدي الى اتجاه الذي يولد الشروط المناسبة التي تفي الهدف من الدورة.
دورات جرد شبيهة "دورات تصميم التطبيق" ، الدورات التي تعمل على استخلاص متطلبات دليل التصميم، في حين أن هذا يؤدي بالحصول على ميزات تصميم محددة و تنفيذها في إشباع الاحتياجات.
 
=== قوائم شرط ومتطلبات العقد ===
 
كانت إحدى الطرق التقليدية لتوثيق متطلبات العقد . في نظام معقد يمكن تشغيل هذه القوائم المتطلبات لمئات من صفحات طويلة.
استعارة المناسبة راغبه في تسوق منذ فترة طويلة جداً. هذه القوائم إلى حد كبير من المؤيدين في التحليل الحديثة؛ كماثبت أنها فاشلة فشلاً ذريعا في تحقيق أهدافها؛ إلا أنها تزال تعتبر حتى يومنا هذا.
 
==== نقاط القوة ====
• توفير قائمة متطلبات.
 
• النظام كبير يمكن أن تقدم وصفاً رفيع مستوى يمكن أن تستمد منها متطلبات المستوى الأدنى
 
==== نقاط الضعف ====
 
• يمكن تشغيل هذه القوائم لمئات صفحات. غير أنها معدّة لتكون بمثابة وصف للقارئ للتطبيق المطلوب.
• يكاد يكون من المستحيل لكشف جميع المتطلبات الوظيفية أمام العملية التنمية، ويبدأ الاختبار. إذا كانت هذه القوائميعاملون كعقد غير قابل للتغيير، ثم الاحتياجات التي تنشأ في عملية التنمية قد تولد طلب تغيير مثير للجدل.
 
==== بديل لقوائم المتطلبات ====
كبديل للشرط يستخدم قوائم " برمجية تطوير" قصص المستخدم لتشير إلى شرط في كل لغة اليوم.
 
=== الأهداف القابلة للقياس ===
المقال الرئيسي: هدف النمذجة
 
أفضل الممارسات تأخذ قائمة تتألف من متطلبات كمجرد القرائن ومرارا وتكرارا نسأل "لماذا؟" حتى يتم اكتشاف أغراض تجارية فعلية. أصحاب المصلحة والمطورين يمكنهم وضع اختبارات قياس ما هو مستوى كل هدف وقد تحقق حتى الآن. هذه الأهداف تتغير ببطء أكثر من قائمة طويلة من متطلبات محددة ولكن المقيسة. وبمجرد مجموعة صغيرة من الحرج، قياس الأهداف كانت النماذج المتبعة، وسرعة وقد تمضي مراحل التطوير التكراري بوقت قصير لتسليم أصحاب المصلحة الفعلية القيمة الفعليه قبل المشروع.
 
=== النماذج الأولية ===
المقال الرئيسي: النماذج البرمجيات
 
النماذج الأولية يمكن أن تكون مخططات مسطحه أو عمل التطبيقات التي تستخدم وظائف تجميعي. مصنوعة في مجموعة متنوعة من وثائق تصميم الرسوم البيانية، وكثيراً ما إزالة جميع الألوان من التصميم (أي استخدام لوحة ألوان اللون رمادي)في الحالات التي من المتوقع أن يكون تصميم رسومي يطبق لأنه فيها البرنامج النهائي. وهذا يساعد على منع الالتباس فيما يتعلق بما إذا كان يمثل النموذج النهائي البصرية الشكل والمظهر من التطبيق.
 
=== حالات الاستخدام ===
المقال الرئيسي: حالات الاستخدام
 
حالات الاستخدام أدوات بسيطة مخادعة لوصف سلوك البرمجيات أو الأنظمة. حالة استخدام يحتوي على وصف نصيةمن الطرق التي يراد بها المستخدمين العمل مع البرامج أو النظام. ينبغي أن لا تصف حالات استخدام أساليب العمل الداخلية للنظام، ولا ينبغي أن تفسر كيف سيتم تنفيذ هذا النظام. بدلاً من ذلك، أنها تظهر الخطوات اللازمة لتنفيذ مهمة.
 
=== متطلبات مواصفة ===
ناتج عملية تحليل متطلبات مواصفة متطلبات.
== أنواع الاحتياجات ==
 
وتصنف الاحتياجات في عدة طرق. وفيما يلي التصنيفات الشائعة للمتطلبات التي تتعلق بالإدارة التقنية:<ref name="SEF01"/>
شرط الذي تم إنشاؤه بتقسيم أو خلاف ذلك تخصيص مطلب رفيع المستوى إلى الاحتياجات المتعددة للمستوى الأدنى.على سبيل المثال: قد يؤدي عنصر 100 جنيه الذي يتكون من نظامين فرعيين في متطلبات الوزن من 70 مليون جنيه و30 مليون جنيه لعناصر المستوى الأدنى اثنين
 
== متطلبات تحليل القضايا ==
=== قضايا أصحاب المصلحة ===
Steve McConnell ، في كتاب له "التطور السريع"، تفاصيل عدد من مستخدمي الطرق يمكن أن تحول دون جمع المتطلبات:
 
وهذا قد يؤدي إلى حالة حيث تتغير متطلبات المستخدم حتى عندما بدأ تطوير النظام أو المنتج.
 
=== مهندس/المطور المسائل ===
المشاكل المحتملة الناجمة عن المهندسين والمطورين أثناء تحليل المتطلبات:
 
• يمكن غالباً إجراء تحليل بالمهندسين أو المبرمجين، بدلاً من العاملين بمجال المعرفة فهم احتياجات العميل بشكل صحيح.
 
=== محاولة الحلول ===
قد تم حل محاولة واحدة لمشاكل الاتصالات توظيف متخصصين في الأعمال التجارية أو تحليل النظام.
 
• القدرة للمستخدمين البعيد والموزعة تشغيل وتتفاعل مع المحاكاة
 
== المراجع ==
 
{{غير مصنفة|تاريخ=يناير 2015}}
1٬400٬382

تعديل

قائمة التصفح