قصص المستخدمين ومتطلباتهم requirement analysis and User Stories
جدول المحتويات
قصص المستخدمين ومتطلباتهم (requirement analysis and User Stories) ، هي مصطلحات شائعة مستخدمة في صناعة البرمجيات.
لكن ما هي بالضبط قصص المستخدمين ومتطلباتهم ؟ هل هم مختلفون؟ هل هم نفس الشيء؟
سنجيب في هذه المقالة على هذه الأسئلة المتعلقة ب (requirement analysis and User Stories).
ما هي قصص المستخدمين ومتطلباتهم
لنعرف ما هي قصص المستخدمين ومتطلباتهم (requirement analysis and User Stories)، سنتعرف على كل واحدة بمفردها.
ما هي قصة المستخدم (User Stories)؟
قصص المستخدمين (User Stories)، هي عبارة عن أوصاف مختصرة للوظائف يتم سردها من وجهة نظر المستخدم.
ينصب التركيز فيها على سبب وكيفية تفاعل المستخدم مع البرنامج.
قصة المستخدم هي في الأساس تعريف عالي المستوى لما يجب أن يكون البرنامج قادراً على فعله.
عادةً، يمكن كتابة أي تعليقات أو طلب يأتي من الشركة أو المستخدم النهائي كقصة للمستخدم.
تتم كتابة قصة المستخدم الجيدة بلغة بسيطة وتتحدث عن السبب والفوائد المتوقعة لميزة معينة من البرنامج.
عادة ما يتبعون نموذجًا مثل هذا:
بصفتي <نوع المستخدم>، أريد <بعض النتائج المرغوبة> حتى <سبب>.
في ما يلي مثال على قصة مستخدم لموقع تجارة إلكترونية أساسي:
كعميل، أريد أن أكون قادراً على عرض العناصر في سلة التسوق الخاصة بي حتى أعرف على وجه اليقين ما أشتريه.
أو كمدير للبرنامج، أريد أن شاهد تقارير عن مبيعات الشهر الماضي، حتى أعرف نسب زيادة أو نقصان المبيعات.
غالباً ما تصاحب معايير القبول قصة المستخدم.
هذه المعايير هي حدود قصة المستخدم وهي تحدد بشكل أساسي متى تكتمل قصة المستخدم.
معايير القبول هي أيضاً ما سيكتب / يجري المختبر اختباراته مقابله.
يمكنك التفكير في معايير القبول باعتبارها المتطلبات الوظيفية التي تدعم قصة المستخدم.
اقرأ أيضاً: الذكاء الجماعي الرقمي , حشد المصادر , التمويل الجماعي
ما هو المتطلبات (requirement analysis)؟
تصف المتطلبات التقليدية كيفية عمل البرنامج. وما هو الهدف من النظام.
تدخل مستندات المتطلبات في تفاصيل دقيقة حول كيفية عمل مجال البرنامج. عادة ما تخدم الغرض من توجيه كيفية قيام فريق البرنامج ببناء شيء ما.
بينما تكون قصص المستخدم بسيطة وبسيطة، فإن مستندات المتطلبات تدخل في الكثير من التفاصيل وتستغرق وقتاً طويلاً في كتابتها.
غالبًا ما تحتوي مستندات المتطلبات على أشياء مثل الملخصات التنفيذية والنطاق والمخاطر والمزيد. أنها تحدد مستوى الجودة للوظائف والأداء وتجربة المستخدم.
في ما يلي مثال لبعض المتطلبات لموقع التجارة الإلكترونية الأساسي:
اعرض اسم كل عنصر في عربة التسوق.
اعرض كمية كل عنصر في عربة التسوق.
اسمح للمستخدم بإزالة أي عناصر من عربة التسوق.
اقرأ أيضاً: بناء متجر الكتروني بشكل احترافي باستخدام WooCommerce
ما هو الاختلاف؟
بشكل عام، يتم استخدام قصص المستخدمين بشكل أكثر شيوعاً ضمن منهجية Agile، بينما ترتبط مستندات المتطلبات بشكل أكثر شيوعاً بمنهجية الشلال التقليدية (waterfall methodology).
نظرًا للطبيعة الخفيفة لقصص المستخدمين، فإنها تعزز المناقشة والتعاون أكثر من مستندات المتطلبات.
كما ترى في الأمثلة أعلاه، تحدد المتطلبات تفاصيل محددة بينما يترك مثال قصة المستخدم مساحة للمناقشة.
قد تتم هذه المناقشات قبل أو خلال جلسة التخطيط. حيث يجب أن يشارك الفريق بأكمله في هذه المناقشة.
اقرأ أيضاً: استراتيجيات وطرق التسعير
الفرق الأساسي بين قصص المستخدمين ومتطلباتهم
هناك فرق رئيسي واحد بين قصص المستخدم ومتطلباته: وهو الهدف.
- تركز قصة المستخدم على التجربة، أي ما يريد الشخص الذي يستخدم المنتج أن يكون قادراً على القيام به.
- يركز أحد المتطلبات التقليدية على الوظيفة، أي ما يجب أن يفعله المنتج.
- الاختلافات المتبقية هي قائمة دقيقة، لكنها مهمة، وهي “كيف” و “من” و “متى”.
إليك كيف تختلف قصص المستخدمين ومتطلباتهم:
كيف يكتب؟
يجب كتابة قصص المستخدم في جملة أو جملتين وتحديد هوية المستخدم وماذا يريد ولماذا.
مثال: بصفتي مستخدماً، أريد أن أتمكن من إعادة تعيين كلمة المرور الخاصة بي حتى أتمكن من العودة إلى النظام إذا نسيتها.
تميل المتطلبات إلى أن تكون مفصلة للغاية وتستغرق وقتًا أطول للكتابة.
مثال: يُسمح للمستخدم بإعادة تعيين كلمة المرور الخاصة به بمجرد استلام بريد إلكتروني لإعادة تعيين كلمة المرور.
يجب أن يحتوي البريد الإلكتروني على رابط فريد لإعادة تعيين كلمة المرور ويجب أن تنتهي صلاحية هذا الرابط بعد ساعتين.
من يكتبها؟
يمكن كتابة قصص المستخدم من قبل أي شخص قريب من البرنامج، كالمطورين، ومختبِر ضمان الجودة. لكن مدير المنتج أو المالك هو الذي يحتفظ بتراكم قصص المستخدمين.
تتم كتابة المتطلبات بواسطة مدير المنتج أو مالك المنتج أو محلل الأعمال. كذالك غالباً ما يشارك العملاء المحتملون الفنيون بالإضافة إلى المهندسين الذين سيكونون مسؤولين عن العمل على الميزات أو التحسينات.
متى كتبت؟
تتم كتابة قصص المستخدم في جميع أنحاء بناء المنتج. يمكن أن يحدث تحديث القصص (أو إضافة قصص جديدة) في أي وقت.
يمكن صياغة المتطلبات في أي وقت. ومع ذلك، من الأفضل تحديد ما هو مطلوب من وجهة نظر المستخدم أولاً إذا كان كل من القصص وتعريف المتطلبات مطلوبًا.
كلما استمر الفريق في التخطيط، زاد فهم الفريق لاحتياجات المستخدم والعمل.
على الرغم من اختلاف الهدف من قصة المستخدم أو المتطلبات، إلا أن الهدف هو نفسه دائمًا – بناء منتج يحبه العملاء.
سواء كنت تكتب قصة مستخدم أو مطلبًا، فأنت بحاجة إلى التركيز على ما هو أكثر أهمية: وصف النتيجة المرجوة للعميل وإعطاء التطوير ما يحتاجون إليه لبنائه بنجاح.
بالنهاية، في حين أن قصص المستخدمين ومتطلباتهم (requirement analysis and User Stories) متشابهة في طبيعتها، فهي مختلفة تماماً، وتتضمن نهجاً مختلفاً للعمل وبناء البرامج.
تعّرف أيضاً عن الفرق بين المتطلبات الوظيفية وغير الوظيفية functional and non-functional requirements
