كيف أتعامل مع عميل وأجمع منه متطلبات المشروع ؟
من أكثر الأخطاء التي يقع فيها المهندس في بداية دخوله سوق العمل أن يتعامل مع كلام العميل على أنه المتطلبات النهائية للنظام.
يأتي العميل ويقول مثلًا:
«أريد نظامًا لإدارة المخزون والمبيعات، وأريد شاشة للفواتير وتقارير وحسابات للعملاء.»
قد يبدو الأمر واضحًا، فنبدأ مباشرة بتصميم قاعدة البيانات والواجهات ثم كتابة الكود.
لكن بعد فترة تبدأ المفاجآت:
"نسيت أقول لك أن بعض العملاء يشترون بالدين."
"عندنا أكثر من مخزن."
"أحيانًا نرجع جزءًا من الفاتورة."
"بعض الموظفين مسموح لهم البيع لكن غير مسموح لهم تعديل الأسعار."
"المدير يريد معرفة أرباح كل فرع بشكل منفصل."
وهنا نكتشف أن المشكلة لم تكن في البرمجة أصلًا، بل في أننا بدأنا البرمجة قبل أن نفهم العمل نفسه.
العميل يعرف مشكلته… لكنه ليس بالضرورة مهندس متطلبات
في المشاريع الحقيقية، العميل غالبًا لا يأتي إليك ومعه وثيقة 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 #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات
#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 #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
في هندسة البرمجيات، أن يعمل النظام لا يعني بالضرورة أنه نظام جيد.
قد تنجح عملية تسجيل الدخول، لكن المستخدم ينتظر 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 #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات