End-user support material is typically required of any system that has an interface that users will interact with;
systems that are principally embedded and have little or no user interface may omit this work product, although it may
be applicable and useful even where API's need to be documented.
This work product often encloses one or more of the following documents and work products:
-
User Guides
-
Operational Guides
-
Maintenance Guides
-
Online demos
-
Online help system
-
Context-sensitive help
-
Release notes
The user documentation gives instructions for using the software. Provide documentation for all types of users.
Use use cases as a basis for your user's guide.
The user manual can be written by technical writers, with input from developers, or it can be written by the test team,
whose members are likely to understand the user's perspective.
A reason for allocating the user manual to the test team is that it can be generated in parallel with development and
evolved early as a tangible and relevant perspective of evaluation criteria. Errors and poor solutions in the user
interface and use-case model can be spotted and corrected during the early iterations of the project, when changes are
cheaper.
By writing the user manual, the testers will get to know the system well before they start any full-scale testing.
Furthermore, it provides a necessary basis for test plans and test cases, and for construction of automated test
suites.
How early in the development cycle to begin producing the user manual depends on the type of system. Systems with
complex interfaces or with a lot of user interaction will require early versions of the user manual and also early
prototypes of the interface. Embedded systems with little human interface will probably not require an early start on
user documentation.
|