كتابة المتطلبات User Stories

كتابة المتطلبات User Stories

تعتبر الـ User Story أداة مرنة يمكن لمحلل الأعمال أن يستخدمها لكتابة المتطلبات بشكل بسيط وسهل يجعل جميع أطراف المشروع على نفس الدراية بالمتطلبات، تتكون من بعض الأجزاء لتكون مناسبة لفريق العمل.


نطاق الوثيقة

تشمل الوثيقة تعريف الـ User Story وخطوات كتابتها بكفاءة وبعض الأدوات المساعدة لها ليتمكن محلل الأعمال من التعبير عن المعلومات بأدوات مختلفة. كما تحتوي علي مثال لكل أداة وتعطي المراجع المناسبة للتوسع والاطلاع.


الأهداف

  • أن يتمكن محلل الأعمال من كتابة المتطلبات بشكل سريع ومرن.
  • أن يتم كتابة المتطلبات بطريقة تساعد الجميع على فهم المتطلبات بنفس وجهة النظر المطلوبة.
  • أن تكون مرجع للفريق في أي وقت لمناقشة المتطلبات.
  • أن يقوم المختبرين ببناء حالات الاختبار بناءا على ما تم كتابته.
  • أن يقوم مالك المشروع باستلام المشروع طبقا لما تم كتابته من خلالها.

خطوات كتابة الـ User Story:

  1. كتابة العنوان واضح وغالبا ما يبدأ بفعل (مثال: إضافة مستخدم جديد)
  2. كتابة الوصف بشكل يساعد على فهم الفعل المطلوب والهدف من هذا الفعل مع توضيح ومن سيقوم بهذا الفعل (مثال: كمدير للنظام أريد أن أتمكن من إضافة مستخدم جديد حتى يتمكنوا من استخدام النظام)
  3. يجب أن تكون الـ User Story تمثل قيمة للـ Business
  4. يجب أن يكون المختبرين قادرين على اختبار الـ User Story
  5. يجب أن يكون التقنيين قادرين على وضع الوقت المناسب لتنفيذ الـ User Story
  6. من الأفضل أن تكون الـ User Story صغيرة يمكن إنجازها في يوم واحد
  7. يجب وضع تصميم سواء Design أو Wireframe لتوضيح خبرة المستخدم إلا في حالات استثنائية مثلا User Story لعمل Payment Gateway فيمكن الاستغناء عن التصميم
  8. معلومات توضيحية للـ User Story يتم تحديدها طبقا لنوعية المعلومات المطلوب توضيحها
  9. يمكنك الاطلاع على هذا الكتاب للزيادة (هنا) ويمكنك الاطلاع على الـ BABOK الصادر من الـ IIBA الإصدار الأخير 3.0

متي يمكن بدء العمل علي الـ User Story:

يتم إنجاز الـ User Story عند الانتهاء من الـ DOR (Definiton of Ready) الخاص بها

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

متي يتم إنجاز الـ User Story:

يتم إنجاز الـ User Story عند الانتهاء من الـ DOD (Definiton of Done) الخاص بها

  1. يجب أن تحقق جميع خصائص القبول
  2. يجب توافر الـ Code الذي يحقق المطلوب
  3. يجب أن يتحقق جميع حالات الاختبار الأساسية ولا يكون هناك مشكلة أساسية تعوق تنفيذ العمل المذكور في خصائص القبول
  4. يجب أن يتسلم محلل الأعمال ما تم تنفيذه ويوافق عليه طبقا لاحتياجات العمل المذكورة في خصائص القبول

أشهر أنواع المعلومات:

من المعروف أن الـ User Story هي تعطي رؤية سريعة ومختصرة عن المطلوب لكنها لا تتحمل كل التفاصيل التي تهم الفريق وفي نفس الوقت لا تكون كافية لفريق التقنية لتوفر له جميع المعلومات اللازمة للتطوير.

إن أفضل طريقة لكتابة جميع تفاصيل المتطلبات للفريق التقني هي إرفاق التفاصيل كملفات ملحقة مع الـ User Story من خلال معرفة نوعية المعلومات المطلوب كتابتها واستخدام طريقة مناسبة لعرض المعلومات.

معلومات المستخدمين: ونذكر للتوضيح مثال فنتكلم عن أنواع المستخدمين الذين سيقومون باستخدام النظام فمثلا القاضي هذه الحالة يفضل استخدام الـ User Persona

فهذه الأداة تمنحك المساحة للتحدث عن كل نوع من الشخصيات باستفاضة وكتابة كل المواصفات التي تساعدك علي تلبية احتياجاتها اضغط هنا للمزيد

معلومات الخصائص: ونذكر للتوضيح مثال فنتكلم عن إنشاء وظيفة تسجيل مستخدم جديد له اسم ونوع وبريد إلكتروني وبلد ورقم هاتف في هذه الحالة يفضل استخدام الـ Data Table

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

معلومات الحالة: ونذكر مثلا حالة القضية فتبدأ بقضية جديدة وعند حدوث فعل معين تنتقل لحالة تحت النظر مثلا ويفضل في هذا النوع من المعلومات استخدام الـ State Diagram أو الـ State Table للمزيد (اضغط هنا)

هذه الطريقة تمكنك من توضيح حالات وحدة معينة Entity بسهولة وتعطيك المساحة لتتبع دورة حياة هذه الوحدة

معلومات التكامل مع نظم خارج النظام: ونذكر مثلا الربط مع نظام وزارة الداخلية فيتم وضع رسم توضيحي يسمي Context Diagram يوضح العلاقة الخاصة بجزئية الربط بين النظامين للمزيد (اضغط هنا)

هذا الرسم يمكنك من إيضاح الفكرة بشكل مبسط وسهل ويعطيك رؤية واضحة عن ماهي المعلومات المطلوبة من النظام وما هي المعلومات المنتظرة من النظم الأخرى التي سيتم الربط معها

معلومات صلاحيات المستخدمين: ونذكر هنا مثلا أنه لدينا مجموعة من المستخدمين لكل منهم صلاحيات خاصة به داخل النظام فيتم استخدام طريقة الـ Access Table أو Privilege Table ليوضح صلاحيات كل مستخدم في النظام

يمكنك هذا الجدول من توضيح كافة المعلومات حول صلاحيات المستخدمين مع كل وظيفة في النظام ويمكن وضع هذه المعلومات دائما مع كل User Story يتم كتابتها ليتم توضيح من له الحق في استخدام هذه الوظيفة

معلومات اتخاذ القرارات: ونذكر هنا مثلا أنه في حالة إن كانت القضية من النوع أ سيكون متاحا علي النظام أن يقوم المستخدم بفعل كذا وكذا أما إن كانت القضية من النوع ب فسيكون متاحا على النظام أن يقوم المستخدم بفعل كذا وكذا ، في هذه الحالة يفضل استخدام أداة Decision Table أو Decision Tree لتوضيح المسارات التي تتخذ قرارات مختلفة للمزيد (اضغط هنا)

تمكنك هذه الطريقة في عرض المعلومات من إيضاح المسارات المختلفة لكل قرار وبالتالي تجعل الرؤية العامة للمسارات واضحة وسهلة

معلومات عن مسار العمليات داخل النظام: ونذكر هنا مثلا أننا نريد أن نوضح المسار لعملية معينة داخل النظام فمثلا شركة شحن طرود فعندما نريد أن نوضح العملية التي تخص الطرد داخل النظام كأن يتم تسجيل طرد جديد بواسطة مستخدم ما ثم يتخذ هذا الطرد ليكون طرد داخل المخزن عن طريق أمين المخزن ثم يتم توصيله للعميل عن طريق مندوب التوصيل، في هذه الحالة يتم توضيح العملية عن طريق Swamlane Diagram وفي كل خطوة يتم توضيح من سيقوم بهذه الخطوة  للمزيد (اضغط هنا)

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

معلومات عن قواعد المنطق في النظام: ونذكر هنا مثلا أننا نريد أن نوضح قواعد العمل التي يتبعها مستخدم معين أو عند تطبيق عملية معينة فمثلا القاضي لا يمكن أن يبت في القضية مرتين وفيه هذا النوع يتم استخدام ما يسمى بجمل قواعد المنطق أو قواعد العمل Business Rules للمزيد (اضغط هنا)

لا يمكن للقضية أن يبت فيها قاضي مرتين، لا يمكن أن تذهب القضية إلي الطعن إلا مرة واحدة ، وهكذا

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

معلومات عن تجربة المستخدم: ونذكر هنا مثلا أننا نريد أن نقوم بشرح لتجربة مستخدم معينة كتسجيل مستخدم مثلا بشكل ما، في هذه الحالة يتم استخدام Wireframe أو تصميم فعلي إن وُجد للمزيد (اضغط هنا)

يمكنك الاطلاع علي المزيد حول طريقة كتابة الـ User Story من خلال AzureDevOps من خلال هذا الفيديو (اضغط هنا)