البريد الإلكتروني: [tareq.software.devloper@gmail.com]
+967715299909
محافظة إب - اليمن 🇾🇪
Software Engineer: Tareq Al-Omari - طارق العمري
#DemoSoft
#IBBBusinessDatabase
#DemoSoft
#TareqAlOmari
#SoftwareEngineering
#SoftwareEngineer
#هندسة_البرمجيات
#مهندس_برمجيات
#تحليل_الأنظمة
#SystemAnalysis
#BusinessAnalysis
#تحليل_الأعمال
#RequirementsEngineering
#SoftwareArchitecture
#DatabaseDesign
#تصميم_قواعد_البيانات
#API_Design
#UXDesign
#UIDesign
#ProjectPlanning
#ProjectDiscovery
#MarketAnalysis
#تحليل_السوق
#DataAnalysis
#قواعد_البيانات
#مشاريع_برمجية
#مشاريع_تخرج
#أفكار_مشاريع
#مشاريع_تقنية
#InformationTechnology
#تقنية_المعلومات
#DigitalTransformation
#التحول_الرقمي
#OpenSource
#اليمن
#Yemen
#إب
#Ibb
#مبرمجين_اليمن
#مهندسين_اليمن
#التقنية_في_اليمن
+967715299909
محافظة إب - اليمن 🇾🇪
Software Engineer: Tareq Al-Omari - طارق العمري
#DemoSoft
#IBBBusinessDatabase
#DemoSoft
#TareqAlOmari
#SoftwareEngineering
#SoftwareEngineer
#هندسة_البرمجيات
#مهندس_برمجيات
#تحليل_الأنظمة
#SystemAnalysis
#BusinessAnalysis
#تحليل_الأعمال
#RequirementsEngineering
#SoftwareArchitecture
#DatabaseDesign
#تصميم_قواعد_البيانات
#API_Design
#UXDesign
#UIDesign
#ProjectPlanning
#ProjectDiscovery
#MarketAnalysis
#تحليل_السوق
#DataAnalysis
#قواعد_البيانات
#مشاريع_برمجية
#مشاريع_تخرج
#أفكار_مشاريع
#مشاريع_تقنية
#InformationTechnology
#تقنية_المعلومات
#DigitalTransformation
#التحول_الرقمي
#OpenSource
#اليمن
#Yemen
#إب
#Ibb
#مبرمجين_اليمن
#مهندسين_اليمن
#التقنية_في_اليمن
#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 #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات
كيف أتعامل مع عميل وأجمع منه متطلبات المشروع ؟
من أكثر الأخطاء التي يقع فيها المهندس في بداية دخوله سوق العمل أن يتعامل مع كلام العميل على أنه المتطلبات النهائية للنظام.
يأتي العميل ويقول مثلًا:
«أريد نظامًا لإدارة المخزون والمبيعات، وأريد شاشة للفواتير وتقارير وحسابات للعملاء.»
قد يبدو الأمر واضحًا، فنبدأ مباشرة بتصميم قاعدة البيانات والواجهات ثم كتابة الكود.
لكن بعد فترة تبدأ المفاجآت:
"نسيت أقول لك أن بعض العملاء يشترون بالدين."
"عندنا أكثر من مخزن."
"أحيانًا نرجع جزءًا من الفاتورة."
"بعض الموظفين مسموح لهم البيع لكن غير مسموح لهم تعديل الأسعار."
"المدير يريد معرفة أرباح كل فرع بشكل منفصل."
وهنا نكتشف أن المشكلة لم تكن في البرمجة أصلًا، بل في أننا بدأنا البرمجة قبل أن نفهم العمل نفسه.
العميل يعرف مشكلته… لكنه ليس بالضرورة مهندس متطلبات
في المشاريع الحقيقية، العميل غالبًا لا يأتي إليك ومعه وثيقة Software Requirements Specification جاهزة.
هو يعرف نشاطه التجاري، ويعرف المشاكل التي يعاني منها، وقد تكون لديه فكرة عن النظام الذي يريده.
لكن مهمتك كمهندس برمجيات ليست أن تحول كلامه مباشرة إلى Code.
مهمتك أولًا أن تحول احتياجه إلى متطلبات واضحة وقابلة للتنفيذ والاختبار.
وهنا يظهر الفرق بين المبرمج الذي يسأل:
ماذا تريد مني أن أبرمج؟
ومهندس البرمجيات الذي يسأل:
ما المشكلة التي نحاول حلها؟
لا تسأل فقط: ماذا تريد؟
من أهم المهارات في تحليل المتطلبات أن تتجاوز السؤال المباشر.
إذا قال العميل:
"أريد أن يستطيع المدير حذف الفواتير."
لا تكتب مباشرة:
The system shall allow the manager to delete invoices.
بل اسأل:
لماذا يحتاج المدير إلى حذف الفاتورة؟
ماذا يحدث إذا حُذفت فاتورة مرتبطة بالمخزون؟
هل يجب حذفها فعلًا أم إلغاؤها مع الاحتفاظ بسجل لها؟
من يملك صلاحية الإلغاء؟
هل يجب تسجيل اسم الموظف ووقت العملية وسبب الإلغاء؟
ماذا لو كانت الفاتورة قد سُددت بالفعل؟
سؤال واحد من العميل قد يتحول بعد التحليل إلى مجموعة من Functional Requirements و Business Rules و Security Requirements.
وهذه هي قيمة التحليل.
المتطلبات الحقيقية لا تأتي من العميل فقط
من واقع المشاريع، هناك خطأ آخر وهو اعتبار الشخص الذي يدفع تكلفة المشروع المصدر الوحيد للمتطلبات.
لنفترض أنك تبني نظامًا لمستشفى.
المدير لديه متطلبات.
لكن الطبيب لديه متطلبات مختلفة.
والممرض لديه احتياجات أخرى.
والمحاسب لديه إجراءات مختلفة.
وموظف الاستقبال يستخدم النظام بطريقة مختلفة تمامًا.
وهؤلاء جميعًا يمثلون Stakeholders — أصحاب المصلحة.
لذلك استخراج المتطلبات قد يعتمد على عدة مصادر، مثل مقابلات المستخدمين، مراقبة طريقة العمل الحالية، دراسة النظام السابق، مراجعة النماذج والتقارير المستخدمة، وفهم إجراءات وسياسات المؤسسة.
أحيانًا ستكتشف متطلبًا مهمًا من موظف يستخدم النظام يوميًا لم يخطر حتى على بال الإدارة.
افهم الـ Business Process قبل أن تصمم الـ Software
قبل أن تسأل:
كيف سنبني النظام؟
اسأل:
كيف يعمل العمل حاليًا؟
خذ متجرًا كمثال.
لا تبدأ مباشرة بإنشاء جداول:
Customers
Products
Invoices
Payments
بل افهم دورة العمل:
العميل يطلب منتجًا → الموظف يتحقق من توفره → يتم إنشاء الفاتورة → يتم تحديد طريقة الدفع → يتم خصم الكمية من المخزون → يتم تسجيل العملية → تظهر في التقارير.
ثم ابدأ بدراسة الحالات غير الطبيعية:
ماذا لو لم تتوفر الكمية؟
ماذا لو دفع العميل جزءًا من المبلغ؟
ماذا لو أعاد المنتج؟
ماذا لو ألغيت الفاتورة؟
ماذا لو تم البيع من فرع آخر؟
هنا تبدأ المتطلبات الحقيقية في الظهور.
النظام الحالي مصدر مهم جدًا للمتطلبات
إذا كانت المؤسسة تستخدم برنامجًا قديمًا، ملفات Excel، سجلات ورقية، أو حتى إجراءات يدوية، فلا تتجاهلها.
اسأل:
ما الذي يعمل جيدًا حاليًا؟
ما الذي يسبب المشاكل؟
ما العمليات التي تستغرق وقتًا؟
ما البيانات التي يتم إدخالها أكثر من مرة؟
ما التقارير التي يحتاجها المدير؟
ما الأخطاء المتكررة؟
لأن الهدف ليس بناء نسخة أجمل من النظام القديم.
الهدف هو فهم المشكلة وتحسين طريقة العمل باستخدام البرمجيات.
لا تنسَ المتطلبات غير الوظيفية
العميل غالبًا يتحدث عن الوظائف:
أريد تسجيل الدخول.
أريد إضافة العملاء.
أريد إصدار فاتورة.
أريد تقرير المبيعات.
لكن قد لا يقول لك:
يجب ألا يتمكن الموظف العادي من رؤية الأرباح.
يجب أن يستجيب النظام بسرعة.
يجب أخذ نسخة احتياطية من البيانات.
يجب حماية بيانات المستخدمين.
يجب أن يعمل النظام لعدد معين من المستخدمين في الوقت نفسه.
من أكثر الأخطاء التي يقع فيها المهندس في بداية دخوله سوق العمل أن يتعامل مع كلام العميل على أنه المتطلبات النهائية للنظام.
يأتي العميل ويقول مثلًا:
«أريد نظامًا لإدارة المخزون والمبيعات، وأريد شاشة للفواتير وتقارير وحسابات للعملاء.»
قد يبدو الأمر واضحًا، فنبدأ مباشرة بتصميم قاعدة البيانات والواجهات ثم كتابة الكود.
لكن بعد فترة تبدأ المفاجآت:
"نسيت أقول لك أن بعض العملاء يشترون بالدين."
"عندنا أكثر من مخزن."
"أحيانًا نرجع جزءًا من الفاتورة."
"بعض الموظفين مسموح لهم البيع لكن غير مسموح لهم تعديل الأسعار."
"المدير يريد معرفة أرباح كل فرع بشكل منفصل."
وهنا نكتشف أن المشكلة لم تكن في البرمجة أصلًا، بل في أننا بدأنا البرمجة قبل أن نفهم العمل نفسه.
العميل يعرف مشكلته… لكنه ليس بالضرورة مهندس متطلبات
في المشاريع الحقيقية، العميل غالبًا لا يأتي إليك ومعه وثيقة Software Requirements Specification جاهزة.
هو يعرف نشاطه التجاري، ويعرف المشاكل التي يعاني منها، وقد تكون لديه فكرة عن النظام الذي يريده.
لكن مهمتك كمهندس برمجيات ليست أن تحول كلامه مباشرة إلى Code.
مهمتك أولًا أن تحول احتياجه إلى متطلبات واضحة وقابلة للتنفيذ والاختبار.
وهنا يظهر الفرق بين المبرمج الذي يسأل:
ماذا تريد مني أن أبرمج؟
ومهندس البرمجيات الذي يسأل:
ما المشكلة التي نحاول حلها؟
لا تسأل فقط: ماذا تريد؟
من أهم المهارات في تحليل المتطلبات أن تتجاوز السؤال المباشر.
إذا قال العميل:
"أريد أن يستطيع المدير حذف الفواتير."
لا تكتب مباشرة:
The system shall allow the manager to delete invoices.
بل اسأل:
لماذا يحتاج المدير إلى حذف الفاتورة؟
ماذا يحدث إذا حُذفت فاتورة مرتبطة بالمخزون؟
هل يجب حذفها فعلًا أم إلغاؤها مع الاحتفاظ بسجل لها؟
من يملك صلاحية الإلغاء؟
هل يجب تسجيل اسم الموظف ووقت العملية وسبب الإلغاء؟
ماذا لو كانت الفاتورة قد سُددت بالفعل؟
سؤال واحد من العميل قد يتحول بعد التحليل إلى مجموعة من Functional Requirements و Business Rules و Security Requirements.
وهذه هي قيمة التحليل.
المتطلبات الحقيقية لا تأتي من العميل فقط
من واقع المشاريع، هناك خطأ آخر وهو اعتبار الشخص الذي يدفع تكلفة المشروع المصدر الوحيد للمتطلبات.
لنفترض أنك تبني نظامًا لمستشفى.
المدير لديه متطلبات.
لكن الطبيب لديه متطلبات مختلفة.
والممرض لديه احتياجات أخرى.
والمحاسب لديه إجراءات مختلفة.
وموظف الاستقبال يستخدم النظام بطريقة مختلفة تمامًا.
وهؤلاء جميعًا يمثلون Stakeholders — أصحاب المصلحة.
لذلك استخراج المتطلبات قد يعتمد على عدة مصادر، مثل مقابلات المستخدمين، مراقبة طريقة العمل الحالية، دراسة النظام السابق، مراجعة النماذج والتقارير المستخدمة، وفهم إجراءات وسياسات المؤسسة.
أحيانًا ستكتشف متطلبًا مهمًا من موظف يستخدم النظام يوميًا لم يخطر حتى على بال الإدارة.
افهم الـ Business Process قبل أن تصمم الـ Software
قبل أن تسأل:
كيف سنبني النظام؟
اسأل:
كيف يعمل العمل حاليًا؟
خذ متجرًا كمثال.
لا تبدأ مباشرة بإنشاء جداول:
Customers
Products
Invoices
Payments
بل افهم دورة العمل:
العميل يطلب منتجًا → الموظف يتحقق من توفره → يتم إنشاء الفاتورة → يتم تحديد طريقة الدفع → يتم خصم الكمية من المخزون → يتم تسجيل العملية → تظهر في التقارير.
ثم ابدأ بدراسة الحالات غير الطبيعية:
ماذا لو لم تتوفر الكمية؟
ماذا لو دفع العميل جزءًا من المبلغ؟
ماذا لو أعاد المنتج؟
ماذا لو ألغيت الفاتورة؟
ماذا لو تم البيع من فرع آخر؟
هنا تبدأ المتطلبات الحقيقية في الظهور.
النظام الحالي مصدر مهم جدًا للمتطلبات
إذا كانت المؤسسة تستخدم برنامجًا قديمًا، ملفات Excel، سجلات ورقية، أو حتى إجراءات يدوية، فلا تتجاهلها.
اسأل:
ما الذي يعمل جيدًا حاليًا؟
ما الذي يسبب المشاكل؟
ما العمليات التي تستغرق وقتًا؟
ما البيانات التي يتم إدخالها أكثر من مرة؟
ما التقارير التي يحتاجها المدير؟
ما الأخطاء المتكررة؟
لأن الهدف ليس بناء نسخة أجمل من النظام القديم.
الهدف هو فهم المشكلة وتحسين طريقة العمل باستخدام البرمجيات.
لا تنسَ المتطلبات غير الوظيفية
العميل غالبًا يتحدث عن الوظائف:
أريد تسجيل الدخول.
أريد إضافة العملاء.
أريد إصدار فاتورة.
أريد تقرير المبيعات.
لكن قد لا يقول لك:
يجب ألا يتمكن الموظف العادي من رؤية الأرباح.
يجب أن يستجيب النظام بسرعة.
يجب أخذ نسخة احتياطية من البيانات.
يجب حماية بيانات المستخدمين.
يجب أن يعمل النظام لعدد معين من المستخدمين في الوقت نفسه.
وهنا تأتي أهمية 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 #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات