#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 #هندسة_البرمجيات #تحليل_النظم #قصص_المستخدم #تطوير_البرمجيات
#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 #دفعة_الظل_التقني
#الدفعة_السادسة