حدّد قدر التفصيل الذي يحتاجه مشروعك
لا يوجد حجم واحد صحيح لوثيقة المتطلبات. فإن قلّ التفصيل بنى الفريق على التخمين، وإن زاد مرّت أشهر قبل أن يتعلم أحد شيئاً. دع ظروف المشروع تحدد العمق المناسب.
| الوضع | العمق المناسب | السبب |
|---|---|---|
| فكرة مبكرة تريد استكشافها | ملخص من صفحة واحدة، تليه مرحلة استكشاف | لا تعرف بعد ما يكفي لكتابة المواصفات، وادعاء العكس يهدر الجهد |
| استبدال أداة داخلية أو جداول بيانات | وثيقة كاملة لمسارات العمل الأساسية، وأخف لما عداها | الإجراء قائم ويمكن وصفه بدقة |
| عمل يحكمه عقد أو تنظيم رقابي | مواصفات رسمية بمعرّفات واعتماد موقّع | يجب أن يمكن تتبّع كل متطلب إلى اختباراته وموافقاته |
| منتج سيظل يتغير | نواة قصيرة ثابتة، وقائمة أعمال متجددة | التفاصيل المكتوبة قبل وقتها بكثير تتقادم قبل أن تُبنى |
نموذج وثيقة متطلبات البرمجيات
انسخ هذا الهيكل وعدّله بما يناسبك. القسمان 4 و7 يحتاجان إلى أكبر قدر من العناية، والأمثلة اللاحقة في هذا الدليل تبيّن كيف تكتبهما.
وثيقة متطلبات البرمجيات
Template1. الغرض
المشكلة التي يحلها النظام، ولمن، والنتيجة المتوقعة
2. المستخدمون والأدوار
كل دور، وما يتولاه، وما يحق له أن يراه ويفعله
3. النطاق
الإجراءات والميزات التي يشملها هذا الإصدار
ما هو خارج النطاق صراحةً
4. المتطلبات الوظيفية
متطلب واحد في كل سطر: المعرّف، والنص، والأولوية، ومعايير القبول
مجمّعة بحسب مسار العمل، وبالترتيب الذي يجري به العمل
5. البيانات
السجلات الرئيسية، وحقولها المهمة، والمسؤول عن كل منها
البيانات التي ستُنقل، ومن أين
قواعد الاحتفاظ بالبيانات وحذفها
6. الربط مع الأنظمة الأخرى
كل نظام خارجي، وما يُتبادل معه، وفي أي اتجاه، وبأي وتيرة
7. متطلبات الجودة
الأداء، والتوافر، والأمان، والخصوصية، وإمكانية الوصول، والتوافق
8. القيود والافتراضات
التقنية، والميزانية، والمواعيد، والسياسات، وكل ما يُفترض صحته
9. القبول والاعتماد
كيف سيُختبر النظام بعد اكتماله، ومن يعتمده
10. المصطلحات والأسئلة المفتوحة
المصطلحات، ولكل منها معنى واحد متفق عليه
القرارات التي لم تُتخذ بعد، ومن سيتخذها
كيف تكتب متطلباً يمكن اختباره
يكون المتطلب مفيداً حين يقرؤه شخصان فيبنيان الشيء نفسه، ويستطيع ثالث أن يتحقق منه. والاختبار بسيط: اسأل كيف ستثبت أنه أُنجز. فإن لم تجد إجابة، فأعد كتابته.
| متطلب ضعيف | سبب ضعفه | صيغة قابلة للاختبار |
|---|---|---|
| يجب أن يكون النظام سهل الاستخدام | لا يستطيع أحد أن يثبت صحته أو خطأه | يستطيع موظف مستودع جديد أن يسجّل استلام بضاعة دون تدريب، بالاعتماد على الإرشادات الظاهرة على الشاشة وحدها |
| يستطيع المديرون اعتماد الطلبات | لا يحدد أي المديرين، ولا أي الطلبات، ولا ما يحدث بعد ذلك | الطلب الذي يتجاوز حد الاعتماد يُعلَّق حتى يعتمده أو يرفضه مستخدم يحمل دور المدير في تلك المنطقة، مع ذكر السبب |
| يجب أن يكون النظام سريعاً | لا معنى متفقاً عليه لكلمة «سريع» | تعرض قائمة الطلبات أولى نتائجها خلال زمن الاستجابة المتفق عليه في القسم 7، مقيساً على الحاسوب المحمول والاتصال المرجعيين |
| يمكن تصدير التقارير | لا يذكر الصيغة ولا المحتوى | يمكن تصدير أي تقرير في ملف جدول بيانات يحتوي الصفوف والأعمدة نفسها الظاهرة على الشاشة، مع عوامل التصفية المطبقة |
| يرتبط النظام بنظام المحاسبة | يذكر نظاماً ولا يصف أي سلوك | حين تُعتمد فاتورة، تُنشأ في نظام المحاسبة خلال المدة المتفق عليها، ويظهر أي إخفاق لمن يحمل دور المالية |
اكتب كل متطلب في عبارة واحدة. فإذا ربطت الجملة بين أمرين بحرف «و»، فهي في الغالب متطلبان، وسيُنسى أحدهما في الاختبار.
مثال على متطلب وظيفي
اعتماد الطلبات، مكتوباً كاملاً
من نظام افتراضي لإدارة الطلبات. والمعرّف يتيح للتصاميم والاختبارات وطلبات التغيير أن تشير إلى السطر نفسه.
- المعرّفORD-012
- النصالطلب الذي يتجاوز إجماليه حد الاعتماد المحدد لحساب العميل يجب أن يعتمده مدير المنطقة قبل إرساله إلى المستودع.
- الأولويةضروري
- القواعديُحدَّد الحد لكل حساب عميل على حدة. ولا يستطيع المدير اعتماد طلب أنشأه بنفسه. والطلب المرفوض يعود إلى من أنشأه مع سبب الرفض.
- معايير القبولالطلب الذي لا يتجاوز الحد يذهب مباشرة إلى المستودع. والطلب الذي يتجاوزه يظهر في قائمة الاعتماد الخاصة بالمنطقة الصحيحة، ولا يظهر في غيرها. ويُسجَّل الاعتماد والرفض مع اسم المستخدم والتاريخ والسبب. ويُبلَّغ منشئ الطلب بالنتيجة.
- سؤال مفتوحمن يعتمد الطلب حين يغيب مدير المنطقة؟
لاحظ السؤال المفتوح. فكتابة المتطلب كما ينبغي كشفت قراراً لم تكن الشركة قد اتخذته بعد. وهذا بالضبط ما وُجدت الوثيقة لأجله.
أمثلة على متطلبات الجودة
متطلبات الجودة، وتُسمّى أيضاً المتطلبات غير الوظيفية، تصف مدى الجودة التي يجب أن يؤدي بها النظام عمله. وهي أكثر المتطلبات إغفالاً، وأكثرها تكلفة حين تُضاف لاحقاً. أما القيم بين الأقواس المربعة فتحددها أنت.
| الجانب | السؤال الذي يجيب عنه | مثال على المتطلب |
|---|---|---|
| الأداء | ما سرعة الاستجابة المطلوبة، وتحت أي حمل؟ | مع [العدد] من المستخدمين يعملون في وقت واحد، تظهر نتائج البحث خلال [المدة] على الجهاز المرجعي |
| التوافر | متى يجب أن يكون متاحاً، وكم يُسمح بأن يتوقف؟ | النظام متاح خلال ساعات العمل في كل منطقة يخدمها، وتجري الصيانة خارجها |
| الأمان | من يحق له الوصول إلى ماذا، وكيف يُفرض ذلك؟ | يسجّل كل مستخدم دخوله عبر الدخول الموحد للشركة (SSO)، والوصول إلى سجلات العملاء محدود بحسب الدور |
| الخصوصية | ما البيانات الشخصية المحفوظة، ووفق أي قواعد؟ | تُحفظ البيانات الشخصية في [المنطقة]، ويمكن تصديرها أو حذفها عند الطلب |
| إمكانية الوصول | من يجب أن يتمكن من استخدامه؟ | تستوفي كل الشاشات معيار إمكانية الوصول المذكور في العقد |
| التوافق | أي المتصفحات والأجهزة والأنظمة؟ | الإصدار الحالي والسابق من المتصفحات الرئيسية، على الحواسيب المحمولة والأجهزة اللوحية |
| التدقيق | ما الذي يجب أن يمكن تتبّعه لاحقاً؟ | كل تغيير على الطلب يُسجَّل معه المستخدم والوقت والقيمتان القديمة والجديدة |
| الاستعادة | كم من البيانات يُقبل فقدانه، وبأي سرعة يجب أن تعود الخدمة؟ | تتيح النسخ الاحتياطية الاستعادة إلى نقطة لا تبعد أكثر من [المدة] عن وقت العطل |
قائمة مراجعة الوثيقة
قبل اعتماد الوثيقة
0 من 10 منجزةأخطاء شائعة
- وصف النظام الحالي شاشةً شاشة، فتُعاد بذلك مشكلاته نفسها
- كتابة متطلبات لا يستطيع أحد اختبارها، مثل «بديهي» أو «مرن»
- تحديد الحل، كقائمة منسدلة، بينما الحاجة الحقيقية هي الاختيار من قائمة
- إغفال الاستثناءات، مثل المرتجعات، والإلغاءات، والتصحيحات، وغياب من يعتمد
- نسيان نقل البيانات حتى أسبوع الإطلاق
- اعتبار الاعتماد نهاية التفكير، مع أن الحقائق الجديدة يجب أن تظل قادرة على تغيير الوثيقة
ماذا تفعل الآن
ابدأ بالأقسام من 1 إلى 3، ومسار العمل الأساسي في القسم 4. فهذا يكفي لبدء حديث جاد مع شريك تطوير، ويتناول دليل كيف تختار شريكاً لتطوير البرمجيات المخصصة هذه الخطوة. وإن كان النظام سيحل محل جداول البيانات، فيشرح دليل كيف تنتقل بعملك من جداول البيانات إلى البرمجيات كيف ترسم أولاً ما تؤديه هذه الجداول.
وإن لم يكن لدى فريقك وقت لكتابة الوثيقة، فإن ورشة استكشاف المنتج تُنتجها معك. وتشرح صفحة تطوير البرمجيات المخصصة كيف نبني انطلاقاً منها. ويمكنك أيضاً أن ترسل إلينا مسودة، وسنحدد لك ما يحتاج أي فريق إلى توضيحه.
أسئلة شائعة
ما الفرق بين وثيقة SRS ووثيقة PRD ووثيقة BRD؟
وثيقة متطلبات الأعمال (BRD) تحدد ما تحتاجه الشركة ولماذا. ووثيقة متطلبات المنتج (PRD) تصف ما ينبغي أن يقدمه المنتج لمستخدميه. أما مواصفات متطلبات البرمجيات (SRS) فتضيف المتطلبات الوظيفية ومتطلبات الجودة المفصلة التي يبني الفريق عليها ويختبر وفقها. وكثيراً ما تجمع المشاريع الصغيرة الثلاث في وثيقة واحدة، ولا بأس في ذلك ما دام كل مستوى حاضراً فيها.
هل تحتاج الفرق التي تعمل بالمنهجية المرنة (أجايل) إلى وثيقة متطلبات؟
نعم، لكن في صورة أخف. ففي المنهجية المرنة، يحل محل المواصفات الضخمة المكتوبة مسبقاً بيان ثابت للأهداف والنطاق والقيود ومتطلبات الجودة، إلى جانب قائمة أعمال تُفصَّل كل مهمة فيها قبيل بنائها. وما تُلغيه المنهجية المرنة هو الدقة الزائفة، لا الحاجة إلى الكتابة.
كم ينبغي أن يكون طول وثيقة متطلبات البرمجيات؟
بالقدر الذي تتطلبه المخاطر. فالأداة الداخلية المحددة الغرض قد تحتاج إلى ما بين عشر صفحات وعشرين، والنظام الخاضع لتنظيم رقابي يحتاج إلى أكثر. لكن الطول مقياس ضعيف، والمقياس الأفضل: هل يستطيع مهندس لم يلتقِ بك قط أن يقدّر العمل منها؟
من ينبغي أن يعتمد المتطلبات؟
المسؤول عن النتيجة التجارية، ومن سيتولى النظام في العمل اليومي، والقائد التقني الذي سيبنيه. وكل منهم يؤكد شيئاً مختلفاً: أن العمل يستحق التنفيذ، وأن الوثيقة تصف العمل الحقيقي، وأن بناء النظام ممكن.
هل يمكن أن تتغير المتطلبات بعد اعتمادها؟
يمكن ذلك، وسيحدث. فالاعتماد يضع خط أساس، حتى يكون كل تغيير لاحق ظاهراً ومسعّراً ومتفقاً عليه، بدل أن يتسلل دون أن ينتبه إليه أحد. والمشروع الذي لا تتغير متطلباته أبداً هو في الغالب مشروع لا يتعلم فيه أحد شيئاً.
