لكي لا تنسى تحديد «كم ثانية يجب أن يستغرق التشغيل حتى يكون مُرضياً» ── تنظيم المتطلبات غير الوظيفية باستخدام «درجة المتطلبات غير الوظيفية» الصادرة عن IPA

«قيل لنا إنّ الانتقال بين الشاشات بطيء، لكن لا يوجد في العقد ولا في المواصفات أيّ اتفاق على زمن الاستجابة.»

«توقفت المعالجة الدفعية الليلية عن الانتهاء بحلول الصباح، لكن لم يُقدِّر أحد كم ستزداد البيانات على مدى كم سنة.»

«لم ندرك إلا بعد توقف الخادم نصف يوم بسبب عطل أننا لم نتحقق عند الطلب من “خلال كم ساعة يمكن للبنية أن تستعيد العمل”.»

حين نفكر في مشكلات تطوير الأنظمة، يتبادر إلى الذهن اختلاف الفهم حول الوظائف، لكن ما يثير الخلاف فعلياً بعد بدء التشغيل ليس قليلاً هو نسيان تحديد هذه المتطلبات غير الوظيفية، أي ما يُعرف بالمتطلبات خارج نطاق الوظائف.

والأداة الرسمية لمنع هذا النسيان هي درجة المتطلبات غير الوظيفية الصادرة عن IPA (الهيئة المستقلة لترويج تقنية المعلومات). في هذا المقال، ننظّم محتواها وطريقة استخدامها الواقعية في أنظمة الأعمال بالشركات الصغيرة والمتوسطة، بلغة يفهمها الجانب الطالب أيضاً.

1. الخلاصة أوّلاً

• المتطلبات غير الوظيفية هي متطلبات «بأي جودة وشروط يعمل النظام»، وليست «ما الذي يفعله». يمكن تنظيمها في ستة مجالات: التوفر، والأداء، والتشغيل، والترحيل، والأمان، وبيئة التركيب
• درجة المتطلبات غير الوظيفية هي مجموعة أدوات (مجانية) من IPA تُدرِج عناصر المتطلبات في هذه المجالات الستة إدراجاً شاملاً في قائمة، لمواءمتها بين الجانب الطالب والجانب المطوِّر عبر مستويات تدريجية
• لا حاجة لملء كل العناصر. الاستخدام المتصوَّر هو اختيار «نظام نموذجي» قريب من شركتك، ثم الضبط بدءاً من العناصر المهمة تباعاً بما يلائم واقع شركتك
• كلما رُفِع مستوى المتطلبات غير الوظيفية، ازدادت التكلفة. لا يُطلَب مستوى مرتفع «بشكل غامض»، بل يُختار المستوى بالعمل عكسياً انطلاقاً من أثره على العمل
• تُحفَظ نتيجة القرار في وثيقة تعريف المتطلبات. فالفرضيات المحدَّدة هنا مفيدة في مقارنة عروض الأسعار، وفي منع جدال «هل قلت هذا أم لا» بعد بدء التشغيل

2. ما هي المتطلبات غير الوظيفية ── ما يقع بين «يعمل» و«صالح للاستخدام»

المتطلبات الوظيفية هي متطلبات ما يفعله النظام، مثل «يمكن تسجيل الطلبات» أو «يمكن طباعة التقارير». وتتركز اجتماعات التطوير طبيعياً حول هذا الموضوع.

في المقابل، لا تظهر الأسئلة التالية في قائمة الوظائف.

• من أيّ ساعة إلى أيّ ساعة ينبغي أن يعمل هذا النظام؟ وماذا عن أيام السبت والأحد؟ وأثناء المعالجة الدفعية الليلية؟
• عند التوقف بسبب عطل، خلال كم ساعة يجب الاستعادة حتى لا يتعطل سير العمل؟ وإلى أيّ نقطة زمنية من البيانات يُقبَل الرجوع؟
• كم شخصاً يستخدم النظام في الوقت نفسه، وكم عملية يُعالِج يومياً؟ وكم سيزداد حجم البيانات بعد خمس سنوات؟
• من الذي يراقب النظام، ويأخذ النسخ الاحتياطية، ويستقبل أوّل إبلاغ عن الأعطال؟
• إلى أيّ مدى تُنقَل بيانات النظام القديم إلى النظام الجديد؟

هذه هي المتطلبات غير الوظيفية. والمزعج فيها أنّ النظام «يعمل» على أيّ حال حتى لو لم تُحدَّد. تظهر المشكلة على السطح فقط عندما يبدأ التشغيل، ويزداد الحمل، ويقع عطل. وفي تلك المرحلة، بما أنّ الأمر يمس جوهر بنية الخادم والتصميم، يصبح الإصلاح مكلفاً للغاية.

3. ما هي درجة المتطلبات غير الوظيفية

درجة المتطلبات غير الوظيفية هي مجموعة أدوات تنشرها IPA بهدف منع اختلاف الفهم بين الجانب الطالب والجانب المطوِّر حول المتطلبات غير الوظيفية. نُشِر الإصدار الأوّل في أبريل 2010، والإصدار الأحدث حالياً هو «درجة المتطلبات غير الوظيفية 2018» (الصادر في أبريل 2018) الذي يعكس التغيرات في مجالَي الأمان والمحاكاة الافتراضية (السحابة). وهي موضوعة حالياً في صفحة مصنَّفة كأرشيف على موقع IPA، لكنها لا تزال تُستخدَم في العمل الفعلي كمعيار أساسي للتحقق من عدم إغفال المتطلبات غير الوظيفية.

يتكون محتواها من الأدوات التالية:

لكل مقياس خيارات مستويات متدرجة مُعرَّفة مسبقاً، وميزة ذلك أنّه يمكن التعبير عن المتطلب باختيار مستوى، بدل ألفاظ غامضة مثل «مرتفع/منخفض».

الأنظمة النموذجية الثلاثة

سمة أخرى هي الأنظمة النموذجية الثلاثة المقسَّمة بحسب حجم الأثر المجتمعي عند توقف النظام.

• نظام ليس له أثر مجتمعي يُذكَر تقريباً
• نظام ذو أثر مجتمعي محدود (مثل الأنظمة الأساسية للشركات)
• نظام ذو أثر مجتمعي كبير للغاية (مثل البنية التحتية المجتمعية)

المستوى التقريبي لكل نموذج مُدوَّن مسبقاً في جدول الدرجات. بمعنى آخر، لا حاجة لبدء النقاش من الصفر، بل يمكن استخدامه بتقدير «شركتنا أقرب إلى هذا النموذج» ثم الرفع أو الخفض بما يلائم الواقع.

4. العناصر الرئيسية الستة ── ترجمتها إلى لغة الجانب الطالب

إذا استُبدِلت العناصر الرئيسية الستة لدرجة المتطلبات غير الوظيفية بأسئلة يستطيع الجانب الطالب الإجابة عنها، تصبح كالتالي.

بالنظر إلى هذا، يتضح أنّ معظم العناصر الرئيسية الستة أسئلة عن العمل وليست أسئلة تقنية. فمن يستطيع الإجابة عن «ماذا يحدث إذا تأخرت معالجة فواتير نهاية الشهر نصف يوم» هو الجانب الطالب، لا شركة التطوير. زمام المبادرة في المتطلبات غير الوظيفية، في الواقع، بيد الجانب الطالب.

5. الاستخدام الواقعي ── لا تحاول ملء العناصر الـ238

تضم قائمة العناصر 238 مقياساً، لكن مناقشتها كلها واحداً تلو الآخر ليس واقعياً في مشاريع الشركات الصغيرة والمتوسطة، ولم يُتصوَّر هذا الاستخدام حتى في دليل الاستخدام. التدفق المتصوَّر هو كالتالي.

1. اختيار النظام النموذجي
   (إلى أيّ درجة تأثير يقترب نظام شركتك)
        ↓
2. بالنسبة للعناصر المهمة في جدول الدرجات،
   يُضبَط المستوى التقريبي للنموذج انطلاقاً منه بما يلائم واقع الشركة
        ↓
3. يُفصَّل في قائمة العناصر الجزء اللازم فقط

بالنسبة لتطبيقات الأعمال في الشركات الصغيرة والمتوسطة، فإنّ الخطوة 2 وحدها، أي «مواءمة العناصر المهمة»، كافية لتحقيق أثر جيد. من واقع الخبرة، يُنصَح بتوثيق النقاط التالية على الأقل في تعريف المتطلبات.

• أوقات التشغيل، وأثر التوقف على العمل (التوفر)
• الفاصل الزمني لأخذ النسخ الاحتياطية، و«إلى أيّ نقطة زمنية من البيانات» و«خلال كم ساعة» تتم الاستعادة عند العطل (التوفر والتشغيل)
• حجم البيانات وعددها حالياً، والتوقعات بعد عدة سنوات (الأداء وقابلية التوسع)
• القيمة المستهدَفة لزمن الاستجابة أو زمن المعالجة الدفعية. يكفي تحديد معيار ولو كان «مساوياً للنظام الحالي أو أفضل منه» (الأداء)
• توزيع مهام المراقبة والنسخ الاحتياطي والتعامل الأوّلي مع الأعطال (قابلية التشغيل والصيانة)

ولا ينبغي أن يُنسى هنا التبادل بين المستوى والتكلفة. فإذا استُهدِف مثلاً «نظام لا يتوقف مطلقاً»، تقفز التكلفة بسبب تكرار الخوادم (redundancy) ونظام المراقبة. وإذا أمكن الحكم بأنّ «الاستعادة خلال نفس اليوم كافية إن كان بإمكان العمل الانتظار حتى صباح اليوم التالي»، يمكن تحويل ذلك الفارق إلى جهة أخرى. المسافة الصحيحة للتعامل مع مستويات درجة المتطلبات غير الوظيفية هي استخدامها لغةً مشتركة للتباحث حول التوازن بين أثر العمل والتكلفة، لا أداة لرفع المتطلبات.

6. العلاقة بالعقد وعروض الأسعار

ترتبط المتطلبات غير الوظيفية ارتباطاً مباشراً بالعقد أيضاً.

أوّلاً، مقارنة عروض الأسعار. فإذا طُلِبت عروض أسعار من عدة شركات دون توحيد الفرضيات غير الوظيفية، فقد تُقدِّم الشركة (أ) عرضها بناءً على بنية مكررة (redundant)، بينما تُقدِّم الشركة (ب) عرضها بناءً على خادم واحد فقط. عندها يصبح من المستحيل على الجانب الطالب تمييز ما إذا كان فارق المبلغ ناتجاً عن اختلاف البنية أم عن تقدير متساهل.

ثم مرحلة القبول وما بعد بدء التشغيل. فإذا كانت الاتفاقات المتعلقة بزمن الاستجابة والنسخ الاحتياطي موثَّقة، يتحول الجدال العقيم من نوع «بطيء» أو «لم يكن متوقَّعاً» إلى تحقّق من واقعة بالقياس إلى معيار محدَّد.

وفي «العقد النموذجي لمعاملات نظم المعلومات» الصادر عن IPA أيضاً، يُفترَض توثيق المتطلبات غير الوظيفية كمُخرَج لمرحلة تعريف المتطلبات. ويمكن إدماج درجة المتطلبات غير الوظيفية بشكل طبيعي ضمن تدفق التعاقد متعدد المراحل، الذي يُنفَّذ فيه تعريف المتطلبات بعقد شبه تفويض، ثم يُتعاقَد على التطوير بعقد مقاولة بناءً على المحتوى المحدَّد. للاطلاع على شكل العقد، راجع مقال شرح «العقد النموذجي» الصادر عن IPA.

الخلاصة

نلخّص أهم نقاط «درجة المتطلبات غير الوظيفية» الصادرة عن IPA.

• المتطلبات غير الوظيفية هي متطلبات «بأي جودة وشروط يعمل النظام». يعمل النظام حتى دون تحديدها، لكن المشكلة تظهر على السطح وتثير الخلاف بعد بدء التشغيل
• درجة المتطلبات غير الوظيفية هي مجموعة أدوات مجانية من IPA تُواءِم العناصر الرئيسية الستة (التوفر، والأداء وقابلية التوسع، والتشغيل وقابلية الصيانة، وقابلية الترحيل، والأمان، وبيئة النظام) والمقاييس الـ238 عبر مستويات تدريجية
• يُضبَط الأمر بدءاً من العناصر المهمة، انطلاقاً من المستوى التقريبي للأنظمة النموذجية الثلاثة. لا حاجة لملء كل العناصر
• محتوى العناصر الرئيسية الستة في معظمه أسئلة عن العمل. ومن يملك الإجابة هو الجانب الطالب
• كلما رُفِع المستوى، ازدادت التكلفة. يُختار التوازن بالعمل عكسياً انطلاقاً من أثره على العمل، وتُحفَظ النتيجة في وثيقة تعريف المتطلبات

تحديد «بأي جودة سيستمر النظام في العمل» مسبقاً، بأهمية تحديد «ما الذي سيُصنَع» تماماً. هذا هو أرخص سبيل لمنع نظام يعمل لكنه غير قابل للاستخدام، ومنع الخلافات التي تليه.

لمن يواجه صعوبة في تنظيم متطلبات نظام الأعمال

تتطلب مواءمة المتطلبات غير الوظيفية عملاً يتنقل بين واقع العمل (فترات الذروة، وحجم البيانات، وأثر التوقف) وبنية النظام التي تحقق ذلك الواقع.

في شركة كومورا سوفت ذ.م.م.، عند استقبال استشارات التطوير الخارجي والتعديل لتطبيقات Windows للأعمال وأنظمة الويب، نساعد على تنظيم الأداء والتشغيل والسلوك عند حدوث الأعطال في مرحلة المتطلبات، وفق الفكرة المعروضة في هذا المقال. ويمكنكم التواصل معنا حتى من مرحلة مثل «معالجة النظام الحالي أصبحت أبطأ تدريجياً» أو «نريد إعادة النظر في اتفاقات التشغيل بمناسبة التحديث».

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما هي المتطلبات غير الوظيفية؟

هي المتطلبات المتعلقة بـ«بأي جودة وشروط يعمل النظام»، بخلاف «ما الذي يفعله» النظام (المتطلبات الوظيفية). ومن أمثلتها: متى يجب أن يكون النظام متاحاً للاستخدام (التوفر)، وكم شخصاً يستخدمه وفي كم ثانية يستجيب (الأداء وقابلية التوسع)، ومن يتولى تشغيله وصيانته وكيف (قابلية التشغيل والصيانة)، وكيف تُنقَل البيانات من النظام القديم (قابلية الترحيل)، وما أنواع الحماية المطلوبة (الأمان)، وفي أيّ بيئة يُركَّب (بيئة النظام). وإذا نُسِي تحديدها، يميل النظام إلى أن يكون «يعمل لكنه غير قابل للاستخدام فعلياً».

هل يمكن استخدام درجة المتطلبات غير الوظيفية مجاناً؟ وأين يمكن الحصول عليها؟

يمكن تنزيلها مجاناً من موقع IPA الإلكتروني. تأتي مجموعة تضم جدول الدرجات وقائمة العناصر والمخطط الشجري وورقة الاستخدام مع دليل الاستخدام (قسم الشرح، وقسم الاستخدام، وقسم التطبيق)، وأحدث إصدار هو «درجة المتطلبات غير الوظيفية 2018» الصادر في أبريل 2018. توجد حالياً في صفحة مصنَّفة كأرشيف على موقع IPA، لكنها لا تزال تُستخدَم على نطاق واسع في العمل الفعلي كمعيار للتحقق من عدم إغفال المتطلبات غير الوظيفية.

هل يجب تحديد كل العناصر الـ238؟

لا. لم يُتصوَّر حتى في دليل الاستخدام مناقشة جميع المقاييس واحداً تلو الآخر. الطريقة المعروضة هي استخدام تدريجي: يُختار أوّلاً نظام نموذجي قريب من شركتك لتحديد تقدير عام، ثم تُضبَط العناصر المهمة في جدول الدرجات بما يلائم واقع شركتك، ثم يُفصَّل في قائمة العناصر النطاق اللازم فقط. وبالنسبة لأنظمة الأعمال في الشركات الصغيرة والمتوسطة، فإنّ مجرد مواءمة العناصر المهمة وحدها يمنع معظم «الخلافات الناتجة عن نسيان التحديد».

متى ينبغي تحديد المتطلبات غير الوظيفية؟

في مرحلة تعريف المتطلبات. لأنّ أهداف التوفر والأداء ترتبط بجوهر بنية الخادم والتصميم، فإنّ تغييرها بعد تقدّم التطوير يؤثر بشكل كبير في التكلفة والمدة. وفي «العقد النموذجي لمعاملات نظم المعلومات» الصادر عن IPA أيضاً، يُفترَض توثيق المتطلبات غير الوظيفية إلى جانب المتطلبات الوظيفية كمُخرَج لمرحلة تعريف المتطلبات. وإذا لم تُوحَّد فرضيات الجانب غير الوظيفي عند مقارنة عروض الأسعار، يصبح من المستحيل الحكم على ما إذا كان اختلاف المبالغ ناتجاً عن اختلاف البنية أم عن تقدير متساهل.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.