قصص المستخدم للمتطلبات الوظيفية [مغلقة

Question

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

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

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

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

Answer 1

أنا على خلاف مع ما قاله شخصان آخران.

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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