كتابة وثيقة متطلبات البرمجيات: 7 خطوات ونموذج

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

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

ما الغرض من وثيقة متطلبات البرمجيات

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

تؤدي هذه الوثيقة ثلاث مهام:

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

وفي مشروع بسعر ثابت، تصبح أيضاً أساس السعر: كلما كانت أوضح، كان عرض السعر أكثر موثوقية، كما نشرح في مقالنا عن تكلفة البرمجيات المخصصة.

كيف تكتبون وثيقة المتطلبات في 7 خطوات

1. انطلقوا من المشكلة، لا من الحل

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

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

2. صِفوا طريقة العمل الحالية

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

وتعقّبوا الاستثناءات: فالجمل التي تبدأ بعبارة «إلا إذا…» كثيراً ما تخفي أهم قواعد العمل.

3. حددوا المستخدمين وأدوارهم

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

تؤثر هذه الإجابات تأثيراً كبيراً في التصميم. ففي نظام إدارة علاقات العملاء وتخطيط موارد المؤسسات (CRM/ERP) لمكتب محاماة في سيدني، وهو مشروع قاده مؤسسنا، أفضت إلى خيارين هيكليين: صلاحيات وصول تختلف حسب دور كل شخص، وتطبيقات على سطح المكتب و iOS و Android.

4. اكتبوا المتطلبات في صورة سيناريوهات

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

وحددوا لكل سيناريو معيار نجاح: كيف ستعرفون أنه يعمل؟ فهذه المعايير تغذي اختبارات القبول مباشرة.

5. رتّبوا الأولويات، دون أن تجعلوا كل شيء «ضرورياً»

صنّفوا كل سيناريو: ضروري للنسخة الأولى (Must have)، أو مهم (Should have)، أو مرغوب (Could have)، أو مؤجل هذه المرة (Won’t have). هذه هي روح منهجية MoSCoW. فإذا كان كل شيء ضرورياً، فلا شيء ضروري، ولا تصل النسخة الأولى أبداً.

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

6. عدّدوا القيود، والبيانات، والأدوات المطلوب ربطها

اجمعوا كل ما يؤطر المشروع:

• الأدوات القائمة: ما يجب الإبقاء عليه أو استبداله أو ربطه بالبرنامج المستقبلي (المحاسبة، والبريد الإلكتروني، ونظام CRM، والمدفوعات)؛
• البيانات الموجودة: الملفات، أو جداول البيانات، أو البرامج القديمة المطلوب ترحيل بياناتها، مع مثال لكل منها؛
• الأمن والسرية: البيانات الحساسة، وصلاحيات الوصول، وسجل لمن فعل ماذا، واللائحة العامة لحماية البيانات (GDPR)؛
• المنصات: الحاسوب، أو الهاتف، أو الجهاز اللوحي، وأي حاجة إلى العمل دون اتصال؛
• الجدول الزمني والميزانية: التاريخ المستهدف للنسخة الأولى، ونطاق تقديري للميزانية.

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

7. اعرضوها للمراجعة، ثم أبقوها حية

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

نموذج لوثيقة متطلبات البرمجيات جاهز للنسخ

إليكم المخطط الذي نوصي به. وتكفي بضعة أسطر لكل قسم للبدء.

1. السياق: شركتكم، ونشاطكم، ودوافع المشروع.
2. الأهداف: ما الذي يجب أن يتغير، وكيف يُقاس.
3. الوضع الحالي: العملية الحالية، والأدوات، ونقاط الاحتكاك.
4. المستخدمون والأدوار: من يستخدم الأداة، وما يمكن لكل شخص رؤيته أو فعله.
5. السيناريوهات: المتطلبات مرتبة حسب الأولوية، مع معايير نجاحها.
6. قواعد العمل: الحسابات، والحالات، والاستثناءات، والمستندات المطلوب إنتاجها.
7. البيانات والتكاملات: ما يجب ترحيله، والأدوات المطلوب ربطها.
8. القيود: الأمن، والسرية، والمنصات، والاستضافة، وإمكانية الوصول.
9. خارج النطاق: ما لن يقوم به المشروع، أو لن يقوم به بعد.
10. الجدول الزمني والميزانية: التواريخ المستهدفة والميزانية التقديرية.
11. التنظيم: قائد المشروع، والمستخدمون الرئيسيون، ومن يوافق على ماذا.

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

خمسة أخطاء يجب تجنبها في وثيقة المتطلبات

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

أكملوا الوثيقة بورشة تحديد النطاق

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

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

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

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

من يجب أن يكتب وثيقة المتطلبات؟

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

ما الطول المناسب لوثيقة متطلبات البرمجيات؟

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

هل تتوافق وثيقة المتطلبات مع المنهجيات الرشيقة؟

نعم. فالمنهجية الرشيقة (Agile) لا تلغي تحديد النطاق: بل تتجنب تجميد كل شيء منذ البداية. تحدد الوثيقة الأهداف والنطاق والأولويات؛ أما تفاصيل كل وظيفة فتُحدَّد في كل دورة تطوير، مع عروض توضيحية منتظمة لتصحيح المسار في أبكر وقت ممكن.

باختصار

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

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