كيفية كتابة حالات الاستخدام الفعال

استخدم اسم الحالة - طلب التذاكر

الاسم جيد. من الواضح أنه يعطي مؤشرا على ماهية حالة الاستخدام

الهدف - يقوم العميل بحجز تذاكر مباراة كرة القدم بنجاح على الموقع الإلكتروني

الوصف- الممثل يزور الموقع ، ويطلع على
الجدول الزمني ، يختار المباراة
والمقاعد والكتب
تذكرة ويقوم بالدفع مقابل مباراة كرة القدم

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

الفاعلون - العميل ، ممثل خدمة العملاء
الشروط المسبقة - النظام يعمل.
Trigger - قام الممثل بالوصول إلى النظام لحجز التذاكر.
Post-Condition - الممثل قادر على حجز التذاكر. يقوم النظام بتحديث المعلومات.

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

التدفق الرئيسي - الخطوات

1. الممثل يصل إلى الموقع ويختار حجز التذاكر
2. يعرض النظام معلومات الحجز
3. يؤكد الممثل تفاصيل المباراة (مزيد من التفاصيل في مواصفات واجهة المستخدم)
4. يؤكد الممثل تفاصيل المقعد (مزيد من التفاصيل في مواصفات واجهة المستخدم)
5. يؤكد النظام التوفر
6. يقدم النظام نموذجًا للحصول على معلومات المستخدم
7. الممثل يعطي معلومات للمستخدم (التفاصيل في حالة استخدام أخرى)
8. يقدم النظام استمارة لمعلومات الدفع
9. الممثل يعطي معلومات الدفع (التفاصيل في حالة استخدام أخرى)
10. يؤكد النظام التفاصيل ويعطي معرف الحجز
11. الممثل يحفظ التذكرة
12. الممثل يخرج من النظام.

حالات الاستخدام المتضمنة

- قم بالدفع

- إنشاء معرف الحجز

حالات الاستخدام الممتدة

- إنشاء إشعار فشل في الدفع

- طباعة التذكرة

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

التدفق البديل

-إلغاء التذاكر

1. الفاعل يلغي الصفقة
2. النظام يلغي المعاملة

تدفق الاستثناءات

- التذاكر غير متوفرة للمباراة المختارة / المقاعد المختارة

1. يعرض النظام رسالة خطأ

تم تفصيل التدفقات البديلة والاستثناءات .

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

استخدام اسم الحالة - طلب التذاكر

الاسم ليس من منظور المستخدم ويبدو أنه تعريف عملية الأعمال.

الوصف - يقوم الممثل بزيارة الموقع الإلكتروني ، وعرض الجدول الزمني ، واختيار المباراة والمقاعد ، وحجز التذكرة ، وإجراء الدفع مقابل مباراة كرة القدم

الهدف من حالة الاستخدام مفقود. لن يفهم المصممون ومحللو الاختبار والمطورون سبب تطوير هذه الوظيفة.

الفاعلون - العميل ، ممثل خدمة العملاء
Trigger - قام الممثل بالوصول إلى النظام لحجز التذاكر.
Post-Condition - الممثل قادر على حجز التذاكر. يقوم النظام بتحديث المعلومات.

الشروط المسبقة مفقودة.

خطوات التدفق الرئيسية

1. يدخل العميل إلى الموقع ويختار خيار "حجز التذاكر" لحجز التذاكر
2. يعرض النظام قائمة التطابقات في قائمة منسدلة.
3. يختار ممثل خدمة العملاء من القائمة المنسدلة
4. يعرض النظام تفاصيل المقعد في خريطة المقاعد
5. الممثل يختار المقاعد. إذا كانت المقاعد غير متوفرة وظهرت رسالة خطأ.
6. الممثل يعطي تفاصيل الدفع
7. الممثل يحجز التذكرة وإلا يلغي التذكرة.
8. يقوم النظام بإنشاء معرف حجز باستخدام الاسم الأول للعميل ورقم مكون من 4 أرقام يتم إنشاؤه عشوائيًا

حالات الاستخدام المتضمنة
- قم بالدفع

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

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

1. اسم
2. الوصف / الهدف
3. الشروط المسبقة
4. مشغل
5. التدفق الأساسي والتدفقات البديلة
6. سيناريوهات الاستثناء
7. شروط المشاركة
8. المتطلبات الخاصة إن وجدت
9. رابط إلى تفاصيل واجهة المستخدم والنماذج / الرسوم البيانية الأخرى ذات الصلة

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

.