IBB Business Database
https://github.com/tareq-alomari/ibb-business-database
هو مستودع يهدف إلى بناء قاعدة تحليل شاملة ومنظمة لجميع المؤسسات والمحلات التجارية والخدمية في محافظة إب، في اليمن ويمكن تطويره وتوسيعة ليشمل جميع محافظات الجمهورية
يعتمد المشروع على هيكل قطاعي موحد يضم 22 قطاعًا رئيسيًا وأكثر من 150 مجالًا فرعيًا، مما يسهل عملية البحث والتحليل ك هندسة برمجيات
وأيضاّ مستودع غني بالافكار سوى لمشاريع التخرج او لمشاريع سوق عمل
تم تخطيط و تصميم هذا المستودع ليكون مرجع للمهندسين والمطورين والباحثين والجهات الحكومية والخاصة، مع إمكانية إضافة قطاعات ومجالات جديدة مستقبلًا دون التأثير على بنية قاعدة البيانات.
الهيكل القطاعي
القطاعات الرئيسية (22 قطاعًا)
# القطاع المجالات الفرعية
01 الصحة المستشفيات، المراكز الطبية، العيادات، المختبرات، الصيدليات، مراكز الأشعة، العلاج الطبيعي، البصريات، الأسنان، الإسعاف
02 التعليم الجامعات، الكليات، المدارس الحكومية، المدارس الأهلية، المعاهد، مراكز التدريب، الحضانات، رياض الأطفال، مراكز اللغات
03 التجارة والتجزئة السوبرماركت، البقالات، الهايبر ماركت، محلات الملابس، الأحذية، الحقائب، العطور، مستحضرات التجميل، الألعاب، الهدايا
04 الأغذية والمشروبات المطاعم، الكافتيريات، المقاهي، المخابز، الحلويات، العصائر، محامص البن، البهارات، المياه
05 التقنية والاتصالات شركات البرمجيات، محلات الكمبيوتر، الهواتف، صيانة الأجهزة، الشبكات، الإنترنت، كاميرات المراقبة، الطابعات
06 المال والأعمال البنوك، شركات الصرافة، التمويل الأصغر، المحاسبة، التدقيق، التأمين، الاستشارات
07 العقارات والإنشاءات المكاتب العقارية، المقاولات، مواد البناء، الديكور، الألمنيوم، الزجاج، النجارة، الحدادة
08 النقل والمواصلات مكاتب السفر، النقل الداخلي، النقل بين المحافظات، الشحن، التخليص، تأجير السيارات
09 السيارات معارض السيارات، الورش، الكهرباء، السمكرة، الدهان، الإطارات، البطاريات، الزيوت، قطع الغيار
10 الزراعة والثروة الحيوانية المشاتل، البذور، الأسمدة، المبيدات، المعدات الزراعية، العسل، الأعلاف، البيطرة
11 الصناعة والإنتاج المصانع، الورش الصناعية، الصناعات الغذائية، البلاستيك، الأثاث، المنسوجات
12 الخدمات المهنية المحاماة، الهندسة، الاستشارات، الترجمة، التصميم، التصوير، الطباعة
13 الخدمات المنزلية التنظيف، مكافحة الحشرات، الغسيل، صيانة المنازل، الكهرباء، السباكة، التكييف
14 التجميل والعناية الشخصية صالونات الحلاقة، صالونات التجميل، مراكز العناية بالبشرة، النوادي الصحية، المساج
15 السياحة والضيافة الفنادق، الشقق الفندقية، المنتجعات، الاستراحات، قاعات المناسبات
16 المنظمات والجمعيات الجمعيات الخيرية، المنظمات المحلية، المنظمات الدولية، المؤسسات التنموية
17 الجهات الحكومية الوزارات، المكاتب التنفيذية، المحاكم، الشرطة، البلديات، المرافق العامة
18 الإعلام والإعلان الصحف، الإذاعات، وكالات الإعلان، التسويق الرقمي، الإنتاج الإعلامي
19 الرياضة والترفيه الأندية الرياضية، الصالات الرياضية، الملاعب، مراكز الألعاب، الحدائق
20 الطاقة والمرافق محطات الوقود، الغاز، الطاقة الشمسية، الكهرباء، المياه
21 الأسواق الشعبية الأسواق العامة، أسواق الجملة، أسواق الخضار، أسواق المواشي، الأسواق الموسمية
22 الحرف والصناعات التقليدية الخياطة، التطريز، الفخار، النجارة التقليدية، صياغة الذهب، الصناعات اليدوية
مراحل التحليل (22 مرحلة)
كل مجال فرعي في قاعدة البيانات يحتوي على هيكل تحليل متكامل مكون من 22 مرحلة:
# المرحلة الوصف
01 Project Discovery فهم المشروع، المشكلة، الحل، SWOT, PESTLE
02 Research بحث في جميع المصادر الممكنة
03 Business Analysis تحليل الأعمال والخدمات
04 Market Analysis تحليل السوق والمنافسين
05 Competitor Analysis تحليل المنافسين الرئيسيين
06 Stakeholders تحديد أصحاب المصلحة
07 User Research بناء Personas احترافية
08 Functional Analysis المتطلبات الوظيفية
09 Non-Functional Requirements المتطلبات غير الوظيفية
10 Information Architecture هيكل المعلومات
11 UX تجربة المستخدم
12 UI Design تصميم الواجهات
13 Database Design تصميم قاعدة البيانات
14 API Design تصميم API
15 Software Architecture بنية البرمجيات
16 Technical Stack التقنيات المقترحة
17 Security تحليل الأمان
18 SEO استراتيجية تحسين محركات البحث
19 Dashboard لوحة التحكم
20 Project Planning تخطيط المشروع
21 Documentation التوثيق
22 Final Deliverables المخرجات النهائية
ملاحظة : المستودع في وضع التطوير
نرحب بمساهماتكم في:
إضافة بيانات جديدة للمجالات الفرعية
إكمال تحليلات المجالات
اقتراح قطاعات أو مجالات جديدة
تحسين هيكل البيانات
للاستفسارات والاقتراحات، يرجى التواصل عبر:
https://github.com/tareq-alomari/ibb-business-database
هو مستودع يهدف إلى بناء قاعدة تحليل شاملة ومنظمة لجميع المؤسسات والمحلات التجارية والخدمية في محافظة إب، في اليمن ويمكن تطويره وتوسيعة ليشمل جميع محافظات الجمهورية
يعتمد المشروع على هيكل قطاعي موحد يضم 22 قطاعًا رئيسيًا وأكثر من 150 مجالًا فرعيًا، مما يسهل عملية البحث والتحليل ك هندسة برمجيات
وأيضاّ مستودع غني بالافكار سوى لمشاريع التخرج او لمشاريع سوق عمل
تم تخطيط و تصميم هذا المستودع ليكون مرجع للمهندسين والمطورين والباحثين والجهات الحكومية والخاصة، مع إمكانية إضافة قطاعات ومجالات جديدة مستقبلًا دون التأثير على بنية قاعدة البيانات.
الهيكل القطاعي
القطاعات الرئيسية (22 قطاعًا)
# القطاع المجالات الفرعية
01 الصحة المستشفيات، المراكز الطبية، العيادات، المختبرات، الصيدليات، مراكز الأشعة، العلاج الطبيعي، البصريات، الأسنان، الإسعاف
02 التعليم الجامعات، الكليات، المدارس الحكومية، المدارس الأهلية، المعاهد، مراكز التدريب، الحضانات، رياض الأطفال، مراكز اللغات
03 التجارة والتجزئة السوبرماركت، البقالات، الهايبر ماركت، محلات الملابس، الأحذية، الحقائب، العطور، مستحضرات التجميل، الألعاب، الهدايا
04 الأغذية والمشروبات المطاعم، الكافتيريات، المقاهي، المخابز، الحلويات، العصائر، محامص البن، البهارات، المياه
05 التقنية والاتصالات شركات البرمجيات، محلات الكمبيوتر، الهواتف، صيانة الأجهزة، الشبكات، الإنترنت، كاميرات المراقبة، الطابعات
06 المال والأعمال البنوك، شركات الصرافة، التمويل الأصغر، المحاسبة، التدقيق، التأمين، الاستشارات
07 العقارات والإنشاءات المكاتب العقارية، المقاولات، مواد البناء، الديكور، الألمنيوم، الزجاج، النجارة، الحدادة
08 النقل والمواصلات مكاتب السفر، النقل الداخلي، النقل بين المحافظات، الشحن، التخليص، تأجير السيارات
09 السيارات معارض السيارات، الورش، الكهرباء، السمكرة، الدهان، الإطارات، البطاريات، الزيوت، قطع الغيار
10 الزراعة والثروة الحيوانية المشاتل، البذور، الأسمدة، المبيدات، المعدات الزراعية، العسل، الأعلاف، البيطرة
11 الصناعة والإنتاج المصانع، الورش الصناعية، الصناعات الغذائية، البلاستيك، الأثاث، المنسوجات
12 الخدمات المهنية المحاماة، الهندسة، الاستشارات، الترجمة، التصميم، التصوير، الطباعة
13 الخدمات المنزلية التنظيف، مكافحة الحشرات، الغسيل، صيانة المنازل، الكهرباء، السباكة، التكييف
14 التجميل والعناية الشخصية صالونات الحلاقة، صالونات التجميل، مراكز العناية بالبشرة، النوادي الصحية، المساج
15 السياحة والضيافة الفنادق، الشقق الفندقية، المنتجعات، الاستراحات، قاعات المناسبات
16 المنظمات والجمعيات الجمعيات الخيرية، المنظمات المحلية، المنظمات الدولية، المؤسسات التنموية
17 الجهات الحكومية الوزارات، المكاتب التنفيذية، المحاكم، الشرطة، البلديات، المرافق العامة
18 الإعلام والإعلان الصحف، الإذاعات، وكالات الإعلان، التسويق الرقمي، الإنتاج الإعلامي
19 الرياضة والترفيه الأندية الرياضية، الصالات الرياضية، الملاعب، مراكز الألعاب، الحدائق
20 الطاقة والمرافق محطات الوقود، الغاز، الطاقة الشمسية، الكهرباء، المياه
21 الأسواق الشعبية الأسواق العامة، أسواق الجملة، أسواق الخضار، أسواق المواشي، الأسواق الموسمية
22 الحرف والصناعات التقليدية الخياطة، التطريز، الفخار، النجارة التقليدية، صياغة الذهب، الصناعات اليدوية
مراحل التحليل (22 مرحلة)
كل مجال فرعي في قاعدة البيانات يحتوي على هيكل تحليل متكامل مكون من 22 مرحلة:
# المرحلة الوصف
01 Project Discovery فهم المشروع، المشكلة، الحل، SWOT, PESTLE
02 Research بحث في جميع المصادر الممكنة
03 Business Analysis تحليل الأعمال والخدمات
04 Market Analysis تحليل السوق والمنافسين
05 Competitor Analysis تحليل المنافسين الرئيسيين
06 Stakeholders تحديد أصحاب المصلحة
07 User Research بناء Personas احترافية
08 Functional Analysis المتطلبات الوظيفية
09 Non-Functional Requirements المتطلبات غير الوظيفية
10 Information Architecture هيكل المعلومات
11 UX تجربة المستخدم
12 UI Design تصميم الواجهات
13 Database Design تصميم قاعدة البيانات
14 API Design تصميم API
15 Software Architecture بنية البرمجيات
16 Technical Stack التقنيات المقترحة
17 Security تحليل الأمان
18 SEO استراتيجية تحسين محركات البحث
19 Dashboard لوحة التحكم
20 Project Planning تخطيط المشروع
21 Documentation التوثيق
22 Final Deliverables المخرجات النهائية
ملاحظة : المستودع في وضع التطوير
نرحب بمساهماتكم في:
إضافة بيانات جديدة للمجالات الفرعية
إكمال تحليلات المجالات
اقتراح قطاعات أو مجالات جديدة
تحسين هيكل البيانات
للاستفسارات والاقتراحات، يرجى التواصل عبر:
البريد الإلكتروني: [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 #هندسة_البرمجيات #المتطلبات_الوظيفية #تحليل_النظم #تطوير_البرمجيات