التقنيات الأساسية لتحديد المتطلبات المفقودة؟

Question

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

ما هي التقنيات الجيدة والفعالة لتحديد المتطلبات المفقودة والضمنية؟

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

_{يسعدني إعادة زيارة الإجابة المقبولة، طالما أن شخصًا ما يقدم حلاً أفضل وأكثر شمولاً.}

Answer 1

تقييم دورة حياة عناصر النموذج فيما يتعلق بالنموذج العام/الشامل مثل

acquisition --> stewardship --> disposal

• هل تعرف من أين يأتي كل كيان وكيف ستدخله إلى نظامك؟
• هل تعرف أين سيتواجد كل كيان، بمجرد الحصول عليه، وإلى متى؟
• هل تعرف ماذا تفعل مع كل كيان عندما لم تعد هناك حاجة إليه؟

للحصول على تحليل أكثر دقة لدورة حياة الكيانات في المواصفات، قم بإنشاء مصفوفة CRUDE للكيانات الرئيسية في المتطلبات؛هذه مصفوفة تحتوي على العمليات/التطبيقات كصفوف والكيانات كأعمدة.في كل خلية، ضع C إذا كان التطبيق ينشئ الكيان، أو R للقراءات، أو U للتحديثات، أو D للحذف، أو E لـ "التعديلات"؛يشمل "E" C وR وU وD (معظم تطبيقات "صيانة الجدول الرئيسي" ستكون Es).ثم تحقق من كل عمود بحثًا عن C وR وU وD (أو E)؛إذا كان أحد المفقودين (باستثناء E)، معرفة ما إذا كان هناك حاجة إليه.يمكن إعادة ترتيب صفوف وأعمدة المصفوفة (يدويًا أو باستخدام تحليل التقارب) لتشكيل مجموعات متماسكة من الكيانات والتطبيقات التي تتوافق بشكل عام مع الأنظمة الفرعية؛قد يساعد هذا في توزيع النظام الفعلي لاحقًا.

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

الهدف هو التحقق من اكتمال المواصفات؛تعتبر التقنيات المذكورة أعلاه مفيدة للتحقق مما إذا كانت دورة حياة الكيانات "مغلقة" فيما يتعلق بالكيانات والتطبيقات المحددة

Answer 2

التواصل المستمر والمتكرر والصريح والثنائي مع العميل يبدو لي أنه "الأسلوب" الرئيسي بالنسبة لي.

Answer 3

هذا يعتمد.

يعتمد الأمر على ما إذا كنت تحصل على أموال مقابل تسليم ما قلت أنك ستسلمه أو تقديم برامج عالية الجودة إلى العميل.

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

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

Answer 4

وإليك كيفية العثور على المتطلبات المفقودة.

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

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

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

4. احصل على إجماع على أفضل اثنين أو ثلاثة فقط.لا تجادل في كل الفروق الدقيقة.ليس من الممكن تصور البرمجيات.لا يمكن لأي شخص أن يتصور كيف سيكون شكل البرنامج وكيف سيستخدمه.إن "متطلبات" معظم الأشخاص هي وصف لكيفية النضال من أجل التغلب على العمليات التجارية غير الكافية التي يعانون منها اليوم.

5. قم ببناء الجزء ذو الأولوية القصوى والأكثر أهمية أولاً.أعطها للمستخدمين.

6. اذهب إلى 1 وكرر العملية.

"انتظر ،" أنت تقول ، "ماذا عن الميزانية الإجمالية؟" ماذا عنها؟لا يمكنك أبدًا معرفة الميزانية الإجمالية.قم بما يلي.

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

Answer 5

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

لقد استخدمت المنهجية في حوالي ستة مشاريع حتى الآن تتراوح من أقل من مائة متطلبات إلى أكثر من 1300 متطلبات.إذا كنت تريد معرفة المزيد أود أن أقترح الذهاب إلى www.behaviorengineering.org هناك بعض الأوراق الجيدة حقا فيما يتعلق بالمنهجية.

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

آمل أن يساعد هذا

مايكل لارسن

Answer 6

ماذا عن بناء نموذج أولي؟

Answer 7

أثناء قراءتي للعديد من المؤلفات المتعلقة بمتطلبات البرامج، وجدت هذين الكتابين المثيرين للاهتمام:

• إطارات المشكلة:تحليل وهيكلة مشاكل تطوير البرمجيات بواسطة مايكل جاكسون (ليس مغني!:-).

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

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

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

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

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

آخر ملاحظاتي المهمة حول هذه الكتب:

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

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

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

هث...

Answer 8

وأنا أتفق مع جالويجيان.تعتبر التقنية الموضحة أكثر كفاءة بكثير من أسلوب "انتظار العميل ليصرخ علينا".