ما هيكل وثيقة المواصفات الوظيفية (FSD)؟

ما هي وثيقة FSD؟

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

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

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

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

ما هي وثيقتا BRD و FSD؟

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

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

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

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

وفي الأنظمة المعقّدة تتعدّد الوثائق، إذ يشير دليل SWEBOK إلى أن ما يصل إلى 3 أنواع من وثائق المتطلبات يُعدّ لهذه الأنظمة: تعريف النظام، ومتطلبات النظام، ومتطلبات البرمجيات.

كيف تبدو وثيقة المتطلبات الوظيفية؟

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

وتشكّل حالات الاستخدام جوهر هذا الهيكل. ويعرّف Ivar Jacobson و Ian Spence حالة الاستخدام بأنها جميع طرق استخدام النظام لتحقيق هدف معيّن لمستخدم معيّن. وفي السرد النصّي لحالة الاستخدام، يصف المسار الأساسي أبسط طريقة لتحقيق الهدف، وتُعرض الطرق الأخرى بوصفها مسارات بديلة.

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

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

من يُعدّ وثيقة BRD؟

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

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

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

ولأن فريقنا يتولّى الكتابة، لا يحتاج مديرو الإدارات لديكم إلا إلى شرح طريقة عملهم ومشاركة نماذج من ملفّاتهم. وبهذا النهج التشاركي تأتي الوثائق الناتجة مطابقة للعمليات الفعلية في شركتكم، لا لافتراضات تقنية مجرّدة.

كيف تحمي المواصفة المتّفق عليها الجدول الزمني لمشروعكم؟

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

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

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

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

كيف تندرج متطلبات الأمان والبنية في المواصفة؟

لا تقف وثيقة المواصفات الوظيفية الكاملة عند الأزرار الظاهرة على الشاشة، بل تتناول أيضاً أمن التشغيل وقدرة النظام على الصمود.

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

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

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

كم تستغرق مرحلة تحديد المتطلبات عادةً؟

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

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

وعند التسليم تتسلّمون الشيفرة المصدرية والوثائق الفنية والاختبارات وكل بيانات الدخول. فلا ارتهان للمورّد (Vendor Lock-in)، وتحتفظ مؤسّستكم بالملكية الكاملة لجميع حقوق الملكية الفكرية التقنية بعد انتهاء التطوير.

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

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

أبرز النقاط

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

المصادر

1. وثائق مواصفات المتطلبات: تعريف النظام ومتطلبات النظام ومتطلبات البرمجيات (دليل SWEBOK) (swebokwiki.org)
2. استنباط المتطلبات وعملية المتطلبات (دليل SWEBOK) (swebokwiki.org)
3. حالات الاستخدام والمسارات والقصص في منهجية Use-Case 2.0 (ivarjacobson.com)
4. مخطّطات حالات الاستخدام في نمذجة المتطلبات (دليل SWEBOK) (swebokwiki.org)