Generic Spec Template

From UG

Revision as of 13:57, 28 January 2010 (edit) Alex (Talk | contribs) (→Detailed Design (Technical Specification)) ← Older edit		Revision as of 20:29, 29 January 2010 (edit) (undo) Alex (Talk | contribs) Newer edit →
Line 1:		Line 1:
-	[[Category:Documentation]]	+	[[Category:Spec Templates]]
-		+
	== General Info and Scope ==		== General Info and Scope ==

---

Revision as of 20:29, 29 January 2010

Contents 1 General Info and Scope 1.1 Scope 2 Business Needs and Business Requirements 3 Notes from Systems Architect 4 Preliminary Design / Prototype 5 Detailed Design (Technical Specification) 5.1 Summary 5.2 Objects and Fields 5.3 User Interface 5.4 Functionality / Use Cases 5.5 Special Cases and Misc 6 Quality Assurance 6.1 Use Cases 6.2 Test Cases 7 Look And Feel 8 Figures 8.1 Figure 1: 9 Questions 10 RFC (Ideas for Future Discussion) 11 Known Non Critical Bugs 12 Links to Archived / Old specs 13 History 13.1 This doc has been created 13.2 (Re-design) (Tweak) (Spec Update): ..... <summary> ..... 14 DB 15 Code

General Info and Scope

• Classified As: (small) (large) component / common feature / ...
• Parent Mantis: tbd

• Prerequisites:
  • read ...
  • ...

Scope

TBD

Business Needs and Business Requirements

• This section is defined by Business Analyst
• In this section this component/feature is defined from the business standpoint. All important points are listed. It could include some design details if business insists on specific design.

Notes from Systems Architect

• This section is defined by Systems Architect. It is written after #Business Requirements are defined.
• The purpose of this section is to give direction to System Analysts who will write detailed specification.

Preliminary Design / Prototype

In some cases (component is non standard) we need to do preliminary not so detailed design before detailed final.

Detailed Design (Technical Specification)

• This section is defined by Systems Analyst.
• It contains detailed technical design is written after #Business Requirements and #Technical Requirements are defined.

Summary

Objects and Fields

• Normally what gets stored/retrieved from DB

User Interface

Functionality / Use Cases

• This section you could spit into two. But often it is hard to do since often most of functionality is UI related

Special Cases and Misc

• If any exist

Quality Assurance

This section is to be written by QA Engineer or QA Manager or Systems Analyst.

Use Cases

• List all major usual scenarios - from the user standpoint . See Use Case.
• Do not repeat use cases that have been already defined in #User Interface and Functionality section. Instead - link to them.

Test Cases

• List unusual scenarios - things that user most of the time would not do but system must handle well
• Do not list Common Test Cases - link to them

Look And Feel

• This section is to be written / defined by Graphic Designer and UI Designer.
• This includes:
  • final graphics
  • final layout
• Layout defined here should refine, provide more detials to "functional definitions" of UI as defined in #User Interface and Functionality section above

Figures

Figure 1:

Questions

RFC (Ideas for Future Discussion)

Known Non Critical Bugs

Links to Archived / Old specs

History

This doc has been created

<date/signat>

(Re-design) (Tweak) (Spec Update): ..... <summary> .....

<wiki date/signature>

• mantis: <link>
• Biz Req updated? N/Y
• Tech Spec updated? N/Y

DB

Code