User Manual

 

Why are we doing the User Manual now?  How can we have screen shots when we haven't designed, much less coded, the application? 

 

1. Sorry, this isn't really a user manual - it's a developers’ user manual.

·        Major difficulty in TRUE new designs - learning the domain concurrent with solving the domain problem.

·        Most developments are NOT new designs.

·        You need a way to communicate with your users to find out if you understand what they are trying to accomplish.

·        You need to communicate what you learn with your teammates - they may not get the same idea from their customer counterparts, or they may not have an opportunity to interact (think multiple-location developments).

·        You need to verify your requirements are complete and sensible. 

·        Write a developers' user manual.  It tells your users what you think they need to do to accomplish their jobs.  They can disagree or not, but it will get them thinking and get them involved.  It shows your teammates what you'll need to do.  It gives a jump-start to people joining the team.  If you can write a user manual based on your requirements that states, step by step, how someone would do their job and the users say "Yep, that's exactly what I want to do.” then your requirements are probably sufficient (except for constraining requirements).  If they say, or you figure out, that there are holes in your user manual, then there are probably corresponding holes in your requirements.  Furthermore, you can give it to management to help them understand the problem.

·        Sometimes this version of a user manual is never shown to the customer - why?

2. Sell Off Criteria and Procedure Documentation

·        Management frequently won't allow contract acceptance until it is known how the system will be sold off.

·        UM and SRD combined show that you know what you have to test and how you have to test it

·        test equipment

·        simulators

·        test results

·        external documentation

 

3. Traceability Matrix

·        A traceability matrix allows one to see how requirements relate to design and implementation decisions, as well as test procedures.