أدنى مستوى من التفاصيل للمواصفات الوظيفية حتى تكون مفيدة

Question

حيث أعمل، لا يحب الناس كتابة المواصفات.(يا فتى، هل يفعل أحد ذلك؟) لذا فهم لا يفعلون ذلك، إلا إذا أجبرهم رؤسائهم على ذلك.وإذا أجبروا على كتابتها، فإنهم يجعلونها قصيرة قدر الإمكان.(بالمناسبة، هم تحتوي ايضا أنا.)

وهذا يؤدي إلى مواصفات مثل

• يقوم هذا البرنامج بتسجيل الوقت بين الحدثين A وB في سجل الأحداث
• يتم تعيين اسم ومسار المعلمة X في ملف تكوين بتنسيق ini.
• البرنامج نشط دون أن يحتاج المستخدم إلى تسجيل الدخول إلى الكمبيوتر (التنفيذ كخدمة Windows)

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

لذلك سؤالي هو:ما رأيك في الحد الأدنى المطلق لمستوى التفاصيل في المواصفات الوظيفية لأي برنامج غير تافه؟

Answer 1

IMHO الشيء المهم في المواصفات الوظيفية (وجميع الأساليب/الأدوات الرسمية الأخرى لتطوير البرمجيات وتخطيط المشاريع (Yourdon، SSADM، PRINCE2، UML، إلخ) هو أنها تشجع الممارسة الجيدة من خلال جعلك تفكر وفقًا لخطوط مشتركة. ضمان النجاح ولكنها تشجع النجاح من خلال إضفاء الطابع الرسمي على الممارسات الجيدة

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

ما الذي ينبغي أن يذهب بشكل مثالي إلى FS؟بقدر ما هو ضروري وأقل ما يمكن.فقط لأن بعض المواصفات الوظيفية تغطي X وY وZ لا يعني أن المواصفات الخاصة بك يجب أن تغطيها.إذا أصبحت توجيهيًا أكثر من اللازم، فستضيف بيروقراطية غير ضرورية إلى المشاريع الأبسط؛بالمقابل، بالنسبة للمشاريع المعقدة، قد يشجع النهج التوجيهي المطور على التوقف عن الوصول إلى مستوى التفاصيل التي يجب عليهم الذهاب إليها حقًا.

Answer 2

كتب جويل أون سوفتوير مقالاً مفصلاً عن المواصفات.

يمكنك العثور عليها هنامناقشة المواصفات