ما هي وثيقة SRS ووثيقة FRS؟

ما هي وثيقتا FRS و SRS؟

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

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

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

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

ما هي وثيقة SRS؟

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

وواصلت معايير القطاع تطوّرها منذ أواخر التسعينيات. فقد حلّ المعيار ISO/IEC/IEEE 29148:2011 محلّ IEEE 830-1998، ثم صدرت الطبعة الثانية من ISO/IEC/IEEE 29148 في نوفمبر 2018، لتقدّم مبادئ حديثة لهندسة المتطلبات على امتداد دورة حياة البرمجيات كاملة.

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

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

ما المسمّيات الكاملة لاختصارات BRD و FRS و SRS؟

تتكرّر في مشاريع البرمجيات ثلاثة اختصارات أساسية: فـ BRD اختصار Business Requirements Document، أي وثيقة متطلبات الأعمال، و FRS اختصار Functional Requirements Specification، أي مواصفة المتطلبات الوظيفية، و SRS اختصار Software Requirements Specification، أي مواصفة متطلبات البرمجيات. ويمثّل كل منها مستوى محدّداً من التفصيل في تخطيط الأنظمة البرمجية.

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

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

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

ما الغرض من وثيقة SRS؟

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

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

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

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

نسبة 47 في المئة: وجدت دراسة Pulse of the Profession الصادرة عن معهد إدارة المشاريع (PMI) أن 47 في المئة من المشاريع غير الناجحة تُخفق في بلوغ أهدافها بسبب عدم دقّة إدارة المتطلبات.

لماذا تُخفق مشاريع البرمجيات في غياب مواصفات مكتوبة؟

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

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

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

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

كيف نجمع المتطلبات وننظّمها قبل التطوير؟

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

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

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

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

ما المعايير وإجراءات الحماية التي تحكم المواصفة الاحترافية؟

تتبع المواصفة الموثوقة معايير دولية معترفاً بها. وقد صدرت الطبعة الثانية من ISO/IEC/IEEE 29148 في نوفمبر 2018، وهي تحدّد عمليات حديثة لهندسة المتطلبات.

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

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

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

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

أبرز النقاط

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

المصادر

1. وثائق مواصفات المتطلبات: تعريف النظام ومتطلبات النظام ومتطلبات البرمجيات (دليل SWEBOK) (swebokwiki.org)
2. IEEE 830-1998: الممارسة الموصى بها لمواصفات متطلبات البرمجيات (standards.ieee.org)
3. استنباط المتطلبات وعملية المتطلبات (دليل SWEBOK) (swebokwiki.org)
4. معيار ISO/IEC/IEEE 29148 لهندسة المتطلبات (iso.org)
5. إدارة المتطلبات وإخفاق المشاريع: دراسة Pulse of the Profession (pmi.org)
6. مخطّطات حالات الاستخدام في نمذجة المتطلبات (دليل SWEBOK) (swebokwiki.org)
7. فئات المتطلبات الأربع في تصنيف دليل BABOK (iiba.org)