في هندسة البرمجيات، كتابة الكود ليست أول خطوة، وإطلاق النظام ليس آخر خطوة.
قبل أن نبدأ بالتطوير، نحتاج إلى فهم الرحلة الكاملة التي يمر بها أي نظام برمجي، وهنا يأتي مفهوم SDLC — Software Development Life Cycle أو دورة حياة تطوير البرمجيات.
SDLC تنظم عملية تطوير النظام عبر مراحل واضحة:
تحليل المتطلبات → التخطيط → التصميم → البرمجة → الاختبار → النشر → الصيانة
القيمة الحقيقية لهذه المراحل ليست في حفظ أسمائها، بل في فهم دور كل مرحلة.
فالمتطلبات الخاطئة قد تجعلنا نبني المنتج الخطأ، والتصميم الضعيف قد يجعل النظام صعب التطوير، والاختبار غير الكافي قد ينقل المشاكل إلى المستخدم، وحتى بعد النشر تستمر رحلة النظام من خلال الصيانة والتحسين وإضافة المتطلبات الجديدة.
لهذا أنظر إلى SDLC على أنها أكثر من مجرد مراحل لتطوير البرمجيات؛ إنها طريقة منظمة لتحويل مشكلة أو فكرة إلى منتج برمجي قابل للاستخدام والتطوير والاستمرار.
في هذا الكاروسيل شرحت المراحل خطوة بخطوة، مع مثال عملي لبناء متجر إلكتروني لتوضيح الصورة.
هذا هو المنشور #002 من سلسلة Software Engineering التي أشارك فيها المفاهيم الأساسية في هندسة البرمجيات بصورة مبسطة وعملية.
المنشور القادم #003: Requirements
وسنتحدث عن الفرق بين Functional Requirements و Non-Functional Requirements وكيف تؤثر المتطلبات على المشروع منذ البداية.
برأيكم: ما المرحلة التي يمكن أن يسبب إهمالها أكبر تكلفة على المشروع؟
— م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #SDLC #SoftwareDevelopment #SoftwareEngineer #BackendDevelopment #SystemDesign #Programming #SoftwareArchitecture #هندسة_البرمجيات #تطوير_البرمجيات #برمجة
قبل أن نبدأ بالتطوير، نحتاج إلى فهم الرحلة الكاملة التي يمر بها أي نظام برمجي، وهنا يأتي مفهوم SDLC — Software Development Life Cycle أو دورة حياة تطوير البرمجيات.
SDLC تنظم عملية تطوير النظام عبر مراحل واضحة:
تحليل المتطلبات → التخطيط → التصميم → البرمجة → الاختبار → النشر → الصيانة
القيمة الحقيقية لهذه المراحل ليست في حفظ أسمائها، بل في فهم دور كل مرحلة.
فالمتطلبات الخاطئة قد تجعلنا نبني المنتج الخطأ، والتصميم الضعيف قد يجعل النظام صعب التطوير، والاختبار غير الكافي قد ينقل المشاكل إلى المستخدم، وحتى بعد النشر تستمر رحلة النظام من خلال الصيانة والتحسين وإضافة المتطلبات الجديدة.
لهذا أنظر إلى SDLC على أنها أكثر من مجرد مراحل لتطوير البرمجيات؛ إنها طريقة منظمة لتحويل مشكلة أو فكرة إلى منتج برمجي قابل للاستخدام والتطوير والاستمرار.
في هذا الكاروسيل شرحت المراحل خطوة بخطوة، مع مثال عملي لبناء متجر إلكتروني لتوضيح الصورة.
هذا هو المنشور #002 من سلسلة Software Engineering التي أشارك فيها المفاهيم الأساسية في هندسة البرمجيات بصورة مبسطة وعملية.
المنشور القادم #003: Requirements
وسنتحدث عن الفرق بين Functional Requirements و Non-Functional Requirements وكيف تؤثر المتطلبات على المشروع منذ البداية.
برأيكم: ما المرحلة التي يمكن أن يسبب إهمالها أكبر تكلفة على المشروع؟
— م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #SDLC #SoftwareDevelopment #SoftwareEngineer #BackendDevelopment #SystemDesign #Programming #SoftwareArchitecture #هندسة_البرمجيات #تطوير_البرمجيات #برمجة
#003 — Requirements | المتطلبات
في هندسة البرمجيات، أحد أكبر الأخطاء هو أن تبدأ في كتابة الكود قبل أن تعرف بدقة ما الذي يجب أن تبنيه ولماذا.
قد يكون لديك فريق ممتاز، وتقنيات حديثة، وكود نظيف، لكن إذا كانت المتطلبات غير واضحة فقد ينتهي بك الأمر إلى بناء نظام ممتاز تقنيًا... لكنه لا يحل المشكلة الحقيقية.
هنا تأتي أهمية Requirements.
المتطلبات هي الجسر بين احتياج المستخدم وبين النظام الذي سنبنيه. ومن خلالها نفهم المشكلة، واحتياجات أصحاب المصلحة، والوظائف المطلوبة، والقيود التي يجب أن يعمل النظام ضمنها.
المتطلبات الواضحة تساعد الفريق على اتخاذ قرارات أفضل في التصميم والتطوير، تقلل إعادة العمل والتكاليف، وتوفر أساسًا واضحًا للاختبار والتحقق من أن المنتج النهائي يحقق الهدف المطلوب.
ولهذا قبل أن تسأل:
كيف سنبني النظام؟
اسأل أولًا:
ماذا نحتاج أن نبني؟ ولماذا؟
فالهدف في هندسة البرمجيات ليس كتابة أكبر قدر من الكود، بل بناء الحل الصحيح للمشكلة الصحيحة.
في هذا الكاروسيل شرحت مفهوم Requirements، مصادر المتطلبات، أهميتها، وما الذي يمكن أن يحدث عندما يبدأ المشروع بمتطلبات غامضة.
السؤال للنقاش:
أيهما أخطر برأيك: تنفيذ Requirement بطريقة خاطئة، أم تنفيذ Requirement لم يكن مطلوبًا من الأساس؟
المنشور القادم #004 — Functional Requirements
وسنتحدث عن كيفية تحديد ما الذي يجب أن يفعله النظام.
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #Requirements #RequirementsEngineering #SoftwareDevelopment #SoftwareEngineer #SystemAnalysis #SystemDesign #BackendDevelopment #Programming #SoftwareArchitecture #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات #برمجة
في هندسة البرمجيات، أحد أكبر الأخطاء هو أن تبدأ في كتابة الكود قبل أن تعرف بدقة ما الذي يجب أن تبنيه ولماذا.
قد يكون لديك فريق ممتاز، وتقنيات حديثة، وكود نظيف، لكن إذا كانت المتطلبات غير واضحة فقد ينتهي بك الأمر إلى بناء نظام ممتاز تقنيًا... لكنه لا يحل المشكلة الحقيقية.
هنا تأتي أهمية Requirements.
المتطلبات هي الجسر بين احتياج المستخدم وبين النظام الذي سنبنيه. ومن خلالها نفهم المشكلة، واحتياجات أصحاب المصلحة، والوظائف المطلوبة، والقيود التي يجب أن يعمل النظام ضمنها.
المتطلبات الواضحة تساعد الفريق على اتخاذ قرارات أفضل في التصميم والتطوير، تقلل إعادة العمل والتكاليف، وتوفر أساسًا واضحًا للاختبار والتحقق من أن المنتج النهائي يحقق الهدف المطلوب.
ولهذا قبل أن تسأل:
كيف سنبني النظام؟
اسأل أولًا:
ماذا نحتاج أن نبني؟ ولماذا؟
فالهدف في هندسة البرمجيات ليس كتابة أكبر قدر من الكود، بل بناء الحل الصحيح للمشكلة الصحيحة.
في هذا الكاروسيل شرحت مفهوم Requirements، مصادر المتطلبات، أهميتها، وما الذي يمكن أن يحدث عندما يبدأ المشروع بمتطلبات غامضة.
السؤال للنقاش:
أيهما أخطر برأيك: تنفيذ Requirement بطريقة خاطئة، أم تنفيذ Requirement لم يكن مطلوبًا من الأساس؟
المنشور القادم #004 — Functional Requirements
وسنتحدث عن كيفية تحديد ما الذي يجب أن يفعله النظام.
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #Requirements #RequirementsEngineering #SoftwareDevelopment #SoftwareEngineer #SystemAnalysis #SystemDesign #BackendDevelopment #Programming #SoftwareArchitecture #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات #برمجة
#004 — Functional Requirements | المتطلبات الوظيفية
عندما نبدأ تحليل أي نظام، من أهم الأسئلة التي يجب أن نجيب عنها:
ماذا يجب أن يفعل النظام؟
هنا يأتي دور Functional Requirements.
المتطلبات الوظيفية تصف الوظائف والسلوكيات التي يجب أن يقدمها النظام لتحقيق احتياجات المستخدم والعمل.
في متجر إلكتروني مثلًا، تسجيل المستخدم، البحث عن المنتجات، إضافة منتج إلى السلة، إنشاء الطلب، الدفع، تتبع الطلب وإرسال إشعار التأكيد؛ كلها أمثلة على متطلبات وظيفية.
لكن معرفة الوظيفة وحدها لا تكفي. يجب أن يكون المتطلب واضحًا ومحددًا وقابلًا للتنفيذ والاختبار.
بدلًا من كتابة:
"يجب أن يحتوي النظام على بحث جيد."
يمكن أن نكتب:
"يجب أن يسمح النظام للمستخدم بالبحث عن المنتجات باستخدام اسم المنتج أو الفئة."
كلما قل الغموض، قلت مساحة التخمين أمام المطور، وأصبح التصميم والتنفيذ والاختبار أكثر دقة.
وعند كتابة Functional Requirement حاول دائمًا الإجابة عن أربعة أسئلة:
WHO? من يستخدم الوظيفة؟
WHAT? ماذا يجب أن يفعل النظام؟
WHEN? متى تحدث الوظيفة؟
RESULT? ما النتيجة المتوقعة؟
المتطلب الوظيفي ليس مجرد جملة نضعها في وثيقة؛ بل هو جزء من الأساس الذي يتحول لاحقًا إلى Design ثم Code ثم Test ثم Feature حقيقية يستخدمها العميل.
في هندسة البرمجيات، الهدف ليس أن نكتب ما يستطيع النظام فعله فقط، بل أن نحدد بدقة ما يحتاج المستخدم أن يفعله من خلال النظام.
المنشور القادم #005 — Non-Functional Requirements
سنتحدث فيه عن سؤال مختلف:
ليس ماذا يفعل النظام، بل كيف يجب أن يؤدي ذلك؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #Requirements #RequirementsEngineering #SystemAnalysis #SoftwareDevelopment #SoftwareEngineer #BackendDevelopment #SystemDesign #BusinessAnalysis #Programming #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات
عندما نبدأ تحليل أي نظام، من أهم الأسئلة التي يجب أن نجيب عنها:
ماذا يجب أن يفعل النظام؟
هنا يأتي دور Functional Requirements.
المتطلبات الوظيفية تصف الوظائف والسلوكيات التي يجب أن يقدمها النظام لتحقيق احتياجات المستخدم والعمل.
في متجر إلكتروني مثلًا، تسجيل المستخدم، البحث عن المنتجات، إضافة منتج إلى السلة، إنشاء الطلب، الدفع، تتبع الطلب وإرسال إشعار التأكيد؛ كلها أمثلة على متطلبات وظيفية.
لكن معرفة الوظيفة وحدها لا تكفي. يجب أن يكون المتطلب واضحًا ومحددًا وقابلًا للتنفيذ والاختبار.
بدلًا من كتابة:
"يجب أن يحتوي النظام على بحث جيد."
يمكن أن نكتب:
"يجب أن يسمح النظام للمستخدم بالبحث عن المنتجات باستخدام اسم المنتج أو الفئة."
كلما قل الغموض، قلت مساحة التخمين أمام المطور، وأصبح التصميم والتنفيذ والاختبار أكثر دقة.
وعند كتابة Functional Requirement حاول دائمًا الإجابة عن أربعة أسئلة:
WHO? من يستخدم الوظيفة؟
WHAT? ماذا يجب أن يفعل النظام؟
WHEN? متى تحدث الوظيفة؟
RESULT? ما النتيجة المتوقعة؟
المتطلب الوظيفي ليس مجرد جملة نضعها في وثيقة؛ بل هو جزء من الأساس الذي يتحول لاحقًا إلى Design ثم Code ثم Test ثم Feature حقيقية يستخدمها العميل.
في هندسة البرمجيات، الهدف ليس أن نكتب ما يستطيع النظام فعله فقط، بل أن نحدد بدقة ما يحتاج المستخدم أن يفعله من خلال النظام.
المنشور القادم #005 — Non-Functional Requirements
سنتحدث فيه عن سؤال مختلف:
ليس ماذا يفعل النظام، بل كيف يجب أن يؤدي ذلك؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #Requirements #RequirementsEngineering #SystemAnalysis #SoftwareDevelopment #SoftwareEngineer #BackendDevelopment #SystemDesign #BusinessAnalysis #Programming #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات
وهنا تأتي أهمية Non-Functional Requirements — المتطلبات غير الوظيفية.
فالنظام لا يكفي أن "يعمل".
يجب أن يعمل بالجودة والأمان والأداء المناسبين لبيئة العمل.
أخطر جملة في المشروع: "هذه إضافة بسيطة"
في منتصف المشروع قد يقول العميل:
"باقي شيء بسيط جدًا…"
لكن هذه الإضافة البسيطة قد تحتاج تعديل قاعدة البيانات، وتغيير Business Logic، وإضافة صلاحيات، وتعديل API، وتحديث الواجهات والتقارير وإعادة الاختبار.
ولهذا يجب أن تكون المتطلبات موثقة قدر الإمكان، وأن يكون هناك اتفاق واضح حول Scope — نطاق المشروع.
لأن المتطلبات غير الواضحة تؤدي غالبًا إلى تعديلات مستمرة، والتعديلات تؤثر في الوقت والتكلفة وجودة المنتج.
عزيزي البش مهندس
في سوق العمل، قيمة مهندس البرمجيات لا تقاس فقط بمدى سرعته في كتابة الكود.
أحيانًا يكون أفضل قرار هندسي تتخذه هو ألا تبدأ البرمجة بعد.
استمع للعميل.
افهم المشكلة.
حدد أصحاب المصلحة.
ادرس طريقة العمل الحالية.
استخرج المتطلبات.
حلل الحالات الطبيعية والاستثنائية.
حدد Functional وNon-Functional Requirements.
تحقق من المتطلبات مع أصحاب المصلحة.
ثم ابدأ التصميم والتنفيذ.
لأن الكود الممتاز المبني على متطلبات خاطئة سيعطيك في النهاية نظامًا ممتازًا يحل المشكلة الخطأ.
وهنا تظهر واحدة من أهم مهارات مهندس البرمجيات في سوق العمل:
لا تبرمج ما يقوله العميل فقط… افهم ما يحتاجه فعلًا.
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #Requirements #RequirementsEngineering #SystemAnalysis #SoftwareDevelopment #SoftwareEngineer #BackendDevelopment #SystemDesign #BusinessAnalysis #Programming #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات
فالنظام لا يكفي أن "يعمل".
يجب أن يعمل بالجودة والأمان والأداء المناسبين لبيئة العمل.
أخطر جملة في المشروع: "هذه إضافة بسيطة"
في منتصف المشروع قد يقول العميل:
"باقي شيء بسيط جدًا…"
لكن هذه الإضافة البسيطة قد تحتاج تعديل قاعدة البيانات، وتغيير Business Logic، وإضافة صلاحيات، وتعديل API، وتحديث الواجهات والتقارير وإعادة الاختبار.
ولهذا يجب أن تكون المتطلبات موثقة قدر الإمكان، وأن يكون هناك اتفاق واضح حول Scope — نطاق المشروع.
لأن المتطلبات غير الواضحة تؤدي غالبًا إلى تعديلات مستمرة، والتعديلات تؤثر في الوقت والتكلفة وجودة المنتج.
عزيزي البش مهندس
في سوق العمل، قيمة مهندس البرمجيات لا تقاس فقط بمدى سرعته في كتابة الكود.
أحيانًا يكون أفضل قرار هندسي تتخذه هو ألا تبدأ البرمجة بعد.
استمع للعميل.
افهم المشكلة.
حدد أصحاب المصلحة.
ادرس طريقة العمل الحالية.
استخرج المتطلبات.
حلل الحالات الطبيعية والاستثنائية.
حدد Functional وNon-Functional Requirements.
تحقق من المتطلبات مع أصحاب المصلحة.
ثم ابدأ التصميم والتنفيذ.
لأن الكود الممتاز المبني على متطلبات خاطئة سيعطيك في النهاية نظامًا ممتازًا يحل المشكلة الخطأ.
وهنا تظهر واحدة من أهم مهارات مهندس البرمجيات في سوق العمل:
لا تبرمج ما يقوله العميل فقط… افهم ما يحتاجه فعلًا.
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #Requirements #RequirementsEngineering #SystemAnalysis #SoftwareDevelopment #SoftwareEngineer #BackendDevelopment #SystemDesign #BusinessAnalysis #Programming #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات
#006 — Functional vs Non-Functional Requirements
في تحليل المتطلبات، من أكثر الأمور التي تسبب الالتباس للمبتدئين الفرق بين Functional Requirements و Non-Functional Requirements.
والتمييز بينهما يصبح أسهل عندما نطرح سؤالين:
ماذا يجب أن يفعل النظام؟
هذا يقودنا غالبًا إلى Functional Requirements.
كيف يجب أن يعمل النظام، وبأي مستوى من الجودة؟
هذا يقودنا إلى Non-Functional Requirements.
مثال بسيط:
إذا قلنا:
"يجب أن يسمح النظام للمستخدم بتسجيل الدخول باستخدام البريد الإلكتروني وكلمة المرور."
فنحن نصف وظيفة يقدمها النظام، وبالتالي هذا Functional Requirement.
أما إذا قلنا:
"يجب أن تكتمل عملية تسجيل الدخول خلال ثانيتين أو أقل تحت الحمل المحدد."
فنحن نحدد مستوى أداء لهذه الوظيفة، وبالتالي هذا Non-Functional Requirement.
وفي متجر إلكتروني مثلًا:
البحث عن المنتجات، إضافة منتج للسلة، إنشاء الطلب، الدفع وتتبع الطلب هي متطلبات وظيفية.
أما سرعة الاستجابة، حماية البيانات، التوافر، الاعتمادية والقدرة على التعامل مع آلاف المستخدمين المتزامنين فهي متطلبات غير وظيفية.
المشكلة تبدأ عندما نهتم بالوظائف فقط.
قد تعمل جميع Features المطلوبة، لكن إذا كان النظام بطيئًا، غير مستقر، غير آمن أو يتوقف تحت الضغط، فلن تكون تجربة المستخدم ناجحة.
لهذا يمكن اختصار الفكرة في معادلة بسيطة:
Correct Functions + Defined Quality = Better Software
هندسة البرمجيات لا تهتم فقط ببناء نظام يعمل، بل ببناء نظام يعمل بالجودة المطلوبة وفي الظروف التي صُمم من أجلها.
والآن اختبار سريع:
في تطبيق بنكي:
"يجب تسجيل خروج المستخدم تلقائيًا بعد 10 دقائق من عدم النشاط."
هل تصنف هذا المتطلب Functional أم Non-Functional؟ ولماذا؟
اكتب إجابتك في التعليقات.
المنشور القادم #007 — Use Cases
كيف نصف تفاعل المستخدم مع النظام بطريقة واضحة ومنظمة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #NonFunctionalRequirements #RequirementsEngineering #Requirements #SystemAnalysis #BusinessAnalysis #SoftwareArchitecture #SystemDesign #SoftwareDevelopment #SoftwareQuality #BackendDevelopment #SoftwareEngineer #UseCases #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
في تحليل المتطلبات، من أكثر الأمور التي تسبب الالتباس للمبتدئين الفرق بين Functional Requirements و Non-Functional Requirements.
والتمييز بينهما يصبح أسهل عندما نطرح سؤالين:
ماذا يجب أن يفعل النظام؟
هذا يقودنا غالبًا إلى Functional Requirements.
كيف يجب أن يعمل النظام، وبأي مستوى من الجودة؟
هذا يقودنا إلى Non-Functional Requirements.
مثال بسيط:
إذا قلنا:
"يجب أن يسمح النظام للمستخدم بتسجيل الدخول باستخدام البريد الإلكتروني وكلمة المرور."
فنحن نصف وظيفة يقدمها النظام، وبالتالي هذا Functional Requirement.
أما إذا قلنا:
"يجب أن تكتمل عملية تسجيل الدخول خلال ثانيتين أو أقل تحت الحمل المحدد."
فنحن نحدد مستوى أداء لهذه الوظيفة، وبالتالي هذا Non-Functional Requirement.
وفي متجر إلكتروني مثلًا:
البحث عن المنتجات، إضافة منتج للسلة، إنشاء الطلب، الدفع وتتبع الطلب هي متطلبات وظيفية.
أما سرعة الاستجابة، حماية البيانات، التوافر، الاعتمادية والقدرة على التعامل مع آلاف المستخدمين المتزامنين فهي متطلبات غير وظيفية.
المشكلة تبدأ عندما نهتم بالوظائف فقط.
قد تعمل جميع Features المطلوبة، لكن إذا كان النظام بطيئًا، غير مستقر، غير آمن أو يتوقف تحت الضغط، فلن تكون تجربة المستخدم ناجحة.
لهذا يمكن اختصار الفكرة في معادلة بسيطة:
Correct Functions + Defined Quality = Better Software
هندسة البرمجيات لا تهتم فقط ببناء نظام يعمل، بل ببناء نظام يعمل بالجودة المطلوبة وفي الظروف التي صُمم من أجلها.
والآن اختبار سريع:
في تطبيق بنكي:
"يجب تسجيل خروج المستخدم تلقائيًا بعد 10 دقائق من عدم النشاط."
هل تصنف هذا المتطلب Functional أم Non-Functional؟ ولماذا؟
اكتب إجابتك في التعليقات.
المنشور القادم #007 — Use Cases
كيف نصف تفاعل المستخدم مع النظام بطريقة واضحة ومنظمة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #NonFunctionalRequirements #RequirementsEngineering #Requirements #SystemAnalysis #BusinessAnalysis #SoftwareArchitecture #SystemDesign #SoftwareDevelopment #SoftwareQuality #BackendDevelopment #SoftwareEngineer #UseCases #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
#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 #هندسة_البرمجيات #تحليل_النظم #حالات_الاستخدام #تطوير_البرمجيات
❤2
#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 #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات