Overview
Following is a list of documentation types that are commonly
used in software development and other technical fields.
The Subscriber module is being used as an example.
Types
Change Request (CR)
Overview
A short summary of what the requested change is. Less than a
page would be typical and small requests could be only a few sentences.
Other important information to be included would be the
client, if this is a new feature or change to an existing one, if it’s
affecting business, and if there is a workaround (with an indication of
difficulty and occurrence).
Urgency can also be included, however clients always push
this higher than it should be. Including an indication of costs (as per
support) is probably a good idea.
Whom
Initially the Client, extra details added by the client’s
internal representative.
Target
Client Representative.
Example
Business Requirements (BR)
Overview
This document expands on the CR by covering what the end
requirements for the business (client) are.
One way of considering this is a justification for the
change
Whom
Client’s internal representative with input from the client.
Target
Client Representative, Client, Technical.
Example
Functional Requirements (FR)
Overview
This document covers what the functional requirements are.
This means what functions the change has and can also include how they work
however does doesn’t cover how they are to be implemented.
Use-cases fit into this category as they detail how
functionally is to be used.
Whom
Client’s internal representative.
Target
Client Representative, Client, Technical.
Example
Design Specification (DS)
Overview
This document covers how the functional requirements are to
be implemented.
This document is expected to be very technical and should
include database changes (schema, stored procedures) and details on how the new
functionality is to be implemented. It should be written with the idea that a
different people will be implementing the functionality.
Examples of included information should be ER diagrams and
documentation of changes can go as far as pseudo-code and snippets of actual
code.
It should also include a list of any other functionality
that may be affected by these changes. This is to assist in the Testing
Specification.
Whom
Technical.
Target
Technical, Tester, Writer.
Example
Testing Specification (TS)
Overview
Testing specifications are used in the testing phase to
insure functionality
Whom
Target
Tester, Technical.
Example
User Documentation (UD)
Overview
Whom
Target
Client
Example
