قوالب المواصفات الفنية والوظيفية [مغلق]

Question

لذلك أنا أبحث بشكل أساسي عن قوالب جيدة لكتابة المواصفات الفنية والوظيفية لمشروع أو طلب عمل.

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

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

يحرر: لقد قرأت رأي جويل عنه مواصفات غير مؤلمة, ، لقد أعجبني حقًا، لكن هل هناك أي آراء أخرى :)

Answer 1

على النصائح العامة؛

نحن نقوم بتنفيذ عملية

1) بيان متطلبات العمل (BRS)

2) المواصفات الوظيفية

3) المواصفات الفنية

ويغطي BRS ما هي مشاكل العمل، وما هي المتطلبات المتعلقة بالحلول والاختبار والأمان والموثوقية والتسليم.وهذا يحدد ما يمكن أن يجعل الحل ناجحا.

توضح المواصفات الوظيفية ما هو مطلوب، وكيف يجب أن يبدو، وطول الحقول، وما إلى ذلك.

توضح المواصفات الفنية مصدر البيانات، وأي تعليمات برمجية صعبة قد تحتاج إلى أخذها في الاعتبار.

العميل يملك المتطلبات.يمتلك المطورون المواصفات التقنية، والمواصفات الوظيفية هي الحل الوسط.يتم إجراء الاختبار وفقًا للمواصفات الفنية (عادةً اختبار الوحدة) ثم مقابل المواصفات الوظيفية (عادةً اختبار النظام) ثم مقابل المتطلبات (UAT).

الجزء المهم من هذا (والذي نكافح من أجله) هو أن المطورين ما زالوا بحاجة إلى الالتزام بالمواصفات الوظيفية ومتطلبات العمل الأصلية.في الواقع، المواصفات الوظيفية والتقنية موجودة فقط من أجل الوضوح.

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

Answer 2

ليس قالبًا، لكن جويل كتب أ زوج من المقالات عند كتابة المواصفات الوظيفية.لديه أيضا عينة هنا.

Answer 3

يمكنك شراء القوالب من موقع IEEE ومن أماكن أخرى، ولكنني كنت دائمًا أصنع قوالبي الخاصة.

بالنسبة للمواصفات الفنية، "اكتمال الكود" بقلم ستيف ماكدونيل لديه قائمة مرجعية جيدة، يمكنك استخلاص بعض المعلومات منها.في وظيفتي الأخيرة، قمت للتو بإنشاء نموذج من رؤوس الأقسام الخاصة به، وقمت بتعديله من هناك.

فيما يتعلق بالمواصفات الوظيفية، فإن الشيء المهم هو تحديد جميع الواجهات:

1. واجهة المستخدم (نماذج الشاشة)
2. واجهات البرامج (المكونات الإضافية، وما إلى ذلك)
3. واجهات الأجهزة (إذا كان ذلك مناسبًا)
4. واجهات الاتصالات (الخدمات، البريد الإلكتروني، الرسائل، إلخ.)

يجب أن يكون هناك أيضًا قسم لقواعد العمل، والأشياء المهمة وظيفيًا والتي لم يتم تناولها في أي تعريف للواجهة.

Answer 4

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

Answer 5

يعجبني هذا ، من بين أمور أخرى: جاهز.

إنه يبيع نسخة احترافية أيضًا.

Answer 6

هذا هو أفضل ما وجدته: http://www.jiludwig.com/templates/FRDTemplate.doc

Answer 7

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

Answer 8

أود أن أقترح إلقاء نظرة على قالب Roberston's Volere هنا.إنهم جزء من Atlantic Systems Guild، جنبًا إلى جنب مع أشخاص مثل Tom DeMarco وTimothy Lister من شهرة "Peopleware".

نظرًا لأن القالب محمي بحقوق الطبع والنشر، فلن أعيد إنتاجه هنا، ولكن سأعطيك بعض العناوين الرئيسية:

1. الغرض من المشروع
2. أصحاب المصلحة
3. القيود المفروضة
4. اصطلاحات التسمية والمصطلحات
5. الحقائق والافتراضات ذات الصلة
6. نطاق العمل
7. نموذج بيانات الأعمال وقاموس البيانات
8. نطاق المنتج
9. المتطلبات الوظيفية
10. انظر وتشعر بالمتطلبات ...

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

ينظر هنا في الفصل 9.