#005 — Non-Functional Requirements | المتطلبات غير الوظيفية

في هندسة البرمجيات، أن يعمل النظام لا يعني بالضرورة أنه نظام جيد.

قد تنجح عملية تسجيل الدخول، لكن المستخدم ينتظر 15 ثانية.
قد يعمل الدفع، لكن البيانات غير محمية بالشكل المطلوب.
قد يحتوي المتجر على جميع الوظائف، لكنه يتوقف بمجرد زيادة عدد المستخدمين.

هنا تظهر أهمية Non-Functional Requirements.

المتطلبات غير الوظيفية لا تركز على ماذا يفعل النظام؟ بقدر ما تحدد كيف يجب أن يعمل النظام، وبأي مستوى من الجودة؟

فهي تحدد خصائص مهمة مثل:

Performance — الأداء وسرعة الاستجابة
Security — الأمان وحماية البيانات
Reliability — الاعتمادية واستقرار النظام
Availability — التوافر واستمرارية الخدمة
Scalability — قابلية التوسع مع نمو المستخدمين
Usability — سهولة الاستخدام
Maintainability — سهولة الصيانة والتطوير

لكن هناك نقطة مهمة: لا يكفي أن نقول:

"يجب أن يكون النظام سريعًا."

الأفضل أن نحولها إلى متطلب واضح وقابل للقياس، مثل:

"يجب أن تستجيب 95% من طلبات الـ API خلال أقل من 500ms تحت الحمل المحدد."

لأن كلمات مثل سريع، آمن، مستقر، قابل للتوسع تظل أوصافًا عامة ما لم نحدد لها معايير يمكن قياسها واختبارها.

وهنا يظهر الفرق الأساسي:

Functional Requirements تحدد الوظائف التي يقدمها النظام.
Non-Functional Requirements تحدد مستوى الجودة والقيود التي تعمل ضمنها هذه الوظائف.

لذلك عند تصميم أي نظام، لا تسأل فقط:

هل النظام يعمل؟

اسأل أيضًا:

هل يعمل بالسرعة، والأمان، والاستقرار، والجودة التي يحتاجها المستخدم؟

فالجودة ليست شيئًا نضيفه بعد الانتهاء من المشروع، بل يجب أن تكون جزءًا من المتطلبات والتصميم منذ البداية.

سؤال للنقاش:
متجر إلكتروني يحتوي على جميع الوظائف المطلوبة، لكنه بطيء جدًا ويتوقف عند زيادة المستخدمين؛ هل تعتبره نظامًا ناجحًا؟

المنشور القادم #006 — Functional vs Non-Functional Requirements
كيف تفرق بينهما بسرعة عند تحليل أي نظام؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #NonFunctionalRequirements #RequirementsEngineering #Requirements #SystemAnalysis #SystemDesign #SoftwareArchitecture #SoftwareQuality #Performance #Security #Scalability #Reliability #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات

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

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

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

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

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

#011 — Understanding the Problem | فهم المشكلة

في هندسة البرمجيات، أحد أكبر الأخطاء هو أن نبدأ في تصميم الحل قبل أن نتأكد أننا فهمنا المشكلة الحقيقية.
قد يقول العميل:
"الطلبات تتأخر، نحتاج نظامًا جديدًا."
لكن هل النظام هو المشكلة فعلًا؟ ربما التأخير سببه طريقة توزيع الطلبات، أو تعدد قنوات الاستقبال، أو ضعف التواصل بين الأقسام، أو عملية يدوية غير منظمة.
لهذا يجب أن نفرّق بين:

Symptom — العرض الظاهر
و
Root Cause — السبب الجذري

فالعرض يخبرنا أن هناك مشكلة، لكنه لا يخبرنا دائمًا لماذا تحدث.
إحدى الطرق البسيطة للوصول إلى السبب الحقيقي هي 5 Whys؛ لا تتوقف عند أول إجابة، بل استمر في السؤال "لماذا؟" حتى تصل إلى السبب الذي إذا عالجته، تقل احتمالية تكرار المشكلة.
لكن السؤال وحده لا يكفي. التحليل الجيد يعتمد على Evidence وليس Assumptions.
مقابلات المستخدمين، البيانات والتحليلات، Logs، تذاكر الدعم، الملاحظة المباشرة، والاستبيانات قد تغيّر فهمك للمشكلة بالكامل.

مثال:

العميل يقول:
"تطبيق التوصيل بطيء، نحتاج Server أقوى."
لكن بعد التحليل نكتشف أن السيرفر يعمل بشكل طبيعي، بينما معظم التأخير يحدث أثناء تعيين السائق للطلب.
هنا لم تكن المشكلة في قوة السيرفر أصلًا، بل في آلية توزيع الطلبات.
وهذا يوضح التسلسل الصحيح:

Symptom → Investigation → Root Cause → Need → Requirement → Solution

وليس:

Problem → أول حل يخطر في بالك
ومن المهم أيضًا فهم السياق: الأشخاص، العمليات، البيانات، التقنية الحالية، القواعد والقيود، وبيئة العمل. لأن المشكلة نفسها قد تحتاج حلًا مختلفًا من مؤسسة إلى أخرى.
بعد ذلك نستطيع صياغة Problem Statement واضحة تحدد من يعاني من المشكلة، وما المشكلة، ومتى أو أين تحدث، وما أثرها.

القاعدة التي أعود إليها دائمًا:

Understand First. Solve Second.
افهم أولًا... ثم حل.

مهندس البرمجيات القوي لا يتميز فقط بقدرته على بناء حلول ممتازة، بل بقدرته على التأكد من أنه يبني الحل الصحيح للمشكلة الصحيحة.

سؤال للنقاش:
لو قال لك عميل:
"موقعي بطيء، نحتاج Server أقوى."
ما أول شيء ستفعله قبل الموافقة على هذا الحل؟
المنشور القادم:
#012 — Stakeholders
من الأشخاص والجهات الذين يجب أن نستمع إليهم قبل تحديد متطلبات النظام؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #UnderstandingTheProblem #ProblemAnalysis #RootCauseAnalysis #5Whys #SystemAnalysis #RequirementsEngineering #ProblemSolving #BusinessAnalysis #SoftwareDevelopment #SystemDesign #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #تحليل_المشكلات #تطوير_البرمجيات

#012 — Stakeholders | أصحاب المصلحة

عندما تبدأ تحليل أي نظام، لا يكفي أن تسأل:
ما الذي يجب أن يفعله النظام؟
السؤال الأهم أولًا هو:
من الأشخاص والجهات التي يجب أن أستمع إليها؟
هنا يأتي مفهوم Stakeholders — أصحاب المصلحة.
الـStakeholder هو أي شخص أو جهة لها علاقة بالنظام؛ قد تستخدمه، تديره، تعتمد على مخرجاته، توفر له بيانات، تؤثر في قراراته، أو تتأثر بنتائجه.
ولهذا فليس كل Stakeholder مستخدمًا للنظام، وليس كل مستخدم صاحب القرار.

في متجر إلكتروني مثلًا قد نجد:

العميل يريد تجربة سهلة وسريعة.
الموظف يريد تقليل الخطوات اليدوية والأخطاء.
المدير يريد تقارير تساعده على اتخاذ القرار.
صاحب العمل يهتم بالقيمة والتكلفة والعائد.
فريق التقنية يهتم بالأمان والصيانة والتوسع.
والأنظمة الخارجية تحتاج تكاملًا واضحًا ودقيقًا.
نفس النظام، لكن كل Stakeholder يراه من زاوية مختلفة.
وهنا تظهر إحدى أهم مهارات محلل النظم:
لا تسأل الجميع نفس الأسئلة.
مع العميل تسأل عن احتياجاته والمشاكل التي يواجهها.
مع الموظف تفهم سير العمل اليومي.
مع الإدارة تبحث عن المعلومات ومؤشرات الأداء.
مع صاحب العمل تفهم الهدف التجاري.
مع فريق التقنية تحدد القيود التقنية والأمنية والتكاملات.

ثم تأتي خطوة أخرى مهمة: Stakeholder Analysis.
ليس جميع أصحاب المصلحة بنفس مستوى التأثير والاهتمام، ولذلك يمكن استخدام Power–Interest Matrix لتحديد طريقة التعامل معهم:
High Power + High Interest → إدارة ومشاركة وثيقة.
High Power + Low Interest → الحفاظ على رضاهم.
Low Power + High Interest → إبقاؤهم على اطلاع.
Low Power + Low Interest → المتابعة بالقدر المناسب.

وقد تبدأ المشكلة عندما تتعارض احتياجاتهم.

العميل يريد أقل عدد من خطوات تسجيل الدخول.
فريق الأمن يريد تحققًا أقوى.
الإدارة تريد تكلفة أقل.
الفريق التقني يريد نظامًا قابلًا للصيانة والتوسع.
دور المحلل هنا ليس قبول كل طلب كما هو، بل:

Understand → Compare → Prioritize → Negotiate → Balance

أي: يفهم، يقارن، يرتب الأولويات، يتفاوض، ثم يصل إلى توازن منطقي يخدم المشروع.
وأحد أخطر أخطاء التحليل هو بناء النظام بناءً على رأي شخص واحد، بينما بقية أصحاب المصلحة لم يتم الاستماع إليهم.
لذلك يمكن اختصار الفكرة بهذه المعادلة:
Right Stakeholders → Better Requirements → Better System

كلما فهمت أصحاب المصلحة بشكل أفضل، أصبحت متطلباتك أكثر واقعية، وقرارات التصميم أدق، وفرصة نجاح النظام أكبر.
سؤال للنقاش:
لو كنت ستحلل تطبيق توصيل طعام، من أهم 5 Stakeholders ستبدأ معهم قبل كتابة المتطلبات؟

المنشور القادم:

#013 — Process Modeling
كيف نفهم ونمثل خطوات العمل داخل النظام؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #Stakeholders #StakeholderAnalysis #RequirementsEngineering #SystemAnalysis #BusinessAnalysis #PowerInterestMatrix #Requirements #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #ProcessModeling #هندسة_البرمجيات #تحليل_النظم #أصحاب_المصلحة #تطوير_البرمجيات

#013 — Process Modeling | نمذجة العمليات

قبل أن تفكر في أتمتة أي عملية داخل النظام، اسأل أولًا:
هل أفهم كيف تتم هذه العملية فعليًا؟
هنا تأتي أهمية Process Modeling.

نمذجة العمليات هي تحويل خطوات العمل الحقيقية إلى نموذج بصري واضح يوضح:

من يبدأ العملية؟
من ينفذ كل خطوة؟
ما القرارات الموجودة؟
ما البيانات المستخدمة؟
أين تحدث الأخطاء؟
ومتى تنتهي العملية؟

بمعنى أبسط:

Input → Process → Decision → Output

لكن الهدف ليس رسم Flowchart جميل فقط.
الهدف الحقيقي هو أن نرى العملية بوضوح حتى نستطيع تحليلها وتحسينها.

ولهذا نبدأ عادةً بـ:

AS-IS Process

أي: كيف تتم العملية الآن في الواقع؟
وليس كيف نتمنى أن تكون.
لأنك عندما ترسم الواقع قد تكتشف:

تأخيرًا غير ضروري.
إدخال بيانات متكررًا.
اعتمادًا زائدًا على التواصل اليدوي.
خطوات لا تضيف قيمة.
نقاط فشل لم تكن واضحة.
وصعوبة في معرفة المسؤول عن كل خطوة.

بعد ذلك نبدأ التحليل:

أين يحدث التأخير؟
ما الذي يمكن الاستغناء عنه؟
ما الذي يمكن أتمتته؟
أين تتكرر البيانات؟
ما القرارات التي تحتاج إلى توضيح؟

ثم ننتقل إلى:

TO-BE Process

أي: كيف يجب أن تصبح العملية بعد التحسين؟
وهنا توجد قاعدة مهمة جدًا:
لا تؤتمت عملية سيئة كما هي.
إذا كانت العملية مليئة بالفوضى، فإن تحويلها إلى Software قد يعني فقط:

فوضى أسرع.
الأفضل هو:

AS-IS → Analyze → Improve → TO-BE → Automate

ومن العناصر المهمة التي نبحث عنها داخل أي Process:

Trigger — ما الذي يبدأ العملية؟
Actors — من يشارك فيها؟
Activities — ما الخطوات التي تتم؟
Decisions — أين تتفرع المسارات؟
Data — ما البيانات المطلوبة؟
Outputs — ما الناتج؟
Exceptions — ماذا يحدث عند الفشل؟
End State — متى تعتبر العملية مكتملة؟

ولدينا أكثر من طريقة لتمثيل العمليات، مثل:

Flowchart للتدفقات البسيطة.
Activity Diagram للأنشطة والتفرعات.
BPMN لنمذجة عمليات الأعمال بتفصيل أكبر.
Swimlanes لإظهار مسؤولية كل Actor أو قسم.

لكن لا تبحث دائمًا عن الأداة الأكثر تعقيدًا.

ابحث عن الأداة التي تجعل العملية أوضح للفريق وأصحاب المصلحة.

يمكن اختصار الفكرة في هذه المعادلة:

Clear Process + Clear Requirements = Better System

المهندس الجيد لا يبدأ بالأتمتة مباشرة، بل يفهم العملية، يبسطها، يحسنها، ثم يحولها إلى نظام.

سؤال للنقاش:

لديك متجر يستقبل الطلبات من WhatsApp والهاتف والموقع، وكل طلب يُسجل يدويًا.
ما أول مشكلة ستبحث عنها في الـ AS-IS Process؟

المنشور القادم:

#014 — Risk Analysis
كيف تكتشف المخاطر قبل أن تتحول إلى مشاكل حقيقية؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #ProcessModeling #BusinessProcess #SystemAnalysis #RequirementsEngineering #Flowchart #ActivityDiagram #BPMN #Swimlanes #BusinessAnalysis #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_النظم #نمذجة_العمليات #تطوير_البرمجيات

#014 — Risk Analysis | تحليل المخاطر

في المشاريع البرمجية، ليست المشكلة فقط فيما حدث بالفعل، بل أيضًا فيما قد يحدث لاحقًا.
وهنا يأتي دور Risk Analysis.
الخطر أو Risk هو حدث غير مؤكد قد يقع مستقبلًا ويؤثر على المشروع أو النظام، بينما الـ Issue هي مشكلة حدثت بالفعل وتحتاج إلى معالجة.

بمعنى أبسط:

Risk = قد يحدث
Issue = حدث بالفعل

لذلك لا تنتظر أن يتحول الخطر إلى مشكلة حتى تبدأ التعامل معه.
عند تحليل أي Risk، نركز على عاملين أساسيين:

Probability — ما احتمال حدوثه؟
Impact — إذا حدث، ما حجم تأثيره؟

ومن هنا تأتي المعادلة:

Risk Level = Probability × Impact

فليس كل خطر يستحق نفس مستوى الاهتمام.
خطر احتماله منخفض وتأثيره بسيط ليس مثل خطر احتماله مرتفع وتأثيره كارثي.
ولهذا نستخدم Risk Matrix لترتيب الأولويات وتحديد ما الذي يحتاج تدخلًا عاجلًا، وما الذي يحتاج خطة، وما الذي تكفي متابعته.
والمخاطر لا تظهر فقط في الكود.

قد تكون:
Technical Risks — مخاطر تقنية
Security Risks — مخاطر أمنية
Schedule Risks — مخاطر زمنية
Cost Risks — مخاطر تكلفة
Operational Risks — مخاطر تشغيلية
Business / External Risks — مخاطر أعمال أو جهات خارجية

وأحد أفضل الأسئلة لاكتشاف المخاطر هو:

What if? — ماذا لو؟
ماذا لو تعطلت بوابة الدفع؟
ماذا لو فقدنا البيانات؟
ماذا لو تأخر المشروع؟
ماذا لو تغيرت المتطلبات؟
ماذا لو لم يتحمل النظام عدد المستخدمين؟
ماذا لو توقفت خدمة خارجية يعتمد عليها النظام؟

هذه الأسئلة لا تعني التشاؤم، بل تعني أنك تحاول اكتشاف نقاط الضعف قبل أن تفاجئك.
بعد تحديد المخاطر، لدينا أربع استراتيجيات أساسية للتعامل معها:

Avoid — تجنب الخطر.
Mitigate — قلل احتماله أو تأثيره.
Transfer — انقل جزءًا من مسؤوليته إلى طرف آخر.
Accept — اقبله مع الاستعداد للتعامل معه إذا حدث.

مثال بسيط:

إذا كان لدينا نظام دفع إلكتروني، فقد يكون أحد المخاطر هو:
توقف Payment Gateway.
وهنا قد تكون الاستجابة:

Retry Mechanism
Alternative Provider
User Notification

وقد يكون خطر آخر:
Duplicate Payment

فنحتاج مثلًا إلى:
Idempotency
Transaction Validation
Unique Order ID

وهنا نلاحظ شيئًا مهمًا:
التفكير في المخاطر قبل البرمجة قد يغيّر تصميم النظام نفسه.
لذلك تحليل المخاطر ليس مستندًا نكتبه وننساه.
بل هو عملية مستمرة:

Identify → Analyze → Prioritize → Respond → Monitor

والهدف ليس منع كل مشكلة في العالم.
الهدف هو ألا تصل المشكلة إليك وأنت تقول:
"لم نفكر في هذا الاحتمال."
القاعدة التي أعود إليها دائمًا:

Early Risk Detection → Better Decisions → Safer Project

وسؤال للنقاش:

لديك تطبيق بنكي يعتمد على خدمة خارجية لإرسال OTP.
إذا توقفت هذه الخدمة لمدة ساعتين، ما المخاطر التي ستحدث؟ وما خطتك للتعامل معها؟
المنشور القادم:

#015 — Requirements Prioritization
عندما تكون كل المتطلبات مهمة... كيف نحدد ماذا نبني أولًا؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #RiskAnalysis #RiskManagement #RiskMatrix #SystemAnalysis #RequirementsEngineering #SoftwareArchitecture #CyberSecurity #ProjectManagement #BusinessAnalysis #SystemDesign #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تحليل_المخاطر #إدارة_المخاطر #تطوير_البرمجيات

#015 — Software Design | تصميم البرمجيات

بعد أن نفهم المشكلة، نجمع المتطلبات، نحلل العمليات، ونحدد المخاطر… يأتي سؤال مهم جدًا:
كيف سنحوّل كل هذا الفهم إلى نظام يمكن بناؤه فعليًا؟
هنا تبدأ مرحلة Software Design — تصميم البرمجيات.
التحليل يخبرنا:
WHAT? — ماذا يجب أن يفعل النظام؟
أما التصميم فيجيب:
HOW? — كيف سنبني النظام ليحقق ذلك؟
ولهذا فالتسلسل الطبيعي ليس:
Requirements → Code

بل:
Requirements → Design → Code
في مرحلة التصميم نبدأ بتحديد مكونات النظام، مسؤولية كل مكوّن، طريقة انتقال البيانات، كيفية التواصل بين الأجزاء، نقاط اتخاذ القرار، والقيود التقنية والأمنية والأدائية التي يجب مراعاتها.
وهنا يظهر مفهومان مهمان:

HLD — High-Level Design ينظر إلى الصورة الكبيرة: Architecture، Services، Database، External Systems، وكيف تتواصل المكونات.

بينما LLD — Low-Level Design يدخل إلى التفاصيل: Classes، Methods، Interfaces، Data Structures، Validation، وError Handling.

لكن التصميم الجيد لا يعني إضافة أكبر عدد ممكن من الطبقات والأنماط والمكونات.
بل يعني أن تعطي كل جزء مسؤولية واضحة.
فبدل أن يكون لدينا Component واحد مسؤول عن Login وOrders وPayments وNotifications وكل شيء آخر، نفصل المسؤوليات بطريقة تجعل النظام أوضح وأسهل في التغيير والاختبار.
وهنا تظهر قاعدة مهمة:

High Cohesion + Low Coupling

أي أن الأشياء المرتبطة منطقيًا تبقى معًا، وفي الوقت نفسه نقلل الاعتماد غير الضروري بين المكونات.

مثال:
لدينا Requirement تقول:
"يجب أن يستطيع العميل إنشاء طلب ودفع قيمته إلكترونيًا."
قد تتحول في التصميم إلى:

Client App → Order Controller → Order Service → Payment Service → Payment Gateway → Database → Notification Service

متطلب واحد فقط، لكنه يحتاج عدة مكونات تتعاون لتحقيق الهدف.
لكن السؤال الأهم:
كيف أعرف أن تصميمي جيد؟

التصميم الجيد عادةً يكون قابلًا للصيانة Maintainable، وقابلًا للتوسع Scalable، وقابلًا للاختبار Testable، وآمنًا Secure، وفعّالًا Performant، وبسيطًا بالقدر المناسب Simple.
لأن التصميم الجيد لا يحل مشكلة اليوم فقط؛ بل يجعل تغيير النظام غدًا أسهل وأقل تكلفة.

وفي المقابل، هناك أخطاء تصميمية شائعة يجب الحذر منها مثل: Overengineering، Tight Coupling، God Class، Premature Optimization، Ignoring Failure Cases، وDesigning Without Requirements.

لذلك:
Good Design ≠ More Complexity
بل:
Good Design = Right Complexity

لا تجعل الكود هو المكان الذي تكتشف فيه تصميم النظام للمرة الأولى.
Think → Design → Then Code
ويمكن تلخيص الرحلة هكذا:
Clear Requirements + Good Design = Cleaner Code

سؤال للنقاش:
لو كنت تصمم متجرًا إلكترونيًا، هل ستضع Orders وPayments وNotifications داخل Service واحدة، أم ستفصل مسؤولياتها؟ ولماذا؟

المنشور القادم:

#016 — Software Architecture
ما الفرق بين التصميم والمعمارية؟ وكيف نحدد الشكل العام للنظام؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #SoftwareDesign #SystemDesign #HighLevelDesign #LowLevelDesign #HLD #LLD #SeparationOfConcerns #CleanArchitecture #SoftwareArchitecture #SystemAnalysis #RequirementsEngineering #BackendDevelopment #SoftwareDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_البرمجيات #معمارية_البرمجيات #تطوير_البرمجيات

#016 — Software Architecture | معمارية البرمجيات

قبل أن تبدأ في كتابة التفاصيل الصغيرة داخل النظام، هناك سؤال أهم:
كيف سيبدو النظام كاملًا من الأعلى؟
هنا تأتي Software Architecture — معمارية البرمجيات.
المعمارية لا تهتم فقط بالـClasses أو Methods، بل تحدد الصورة الكبرى للنظام:
كيف نقسمه إلى مكونات؟
كيف تتواصل هذه المكونات؟
أين تُخزن البيانات؟
كيف سنتعامل مع الخدمات الخارجية؟
وكيف نجعل النظام قادرًا على التوسع، وآمنًا، ومستقرًا؟

ببساطة:
Architecture = Big Picture
Design = Details

فمثلًا:
Client → API Gateway → Services → Database
هذا قرار معماري.
أما تحديد:
OrderService
createOrder()
cancelOrder()
getOrder()

فهذه تفاصيل أقرب إلى Software Design.
لكن المعمارية لا تعتمد فقط على الوظائف التي يقدمها النظام.
قد تقول المتطلبات
يجب أن يستطيع المستخدم إنشاء طلب.
لكن ماذا لو كان النظام سيخدم مئات الآلاف من المستخدمين؟
ماذا لو تعطل Server؟
ماذا لو توقفت Payment Gateway؟
ماذا لو كان فقدان عملية دفع واحدة غير مقبول؟
هنا تدخل Quality Attributes:

Scalability — قابلية التوسع
Availability — التوفر
Performance — الأداء
Security — الأمان
Reliability — الموثوقية
Maintainability — قابلية الصيانة
وهذه المتطلبات قد تغيّر Architecture النظام بالكامل.
ومن أكثر القرارات التي يواجهها المطورون:
Monolith أم Microservices؟

لا توجد إجابة واحدة تناسب الجميع.
قد يكون Monolith هو الخيار الأفضل لمشروع صغير أو فريق محدود لأنه أبسط في التطوير والنشر والتشغيل.
بينما قد تكون Microservices مناسبة عندما يكبر النظام، وتحتاج الخدمات إلى التوسع والنشر والعمل باستقلالية.
لكن تذكّر:

Microservices
ليست دائمًا أفضل.
لأنها تضيف تحديات في:
التواصل بين الخدمات، إدارة البيانات الموزعة، المراقبة، الاختبارات، النشر، والتعامل مع الأعطال.
لذلك لا تختَر Architecture لأنها "رائجة" او شائعة.
اخترها لأنها تحل مشكلة حقيقية في مشروعك
المعادلة الأهم:
Requirements + Constraints + Trade-offs → Architecture
ولهذا:
Good Architecture ≠ More Services
بل:
Good Architecture =
Right Decisions for the Context
المهندس الجيد لا يبحث عن أعقد Architecture، بل عن أبسط Architecture تستطيع تحقيق متطلبات النظام اليوم، وتسمح له بالتطور غدًا دون أن تتحول إلى عبء على الفريق.
Think Big → Decide Carefully → Design Clearly → Then Code

سؤال للنقاش:
لو كنت ستبدأ متجرًا إلكترونيًا جديدًا مع فريق صغير، هل ستختار Monolith أم Microservices؟ ولماذا؟

التالي في السلسلة:
#017 — Architectural Styles
Monolith، Layered، Microservices، Event-Driven… وما الفرق بينها ومتى نستخدم كل أسلوب؟
م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #SoftwareArchitecture #Architecture #SystemDesign #SoftwareDesign #Monolith #Microservices #Scalability #BackendDevelopment #SystemArchitecture #SoftwareDevelopment #SoftwareEngineer #هندسة_البرمجيات #معمارية_البرمجيات #تصميم_الأنظمة #تطوير_البرمجيات

كيف تساعدنا مبادئ مثل SRP و OCP و Dependency Inversion على بناء تصميم مرن، قابل للتوسع والتغيير بكل سهولة؟
م.طارق العمري
Software Engineer| Backend Developer

#SoftwareEngineering #DetailedDesign #SoftwareDesign #SystemDesign #CleanArchitecture #SOLID #BackendDevelopment #CleanCode #SoftwareEngineer #هندسة_البرمجيات #التصميم_التفصيلي #تطوير_البرمجيات

#018 — Database Design | تصميم قواعد البيانات

أي نظام ناجح لا يعتمد فقط على كود جيد، بل يحتاج إلى بيانات منظمة ومصممة بشكل صحيح من البداية.

وهنا يأتي دور:

Database Design — تصميم قواعد البيانات

الفكرة ليست أن تنشئ Tables كثيرة، بل أن تسأل أولًا:

ما البيانات التي أحتاجها فعلًا؟ وكيف ترتبط ببعضها؟

لأن التصميم السيئ قد يؤدي إلى:

تكرار البيانات، صعوبة التعديل، أخطاء في العلاقات، بطء الاستعلامات، ومشاكل تظهر كلما كبر النظام.

لذلك نبدأ عادةً بـ:

Requirements → Entities → Attributes → Keys → Relationships → ERD → Database

فمثلًا في متجر إلكتروني قد نحدد:

Customer — العميل
Product — المنتج
Order — الطلب
Payment — الدفع
Category — التصنيف
Address — العنوان

ثم نحول كل مفهوم مهم إلى Entity، وبعدها نحدد خصائصه.

مثلًا:

Customer

id
name
email
phone

وهنا تأتي المفاتيح:

Primary Key — PK
يميز كل Record بشكل فريد.

Foreign Key — FK
يربط البيانات بين الجداول.

وباختصار:

PK identifies. FK connects.

لكن البيانات لا تعيش منفصلة، لذلك نحتاج إلى فهم Relationships:

1:1 — One-to-One
مستخدم واحد ملف شخصي واحد.

1:N — One-to-Many
عميل واحد → عدة طلبات.

M:N — Many-to-Many
الطلب يحتوي عدة منتجات، والمنتج قد يظهر في عدة طلبات.

وفي حالة M:N نستخدم غالبًا جدولًا وسيطًا مثل:

OrderItems

حتى نحافظ على تصميم منطقي ومنظم.

ثم يأتي دور:

ERD — Entity Relationship Diagram

وهو الخريطة التي توضح:

Entities
Attributes
Primary Keys
Foreign Keys
Relationships
Cardinality

قبل أن تبدأ كتابة SQL.

لكن التصميم لا يتوقف هنا.

نحتاج أيضًا إلى Normalization — التطبيع لتقليل التكرار ووضع كل معلومة في المكان الصحيح.

والقاعدة الجميلة هنا:

Store each fact in the right place.

ثم نضيف عناصر تجعل قاعدة البيانات أكثر موثوقية:

Constraints
مثل NOT NULL وUNIQUE وCHECK وFOREIGN KEY.

Data Types
اختيار النوع المناسب لكل قيمة.

Indexes
لتسريع البحث والاستعلامات عند استخدامها بشكل صحيح.

Naming
أسماء واضحة ومتناسقة.

Integrity
الحفاظ على صحة وترابط البيانات.

Performance
تصميم يناسب طريقة استخدام النظام فعلًا.

ويمكن تلخيص الرحلة كاملة هكذا:

Understand Data
↓
Identify Entities
↓
Define Attributes
↓
Choose Primary Keys
↓
Define Relationships
↓
Draw ERD
↓
Normalize
↓
Add Constraints & Indexes
↓
Validate with Real Scenarios

ثم المعادلة:

Good Data Model → Reliable Database → Better System

وأهم نصيحة:

لا تصمم قاعدة البيانات لتناسب الشاشة الحالية فقط.

صمّمها لتمثل البيانات الحقيقية والعلاقات الحقيقية داخل النظام.

Understand → Model → Relate → Normalize → Implement

سؤال للنقاش:

في متجر إلكتروني، لماذا لا نضع المنتجات مباشرة داخل جدول Orders؟
ولماذا نحتاج جدولًا مثل OrderItems؟


م. طارق العمري
Software Engineer | Backend Developer

#DatabaseDesign #Database #DataModeling #ERD #SQL #Normalization #PrimaryKey #ForeignKey #DatabaseRelationships #BackendDevelopment #SoftwareEngineering #SystemDesign #SoftwareDeveloper #SoftwareEngineer #تصميم_قواعد_البيانات #قواعد_البيانات #هندسة_البرمجيات #تطوير_البرمجيات

#019 — UI/UX Design | تصميم واجهة وتجربة المستخدم

قد يكون النظام قويًا من ناحية البرمجة، سريعًا، وآمنًا…
لكن إذا لم يعرف المستخدم أين يضغط؟ ماذا يفعل؟ وما الخطوة التالية؟ فالتجربة ما زالت سيئة.
وهنا يأتي دور:
UI/UX Design — تصميم واجهة وتجربة المستخدم

الفرق بينهما بسيط:
UX — User Experience
يركز على كيف تعمل التجربة.
هل الخطوات منطقية؟
هل يصل المستخدم إلى هدفه بسهولة؟
هل توجد خطوات زائدة؟
هل رسائل الخطأ واضحة؟
هل يعرف ماذا يفعل بعد ذلك؟

أما:
UI — User Interface
فيركز على كيف تبدو الواجهة.
الألوان، الخطوط، الأزرار، الأيقونات، المسافات، ترتيب العناصر، والحالات البصرية.

بمعنى مختصر:

UX = How it works
UI = How it looks

لكن التصميم الجيد لا يبدأ بالألوان.
يبدأ بسؤال:

من هو المستخدم؟ وماذا يريد أن ينجز؟
فالمستخدم الذي يدخل تطبيقًا لحجز رحلة لا يريد مشاهدة أجمل Animation…

هدفه غالبًا:
Search → Choose → Book → Pay → Confirm

ولهذا نرسم أولًا:
User Flow
أي المسار الذي سيمر به المستخدم للوصول إلى هدفه.
وكل خطوة إضافية يجب أن نسأل عنها:
هل هي ضرورية فعلًا؟
بعد فهم الرحلة ننتقل إلى:

Sketch → Wireframe → Prototype → Visual UI → Development

وهنا قاعدة مهمة جدًا:

Structure First → Style Later
لأن Wireframe سيئًا بألوان جميلة…
يبقى تجربة سيئة.
ثم يأتي دور Visual Hierarchy.

فنستخدم:

Size للحجم.
Contrast للتباين.
Spacing للمسافات.
Alignment للمحاذاة.
Typography للخطوط.
Color لتوجيه الانتباه.

الهدف ليس أن نجعل كل عنصر بارزًا.
بل أن نجعل المستخدم يعرف:
ما المهم الآن؟ وما الذي يجب أن أفعله بعده؟
ثم نحتاج إلى Design System حتى لا تصبح كل شاشة عالمًا مختلفًا.
نحدد نظامًا موحدًا لـ:

Colors — Typography — Buttons — Inputs — Cards — Icons — Spacing — States

لأن:

Consistency reduces confusion.

لكن هناك نقطة غالبًا ما تُنسى:
لا تصمم Happy Path فقط.
صمّم أيضًا للحالات الإستثنائية:

Loading
Empty State
Validation
Error
Success
Disabled

فالمستخدم لا يحكم على النظام فقط عندما يعمل كل شيء بشكل مثالي…
بل أيضًا عندما تحدث مشكلة.

بدل:
Error 504
الأفضل أن تقول للمستخدم:
تعذر إتمام العملية حاليًا.
لم يتم خصم المبلغ. حاول مرة أخرى.
لأن:

A good UX explains what happened and what to do next.
ويمكن تلخيص رحلة UI/UX هكذا:

Understand Users
↓
Define Goals
↓
Map User Flow
↓
Create Wireframes
↓
Build Prototype
↓
Design Visual UI
↓
Handle All States
↓
Test with Users
↓
Improve

والمعادلة الأهم:
User Needs + Clear Flow + Consistent UI = Better Experience

وفي النهاية، المستخدم لا يهتم بعدد الساعات التي قضيتها في التصميم…
هو يهتم بسؤال واحد:
هل استطعت إنجاز ما أريد بسهولة؟

سؤال للنقاش:

لو كان لديك تطبيق حجز يحتاج 9 خطوات لإتمام الحجز، هل تبدأ أولًا بتغيير الألوان؟
أم تبدأ بتحليل الخطوات نفسها وتقليلها؟

سؤال للبحث (:

(Wireframes & Prototypes)
ما الفرق بين Sketch وWireframe وMockup وPrototype؟ ومتى نستخدم كل واحد؟

م. طارق العمري
Software Engineer | Backend Developer

#UIUX #UIDesign #UXDesign #UserExperience #UserInterface #UserFlow #Wireframe #Prototype #DesignSystem #VisualHierarchy #ProductDesign #Usability #SoftwareEngineering #SoftwareDesign #FrontendDevelopment #SoftwareEngineer #هندسة_البرمجيات #تصميم_واجهات #تجربة_المستخدم #تصميم_البرمجيات

#020 — Architectural Patterns | الأنماط المعمارية

عندما يبدأ المشروع يكبر، تظهر أسئلة مهمة:

كيف نقسم النظام؟
كيف نفصل المسؤوليات؟
كيف نجعل التغيير أسهل؟
وكيف نقلل الترابط بين الأجزاء؟

هنا تأتي Architectural Patterns — الأنماط المعمارية.

الـPattern ليس كودًا جاهزًا، بل هو طريقة مجربة لتنظيم النظام وحل مشاكل معمارية متكررة.

ومن أشهر الأنماط:

Layered Architecture
تقسم النظام إلى طبقات واضحة مثل:

Presentation → Application → Business → Data Access → Database

مناسبة للتطبيقات التقليدية عندما نريد بنية واضحة وسهلة الفهم.

MVC — Model View Controller
يفصل بين:

Model
View
Controller

والهدف هو عدم خلط واجهة المستخدم مع منطق النظام.

Clean Architecture
تضع Business Logic في المركز، وتجعل الاعتمادات تتجه للداخل.

الفكرة المهمة:

> منطق الأعمال يجب ألا يعتمد على Framework أو Database معينة.



Hexagonal Architecture — Ports & Adapters
تعزل النظام عن التقنيات الخارجية من خلال Interfaces واضحة.

مثلًا:

PaymentPort

يمكن تنفيذه لاحقًا بواسطة:

Stripe
PayPal
بوابة دفع محلية

دون تغيير Business Logic.

Event-Driven Architecture
بدل أن تستدعي الخدمات بعضها مباشرة، تتفاعل عبر Events.

مثال:

Order Created

ثم تستجيب:

Payment Service
Notification Service
Inventory Service
Analytics Service

وهذا يقلل الترابط ويساعد على التوسع، لكنه يزيد تحديات مثل Debugging وMonitoring وConsistency.

والسؤال الذي يتكرر دائمًا:

ما أفضل Architectural Pattern؟

الإجابة الصحيحة ليست اسم Pattern معين.

لأن:

لا يوجد Pattern مناسب لكل مشروع.

قد يكون Layered هو الأنسب لمشروع بسيط، بينما مشروع آخر يحتاج Clean Architecture، وآخر يعتمد على Event-Driven، وأحيانًا نستخدم أكثر من Pattern داخل نفس النظام.

لذلك لا تختَر بناءً على الشهرة.

اختَر بناءً على:

Problem + Constraints + Context

ثم:

Right Pattern

القاعدة الأهم:

> Choose based on context, not popularity.



المعمارية الجيدة لا تجعل النظام يعمل اليوم فقط، بل تساعده أن يكون أسهل في الصيانة، الاختبار، التوسع، والتغيير مستقبلًا.

Understand → Compare → Choose → Adapt → Build

سؤال للنقاش:

لديك نظام حجز يعتمد على Payment Gateway وSMS Provider وخدمة خرائط خارجية.
أي Architectural Pattern ستستخدم حتى تستطيع تغيير هذه الخدمات مستقبلًا بأقل تأثير على Business Logic؟

المنشور القادم:

#021 — Clean Architecture
كيف نحمي Business Logic من تغيّر Frameworks وقواعد البيانات والخدمات الخارجية؟

م. طارق العمري
Software Engineer | Backend Developer

#SoftwareEngineering #ArchitecturalPatterns #SoftwareArchitecture #SystemDesign #LayeredArchitecture #MVC #CleanArchitecture #HexagonalArchitecture #EventDrivenArchitecture #BackendDevelopment #SoftwareDesign #Scalability #Maintainability #SoftwareEngineer #هندسة_البرمجيات #الأنماط_المعمارية #معمارية_البرمجيات #تصميم_الأنظمة #تطوير_البرمجيات