#006 — Functional vs Non-Functional Requirements
في تحليل المتطلبات، من أكثر الأمور التي تسبب الالتباس للمبتدئين الفرق بين Functional Requirements و Non-Functional Requirements.
والتمييز بينهما يصبح أسهل عندما نطرح سؤالين:
ماذا يجب أن يفعل النظام؟
هذا يقودنا غالبًا إلى Functional Requirements.
كيف يجب أن يعمل النظام، وبأي مستوى من الجودة؟
هذا يقودنا إلى Non-Functional Requirements.
مثال بسيط:
إذا قلنا:
"يجب أن يسمح النظام للمستخدم بتسجيل الدخول باستخدام البريد الإلكتروني وكلمة المرور."
فنحن نصف وظيفة يقدمها النظام، وبالتالي هذا Functional Requirement.
أما إذا قلنا:
"يجب أن تكتمل عملية تسجيل الدخول خلال ثانيتين أو أقل تحت الحمل المحدد."
فنحن نحدد مستوى أداء لهذه الوظيفة، وبالتالي هذا Non-Functional Requirement.
وفي متجر إلكتروني مثلًا:
البحث عن المنتجات، إضافة منتج للسلة، إنشاء الطلب، الدفع وتتبع الطلب هي متطلبات وظيفية.
أما سرعة الاستجابة، حماية البيانات، التوافر، الاعتمادية والقدرة على التعامل مع آلاف المستخدمين المتزامنين فهي متطلبات غير وظيفية.
المشكلة تبدأ عندما نهتم بالوظائف فقط.
قد تعمل جميع Features المطلوبة، لكن إذا كان النظام بطيئًا، غير مستقر، غير آمن أو يتوقف تحت الضغط، فلن تكون تجربة المستخدم ناجحة.
لهذا يمكن اختصار الفكرة في معادلة بسيطة:
Correct Functions + Defined Quality = Better Software
هندسة البرمجيات لا تهتم فقط ببناء نظام يعمل، بل ببناء نظام يعمل بالجودة المطلوبة وفي الظروف التي صُمم من أجلها.
والآن اختبار سريع:
في تطبيق بنكي:
"يجب تسجيل خروج المستخدم تلقائيًا بعد 10 دقائق من عدم النشاط."
هل تصنف هذا المتطلب Functional أم Non-Functional؟ ولماذا؟
اكتب إجابتك في التعليقات.
المنشور القادم #007 — Use Cases
كيف نصف تفاعل المستخدم مع النظام بطريقة واضحة ومنظمة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #NonFunctionalRequirements #RequirementsEngineering #Requirements #SystemAnalysis #BusinessAnalysis #SoftwareArchitecture #SystemDesign #SoftwareDevelopment #SoftwareQuality #BackendDevelopment #SoftwareEngineer #UseCases #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
في تحليل المتطلبات، من أكثر الأمور التي تسبب الالتباس للمبتدئين الفرق بين Functional Requirements و Non-Functional Requirements.
والتمييز بينهما يصبح أسهل عندما نطرح سؤالين:
ماذا يجب أن يفعل النظام؟
هذا يقودنا غالبًا إلى Functional Requirements.
كيف يجب أن يعمل النظام، وبأي مستوى من الجودة؟
هذا يقودنا إلى Non-Functional Requirements.
مثال بسيط:
إذا قلنا:
"يجب أن يسمح النظام للمستخدم بتسجيل الدخول باستخدام البريد الإلكتروني وكلمة المرور."
فنحن نصف وظيفة يقدمها النظام، وبالتالي هذا Functional Requirement.
أما إذا قلنا:
"يجب أن تكتمل عملية تسجيل الدخول خلال ثانيتين أو أقل تحت الحمل المحدد."
فنحن نحدد مستوى أداء لهذه الوظيفة، وبالتالي هذا Non-Functional Requirement.
وفي متجر إلكتروني مثلًا:
البحث عن المنتجات، إضافة منتج للسلة، إنشاء الطلب، الدفع وتتبع الطلب هي متطلبات وظيفية.
أما سرعة الاستجابة، حماية البيانات، التوافر، الاعتمادية والقدرة على التعامل مع آلاف المستخدمين المتزامنين فهي متطلبات غير وظيفية.
المشكلة تبدأ عندما نهتم بالوظائف فقط.
قد تعمل جميع Features المطلوبة، لكن إذا كان النظام بطيئًا، غير مستقر، غير آمن أو يتوقف تحت الضغط، فلن تكون تجربة المستخدم ناجحة.
لهذا يمكن اختصار الفكرة في معادلة بسيطة:
Correct Functions + Defined Quality = Better Software
هندسة البرمجيات لا تهتم فقط ببناء نظام يعمل، بل ببناء نظام يعمل بالجودة المطلوبة وفي الظروف التي صُمم من أجلها.
والآن اختبار سريع:
في تطبيق بنكي:
"يجب تسجيل خروج المستخدم تلقائيًا بعد 10 دقائق من عدم النشاط."
هل تصنف هذا المتطلب Functional أم Non-Functional؟ ولماذا؟
اكتب إجابتك في التعليقات.
المنشور القادم #007 — Use Cases
كيف نصف تفاعل المستخدم مع النظام بطريقة واضحة ومنظمة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #FunctionalRequirements #NonFunctionalRequirements #RequirementsEngineering #Requirements #SystemAnalysis #BusinessAnalysis #SoftwareArchitecture #SystemDesign #SoftwareDevelopment #SoftwareQuality #BackendDevelopment #SoftwareEngineer #UseCases #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
#007 — Use Cases | حالات الاستخدام
قبل أن تبدأ في تصميم النظام أو كتابة الكود، هناك سؤال أهم:
ماذا يريد المستخدم أن يحقق من خلال النظام؟
هنا تأتي أهمية Use Cases.
الـ Use Case تصف تفاعل جهة خارجية Actor مع النظام من أجل الوصول إلى هدف محدد.
بمعنى أبسط:
Actor → Interaction → System → Goal
فمثلًا، في متجر إلكتروني لا نقول فقط إن لدينا شاشة لتسجيل الدخول أو صفحة للدفع، بل نحاول فهم السيناريو كاملًا من منظور المستخدم:
المستخدم يريد تسجيل الدخول إلى حسابه.
العميل يريد إنشاء طلب.
مدير النظام يريد إدارة المنتجات.
بوابة الدفع تريد معالجة عملية الدفع.
والـ Actor ليس بالضرورة شخصًا فقط؛ فقد يكون مستخدمًا، مديرًا، نظامًا خارجيًا أو خدمة أخرى تتفاعل مع النظام.
وعند كتابة Use Case جيدة، نحتاج إلى معرفة:
Actor: من يتفاعل مع النظام؟
Goal: ما الهدف الذي يريد تحقيقه؟
Preconditions: ما الشروط المطلوبة قبل بدء العملية؟
Main Flow: ما المسار الطبيعي للسيناريو؟
Alternative / Exception Flow: ماذا يحدث عند وجود مسار بديل أو خطأ؟
Postconditions: ما حالة النظام بعد انتهاء العملية؟
خذ تسجيل الدخول مثالًا.
الهدف ليس شرح Authentication API أو Database Query أو طريقة إنشاء Token.
الهدف هو وصف تفاعل المستخدم:
يدخل المستخدم بياناته، يتحقق النظام منها، وإذا كانت صحيحة يسمح له بالدخول.
وإذا كانت البيانات خاطئة، يجب أن تصف الـUse Case هذا السيناريو أيضًا: يرفض النظام تسجيل الدخول، يعرض رسالة مناسبة، ويسمح للمستخدم بالمحاولة مرة أخرى.
وهذه نقطة مهمة:
Use Case الجيدة لا تصف طريق النجاح فقط.
بل تساعدنا على التفكير في السيناريوهات البديلة والاستثناءات التي قد تحدث أثناء استخدام النظام.
لذلك لا تكتب الـUse Case من منظور المبرمج وتسأل:
كيف سننفذ هذه الوظيفة؟
اكتبها من منظور المستخدم واسأل:
من يريد ماذا من النظام، وما السيناريو الذي يوصله إلى هدفه؟
عندما تكون Use Cases واضحة، يصبح فهم المتطلبات وتحليل النظام وتصميمه واختباره أسهل على الفريق.
تحدي بسيط:
في تطبيق بنكي، يريد العميل تحويل مبلغ مالي إلى حساب آخر.
من هو الـ Actor؟
ما هو الـ Goal؟
وما أول 3 خطوات تتوقعها في الـ Main Flow؟
اكتب السيناريو في التعليقات.
المنشور القادم #008 — User Stories
كيف نحول احتياجات المستخدم إلى قصص قصيرة وواضحة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UseCases #UML #RequirementsEngineering #Requirements #SystemAnalysis #SystemDesign #SoftwareArchitecture #BusinessAnalysis #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #UserStories #هندسة_البرمجيات #تحليل_النظم #حالات_الاستخدام #تطوير_البرمجيات
قبل أن تبدأ في تصميم النظام أو كتابة الكود، هناك سؤال أهم:
ماذا يريد المستخدم أن يحقق من خلال النظام؟
هنا تأتي أهمية Use Cases.
الـ Use Case تصف تفاعل جهة خارجية Actor مع النظام من أجل الوصول إلى هدف محدد.
بمعنى أبسط:
Actor → Interaction → System → Goal
فمثلًا، في متجر إلكتروني لا نقول فقط إن لدينا شاشة لتسجيل الدخول أو صفحة للدفع، بل نحاول فهم السيناريو كاملًا من منظور المستخدم:
المستخدم يريد تسجيل الدخول إلى حسابه.
العميل يريد إنشاء طلب.
مدير النظام يريد إدارة المنتجات.
بوابة الدفع تريد معالجة عملية الدفع.
والـ Actor ليس بالضرورة شخصًا فقط؛ فقد يكون مستخدمًا، مديرًا، نظامًا خارجيًا أو خدمة أخرى تتفاعل مع النظام.
وعند كتابة Use Case جيدة، نحتاج إلى معرفة:
Actor: من يتفاعل مع النظام؟
Goal: ما الهدف الذي يريد تحقيقه؟
Preconditions: ما الشروط المطلوبة قبل بدء العملية؟
Main Flow: ما المسار الطبيعي للسيناريو؟
Alternative / Exception Flow: ماذا يحدث عند وجود مسار بديل أو خطأ؟
Postconditions: ما حالة النظام بعد انتهاء العملية؟
خذ تسجيل الدخول مثالًا.
الهدف ليس شرح Authentication API أو Database Query أو طريقة إنشاء Token.
الهدف هو وصف تفاعل المستخدم:
يدخل المستخدم بياناته، يتحقق النظام منها، وإذا كانت صحيحة يسمح له بالدخول.
وإذا كانت البيانات خاطئة، يجب أن تصف الـUse Case هذا السيناريو أيضًا: يرفض النظام تسجيل الدخول، يعرض رسالة مناسبة، ويسمح للمستخدم بالمحاولة مرة أخرى.
وهذه نقطة مهمة:
Use Case الجيدة لا تصف طريق النجاح فقط.
بل تساعدنا على التفكير في السيناريوهات البديلة والاستثناءات التي قد تحدث أثناء استخدام النظام.
لذلك لا تكتب الـUse Case من منظور المبرمج وتسأل:
كيف سننفذ هذه الوظيفة؟
اكتبها من منظور المستخدم واسأل:
من يريد ماذا من النظام، وما السيناريو الذي يوصله إلى هدفه؟
عندما تكون Use Cases واضحة، يصبح فهم المتطلبات وتحليل النظام وتصميمه واختباره أسهل على الفريق.
تحدي بسيط:
في تطبيق بنكي، يريد العميل تحويل مبلغ مالي إلى حساب آخر.
من هو الـ Actor؟
ما هو الـ Goal؟
وما أول 3 خطوات تتوقعها في الـ Main Flow؟
اكتب السيناريو في التعليقات.
المنشور القادم #008 — User Stories
كيف نحول احتياجات المستخدم إلى قصص قصيرة وواضحة؟
م. طارق العمري
Software Engineer | Backend Developer
#SoftwareEngineering #UseCases #UML #RequirementsEngineering #Requirements #SystemAnalysis #SystemDesign #SoftwareArchitecture #BusinessAnalysis #SoftwareDevelopment #BackendDevelopment #SoftwareEngineer #UserStories #هندسة_البرمجيات #تحليل_النظم #حالات_الاستخدام #تطوير_البرمجيات
❤1