#007 — Use Cases | حالات الاستخدام
قبل أن تبدأ في تصميم النظام أو كتابة الكود، هناك سؤال أهم:
ماذا يريد المستخدم أن يحقق من خلال النظام؟
هنا تأتي أهمية Use Cases.
الـ Use Case تصف تفاعل جهة خارجية Actor مع النظام من أجل الوصول إلى هدف محدد.
بمعنى أبسط:
Actor → Interaction → System → Goal
فمثلًا، في متجر إلكتروني لا نقول فقط إن لدينا شاشة لتسجيل الدخول أو صفحة للدفع، بل نحاول فهم السيناريو كاملًا من منظور المستخدم:
المستخدم يريد تسجيل الدخول إلى حسابه.
العميل يريد إنشاء طلب.
مدير النظام يريد إدارة المنتجات.
بوابة الدفع تريد معالجة عملية الدفع.
والـ Actor ليس بالضرورة شخصًا فقط؛ فقد يكون مستخدمًا، مديرًا، نظامًا خارجيًا أو خدمة أخرى تتفاعل مع النظام.
وعند كتابة Use Case جيدة، نحتاج إلى معرفة:
Actor: من يتفاعل مع النظام؟
Goal: ما الهدف الذي يريد تحقيقه؟
Preconditions: ما الشروط المطلوبة قبل بدء العملية؟
Main Flow: ما المسار الطبيعي للسيناريو؟
Alternative / Exception Flow: ماذا يحدث عند وجود مسار بديل أو خطأ؟
Postconditions: ما حالة النظام بعد انتهاء العملية؟
خذ تسجيل الدخول مثالًا.
الهدف ليس شرح Authentication API أو Database Query أو طريقة إنشاء Token.
الهدف هو وصف تفاعل المستخدم:
يدخل المستخدم بياناته، يتحقق النظام منها، وإذا كانت صحيحة يسمح له بالدخول.
وإذا كانت البيانات خاطئة، يجب أن تصف الـUse Case هذا السيناريو أيضًا: يرفض النظام تسجيل الدخول، يعرض رسالة مناسبة، ويسمح للمستخدم بالمحاولة مرة أخرى.
وهذه نقطة مهمة:
Use Case الجيدة لا تصف طريق النجاح فقط.
بل تساعدنا على التفكير في السيناريوهات البديلة والاستثناءات التي قد تحدث أثناء استخدام النظام.
لذلك لا تكتب الـUse Case من منظور المبرمج وتسأل:
كيف سننفذ هذه الوظيفة؟
اكتبها من منظور المستخدم واسأل:
من يريد ماذا من النظام، وما السيناريو الذي يوصله إلى هدفه؟
عندما تكون Use Cases واضحة، يصبح فهم المتطلبات وتحليل النظام وتصميمه واختباره أسهل على الفريق.
تحدي بسيط:
في تطبيق بنكي، يريد العميل تحويل مبلغ مالي إلى حساب آخر.
من هو الـ Actor؟
ما هو الـ Goal؟
وما أول 3 خطوات تتوقعها في الـ Main Flow؟
اكتب السيناريو في التعليقات.
المنشور القادم #008 — User Stories
كيف نحول احتياجات المستخدم إلى قصص قصيرة وواضحة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UseCases #UML #RequirementsEngineering #Requirements #SystemAnalysis #SystemDesign #SoftwareArchitecture #BusinessAnalysis #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #UserStories #هندسة_البرمجيات #تحليل_النظم #حالات_الاستخدام #تطوير_البرمجيات
قبل أن تبدأ في تصميم النظام أو كتابة الكود، هناك سؤال أهم:
ماذا يريد المستخدم أن يحقق من خلال النظام؟
هنا تأتي أهمية Use Cases.
الـ Use Case تصف تفاعل جهة خارجية Actor مع النظام من أجل الوصول إلى هدف محدد.
بمعنى أبسط:
Actor → Interaction → System → Goal
فمثلًا، في متجر إلكتروني لا نقول فقط إن لدينا شاشة لتسجيل الدخول أو صفحة للدفع، بل نحاول فهم السيناريو كاملًا من منظور المستخدم:
المستخدم يريد تسجيل الدخول إلى حسابه.
العميل يريد إنشاء طلب.
مدير النظام يريد إدارة المنتجات.
بوابة الدفع تريد معالجة عملية الدفع.
والـ Actor ليس بالضرورة شخصًا فقط؛ فقد يكون مستخدمًا، مديرًا، نظامًا خارجيًا أو خدمة أخرى تتفاعل مع النظام.
وعند كتابة Use Case جيدة، نحتاج إلى معرفة:
Actor: من يتفاعل مع النظام؟
Goal: ما الهدف الذي يريد تحقيقه؟
Preconditions: ما الشروط المطلوبة قبل بدء العملية؟
Main Flow: ما المسار الطبيعي للسيناريو؟
Alternative / Exception Flow: ماذا يحدث عند وجود مسار بديل أو خطأ؟
Postconditions: ما حالة النظام بعد انتهاء العملية؟
خذ تسجيل الدخول مثالًا.
الهدف ليس شرح Authentication API أو Database Query أو طريقة إنشاء Token.
الهدف هو وصف تفاعل المستخدم:
يدخل المستخدم بياناته، يتحقق النظام منها، وإذا كانت صحيحة يسمح له بالدخول.
وإذا كانت البيانات خاطئة، يجب أن تصف الـUse Case هذا السيناريو أيضًا: يرفض النظام تسجيل الدخول، يعرض رسالة مناسبة، ويسمح للمستخدم بالمحاولة مرة أخرى.
وهذه نقطة مهمة:
Use Case الجيدة لا تصف طريق النجاح فقط.
بل تساعدنا على التفكير في السيناريوهات البديلة والاستثناءات التي قد تحدث أثناء استخدام النظام.
لذلك لا تكتب الـUse Case من منظور المبرمج وتسأل:
كيف سننفذ هذه الوظيفة؟
اكتبها من منظور المستخدم واسأل:
من يريد ماذا من النظام، وما السيناريو الذي يوصله إلى هدفه؟
عندما تكون Use Cases واضحة، يصبح فهم المتطلبات وتحليل النظام وتصميمه واختباره أسهل على الفريق.
تحدي بسيط:
في تطبيق بنكي، يريد العميل تحويل مبلغ مالي إلى حساب آخر.
من هو الـ Actor؟
ما هو الـ Goal؟
وما أول 3 خطوات تتوقعها في الـ Main Flow؟
اكتب السيناريو في التعليقات.
المنشور القادم #008 — User Stories
كيف نحول احتياجات المستخدم إلى قصص قصيرة وواضحة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UseCases #UML #RequirementsEngineering #Requirements #SystemAnalysis #SystemDesign #SoftwareArchitecture #BusinessAnalysis #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #UserStories #هندسة_البرمجيات #تحليل_النظم #حالات_الاستخدام #تطوير_البرمجيات
❤1
#008 — User Stories | قصص المستخدم
في تطوير البرمجيات، من السهل أن نبدأ بالتفكير في الـFeatures والحلول التقنية قبل أن نفهم السؤال الأهم:
ماذا يحتاج المستخدم فعلًا؟ ولماذا؟
هنا تأتي أهمية User Stories.
الـUser Story هي طريقة مختصرة وواضحة لوصف احتياج أو وظيفة من منظور المستخدم، وليس من منظور المبرمج أو تفاصيل التنفيذ.
وغالبًا تُكتب بهذه الصيغة:
As a [Role]
I want [Goal]
So that [Benefit]
أي:
بصفتي [مستخدمًا معينًا]، أريد [تحقيق هدف]، حتى أستطيع [الحصول على قيمة].
مثال في متجر إلكتروني:
As a Customer,
I want to track my order,
So that I know when it will arrive.
لاحظ أن القصة لم تقل كيف سنبرمج ميزة التتبع، وما الـAPI الذي سنستخدمه، أو كيف ستُصمم الواجهة.
هي فقط أجابت عن ثلاثة أسئلة أساسية:
WHO? من المستخدم؟
WHAT? ماذا يريد؟
WHY? لماذا يريده؟
لكن كتابة User Story وحدها لا تكفي دائمًا.
نحتاج أيضًا إلى Acceptance Criteria، وهي شروط واضحة تحدد متى نستطيع اعتبار القصة قد تحققت بشكل صحيح.
ولكتابة User Stories أفضل، يمكن الاستفادة من قاعدة INVEST:
Independent — مستقلة
Negotiable — قابلة للنقاش
Valuable — ذات قيمة
Estimable — قابلة للتقدير
Small — صغيرة
Testable — قابلة للاختبار
وهناك فرق مهم بين User Story و Use Case:
الـUser Story تصف الاحتياج والقيمة بشكل مختصر، بينما الـUse Case تدخل في تفاصيل أكبر حول تفاعل الـActor مع النظام، والمسار الأساسي والبدائل والنتيجة.
الفكرة ليست أن تختار واحدة لأنها "أفضل" دائمًا، بل أن تستخدم الأسلوب المناسب لطريقة تحليل وتوثيق مشروعك.
وأحد الأخطاء الشائعة هو كتابة الحل بدل الحاجة:
خطأ:
"نحتاج زرًا أخضر لتتبع الطلب."
أفضل:
"بصفتي عميلاً، أريد تتبع طلبي حتى أعرف حالته الحالية."
في الأولى فرضنا تصميمًا.
وفي الثانية فهمنا احتياج المستخدم أولًا.
وهذه قاعدة مهمة في هندسة البرمجيات:
لا تبدأ من الحل، ابدأ من المشكلة والمستخدم والقيمة التي يحتاجها.
والآن تحدٍ لك:
لديك تطبيق توصيل طعام، والمستخدم يريد معرفة مكان السائق بعد تأكيد الطلب.
كيف ستكتبها بصيغة:
As a...
I want...
So that...
اكتب الـUser Story في التعليقات.
المنشور القادم:
#009 — System Analysis | تحليل النظام
كيف تبدأ تحليل النظام قبل التفكير في الحل؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UserStories #Agile #RequirementsEngineering #Requirements #AcceptanceCriteria #INVEST #UseCases #SystemAnalysis #BusinessAnalysis #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #قصص_المستخدم #تطوير_البرمجيات
في تطوير البرمجيات، من السهل أن نبدأ بالتفكير في الـFeatures والحلول التقنية قبل أن نفهم السؤال الأهم:
ماذا يحتاج المستخدم فعلًا؟ ولماذا؟
هنا تأتي أهمية User Stories.
الـUser Story هي طريقة مختصرة وواضحة لوصف احتياج أو وظيفة من منظور المستخدم، وليس من منظور المبرمج أو تفاصيل التنفيذ.
وغالبًا تُكتب بهذه الصيغة:
As a [Role]
I want [Goal]
So that [Benefit]
أي:
بصفتي [مستخدمًا معينًا]، أريد [تحقيق هدف]، حتى أستطيع [الحصول على قيمة].
مثال في متجر إلكتروني:
As a Customer,
I want to track my order,
So that I know when it will arrive.
لاحظ أن القصة لم تقل كيف سنبرمج ميزة التتبع، وما الـAPI الذي سنستخدمه، أو كيف ستُصمم الواجهة.
هي فقط أجابت عن ثلاثة أسئلة أساسية:
WHO? من المستخدم؟
WHAT? ماذا يريد؟
WHY? لماذا يريده؟
لكن كتابة User Story وحدها لا تكفي دائمًا.
نحتاج أيضًا إلى Acceptance Criteria، وهي شروط واضحة تحدد متى نستطيع اعتبار القصة قد تحققت بشكل صحيح.
ولكتابة User Stories أفضل، يمكن الاستفادة من قاعدة INVEST:
Independent — مستقلة
Negotiable — قابلة للنقاش
Valuable — ذات قيمة
Estimable — قابلة للتقدير
Small — صغيرة
Testable — قابلة للاختبار
وهناك فرق مهم بين User Story و Use Case:
الـUser Story تصف الاحتياج والقيمة بشكل مختصر، بينما الـUse Case تدخل في تفاصيل أكبر حول تفاعل الـActor مع النظام، والمسار الأساسي والبدائل والنتيجة.
الفكرة ليست أن تختار واحدة لأنها "أفضل" دائمًا، بل أن تستخدم الأسلوب المناسب لطريقة تحليل وتوثيق مشروعك.
وأحد الأخطاء الشائعة هو كتابة الحل بدل الحاجة:
خطأ:
"نحتاج زرًا أخضر لتتبع الطلب."
أفضل:
"بصفتي عميلاً، أريد تتبع طلبي حتى أعرف حالته الحالية."
في الأولى فرضنا تصميمًا.
وفي الثانية فهمنا احتياج المستخدم أولًا.
وهذه قاعدة مهمة في هندسة البرمجيات:
لا تبدأ من الحل، ابدأ من المشكلة والمستخدم والقيمة التي يحتاجها.
والآن تحدٍ لك:
لديك تطبيق توصيل طعام، والمستخدم يريد معرفة مكان السائق بعد تأكيد الطلب.
كيف ستكتبها بصيغة:
As a...
I want...
So that...
اكتب الـUser Story في التعليقات.
المنشور القادم:
#009 — System Analysis | تحليل النظام
كيف تبدأ تحليل النظام قبل التفكير في الحل؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UserStories #Agile #RequirementsEngineering #Requirements #AcceptanceCriteria #INVEST #UseCases #SystemAnalysis #BusinessAnalysis #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #قصص_المستخدم #تطوير_البرمجيات