جمع المتطلبات

Question

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

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

Answer 1

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

Answer 2

انظر الهزلي الإلزامي أدناه...

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

بمجرد إنشاء نموذج الأعمال العام، أنتقل بعد ذلك إلى "يجب" و"لا يجب" للتطبيق لإملاء البيانات التي يمكنني استردادها، ومن يمكنه أداء الوظائف، وما إلى ذلك.

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

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

أتمنى أن يساعدك هذا!

Answer 3

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

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

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

والبشر يفشلون فشلا ذريعا في هذا الأمر مع تكرار مثير للقلق بسبب عيوبهم الرائعة.

Agile يفعل الصواب في تعزيز التطوير التكراري.يعد توفير الإصدارات المبكرة للعميل أمرًا مهمًا في تحديد الميزات الأكثر أهمية (ما يأتي في 0.1 - 0.5)، ويساعد على إبقاءكما على المسار الصحيح فيما يتعلق بكيفية عمل التطبيق ويحدد الميزات المخفية بسرعة أنت سوف يفتقد.

السيناريوهان الرئيسيان للمشكلة هما طرفي الميزان:

• ليس لديك أدنى فكرة عما تفعله - احصل على بعض خبراء المجال
• وجود الكثير من المتطلبات - حفرة الميزة.- ميزات السؤال والاختيار (تحديد الأولويات ;)) واستخدام التطوير التكراري

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

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

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

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

Answer 4

واو، من أين تبدأ؟

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

ثانيا، هناك أنواع مختلفة من المتطلبات.

• أهداف:ما الذي يريد المستخدم تحقيقه؟
• وظيفي:ما الذي يجب على المستخدم فعله للوصول إلى هدفه؟(فكر في الخطوات اللازمة للوصول إلى الهدف/الأهداف)
• غير وظيفية:ما هي القيود التي يحتاج برنامجك إلى تنفيذها؟(فكر في 10 مقابل 10 آلاف مستخدم متزامن، والنمو، والنسخ الاحتياطي، وما إلى ذلك)
• قواعد الاعمال:ما هي القيود الديناميكية التي يتعين عليك مواجهتها؟(فكر في الحسابات والتعاريف والمخاوف القانونية وما إلى ذلك)

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

رابعا، الحصول على ردود الفعل.أعلم أنني ذكرت هذا بالفعل، لكنك لن تحصل على كل شيء بشكل صحيح في المرة الأولى، لذا احصل على ردود على ما يريده عميلك.

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

Answer 5

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

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

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

يجب أن تكون المتطلبات ملموسة.وهذا يعني أن القول بأن "واجهة مستخدم النظام يجب أن تكون سهلة الاستخدام" ليس مطلبًا صحيحًا.

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

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

تتطلب المتطلبات مثالًا موجزًا ​​وقابلًا للاختبار، ولكن تابع كل الأشياء الأخرى التي تظهر في الاجتماعات والرسوم البيانية والشكوك وحاول الاحتفاظ بسجل لكل اجتماع.

إذا كان بإمكانك استخدام دورة حياة تدريجية، فسيمنحك ذلك القدرة على تحسين بعض المتطلبات المجمعة السيئة.

Answer 6

لا يمكنك أبدًا طرح الكثير من الأسئلة أو الأسئلة "الغبية".كلما زاد عدد الأسئلة التي تطرحها، زادت الإجابات التي تتلقاها.

Answer 7

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

Answer 8

1. مناقشات رفيعة المستوى حول الغرض والنطاق وقيود بيئة التشغيل والحجم وما إلى ذلك

2. قم بتجربة وصف فقرة واحدة للنظام، وقم بصياغته

3. واجهة المستخدم وهمية

4. إضفاء الطابع الرسمي على المتطلبات المعروفة

5. قم الآن بالتكرار بين 3 و4 مع المزيد والمزيد من النماذج الأولية الوظيفية والمزيد من المواصفات مع مزيد من التفاصيل.اكتب الاختبارات كما تذهب.قم بذلك حتى يكون لديك برنامج وظيفي ومواصفات متطلبات كاملة وموضوعية وقابلة للاختبار.

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

Answer 9

جمع متطلبات العمل هو هراء - ستيف ييج

Answer 10

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

Answer 11

مثل معظم مراحل عملية تطوير البرمجيات، فإن تكرارها يعمل بشكل أفضل.

اكتشف أولاً من هم المستخدمون لديك - قسم XYZ،

ثم اكتشف أين يتناسبون مع المنظمة - جزء من القسم Z،

ثم اكتشف ما يفعلونه بشكل عام - إدارة الأموال النقدية

ثم بعبارات محددة - اجمع النقود من الأموال، وتحقق من وجود عمليات احتيال.

ثم يمكنك البدء في التحدث معهم.

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

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

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

ثم اتفقوا بالتفصيل على كيفية قياس نجاح المشروع.

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

Answer 12

أود أن أقترح عليك أن تقرأ روجر بريسمان هندسة البرمجيات:نهج الممارس

Answer 13

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

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

أعلم أن السؤال كان من منظور ما قبل الاجتماع، ولكن يرجى العلم أنه يمكنك العمل على هذه الأمور قبل الاجتماع وينتهي الأمر بتجمع مفيد وكامل وعالي الجودة.

Answer 14

لقد كنت أستخدم الخرائط الذهنية (مثل هيكل تقسيم العمل) للمساعدة في جمع المتطلبات وتحديد المجهول (قاتل المشروع رقم 1).ابدأ بمستوى عالٍ ثم واصل طريقك إلى الأسفل.أنت بحاجة إلى العمل مع الرعاة والمستخدمين وفريق التطوير لضمان حصولك على جميع الزوايا وعدم تفويت أي شيء.لا يُتوقع منك معرفة النطاق الكامل لما يريدون دون مشاركتهم... أنت - كمدير مشروع/بكالوريوس - تحتاج إلى إشراكهم (الجزء الأكثر أهمية في الوظيفة).

Answer 15

هناك بعض الأفكار العظيمة هنا بالفعل.فيما يلي بعض المتطلبات التي تجمع المبادئ التي أحب دائمًا أن أضعها في الاعتبار:

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

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

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

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

Answer 16

لقد بدأت مؤخرًا في استخدام المفاهيم والمعايير والقوالب التي حددها المعهد الدولي لمحللي الأعمال منظمة (إيبا).

لديهم BOK (كتاب المعرفة) جيد جدًا والذي يمكن تنزيله من موقعهم على الويب.لديهم أيضا شهادة.

Answer 17

تعد هندسة المتطلبات بمثابة فن إلى حد ما، وهناك الكثير من الطرق المختلفة للقيام بذلك، وعليك حقًا تخصيصها بما يتناسب مع مشروعك وأصحاب المصلحة المعنيين.المكان الجيد للبدء هو هندسة المتطلبات لـ Karl Wiegers:

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2

وعملية هندسة المتطلبات التي قد تتكون من عدد من الخطوات على سبيل المثال:

• الاستنباط - كأساس للمناقشة مع رجال الأعمال
• التحليل والوصف - وصف فني لغرض المطورين
• التفصيل والتوضيح والتحقق والتفاوض - مزيد من التحسين للمتطلبات

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

أجد بشكل عام أن كتابة مجموعة من حالات الاستخدام وتضمين النماذج الأولية للإطار السلكي يعمل بشكل جيد لتحديد مجموعة أولية من المتطلبات.ومن تلك النقطة، فهي عملية مستمرة للعمل مع الأشخاص التقنيين ورجال الأعمال لمزيد من التوضيح والتفصيل بشأن المتطلبات.يعد تتبع ما تم الاتفاق عليه في البداية وتتبع المتطلبات الإضافية أمرًا ضروريًا لتجنب زحف النطاق.يلعب التفاوض دورًا صغيرًا هنا أيضًا بين الأطراف المختلفة وفقًا للمثلث الحديدي المكسور (http://www.ambysoft.com/essays/brokenTriangle.html).

Answer 18

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

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

Answer 19

لقد كتبت مقالة مدونة حول النهج الذي أستخدمه:

http://pm4web.blogspot.com/2008/10/needs-analogy-for-business-websites.html

أساسًا:أسئلة يجب طرحها على عميلك قبل إنشاء موقعه على الويب.

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

• إل إم

Answer 20

أفضّل أن أبقي عملية جمع متطلباتي بسيطة ومباشرة وشاملة قدر الإمكان.يمكنك تنزيل نموذج مستند أستخدمه كقالب لمشاريعي في منشور المدونة هذا: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html