ما الذي يجب أن يتضمنه مستند المتطلبات؟

ما الذي يجب أن يتضمنه

الوضع الحالي

كيف تسير الأمور اليوم؟ ما هي الأنظمة، ما هي الجداول، ما هي الأوراق؟

الهدف

ما الذي يجب أن يتغير بعد ذلك - يجب أن يكون قابلاً للقياس. "تقليل الجهد" ليس هدفًا. "تقليل وقت إعداد العروض من 40 إلى 10 دقائق" هو هدف.

العمليات مع حالات الاستثناء

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

الأنظمة المعنية

ما هي الأنظمة التي يجب ربطها، من يديرها، هل هناك واجهة موثقة؟

هيكل الكميات

كم عدد سجلات البيانات، كم عدد المستخدمين، كم عدد العمليات في اليوم؟ هذا يحدد الهيكل المعماري.

الشروط الإطارية

المواعيد، الميزانية، المتطلبات القانونية، أين يمكن أن توجد البيانات.

ما الذي لا يجب أن يتضمنه

المتطلبات التقنية بدون سبب. "يجب أن يتم تطويره بلغة PHP" يكون منطقيًا فقط إذا كنت ترغب في تطويره بنفسك. خلاف ذلك، فإنه يقيّد دون فائدة.

وصف الحلول بدلاً من المتطلبات. "يحتاج إلى زر يقوم بـ X" لا يكشف عن المشكلة التي يحلها X - ويمنع شخصًا ما من اقتراح حل أفضل.

إذا لم تتمكن من كتابة مستند المتطلبات

هذا ليس عائقًا. غالبًا ما يكون من الأفضل إجراء تحليل متطلبات مشترك - موعد أو موعدين يتم فيهما تسجيل العملية وتنظيمها. النتيجة أفضل من مستند تم إنشاؤه بين الباب والباب.