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

في كلٍ من هندسة البرمجيات وهندسة النظم ، تُعرَّف حالة الاستخدام بأنها وصف مُنظَّم لسلوك النظام أثناء استجابته لطلبات من جهات خارجية، بهدف تحقيق غاية مُحدَّدة. ويُستخدم المصطلح أيضاً خارج نطاق هندسة البرمجيات/النظم لوصف كيفية استخدام شيء ما. ^{[ 1 ]}

في هندسة البرمجيات (والأنظمة القائمة على البرمجيات)، تُستخدم حالات الاستخدام لتحديد المتطلبات الوظيفية والتحقق من صحتها. ^{[ 2 ]} حالة الاستخدام هي قائمة من الإجراءات أو خطوات الأحداث التي تُحدد عادةً التفاعلات بين دور (يُعرف في لغة النمذجة الموحدة (UML) باسم "الفاعل ") ونظام لتحقيق هدف ما. قد يكون الفاعل إنسانًا أو نظامًا خارجيًا آخر. في هندسة النظم، تُستخدم حالات الاستخدام على مستوى أعلى من هندسة البرمجيات ، وغالبًا ما تُمثل مهامًا أو أهدافًا لأصحاب المصلحة . بعد ذلك، يمكن توثيق المتطلبات التفصيلية في لغة نمذجة النظم (SysML) أو كبيانات تعاقدية.

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

في هندسة البرمجيات والأنظمة ، تُعتبر عبارة "حالة الاستخدام" عبارة متعددة المعاني ولها معنيان :

1. سيناريو استخدام لبرنامج ما؛ وغالبًا ما يستخدم بصيغة الجمع للإشارة إلى المواقف التي قد يكون فيها البرنامج مفيدًا.
2. سيناريو محتمل يتلقى فيه النظام طلبًا خارجيًا (مثل إدخال المستخدم) ويستجيب له.

تتناول هذه المقالة المعنى الأخير. (للمزيد حول المعنى الآخر، انظر: الشخصية (تجربة المستخدم) ).

في عام ١٩٨٧، قدّم إيفار جاكوبسون أول مقال حول حالات الاستخدام في مؤتمر OOPSLA '87. ^{[ ٣ ]} وصف كيف استُخدمت هذه التقنية في شركة إريكسون لتحديد متطلبات النظام وتصنيفها باستخدام تقنيات النمذجة النصية والهيكلية والمرئية لتوجيه التحليل والتصميم الموجه للكائنات. ^{[ ٤ ]} في البداية، استخدم مصطلحي " سيناريوهات الاستخدام" و "حالة الاستخدام" - وهي ترجمة مباشرة لمصطلحه السويدي användningsfall - لكنه وجد أن أياً من هذين المصطلحين لا يبدو طبيعياً في اللغة الإنجليزية، واستقر في النهاية على مصطلح "حالة الاستخدام" . ^{[ ٥ ]}

في عام 1992، شارك في تأليف كتاب " هندسة البرمجيات الموجهة للكائنات - منهج قائم على حالات الاستخدام" ^{[ 6 ]} ، الذي وضع أسس منهجية هندسة أنظمة OOSE وساهم في نشر استخدام حالات الاستخدام لتحديد المتطلبات الوظيفية ، لا سيما في تطوير البرمجيات . وفي عام 1994، نشر كتابًا حول حالات الاستخدام وتقنيات البرمجة الموجهة للكائنات المطبقة على نماذج الأعمال وإعادة هندسة عمليات الأعمال ^{[ 7 ]} .

في الوقت نفسه، عمل جرادي بوتش وجيمس رامبو على توحيد أساليب التحليل والتصميم الموجهة للكائنات ، وهما أسلوب بوتش وتقنية نمذجة الكائنات (OMT) على التوالي. في عام 1995، انضم إليهم إيفار جاكوبسون، وابتكروا معًا لغة النمذجة الموحدة (UML) ، التي تتضمن نمذجة حالات الاستخدام. وقد اعتمدت مجموعة إدارة الكائنات (OMG) لغة UML كمعيار في عام 1997. ^{[ 8 ]} كما عمل جاكوبسون وبوتش ورامبو على تحسين عملية تطوير البرمجيات Objectory . ونُشرت العملية الموحدة الناتجة في عام 1999، والتي روجت لنهج قائم على حالات الاستخدام. ^{[ 9 ]}

منذ ذلك الحين، ساهم العديد من المؤلفين في تطوير هذه التقنية، ومن أبرزهم: لاري كونستانتين الذي طور عام 1995، في سياق التصميم المرتكز على الاستخدام ، ما يُسمى "حالات الاستخدام الأساسية" التي تهدف إلى وصف نوايا المستخدم بدلاً من تسلسل الإجراءات أو السيناريوهات التي قد تُقيّد أو تُؤثر على تصميم واجهة المستخدم؛ ^{[ 10 ]} أليستير كوكبيرن الذي نشر عام 2000 ممارسة لحالات الاستخدام موجهة نحو الهدف، تعتمد على السرد النصي والمواصفات الجدولية؛ ^{[ 11 ]} كورت بيتنر وإيان سبنس اللذان طورا عام 2002 ممارسات متقدمة لتحليل المتطلبات الوظيفية باستخدام حالات الاستخدام؛ ^{[ 12 ]} دين ليفينغويل ودون ويدريغ اللذان اقترحا تطبيق حالات الاستخدام على إدارة التغيير وأنشطة التواصل مع أصحاب المصلحة؛ ^{[ 13 ]} غونار أوفيرغارد الذي اقترح عام 2004 توسيع مبادئ أنماط التصميم لتشمل حالات الاستخدام. ^{[ 14 ]}

في عام 2011، نشر جاكوبسون بالاشتراك مع إيان سبنس وكورت بيتنر كتابًا إلكترونيًا بعنوان " حالات الاستخدام 2.0 " لتكييف هذه التقنية مع سياق منهجية أجايل، وإثرائها بشرائح حالات استخدام تدريجية، والترويج لاستخدامها في جميع مراحل دورة التطوير ^{[ 15 ]} بعد أن قدموا هذا النهج المُجدد في المؤتمر السنوي للمعهد الدولي لتحليل الأعمال (IIBA) . ^{[ 16 ] [ 17 ]}

حالات الاستخدام هي أسلوب لتحديد متطلبات النظام ونمذجتها وتوصيفها. ^{[ 12 ]} تمثل حالة الاستخدام مجموعة من السلوكيات التي قد يؤديها النظام عند تفاعله مع الجهات الفاعلة فيه، والتي تُنتج نتيجة ملموسة تُسهم في تحقيق أهدافه. تمثل الجهات الفاعلة الدور الذي يلعبه المستخدمون البشريون أو الأنظمة الأخرى في هذا التفاعل.

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

وفقًا لدليل هندسة البرمجيات (SWEBOK) ، ^{[ 18 ]} تنتمي حالات الاستخدام إلى تقنيات استخلاص المتطلبات القائمة على السيناريوهات ، بالإضافة إلى تقنيات التحليل القائمة على النماذج . كما تدعم حالات الاستخدام أيضًا جمع المتطلبات القائم على السرد، واكتساب المتطلبات التدريجي، وتوثيق النظام، واختبار القبول. ^{[ 3 ]}

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

أسلوب كوكبيرن

يُعدّ النموذج الذي حدده أليستير كوكبيرن في كتابه " كتابة حالات الاستخدام الفعالة" أحد أكثر أساليب كتابة حالات الاستخدام استخدامًا على نطاق واسع.

نطاقات التصميم

يقترح كوكبيرن إضافة رمز إلى كل حالة استخدام لتوضيح "نطاق التصميم"، والذي قد يكون صندوقًا أسود (التفاصيل الداخلية مخفية) أو صندوقًا أبيض (التفاصيل الداخلية ظاهرة). تتوفر خمسة رموز: ^{[ 22 ]}

نِطَاق	رمز	رمز
التنظيم (الصندوق الأسود)	البيت الممتلئ
التنظيم (الصندوق الأبيض)	بيت غير مأهول
النظام (الصندوق الأسود)	صندوق ممتلئ
النظام (الصندوق الأبيض)	صندوق فارغ
عنصر	برغي أو مسمار

يُطلق بعض المؤلفين أحيانًا على حالات الاستخدام على مستوى المؤسسة اسم "حالات استخدام الأعمال". ^{[ 23 ]}

مستويات الأهداف

يقترح كوكبيرن وضع رمز لكل حالة استخدام لإظهار "مستوى الهدف"؛ ^{[ 24 ]} المستوى المفضل هو "هدف المستخدم" (أو بالعامية "مستوى سطح البحر" ^{[ 25 ] : 101} ).

مستوى الهدف	رمز	رمز النص	رمز
ملخص عالي جداً	سحاب	++
ملخص	طائرة ورقية محلقة	+
هدف المستخدم	أمواج في البحر	!
الوظيفة الفرعية	سمكة	-
منخفض جداً	صدفة المحار في قاع البحر	--

في بعض الأحيان، عند كتابة النصوص، يكون اسم حالة الاستخدام متبوعًا برمز نص بديل (! +، -، إلخ) طريقة أكثر إيجازًا وملاءمة للدلالة على المستويات، على سبيل المثال: قم بتقديم طلب!، تسجيل الدخول- .

بكامل ملابسه

يصف كوكبيرن هيكلاً أكثر تفصيلاً لحالة الاستخدام، ولكنه يسمح بتبسيطه عند الحاجة إلى تفاصيل أقل. يتضمن نموذج حالة الاستخدام الكامل الخاص به الحقول التالية: ^{[ 26 ]}

• العنوان: "عبارة هدف فعلية تحدد هدف الفاعل الرئيسي" ^{[ 27 ]}
• الممثل الرئيسي
• الهدف في السياق
• نِطَاق
• مستوى
• أصحاب المصلحة والمصالح
• شرط مسبق
• الحد الأدنى من الضمانات
• ضمانات النجاح
• مشغل
• سيناريو النجاح الرئيسي
• الإضافات
• قائمة اختلافات التكنولوجيا والبيانات

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

لقد أثر نهج كوكبيرن على مؤلفين آخرين؛ على سبيل المثال، قام ألكسندر وبيوس دوكيتش بتعميم نموذج كوكبيرن "حالة الاستخدام المجهزة بالكامل" من البرامج إلى الأنظمة من جميع الأنواع، مع اختلاف المجالات التالية عن كوكبيرن: ^{[ 28 ]}

• سيناريوهات التباين "(ربما التفرع من السيناريو الرئيسي وربما العودة إليه)"
• الاستثناءات "أي أحداث الاستثناء وسيناريوهات معالجة الاستثناءات الخاصة بها"

غير رسمي

يُقرّ كوكبيرن بأن المشاريع قد لا تحتاج دائمًا إلى حالات استخدام مفصلة وكاملة. ويصف حالة استخدام عادية تتضمن الحقول التالية: ^{[ 26 ]}

• العنوان (الهدف)
• الممثل الرئيسي
• نِطَاق
• مستوى
• (القصة): يتكون نص حالة الاستخدام ببساطة من فقرة أو فقرتين من النص، يصفان بشكل غير رسمي ما يحدث.

تُحدد حالة الاستخدام التفاعلات بين الجهات الخارجية والنظام قيد الدراسة لتحقيق هدف معين. يجب أن تكون الجهات قادرة على اتخاذ القرارات، ولكن ليس بالضرورة أن تكون بشرية: "قد تكون الجهة شخصًا، أو شركة، أو مؤسسة، أو برنامج حاسوبي، أو نظام حاسوبي - سواء كان جهازًا أو برنامجًا أو كليهما." ^{[ 30 ]} تُعد الجهات دائمًا من أصحاب المصلحة ، ولكن ليس كل أصحاب المصلحة جهات فاعلة، إذ قد "لا يتفاعلون أبدًا بشكل مباشر مع النظام، على الرغم من حقهم في الاهتمام بكيفية عمل النظام." ^{[ 30 ]} على سبيل المثال، "قد يكون مالكو النظام، ومجلس إدارة الشركة، والهيئات التنظيمية مثل مصلحة الضرائب ودائرة التأمين" من أصحاب المصلحة، ولكن من غير المرجح أن يكونوا جهات فاعلة. ^{[ 30 ]}

وبالمثل، قد يُصوَّر الشخص الذي يستخدم النظام كفاعل مختلف بسبب قيامه بأدوار مختلفة. على سبيل المثال، قد يقوم المستخدم "جو" بدور العميل عند استخدام جهاز الصراف الآلي لسحب النقود من حسابه، أو بدور موظف البنك عند استخدام النظام لإعادة تعبئة درج النقود نيابةً عن البنك.

غالبًا ما يعمل المستخدمون نيابةً عن جهة أخرى. يكتب كوكبيرن: "أستخدم هذه الأيام عبارات مثل 'مندوب مبيعات للعميل' أو 'موظف لقسم التسويق' للإشارة إلى أن مستخدم النظام يعمل نيابةً عن جهة أخرى". هذا يُوضح للمشروع أن "واجهة المستخدم والتصاريح الأمنية" يجب تصميمها لمندوب المبيعات والموظف، بينما العميل وقسم التسويق هما الجهتان المعنيتان بالنتائج. ^{[ 31 ]}

قد يلعب صاحب المصلحة دورًا فعالًا أو غير فعال: على سبيل المثال، المستهلك هو "مشتري السوق الشامل" (لا يتفاعل مع النظام) ومستخدم (فاعل يتفاعل بنشاط مع المنتج الذي اشتراه). ^{[ 32 ]} في المقابل، المستخدم هو "مشغل عادي" (فاعل يستخدم النظام للغرض المقصود منه) و"مستفيد وظيفي" (صاحب مصلحة يستفيد من استخدام النظام). ^{[ 32 ]} على سبيل المثال، عندما يسحب المستخدم "جو" نقودًا من حسابه، فإنه يستخدم جهاز الصراف الآلي ويحصل على نتيجة لصالحه.

ينصح كوكبيرن بالبحث عن الجهات الفاعلة بين أصحاب المصلحة في النظام، والجهات الفاعلة الأساسية والداعمة (الثانوية) لحالة الاستخدام، والنظام قيد التصميم نفسه، وأخيراً بين "الجهات الفاعلة الداخلية"، أي مكونات النظام قيد التصميم. ^{[ 30 ]}

كما يصف نموذج حالة الاستخدام سلسلة من الأحداث والتفاعلات بين المستخدم (أو أي نوع آخر من الجهات الفاعلة) والنظام، بهدف تحقيق نتيجة ذات قيمة (هدف)، يصف نموذج حالة الاستخدام التجاري التفاعل الأكثر عمومية بين نظام الأعمال ومستخدميه/جهاته الفاعلة لتحقيق نتائج تجارية ذات قيمة. ويكمن الاختلاف الرئيسي في أن النظام الذي يُنظر فيه في نموذج حالة الاستخدام التجاري قد يحتوي على أفراد بالإضافة إلى الأنظمة التقنية. يُطلق على هؤلاء "الأفراد في النظام" اسم العاملين في مجال الأعمال. في مثال المطعم، يجب اتخاذ قرار بشأن ما إذا كان ينبغي التعامل مع كل شخص كجهة فاعلة (وبالتالي خارج النظام) أو كعامل في مجال الأعمال (داخل النظام). إذا اعتُبر النادل جهة فاعلة، كما هو موضح في المثال أدناه، فإن نظام المطعم لا يشمل النادل، ويكشف النموذج عن التفاعل بين النادل والمطعم. أما البديل فهو اعتبار النادل جزءًا من نظام المطعم (عامل في مجال الأعمال) مع اعتبار العميل خارج النظام (جهة فاعلة). ^{[ 33 ]}

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

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

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

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

حالة الاستخدام : تحرير مقال

الفاعل الرئيسي : عضو (مستخدم مسجل)

النطاق : نظام ويكي

المستوى :  ! (هدف المستخدم أو مستوى سطح البحر)

موجز : (يعادل قصة المستخدم أو الملحمة)

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

المالكون

...

الشروط اللاحقة

الحد الأدنى من الضمانات :

ضمانات النجاح :

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

الشروط المسبقة :

يتم عرض المقالة مع تمكين التحرير على العضو.

المحفزات :

يقوم العضو باستدعاء طلب تعديل (للمقالة بأكملها أو لقسم واحد فقط) على المقالة.

التدفق الأساسي :

1. يُوفّر النظام منطقة/مربع تحرير جديدًا يحتوي على جميع محتويات المقالة ذات الصلة، بالإضافة إلى ملخص تحريري مُفيد ليتمكن العضو من تعديله. إذا أراد العضو تعديل قسمٍ مُحدد من التقرير، فسيتم عرض المحتوى الأصلي لهذا القسم فقط، مع ملء عنوان القسم تلقائيًا في ملخص التحرير.
2. يقوم العضو بتعديل محتوى المقالة حتى يرضى عنها.
3. يقوم العضو بتعبئة ملخص التعديل، ويخبر النظام ما إذا كان يريد مشاهدة هذه المقالة، ثم يرسل التعديل.
4. يقوم النظام بحفظ المقالة، وتسجيل حدث التحرير، وإنهاء أي معالجة لاحقة ضرورية.
5. يعرض النظام النسخة المحدثة من المقالة للعضو.

الإضافات :

2-3.

أ. عرض المعاينة:

1. يختار العضو خيار "عرض المعاينة" الذي يقوم بدوره بإرسال المحتوى المعدل.
2. يعيد النظام تشغيل الخطوة 1 مع إضافة المحتوى المحدث المعروض للمعاينة، ويُبلغ العضو بأن تعديلاته لم يتم حفظها بعد، ثم يتابع.

ب. إظهار التغييرات:

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

ج. إلغاء التعديل:

1. يختار العضو "إلغاء" .
2. يتجاهل النظام أي تغيير أجراه العضو، ثم ينتقل إلى الخطوة 5.

4أ. مهلة زمنية:

...

منذ ظهور حركة أجايل، اكتسبت تقنية قصص المستخدم من البرمجة المتطرفة شعبية واسعة لدرجة أن الكثيرين يعتقدون أنها الحل الأمثل والوحيد لتلبية متطلبات أجايل في جميع المشاريع. ويذكر أليستير كوكبيرن خمسة أسباب تجعله لا يزال يستخدم حالات الاستخدام في تطوير أجايل . ^{[ 34 ]}

1. تُقدّم قائمة أسماء الأهداف ملخصًا موجزًا ​​لما سيُوفّره النظام (حتى في هذه الحالة، قصص المستخدم). كما تُوفّر هيكلًا أساسيًا لتخطيط المشروع، يُستخدم لتحديد الأولويات الأولية، والتقديرات، وتوزيع الفريق، والجدول الزمني.
2. يُتيح سيناريو النجاح الرئيسي لكل حالة استخدام لجميع الأطراف المعنية اتفاقًا حول ما سيفعله النظام بشكل أساسي وما لن يفعله. كما يُوفر سياقًا لكل متطلب محدد (مثل قصص المستخدم التفصيلية)، وهو سياق يصعب الحصول عليه من أي مكان آخر.
3. توفر شروط التوسعة لكل حالة استخدام إطارًا للتحقيق في جميع التفاصيل الصغيرة والمزعجة التي تستنزف 80% من وقت التطوير وميزانيته. كما توفر آلية استباقية تمكّن أصحاب المصلحة من رصد المشكلات التي يُحتمل أن تستغرق وقتًا طويلاً لإيجاد حلول لها. ويمكن، بل ينبغي، وضع هذه المشكلات في مقدمة الجدول الزمني حتى تكون الحلول جاهزة عندما يبدأ فريق التطوير العمل عليها.
4. تُقدّم أجزاء سيناريوهات توسيع حالات الاستخدام إجاباتٍ للعديد من الأسئلة التجارية المُفصّلة، والتي غالبًا ما تكون مُعقّدة ومُهملة: "ماذا يُفترض بنا أن نفعل في هذه الحالة؟". إنه إطار عمل للتفكير والتوثيق يُطابق عبارة "إذا...ثم...وإلا"، ويُساعد المُبرمجين على التفكير مليًا في المشكلات. إلا أنه يتم ذلك أثناء مرحلة التحقيق، وليس أثناء مرحلة البرمجة.
5. تُظهر مجموعة حالات الاستخدام الكاملة أن المحققين قد فكروا ملياً في احتياجات كل مستخدم، وكل هدف لديهم فيما يتعلق بالنظام، وكل متغير تجاري ذي صلة.

باختصار، فإن تحديد متطلبات النظام في حالات الاستخدام له هذه الفوائد الواضحة مقارنة بالأساليب التقليدية أو غيرها:

يركز على المستخدم

تُشكّل حالات الاستخدام أداةً فعّالةً ومُركّزةً على المستخدم في عملية تحديد متطلبات البرمجيات. ^{[ 35 ]} يبدأ نمذجة حالات الاستخدام عادةً بتحديد أدوار أصحاب المصلحة الرئيسيين ( الجهات الفاعلة ) المتفاعلة مع النظام، وأهدافهم التي يجب أن يُحققها النظام (من منظور خارجي). تُصبح أهداف المستخدم هذه بعد ذلك المُرشّحة المثالية لأسماء أو عناوين حالات الاستخدام التي تُمثّل الميزات أو الخدمات الوظيفية المطلوبة التي يُقدّمها النظام. يضمن هذا النهج المُركّز على المستخدم تطوير ما له قيمة تجارية حقيقية وما يريده المستخدم فعلاً، وليس تلك الوظائف الثانوية المُتكهّن بها من منظور المُطوّر أو النظام (من الداخل).

يُعد تأليف حالات الاستخدام أداة تحليل في مجال التصميم المتمحور حول المستخدم (UCD) .

تواصل أفضل

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

متطلبات الجودة من خلال الاستكشاف المنظم

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

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

تسهيل عملية الاختبار وتوثيق المستخدم

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

تشمل قيود حالات الاستخدام ما يلي:

• لا تُعدّ حالات الاستخدام مناسبةً لتحديد متطلبات النظام غير القائمة على التفاعل (مثل متطلبات الخوارزميات أو المتطلبات الرياضية) أو المتطلبات غير الوظيفية (مثل متطلبات المنصة، أو الأداء، أو التوقيت، أو الجوانب بالغة الأهمية للسلامة). من الأفضل تحديد هذه المتطلبات بشكلٍ تصريحي في مكانٍ آخر.
• نظراً لعدم وجود تعريفات قياسية كاملة لحالات الاستخدام، يجب على كل مشروع أن يشكل تفسيره الخاص.
• بعض علاقات حالات الاستخدام، مثل extends ، غامضة في تفسيرها ويمكن أن يكون من الصعب على أصحاب المصلحة فهمها كما أشار كوكبيرن (المشكلة رقم 6) ^{[ 37 ].}
• يجد مطورو حالات الاستخدام صعوبةً في تحديد مستوى اعتماد واجهة المستخدم على حالة الاستخدام. فبينما تشير نظرية حالات الاستخدام إلى عدم تضمين واجهة المستخدم فيها، قد يكون من الصعب تجريد هذا الجانب من التصميم، إذ يُصعّب ذلك تصور حالات الاستخدام. في هندسة البرمجيات، تُحل هذه الصعوبة بتطبيق تتبع المتطلبات ، باستخدام مصفوفة التتبع على سبيل المثال . وهناك طريقة أخرى لربط عناصر واجهة المستخدم بحالات الاستخدام، وهي إرفاق تصميم واجهة المستخدم بكل خطوة في حالة الاستخدام، وهو ما يُعرف بلوحة قصة حالة الاستخدام.
• قد يُبالغ في التركيز على حالات الاستخدام. يناقش برتراند ماير قضايا مثل توجيه تصميم النظام حرفيًا جدًا من حالات الاستخدام، واستخدام حالات الاستخدام على حساب تقنيات تحليل المتطلبات الأخرى التي قد تكون قيّمة. ^{[ 38 ]}
• تُعدّ حالات الاستخدام نقطة انطلاق لتصميم الاختبار، ^{[ 39 ]} ولكن بما أن كل اختبار يحتاج إلى معايير نجاح خاصة به، فقد يلزم تعديل حالات الاستخدام لتوفير شروط لاحقة منفصلة لكل مسار. ^{[ 40 ]}
• على الرغم من أن حالات الاستخدام تتضمن الأهداف والسياقات، فإن ما إذا كانت هذه الأهداف والدوافع الكامنة وراء الأهداف (مخاوف أصحاب المصلحة وتقييماتهم بما في ذلك عدم التفاعل) تتعارض أو تؤثر سلبًا/إيجابًا على أهداف النظام الأخرى هو موضوع تقنيات نمذجة المتطلبات الموجهة نحو الأهداف (مثل BMM و I* و KAOS و ArchiMate ARMOR).

من المفاهيم الخاطئة الشائعة حول حالات الاستخدام ما يلي:

قصص المستخدمين مرنة؛ أما حالات الاستخدام فليست كذلك.

تعتبر منهجيات أجايل وسكروم محايدة فيما يتعلق بتقنيات تحديد المتطلبات. وكما ورد في كتاب سكروم التمهيدي ^{[ 41 ]} ،

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

لقد تطورت تقنيات حالات الاستخدام لتأخذ في الاعتبار مناهج Agile من خلال استخدام شرائح حالات الاستخدام لإثراء حالة الاستخدام بشكل تدريجي. ^{[ 15 ]}

حالات الاستخدام عبارة عن مخططات بشكل أساسي.

يؤكد كريج لارمان أن "حالات الاستخدام ليست رسومًا بيانية، بل هي نصوص". ^{[ 42 ]}

تحتوي حالات الاستخدام على الكثير من المحتوى المتعلق بواجهة المستخدم.

كما يقول البعض،

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

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

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

كتابة حالات الاستخدام للأنظمة الكبيرة أمر ممل ومضيعة للوقت.

كما يقول البعض،

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

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

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

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

تتضمن بعض أدوات حالات الاستخدام المعروفة ما يلي:

• CaseComplete
• مهندس معماري للمؤسسات
• ماجيك درو
• RequisitePro من شركة Rational Software - أحد الأدوات المبكرة والمعروفة لإدارة حالات الاستخدام والمتطلبات في التسعينيات.
• برنامج تصميم الأفكار
• برامج ويكي – أدوات جيدة للفرق لإنشاء وإدارة حالات الاستخدام بشكل تعاوني.

تدعم معظم أدوات UML كلاً من كتابة النصوص والنمذجة المرئية لحالات الاستخدام.

• قضية إساءة معاملة
• دراسة جدوى
• الكيان – التحكم – الحدود
• تقسيم الأحداث
• ميزة
• قائمة أدوات UML
• قضية إساءة استخدام
• متطلبات
• استخلاص المتطلبات
• سيناريو
• لوحة القصة
• حالة اختبار
• استخدم نقاط الحالة

• ألكسندر، إيان وبيوس-دوكيتش، ليركا. اكتشاف المتطلبات: كيفية تحديد المنتجات والخدمات . وايلي، 2009.
• ألكسندر، إيان ومايدن، نيل. سيناريوهات، قصص، حالات استخدام . وايلي 2004.
• أرمور، فرانك، وغرانفيل ميلر. نمذجة حالات الاستخدام المتقدمة: أنظمة البرمجيات . أديسون-ويسلي، 2000.
• كورت بيتنر، إيان سبنس، نمذجة حالات الاستخدام ، أديسون-ويسلي بروفيشنال، 20 أغسطس 2002.
• كوكبيرن، أليستير. كتابة حالات الاستخدام الفعالة. أديسون-ويسلي، 2001.
• لاري كونستانتين، لوسي لوكوود، البرمجيات للاستخدام: دليل عملي للنماذج والأساليب الأساسية للتصميم المرتكز على الاستخدام ، أديسون ويسلي، 1999.
• ديني، ريتشارد. النجاح باستخدام حالات الاستخدام: العمل بذكاء لتقديم الجودة . أديسون-ويسلي، 2005.
• فاولر، مارتن. UML Distilled (الطبعة الثالثة) . أديسون-ويسلي، 2004.
• Jacobson, Ivar; Christerson, M.; Jonsson, P.; Övergaard, G., هندسة البرمجيات الموجهة للكائنات - نهج قائم على حالات الاستخدام ، Addison-Wesley، 1992.
• Jacobson, Ivar; Spence, I.; Bittner, K., Use Case 2.0: The Guide to Succeeding with Use Cases , IJI SA, 2011.
• دين ليفينغويل، دون ويدريغ، إدارة متطلبات البرمجيات: نهج حالة الاستخدام ، أديسون-ويسلي بروفيشنال. 7 ديسمبر 2012.
• كولاك، داريل، وإيمون غيني. حالات الاستخدام: المتطلبات في سياقها. أديسون-ويسلي، 2012.
• ماير، برتراند. بناء البرمجيات الموجهة للكائنات . (الطبعة الثانية). برنتيس هول، 2000.
• شنايدر، جيري ووينترز، جيسون ب. تطبيق حالات الاستخدام، الطبعة الثانية: دليل عملي . أديسون-ويسلي، 2001.
• وازلاويك، راؤول س. التحليل والتصميم الموجه للكائنات لأنظمة المعلومات: النمذجة باستخدام UML وOCL وIFML . مورغان كوفمان، 2014.

• عمود حالات الاستخدام . مؤرشف بتاريخ ٢٧ يناير ٢٠١٦ في أرشيف الإنترنت (Wayback Machine) . وقالب حالات الاستخدام الأساسي . مؤرشف بتاريخ ١٣ سبتمبر ٢٠٠٨ في أرشيف الإنترنت (Wayback Machine) بواسطة أليستير كوكبيرن.
• حالات الاستخدام على موقع Usability.gov التابع لإدارة الخدمات العامة
• تطبيق حالات الاستخدام لتحليل أصحاب المصلحة "مشروع إيكاروس" على موقع Academia.edu
• ابحث عن "حالة الاستخدام" في IBM Developer