الفرق بين BRD و SRS و SDD: أيّ وثيقة يحتاجها مشروعكم فعلاً؟

هل تحتاجون إلى BRD و SRS و SDD، أم تكفي وثيقة واحدة؟

يتكرّر هذا السؤال كثيراً لدى فرق العمل في دبي وسائر الإمارات: هل نحتاج فعلاً إلى BRD و SRS و SDD، أم تكفي وثيقة واحدة؟ والجواب الصريح أن الوثائق الثلاث لا يحلّ بعضها محلّ بعض، فلكل منها سؤالها وقارئها وتوقيتها في المشروع. وحين تُعامل الثلاث كأنها وثيقة واحدة، ينحرف النطاق دون أن يلاحظ أحد، وينتهي المشروع إلى أن يحلّ بإتقان مشكلة غير المشكلة الحقيقية.

نعرض هنا الغرض من كل وثيقة، وكيف تترابط الثلاث، وأيّها يحتاجه مشروعكم فعلاً.

ما هي وثيقة متطلبات الأعمال (BRD) وماذا تتضمّن؟

تبقى وثيقة BRD على مستوى الأعمال لا على مستوى البرمجيات. فهي تحدّد الأهداف، والنتيجة التي تموّل المؤسّسة المشروع لتحقيقها، والقيود التي يجب أن يلتزم بها الحلّ. وفي اصطلاح تحليل الأعمال، تجيب متطلبات الأعمال عن سؤال «ماذا» وتتوقّف عمداً قبل سؤال «كيف»، إذ لا تتفرّع إلى متطلبات منتج أو نظام أو برمجيات تصف طريقة التنفيذ [5].

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

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

ما هي وثيقة مواصفات متطلبات البرمجيات (SRS) وماذا تضيف؟

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

ولا يُترك شكل هذه الوثيقة للاجتهاد. فقد صاغ معهد IEEE غرض وثيقة SRS ومحتواها صياغةً رسمية لأوّل مرّة في المعيار IEEE 830، ثم حلّ محلّه المعيار الدولي ISO/IEC/IEEE 29148 عام 2011 [1][2]. والعمل وفق معيار 29148 هو ما يتيح فحص كل متطلب من حيث صفات كالاكتمال والاتّساق وقابلية التحقّق، بدل أن يبقى أمنية مبهمة يقرؤها فريقان قراءتين مختلفتين.

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

ما الغرض من وثيقة تصميم البرمجيات (SDD)؟

إذا كانت وثيقة SRS تجيب عن «ماذا»، فوثيقة SDD تجيب عن «كيف». وتُعرّف وثيقة تصميم البرمجيات بأنها تمثيل لتصميم برمجي يُستخدم لتسجيل معلومات التصميم، ومعالجة الاعتبارات التصميمية المختلفة، وإيصال هذه المعلومات إلى أصحاب المصلحة في التصميم [3]. وفيها تُكتب بنية النظام ونماذج البيانات وحدود المكوّنات ونقاط التكامل قبل الشروع في تطويرها.

ولشكل هذه الوثيقة أيضاً معيار يستند إليه، إذ يحدّد المعيار IEEE 1016-2009 المعلومات التي تتضمّنها وثيقة تصميم البرمجيات وطريقة تنظيمها [3][4]. ووثيقة SDD المحكمة هي ما يتيح لمهندس آخر فهم النظام دون أن يضطرّ إلى استنتاجه من الشيفرة بالهندسة العكسية، وهي ما يجعل انتقال مشروع مؤسّسي معقّد بين فرق العمل، أو صيانته بعد سنوات، أمراً آمناً.

ما وثيقة المتطلبات الوظيفية (FRD)، وما الفرق بينها وبين SRS؟

تسرد وثيقة المتطلبات الوظيفية (FRD) ما يجب أن يفعله النظام، وظيفةً وظيفة. وأوّل ما يربك فيها اسمها، إذ تتنقّل الوثيقة نفسها بين أربعة مسمّيات على الأقلّ: فالمواصفة الوظيفية، وتُسمّى أيضاً وثيقة المواصفات الوظيفية (FSD) أو مواصفة المتطلبات الوظيفية، وثيقة تحدّد الوظائف التي يجب أن يؤدّيها نظام أو مكوّن، وكثيراً ما تكون جزءاً من مواصفة المتطلبات [6]. وللمجال معجم موحّد لهذا الغرض هو المعيار ISO/IEC/IEEE 24765، الذي يوفّر مفردات مشتركة تنطبق على كل أعمال هندسة النظم والبرمجيات، وقد أُعدّ لجمع المصطلحات وتوحيدها [12]. فإذا طلب منكم عميل وثيقة FRD أو FSD أو FRS، فهو يطلب الشيء نفسه.

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

وتقف وثيقة FRD أيضاً عند حدّ وثيقة SDD. ففي دورة الحياة الشلّالية المتسلسلة، تصف المواصفة الوظيفية ما يجب تنفيذه، ثم تأتي وثيقة بنية النظام لتصف كيف ستُحقَّق الوظائف ضمن بيئة برمجية مختارة [7]. وهو الحدّ نفسه الذي تقف عنده SRS من جهة و SDD من جهة أخرى. فإن بدأت وثيقة FRD لديكم تسمّي جداول قواعد البيانات وبنية طوابير الرسائل، فقد خرجت عن كونها FRD.

أين تقع وثيقة متطلبات المنتج (PRD)، وهل تحتاجونها؟

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

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

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

ما الفرق بين PRD و SRS؟

تصف وثيقة PRD ما ينبغي أن يفعله المنتج من وجهة نظر المستخدم، وتترك عمداً سؤال «كيف» مفتوحاً [10]. أما وثيقة SRS فتحدّد المتطلبات الوظيفية وغير الوظيفية التي يجب أن تستوفيها البرمجيات [8]، بدقّة تكفي للتطوير والاختبار على أساسها.

وتقع الوثيقتان في موضعين مختلفين من السلسلة. فوثيقة PRD تأتي عادةً أولاً، وتكتبها إدارة المنتج أو التسويق أو العميل، ثم يحلّلها المطوّر من منظور تقني ويفصّلها في مواصفة [11]. فقد تنصّ PRD على أن يتمكّن العميل من الدفع بالبطاقة عبر التطبيق، ثم تحوّل SRS ذلك إلى وظائف الدفع وهدف زمن الاستجابة ومتطلبات الأمان التي يستطيع المختبِر فحصها بنداً بنداً.

كيف تترابط هذه الوثائق، وما الفرق بين SRS و SDD؟

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

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

وتنضمّ الوثيقتان الإضافيتان إلى السلسلة نفسها ولا تتفرّعان عنها. فوثيقة PRD تقف إلى جانب BRD في أعلى السلسلة، وتصف المنتج فيما تصف BRD النتيجة التي تريدها المؤسّسة. أما وثيقة FRD فتندرج ضمن SRS وتضمّ المتطلبات الوظيفية، فيما تشمل SRS المتطلبات غير الوظيفية أيضاً. ويبقى اتّجاه المسار كما هو: غاية الأعمال، ثم السلوك المطلوب، ثم التصميم.

أيّ الوثائق يحتاجها مشروعكم فعلاً؟

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

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

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

أبرز النقاط

• وثيقة BRD تخصّ الأعمال: تبيّن سبب وجود المشروع والنتيجة التي يجب أن يحقّقها، لا طريقة تطويره.
• وثيقة SRS هي العقد القابل للاختبار الذي يحدّد ما يجب أن تفعله البرمجيات، ويُستحسن أن تُكتب وفق معيار ISO/IEC/IEEE 29148.
• وثيقة SDD تُكتب وفق معيار IEEE 1016 وتسجّل كيف سيُنفّذ النظام تقنياً، ليبقى التصميم مفهوماً ويسهل انتقاله من فريق إلى آخر.
• ترتبط الوثائق الثلاث في سلسلة تتبّع واحدة: التصميم يلبّي المتطلبات، والمتطلبات تخدم أهداف الأعمال.
• إذا كان النظام سيطوّره أكثر من فريق، أو سيتكامل مع أنظمة لا تتحكّمون فيها، أو سيخضع للتدقيق، فاكتبوا الوثائق الثلاث.
• وثيقة FRD (وتُسمّى أيضاً FSD أو FRS) هي الشقّ الوظيفي من وثيقة SRS، ووثيقة PRD هي نظيرة BRD من جانب المنتج، ولا تحتاج معظم الفرق إلا إلى وثيقة واحدة لكل مستوى، لا إلى الوثائق الخمس.

المصادر

1. Software requirements specification (en.wikipedia.org)
2. ISO/IEC/IEEE 29148 - Systems and software engineering - Life cycle processes - Requirements engineering (standards.ieee.org)
3. Software design description (en.wikipedia.org)
4. IEEE 1016-2009 - IEEE Standard for Information Technology: Systems Design: Software Design Descriptions (standards.ieee.org)
5. Business requirements (en.wikipedia.org)
6. Functional specification (en.wikipedia.org)
7. Functional specification (en.wikipedia.org)
8. Software requirements specification (en.wikipedia.org)
9. Business requirements (en.wikipedia.org)
10. Product requirements document (en.wikipedia.org)
11. Product requirements document (en.wikipedia.org)
12. ISO/IEC/IEEE 24765 - Systems and software engineering - Vocabulary (standards.ieee.org)