ما الذي يجب أن يكون في المستند المحدد؟

ما الذي يجب أن يكون فيه

الوضع الراهن

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

الهدف

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

الإجراءات مع حالات الاستثناء

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

الأنظمة المتضررة

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

الهيكل الكمي

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

الظروف الإطارية

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

ما الذي لا يجب أن يكون فيه

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

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

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

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