يبحث مديرو المنتجات باستمرار عن طرق لتبسيط مشاريعهم وتحسين التواصل داخل فرق العمل. وتأتي حالات الاستخدام في هذا السياق كخيار ممتاز، فعند بناء منتج تقني، فنحن بحاجة أولًا إلى فهم المنطق العملي لتفاعلات المستخدمين معه، من أجل التركيز على تلبية هدف حالة استخدام المنتج. وتمثل حالات الاستخدام في هذا السياق أداةً مثاليةً لوصف التفاعلات بين المستخدمين والمنتج بعيدًا عن تطبيقاته التقنية، كما أنها وسيلة قوية لتحديد المتطلبات والثغرات المحتملة في نطاق المشروع.
نتناول في هذا المقال أساسيات حالات الاستخدام، بما في ذلك مفهومها وكيفية بنائها والأنواع المختلفة لحالات الاستخدام، وميزاتها ومحدوديتها؛ إلى جانب التركيز على استخدامها في سياق إدارة المنتجات.
ما هي حالات الاستخدام؟
حالة الاستخدام هي وصف مفصل وشامل يُحدد كل الحالات الممكنة لتفاعل المستخدم مع النظام ونتائجها، بالإضافة إلى أهداف ومتطلبات المشروع. وهي مفهوم واسع الاستخدام في مجال إدارة المنتجات التقنية، حيث يصف في هذا السياق التفاعلات بين المستخدم والنظام الذي يمكن أن يكون برنامجًا أو أشخاصًا أو الاثنين معًا.
تخدم حالات الاستخدام مدير المنتجات من عدة زوايا، كما تسهّل التواصل بين أصحاب المصلحة ذوي الخلفيات المختلفة الموزعة بين مجال الأعمال والتقنية. على سبيل المثال، يمكن لمدير منتج يتعلق بموقع للتجارة الإلكترونية إنشاء حالة استخدام لوصف كيفية تفاعل العملاء مع الموقع، ويدخل ضمن ذلك كيفية البحث عن المنتجات وإضافة المشتريات المرغوبة إلى سلة التسوّق، وإتمام عملية الدفع، وتسمح حالة الاستخدام هذه بترسيخ فهم واضح لمتطلبات النظام، وهو ما يساعد بدوره على ضمان تلبية المنتج النهائي لاحتياجات كل من المستخدمين والعميل.
استعمِلت حالات الاستخدام عند ظهورها في مجال هندسة البرامج لتوثيق ورسم المتطلبات التي تسمح بتطوير برامج تتوافق مع احتياجات المستخدمين، لتصبح ذات استخدام شائع في مجال إدارة المشاريع التقنية منذ سنوات الثمانينات، فقد استعملها مديرو المشاريع لإيصال نطاق المشروع لأصحاب المصلحة والتوفيق بين أهداف المنتج والمتطلبات التقنية، ويُعد مقال عالم الحاسوب السويدي إيفار جاكوبسون Ivar Jacobson المنشور سنة 1987 أول مقال حول حالات الاستخدام، حيث وصف كيفية استخدامها في شركة إريكسون Ericsson للاتصالات لغرض توثيق متطلبات النظام وجاء بمصطلحي حالات الاستخدام usage cases وسيناريوهات الاستخدام usage scenarios، ووثق جاكوبسون كيفية تطويره وتطبيقه لحالات الاستخدام في كتاب هندسة البرامج المدفوعة بالأهداف Object-Oriented Software Engineering المنشور سنة 1992.
عناصر حالات الاستخدام
حتى نتمكن من الوصف الدقيق لحالة استخدام معينة، ينبعي تحديد ثلاثة عناصر أساسية.
1. الطرف أو الأطراف الفاعلة Actor(s)
الطرف الفاعل هو أحد أنواع المستخدمين الذين يتعاملون من النظام، ويكون تفاعلهم من خلال النقر على الأزرار أو الأيقونات أو إدخال النصوص وما إلى ذلك، والأطراف الفاعلة خارجية بالنسبة للنظام، ولا تكون بالضرورة أشخاصًا إذ يمكن أن تكون أنظمة أخرى في حد ذاتها، أو أن تكون ببساطة عامل الزمن، فعندما يؤكد عميل ما طلبه على موقع للتجارة الإلكترونية، ينتقل نظام الطلبيات إلى نظام الجرد لتحديد ما إذا كان المنتج المطلوب موجودًا في المخزون أم لا، وهنا يُعد نظام الجرد جهة فاعلة أخرى، وإذا أدت عمليات نهاية الشهر إلى تشغيل نظام الطلبات لإنشاء تقارير حول المبيعات على سبيل المثال، فإن عامل الزمن هنا يمثل طرفًا فاعلًا، وتسمى الجهات الفاعلة الزمنية بالجهات الفاعلة المؤقتة temporal actors.
2. النظام the system
النظام هو كل ما نخطط لإنشائه، ويمثل حدود المشروع، فمثلًا تتمثل حدود مشروع تطوير موقع للتجارة الإلكترونية المنصة بالكامل وواجهاتها وصفحاتها المختلفة، وتساعد حدود النظام في تحديد نطاق المشروع ومخاطره، وتوثيق المتطلبات، وإذا كان تحديد الجهات الفاعلة الصحيحة معيارًا رئيسيًا لنجاح استعمالنا لحالة الاستخدام، فإن تحديد نطاق النظام هو أساس إدارة المشروع، ويفيد في تحديد الجهات الفاعلة في حد ذاتها.
3. الهدف الوظيفي functional goal
ويمثل الهدف الذي يبلُغه المستخدم من خلال استخدام النظام، وينبغي أن يكون هذا الهدف ذا قيمة للأطراف الفاعلة، فعند تحليل المتطلبات الوظيفية للنظام، يجب الأخذ في الحسبان من سيستخدم النظام والغرض من هذا الاستخدام.
اقتباسما هو سيناريو حالة الاستخدام؟
لا يحصل جميع المستخدمين الراغبين في الدفع عند الشراء من موقع للتجارة الإلكترونية على نفس النتائج وبنفس الطريقة، فأحيانًا تكون بطاقات الدفع المستخدمة غير مقبولة، وأحيانًا أخرى يكون رصيدهم غير كاف، فيما تسير الأمور بسلاسة بالنسبة لمستخدمين آخرين، وهذه أمثلة عن سيناريوهات حالة الاستخدام، فالنتائج تختلف باختلاف الظروف إلا أنها مدفوعة بنفس الحاجة التي أطلقتها في البداية وترتبط جميعًا بنفس الهدف الوظيفي.
اقتباستوصف حالات الاستخدام عمليًا من خلال وصف السيناريوهات، إذ تشكل هذه الأخيرة أساس تصميم التفاعل بين النظام والمستخدمين، كما تسهل وضع تصور لعناصر التطوير الأخرى مثل نصوص اختبار النظام وتوثيق المستخدم.
مراحل إنشاء حالات الاستخدام
يتطلب إنشاء حالة استخدام حسب موقع Indeed المرور بالخطوات التالية:
1. تحديد الأطراف الفاعلة
إن أول خطوة لإنشاء أي حالة استخدام هي تحديد الأطراف التي ستتفاعل مع النظام، ويمكن أن تكون هذه الأطراف رئيسية أو ثانوية، فالأطراف الرئيسية، مثل المستخدم النهائي، لديها هدف وتحتاج مساعدة النظام لتحقيقه، بينما لدى الأطراف الثانوية، مثل مدير الموقع الإلكتروني، هدف يحتاج النظام إلى معلومات لتحقيقه، ومن أمثلة الأطراف الفاعلة العملاء والمستخدمون النهائيون، ومديرو المنتج، والتقنيون والموظفون.
2. تحديد أهداف المستخدم
نختار خلال هذه المرحلة نوعًا واحدًا من أنواع المستخدمين ونحدد أهدافه، والهدف هو أي شيء يريد الطرف الفاعل الرئيسي أو الثانوي تحقيقه، ويمكن تصنيف الأهداف إلى أهداف صارمة rigid goals من الضروري تحقيقها إذ أنها تدخل عادةً ضمن المتطلبات الدنيا لحالة استخدام النظام المعني، وأخرى مرنة soft goals تُعد نتائج مرغوبة ولكن لا تدخل ضمن المتطلبات.
يتوقف اختيار أي من الأطراف الفاعلة نحدد أهدافه خلال مرحلة معينة على العملية أو النظام وعلى الجمهور المستهدف، كما يمكن أن توجد شروط مسبقة كجزء من هذه الخطوة، إذ أن بعض الخصائص معلوم مسبقًا أنها ضرورية، مثل قدرة المستخدم على شراء شيء من الموقع، أو ضرورة وجود نظام مدمج يشجع العملاء على شراء منتجات إضافية.
3. تحديد العمليات
نحدد خلال هذه المرحلة الخطوات الضرورية ليحقق المستخدم هدفًا معينًا، وينبغي هنا توخي أقصى درجات التفصيل وذِكر إضافةً إلى خطوات المستخدم نتائج هذه الخطوات، وكيف يستجيب النظام لكل واحدة منها في الحالة العادية، ويسمح الفحص الحذر لكل هدف وللعمليات المرتبطة به بإنشاء مخطط لوظائف النظام.
4. تحديد النتائج البديلة
يتطلب تطوير حالة استخدام التنبؤ بالنتائج المعتادة لسلوك معين، إلا أن بعض السلوكيات يمكن أن يكون لها نتائج مختلفة، وفي هذا الحالة ينبغي التفكير في النتائج البديلة لكل خطوة وإضافتها كامتداد لحالة الاستخدام محل التطوير.
5. المقارنة بين حالات الاستخدام وتحديد نقاط التشابه
عندما نتوصل إلى إنشاء قائمة مكتملة لحالات الاستخدام بناءً على سلوكيات المستخدم، ينبغي المقارنة بينها والبحث عن أوجه التشابه بين السلوكيات والنتائج، ويسمح هذا بوضع مجموعة من القواعد التي تقودنا خلال إنشاء أنشطة رد الفعل لنظام المعالجة.
6. تكرار العملية لكل الأطراف الفاعلة
لدى أغلب العمليات مجموعات مختلفة من المستخدمين، لذلك، وكلما انتهينا من عملية تطوير حالة استخدام لمستخدم معين، نكرر العملية لكل طرف فاعل آخر، وعند الانتهاء من تطوير حالات الاستخدام لكل الأطراف الفاعلية، نحللها للوصول إلى فهم أكثر شمولًا للعملية أو للنظام.
يمكن لفرق العمل من خلال اتباع هذه الخطوات إنشاء حالات استخدام توفر صورة واضحة ومفصلة لكيفية تفاعل المستخدمين مع النظام، ما يساعد بدوره على ضمان تلبية النظام لاحتياجاتهم وتوقعاتهم.
اقتباسالفرق بين مخطط حالة الاستخدام ونموذج حالة الاستخدام
مخطط حالة الاستخدام هو تمثيل مرئي للأطراف الفاعلية وحالات الاستخدام وعلاقاتهم، يُستخدم لتقديم نظرة عامة وشاملة عن النظام ووظائفه، وذلك بغرض تحسين التواصل مع أصحاب المصلحة وأعضاء فريق العمل ذوي الخلفية غير التقنية، ويمكن أن يساعد مخطط حالة الاستخدام أيضًا في تحديد الأخطاء الحالية أو الأخطاء المحتملة في النظام.
أما نموذج حالة الاستخدام فهو تمثيل أكثر تفصيلاً لسلوك النظام ووظائفه، يتألف من مجموعة من حالات الاستخدام والجهات الفاعلة والعلاقات، ويتضمن وصفًا تفصيليًا لكل حالة استخدام، بما في ذلك الشروط المسبقة واللاحقة، والسير العادي للأحداث، وتستخدم فرق التطوير نموذج حالة الاستخدام لتصميم النظام وتنفيذه واختباره.
أنواع حالات الاستخدام
توجد عامةً عدة زوايا يمكن من خلالها تصنيف حالات الاستخدام إلى أنواع مختلفة، ولكن أشهر تبويب لها في المراجع ذات الصلة هو تقسيمها إلى حالات استخدام الاعمال Business use cases وحالات استخدام النظام System use وذلك كما يلي:
1. حالات استخدام الأعمال
تركز حالات استخدام الأعمال على متطلبات المستخدمين وتوقعاتهم من النظام، إذ تصف حالات الاستخدام في هذه الحالة المهام التي يحتاج المستخدمون إنجازها باستخدام النظام، فعلى سبيل المثال، يمكن أن تكون حالة استخدام الأعمال لأحد مواقع التجارة الإلكترونية هي "عملية الطلب"، لتصف الخطوات التي يتخذها المستخدم لطلب منتج على الموقع، بما في ذلك اختيار المنتج وإدخال معلومات الشحن وإجراء الدفع.
2. حالات استخدام النظام
تصف حالات استخدام النظام كيف يتصرف النظام استجابةً للإجراءات التي يتخذها المستخدمون، فتركز على وظائف النظام والخطوات التي يتخذها لإنجاز مهمة ما، وفي مثال موقع التجارة الإلكترونية، يمكن أن تصف حالة استخدام النظام المُعَنونة "معالجة الطلب" الخطوات التي يتخذها النظام لمعالجة طلب مستخدم ما، بما في ذلك التحقق من معلومات الدفع، وتحديث مستويات المخزون، وإرسال بريد إلكتروني للتأكيد.
باستخدام كلا النوعين من حالات الاستخدام، يمكن لمديري المنتجات التأكد من أنهم كَوَّنوا فهمًا كاملاً لمتطلبات المستخدم ووظائف النظام، ما يتيح إدارةً أكثر فاعليةً وكفاءةً، فضلًا عن مستوى أعلى من الرضا للمستخدمين النهائيين.
ونشير إلى أنه توجد تصنيفات أخرى لحالات الاستخدام مثل تبويبها إلى حالات استخدام أولية تشمل السيناريوهات الأهم التي ينبغي للنظام دعمها، وأخرى داعِمة تقل أهميةً عن تلك الأولية ويمكن أن تكون اختيارية، أو تصنيفها إلى حالات استخدام ذات سير عادي تمثل المسار الطبيعي للمستخدمين لتحقيق الهدف الوظيفي، وحالات استخدام بديلة تصف سيناريوهات أقل شيوعًا أو استثناءات للسير العادي للنظام، كما يُمكن تبويب حالات الاستخدام إلى حالات استخدام غير مفصلة توفر نظرة شاملة عن وظائف النظام، وحالات استخدام مفصلة توفر وصفًا أكثر عمقًا لكل خطوة في سيناريو الحالة.
كيف تفيد حالات الاستخدام مديري المنتجات؟
رغم أن الاستعمال الشائع لحالات الاستخدام هو تحديد متطلبات البرامج، إلا أنها تفيد مديري المنتجات من عدة زوايا، إذ تتيح لهم توضيح الأهداف الغامضة، خاصةً عندما يتضمن المنتج عمليات أو تقنيات جديدة، كما تسمح بتحديد المتطلبات والحفاظ على تناسقها، ويتعلق الأمر عادةً بوظيفة أو عملية معينة يريد مدير المنتجات تحسينها أو تطبيقها، فيبدأ بتحديد المتطلبات الوظيفية والتدفقات الأساسية من خلال مخطط حالة الاستخدام.
ولتوضيح كيفية تحديد المتطلبات اعتمادًا على حالة الاستخدام، فلنفرض على سبيل المثال أن مدير المنتج يرغب في تحسين وظيفة إدارة خدمة العملاء، يمكن أن تتضمن الأطراف الفاعلة في هذه الحالة موظفي مكتب خدمة العملاء، والمديرين التنفيذيين والعملاء أنفسهم، ويمكن أن تتضمن التفاعلات طلبات أو رسائل محددة وكيفية التعامل مع كل واحدة منها، وبعد إنشاء حالة الاستعمال الرئيسية، يمكن أن ينفذ مدير المنتج تحليلًا شاملًا ويصمم طرقًا يمكن من خلالها تحسين عمليات خدمة العملاء الحالية، وتساعد نمذجة حالات الاستخدام على هذا المنوال مديري المنتجات خلال كل من مرحلتي التخطيط والتنفيذ.
يواجه مديرو المنتجات أيضًا صعوبات في ترجمة ما يريده المستخدمون من النظام إلى تصميم تقني، والتأكد من صحة هذه الترجمة من قِبل المستخدمين أنفسهم قبل بناء النظام، كما أن السودوكود أو الكود الزائف pseudo code الذي عادةً ما يكتبه مطورو البرامج يتميز بدرجة عالية من التقنية لا تتيح لأغلب المستخدمين فهمه، إلا أن حالات الاستخدام جاءت لحل هذه المشكلات من خلال توفيرها لترجمة يمكن للمستخدمين النهائيين فهمها وتعديلها قبل استثمار وقت طويل في المشروع، فهي توفر هيكلًا يجمع متطلبات المستخدمين ما يسمح بتحديد نطاق المنتج، كما أنها تسمح باختبار النظام أثناء بنائه من قِبل المستخدمين، ورغم أنها ليست حلًا مكتملًا لقضية جمع المتطلبات، فهي تسهل تطوير واجهات المستخدم والرسائل التي يتعامل معها.
بالإضافة إلى الميزات المذكورة، يستفيد مديرو المنتجات من الميزات التالية عند استخدامهم لحالات الاستخدام:
- توجيه النظام إلى ردة الفعل الملائمة على سلوك المستخدم.
- مساعدة النظام على التنبؤ بالأخطاء قبل حدوثها.
- توفير قائمة أهداف للنظام مع الخطوات اللازمة لتحقيق كل واحد منها.
- وضع مجموعة من القواعد لكيفية الاستخدام الأمثل للتقنية لتحقيق أهداف المستخدم.
- تسهيل التواصل بين العملاء وفرق العمل التقنية.
- إتاحة الاختبارات المبنية على المتطلبات وسيناريوهات قبول المستخدمين.
- هيكلة كيفية التعامل مع الحالات الاستثنائية.
اقتباسيمكن لمدير منتجات في شركة تجارية كُلف بإدارة تطوير منتج يتمثل في موقع للتجارة الإلكترونية لمجموعة من المنتجات إنشاء حالة استخدام للموقع، ما يسمح له بتزويد أصحاب المصلحة بفهم واضح لرحلة العميل من تصفح المنتجات إلى إتمام عملية الشراء، ستساعد هذه العملية في تحديد أي ثغرات في نطاق المشروع والتأكد من أن فريق العمل كوّن فهمًا شاملًا لاحتياجات ومتطلبات العميل، ومن خلال حالة الاستخدام، سيتمكن أصحاب المصلحة من رؤية كيفية عمل موقع الإنترنت، وكيف سيقدم قيمة للعميل، وسيؤدي هذا في النهاية إلى مشروع أكثر نجاحًا وإلى منتج يلبي احتياجات كل من العميل والشركة.
محدودية حالات الاستخدام
رغم كونها أداةً ممتازةً لتوثيق متطلبات النظام والتوفيق بين نطاق المشروع واحتياجات المستخدمين، بالإضافة إلى تسهيل الاتصال بين أصحاب المصلحة التقنيين وذوي الخلفية من مجال الأعمال، فهي لا تكون دائمًا كافية لضمان التوافق التام بين أهداف العمل والمتطلبات التقنية، كما أنها لا تناسب دائمًا كل أنواع المتطلبات، فإذا كان مشروع معين يتطلب أساسًا معالجة البيانات أو إعداد التقارير على سبيل المثال، يمكن أن تكون النماذج الأخرى مثل نماذج البيانات أكثر فعالية، في ذات السياق، لا توثق حالات الاستخدام جميع المتطلبات، وخاصةً تللك التي يصعب نمذجتها، كما أن نمذجتها تستغرق وقتًا يفوق منفعتها في بعض الأحيان، ويمكن أن تتطلب استثمارًا كبيرًا في الموارد المادية والبشرية.
أخيرًا، ورغم محدوديتها، تبقى حالات الاستخدام أصولًا قيّمةً لأي عملية إدارة منتج، وأداةً فعالةً لتحديد متطلبات ونطاق المشاريع، إذ يتيح إنشاء نموذج حالة استخدام ومخططها لأصحاب المصلحة وفريق العمل فهمًا جيدًا لاحتياجات المستخدم والتفاعلات مع المنتج ووظائف النظام، ولمعرفة أكثر عمقًا حول إدارة المنتجات وكيفية إنشاء حالات استخدام فعالة، ننصح بالدورة الشاملة التي توفرها أكاديمية حسوب حول إدارة تطوير المنتجات والتي تحتوي على فصل خاص بتطوير حالات الاستخدام وتطبيقاتها في مجال إدارة المنتجات.
المصادر
- Use Cases -An Introduction
- ?What Is a Use Case
- Use cases what every project manager should know
- Creating a Use Case in 6 Steps (With Definition and Example)
أفضل التعليقات
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.