قريبًا… نصل إلى اللحظة التي انتظرناها طويلًا. 🎓
سنوات من الدراسة، السهر، المشاريع، الاختبارات، التحديات، والمحاولات… في يوم واحد يحمل معنى كبيرًا لنا.
حفل تخرج دفعة الظل التقني — 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 #هندسة_البرمجيات #تحليل_النظام #تحليل_النظم #تطوير_البرمجيات