#009 — Use Case vs User Story
من أكثر الأمور التي تسبب التباسًا عند بداية تعلم هندسة البرمجيات:
ما الفرق بين User Story و Use Case؟ وهل أحتاج إلى الاثنين؟
كلاهما يساعدنا على فهم ما يحتاجه المستخدم، لكن الفرق الأساسي هو مستوى التفاصيل والغرض من الاستخدام.
الـ User Story تصف الحاجة من منظور المستخدم بطريقة مختصرة، وغالبًا تجيب عن ثلاثة أسئلة:
WHO — من؟
WHAT — ماذا يريد؟
WHY — لماذا يريده؟
مثال:
As a Customer,
I want to track my order,
So that I know when it will arrive.
هنا عرفنا المستخدم، وما الذي يريده، والقيمة التي سيحصل عليها، دون الدخول في تفاصيل التنفيذ.
أما الـ Use Case فتأخذنا إلى مستوى أعمق، وتصف كيف يتفاعل الـActor مع النظام للوصول إلى هدف معين.
فنبدأ بالنظر إلى:
Actor → Preconditions → Main Flow → Alternative Flow → Result
على سبيل المثال، في عملية تسجيل الدخول لا يكفي أن نعرف أن المستخدم يريد الوصول إلى حسابه، بل قد نحتاج إلى تحليل السيناريو:
ماذا يحدث عند إدخال البيانات الصحيحة؟
ماذا يحدث إذا كانت كلمة المرور خاطئة؟
ما الشروط المطلوبة قبل بدء العملية؟
وما النتيجة النهائية؟
وهنا تظهر قيمة الـUse Case.
لذلك يمكن تبسيط الفرق بهذه العبارة:
User Story = الحاجة والقيمة.
Use Case = التفاعل والسيناريو.
لكن الأهم: لا تتعامل معهما وكأن أحدهما بديل مطلق للآخر.
في بعض المشاريع قد تكون User Stories كافية للتخطيط والتواصل داخل الفريق، خصوصًا في بيئات Agile.
وفي سيناريوهات أكثر تعقيدًا، مثل الدفع الإلكتروني أو الحجز أو التحويل المالي، قد تحتاج إلى Use Cases لفهم المسارات الأساسية والبديلة بشكل أوضح.
بل يمكن استخدامهما معًا:
User Story → Acceptance Criteria → Use Case → Design → Development → Testing
الفكرة ليست أن تسأل:
أيهما أفضل؟
بل أن تسأل:
ما الذي أحاول فهمه الآن، وما مستوى التفاصيل الذي يحتاجه المشروع والفريق؟
هذه إحدى المهارات المهمة في تحليل الأنظمة:
لا تستخدم أداة لأنها مشهورة، استخدمها لأنها تحل مشكلة فعلية في مرحلة معينة من المشروع.
سؤال للنقاش:
لو كنت تحلل عملية تحويل أموال في تطبيق بنكي، هل ستبدأ بـ User Story أم Use Case؟ ولماذا؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UseCase #UserStory #RequirementsEngineering #SystemAnalysis #BusinessAnalysis #UML #Agile #AcceptanceCriteria #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
من أكثر الأمور التي تسبب التباسًا عند بداية تعلم هندسة البرمجيات:
ما الفرق بين User Story و Use Case؟ وهل أحتاج إلى الاثنين؟
كلاهما يساعدنا على فهم ما يحتاجه المستخدم، لكن الفرق الأساسي هو مستوى التفاصيل والغرض من الاستخدام.
الـ User Story تصف الحاجة من منظور المستخدم بطريقة مختصرة، وغالبًا تجيب عن ثلاثة أسئلة:
WHO — من؟
WHAT — ماذا يريد؟
WHY — لماذا يريده؟
مثال:
As a Customer,
I want to track my order,
So that I know when it will arrive.
هنا عرفنا المستخدم، وما الذي يريده، والقيمة التي سيحصل عليها، دون الدخول في تفاصيل التنفيذ.
أما الـ Use Case فتأخذنا إلى مستوى أعمق، وتصف كيف يتفاعل الـActor مع النظام للوصول إلى هدف معين.
فنبدأ بالنظر إلى:
Actor → Preconditions → Main Flow → Alternative Flow → Result
على سبيل المثال، في عملية تسجيل الدخول لا يكفي أن نعرف أن المستخدم يريد الوصول إلى حسابه، بل قد نحتاج إلى تحليل السيناريو:
ماذا يحدث عند إدخال البيانات الصحيحة؟
ماذا يحدث إذا كانت كلمة المرور خاطئة؟
ما الشروط المطلوبة قبل بدء العملية؟
وما النتيجة النهائية؟
وهنا تظهر قيمة الـUse Case.
لذلك يمكن تبسيط الفرق بهذه العبارة:
User Story = الحاجة والقيمة.
Use Case = التفاعل والسيناريو.
لكن الأهم: لا تتعامل معهما وكأن أحدهما بديل مطلق للآخر.
في بعض المشاريع قد تكون User Stories كافية للتخطيط والتواصل داخل الفريق، خصوصًا في بيئات Agile.
وفي سيناريوهات أكثر تعقيدًا، مثل الدفع الإلكتروني أو الحجز أو التحويل المالي، قد تحتاج إلى Use Cases لفهم المسارات الأساسية والبديلة بشكل أوضح.
بل يمكن استخدامهما معًا:
User Story → Acceptance Criteria → Use Case → Design → Development → Testing
الفكرة ليست أن تسأل:
أيهما أفضل؟
بل أن تسأل:
ما الذي أحاول فهمه الآن، وما مستوى التفاصيل الذي يحتاجه المشروع والفريق؟
هذه إحدى المهارات المهمة في تحليل الأنظمة:
لا تستخدم أداة لأنها مشهورة، استخدمها لأنها تحل مشكلة فعلية في مرحلة معينة من المشروع.
سؤال للنقاش:
لو كنت تحلل عملية تحويل أموال في تطبيق بنكي، هل ستبدأ بـ User Story أم Use Case؟ ولماذا؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UseCase #UserStory #RequirementsEngineering #SystemAnalysis #BusinessAnalysis #UML #Agile #AcceptanceCriteria #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
قريبًا… نصل إلى اللحظة التي انتظرناها طويلًا. 🎓
سنوات من الدراسة، السهر، المشاريع، الاختبارات، التحديات، والمحاولات… في يوم واحد يحمل معنى كبيرًا لنا.
حفل تخرج دفعة الظل التقني — 2026
ليست نهاية مرحلة ، بل بداية طريق جديد نحمل فيه ما تعلمناه ونحوّله إلى إنجازات حقيقية في عالم التقنية.
📅 7 / 9 / 2026
📍 قاعة قصر غمدان
موعدنا مع لحظة لن تُنسى بإذن الله.
COMING SOON…
GRADUATION 2026
#الظل_التقني #حفل_التخرج #تخرج_2026 #تقنية_المعلومات #InformationTechnology #Graduation2026 #IT #دفعة_الظل_التقني
#الدفعة_السادسة
سنوات من الدراسة، السهر، المشاريع، الاختبارات، التحديات، والمحاولات… في يوم واحد يحمل معنى كبيرًا لنا.
حفل تخرج دفعة الظل التقني — 2026
ليست نهاية مرحلة ، بل بداية طريق جديد نحمل فيه ما تعلمناه ونحوّله إلى إنجازات حقيقية في عالم التقنية.
📅 7 / 9 / 2026
📍 قاعة قصر غمدان
موعدنا مع لحظة لن تُنسى بإذن الله.
COMING SOON…
GRADUATION 2026
#الظل_التقني #حفل_التخرج #تخرج_2026 #تقنية_المعلومات #InformationTechnology #Graduation2026 #IT #دفعة_الظل_التقني
#الدفعة_السادسة
#010 — System Analysis | تحليل النظام
قبل أن تبدأ في تصميم الواجهة، اختيار قاعدة البيانات، أو كتابة أول سطر Code، هناك خطوة أهم بكثير:
هل فهمت المشكلة التي تحاول حلها فعلًا؟
هنا تبدأ أهمية System Analysis.
تحليل النظام هو عملية فهم المشكلة، المستخدمين، العمليات، البيانات، المتطلبات، والقيود قبل الانتقال إلى التصميم والتنفيذ.
بمعنى أبسط:
Problem → Understand → Analyze → Requirements → Solution
المحلل الجيد لا يبدأ بسؤال:
كيف سنبني النظام؟
بل يبدأ بأسئلة مثل:
من يستخدم النظام؟
ما المشكلة الحالية؟
كيف تتم العملية الآن؟
أين يحدث التأخير أو الخطأ؟
ما البيانات المطلوبة؟
ما القيود الموجودة؟
وما النتيجة التي يريد أصحاب المصلحة الوصول إليها؟
لأن العميل قد يقول لك:
"أريد تطبيقًا جديدًا."
لكن بعد التحليل قد تكتشف أن المشكلة الحقيقية ليست عدم وجود تطبيق، بل مثلًا:
صعوبة متابعة الطلبات، تكرار إدخال البيانات، ضعف التحكم في المخزون، أو بطء الإجراءات الحالية.
وهنا يظهر الفرق بين:
تنفيذ ما طلبه العميل حرفيًا
و
فهم المشكلة التي جعلته يطلبه أصلًا.
ومن أهم الأشياء التي نحللها:
Stakeholders — أصحاب المصلحة
من يستخدم النظام، ومن يديره، ومن يتأثر به؟
Processes — العمليات
كيف يتم العمل حاليًا؟
Data — البيانات
ما المعلومات التي يحتاجها النظام؟
Requirements — المتطلبات
ماذا يجب أن يفعل النظام؟
Constraints — القيود
ما الحدود والشروط التي يجب مراعاتها؟
ثم نحول هذا الفهم إلى نماذج ومتطلبات واضحة تساعد الفريق في التصميم والتطوير والاختبار.
مثال بسيط:
إذا كانت المشكلة:
"العميل لا يعرف حالة طلبه."
فبعد التحليل يمكن أن تتحول إلى:
Need: العميل يحتاج إلى متابعة الطلب.
ثم:
Functional Requirement:
يجب أن يسمح النظام للعميل بعرض حالة طلبه.
ثم:
User Story:
As a Customer, I want to track my order so that I know its current status.
ثم:
Use Case:
Track Order
وهكذا تتحول المشكلة من فكرة عامة إلى متطلبات يمكن تصميمها وبرمجتها واختبارها.
ولهذا فإن تحليل النظام ليس مرحلة شكلية قبل البرمجة.
بل هو الجسر بين:
المشكلة الحقيقية
و
الحل البرمجي الصحيح
كلما كان التحليل أعمق وأوضح، أصبح التصميم أبسط، والتنفيذ أدق، واحتمالية إعادة العمل والأخطاء أقل.
قاعدة مهمة:
لا تبدأ بالحل قبل أن تفهم المشكلة.
لأن بناء النظام الصحيح لا يبدأ من الكود، بل يبدأ من فهم صحيح لما يجب أن يحله هذا الكود.
سؤال للنقاش:
لو جاءك عميل وقال: "أريد تطبيقًا لمطعمي"، ما أول 3 أسئلة ستطرحها عليه قبل أن تفكر في التصميم؟
المنشور القادم:
#011 — Problem Analysis
كيف تكتشف المشكلة الحقيقية بدل أن تعالج أعراضها فقط؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #SystemAnalysis #RequirementsEngineering #SystemDesign #BusinessAnalysis #SoftwareArchitecture #Requirements #UseCases #UserStories #Stakeholders #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظام #تحليل_النظم #تطوير_البرمجيات
قبل أن تبدأ في تصميم الواجهة، اختيار قاعدة البيانات، أو كتابة أول سطر Code، هناك خطوة أهم بكثير:
هل فهمت المشكلة التي تحاول حلها فعلًا؟
هنا تبدأ أهمية System Analysis.
تحليل النظام هو عملية فهم المشكلة، المستخدمين، العمليات، البيانات، المتطلبات، والقيود قبل الانتقال إلى التصميم والتنفيذ.
بمعنى أبسط:
Problem → Understand → Analyze → Requirements → Solution
المحلل الجيد لا يبدأ بسؤال:
كيف سنبني النظام؟
بل يبدأ بأسئلة مثل:
من يستخدم النظام؟
ما المشكلة الحالية؟
كيف تتم العملية الآن؟
أين يحدث التأخير أو الخطأ؟
ما البيانات المطلوبة؟
ما القيود الموجودة؟
وما النتيجة التي يريد أصحاب المصلحة الوصول إليها؟
لأن العميل قد يقول لك:
"أريد تطبيقًا جديدًا."
لكن بعد التحليل قد تكتشف أن المشكلة الحقيقية ليست عدم وجود تطبيق، بل مثلًا:
صعوبة متابعة الطلبات، تكرار إدخال البيانات، ضعف التحكم في المخزون، أو بطء الإجراءات الحالية.
وهنا يظهر الفرق بين:
تنفيذ ما طلبه العميل حرفيًا
و
فهم المشكلة التي جعلته يطلبه أصلًا.
ومن أهم الأشياء التي نحللها:
Stakeholders — أصحاب المصلحة
من يستخدم النظام، ومن يديره، ومن يتأثر به؟
Processes — العمليات
كيف يتم العمل حاليًا؟
Data — البيانات
ما المعلومات التي يحتاجها النظام؟
Requirements — المتطلبات
ماذا يجب أن يفعل النظام؟
Constraints — القيود
ما الحدود والشروط التي يجب مراعاتها؟
ثم نحول هذا الفهم إلى نماذج ومتطلبات واضحة تساعد الفريق في التصميم والتطوير والاختبار.
مثال بسيط:
إذا كانت المشكلة:
"العميل لا يعرف حالة طلبه."
فبعد التحليل يمكن أن تتحول إلى:
Need: العميل يحتاج إلى متابعة الطلب.
ثم:
Functional Requirement:
يجب أن يسمح النظام للعميل بعرض حالة طلبه.
ثم:
User Story:
As a Customer, I want to track my order so that I know its current status.
ثم:
Use Case:
Track Order
وهكذا تتحول المشكلة من فكرة عامة إلى متطلبات يمكن تصميمها وبرمجتها واختبارها.
ولهذا فإن تحليل النظام ليس مرحلة شكلية قبل البرمجة.
بل هو الجسر بين:
المشكلة الحقيقية
و
الحل البرمجي الصحيح
كلما كان التحليل أعمق وأوضح، أصبح التصميم أبسط، والتنفيذ أدق، واحتمالية إعادة العمل والأخطاء أقل.
قاعدة مهمة:
لا تبدأ بالحل قبل أن تفهم المشكلة.
لأن بناء النظام الصحيح لا يبدأ من الكود، بل يبدأ من فهم صحيح لما يجب أن يحله هذا الكود.
سؤال للنقاش:
لو جاءك عميل وقال: "أريد تطبيقًا لمطعمي"، ما أول 3 أسئلة ستطرحها عليه قبل أن تفكر في التصميم؟
المنشور القادم:
#011 — Problem Analysis
كيف تكتشف المشكلة الحقيقية بدل أن تعالج أعراضها فقط؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #SystemAnalysis #RequirementsEngineering #SystemDesign #BusinessAnalysis #SoftwareArchitecture #Requirements #UseCases #UserStories #Stakeholders #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظام #تحليل_النظم #تطوير_البرمجيات