مثال على وثيقة متطلبات الأعمال (BRD) ودليل إعدادها

ما وثيقتا BRD و FRD، مع مثال عليهما؟

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

ولنأخذ مثالاً واقعياً على وثيقة متطلبات أعمال لشركة تعمل في النجارة التجارية وأعمال التجهيز الداخلي. ففي وثيقة BRD هذه، يسجّل الملخّص التنفيذي أن مشرفي المواقع يخسرون ساعات عمل قابلة للفوترة في المطابقة اليدوية بين طلبات الأخشاب وقوائم القصّ في الورشة. أما القسم المقابل في وثيقة المتطلبات الوظيفية (FRD) فيحدّد صلاحيات الأدوار لمقدّري التكاليف في الورشة، وقواعد التحقّق من أبعاد الألواح الخام، واستعلامات مؤتمتة في قاعدة البيانات على قوائم أسعار المورّدين المحدّثة.

ونتولّى إعداد مواصفات النطاق ونقدّمها لكم لتعتمدوها كتابةً قبل بدء التطوير، فيثبت السعر الإجمالي للمشروع. وتعتمدون هذا النطاق الوظيفي المكتوب قبل أن نكتب أي شيفرة للإنتاج. ومواءمة النتيجة التجارية في وثيقة BRD مع منطق البرمجيات في وثيقة FRD تمنح قيادتكم يقيناً تامّاً بما سيطوّره المهندسون.

ونتّفق معكم على وثائق BRD و SRS و SDD قبل بدء العمل الهندسي، فهي لا تُعدّ لاستخدامنا الداخلي. والوثائق المنظّمة تُبقي الأهداف التجارية محميّة طوال التطوير.

كيف يبدو هيكل وثيقة متطلبات الأعمال في مثال عملي؟

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

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

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

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

كيف تُكتب وثيقة متطلبات الأعمال (BRD)؟

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

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

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

هل من مثال على متطلب من متطلبات الأعمال؟

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

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

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

هل من مثال على حاجة من حاجات الأعمال؟

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

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

وتُعرف وثيقة تعريف النظام أحياناً بوثيقة متطلبات المستخدم أو وثيقة مفهوم العمليات، وهي تحدّد متطلبات النظام عالية المستوى من منظور المجال. وتوضيح ما يقع خارج النطاق لا يقلّ أهمية عن تحديد الوظائف الأساسية، فهو ما يُبقي جداول التسليم قابلة للتوقّع.

كيف يحمي النطاق الوظيفي الواضح ميزانيتكم؟

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

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

وتحدّد وثيقة مواصفات متطلبات البرمجيات (SRS) التي نُعدّها المتطلبات الوظيفية وغير الوظيفية، مستندةً إلى معيار ISO/IEC/IEEE 29148. ويجعل هذا المعيار الدولي كل متطلب كاملاً ومتّسقاً وقابلاً للتحقّق قبل بدء العمل الهندسي. ويمكنكم التعرّف على المزيد في أدلّتنا حول هندسة المتطلبات، وكيف تمنع الوثائق المنضبطة إخفاقات التسليم في بيئات المؤسّسات المعقّدة.

كيف نحمي أمن النظام ونؤمّن تسليم البيانات؟

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

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

وعند التسليم تتسلّمون الشيفرة المصدرية والوثائق الفنية والاختبارات وكل بيانات الدخول. ولا ارتهان للمورّد (Vendor Lock-in)، إذ يمكنكم الاستعانة بفريق آخر لاحقاً. ونحن فريق محلّي مقرّه دبي، ونعمل بالعربية والإنجليزية.

يندرج هذا المقال ضمن عملنا في هندسة المتطلبات وتحليل الأعمال، ويعكس منهجية التخطيط التي تقوم عليها طريقة عملنا.

أبرز النقاط

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

المصادر

1. فئات المتطلبات الأربع في مخطّط التصنيف الوارد في دليل BABOK (iiba.org)
2. وثائق مواصفات المتطلبات: تعريف النظام ومتطلبات النظام ومتطلبات البرمجيات (دليل SWEBOK) (swebokwiki.org)