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

يمكنك تحميل opencode وتجريب العديد النماذج مجانا بما فيها Ox Alpha الذي يشاع بأنه بآداء أفضل من Fable

لتسهيل الوصول له
حمل OpenCode desktop

https://opencode.ai/download

اضغط على النماذج اسفل مربع النص
واختر manage models
وفعل النموذج : Ox Alpha
ثم اختره تحت مربع النص واستمتع بالنموذج مجانا لمدة أسبوع