#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 #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات
#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 #هندسة_البرمجيات #تحليل_النظم #تطوير_البرمجيات