The goal of this project phase is to develop the user's manual for the functionality you are adding to your project. It may seem strange to write the user's manual now, since the application has not yet been developed, and the user interface only exists as a series of paper sketches. Due to this, in many respects what you will write can be viewed as a developer's user manual.
The user's manual tells users what you think they need to do to work with your system. 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 interact with the system and the users say "yes, 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.
One way of viewing the user's manual is that it, along with your scenarios, provide a very user-centered way of thinking about the desired functionality of your system. A clear understanding of the behavior of your system before you start coding is a strong indicator of a solid design.
Since this user's manual is not based on the final running system, there will likely be a need to make modifications to this document as part of the activities of turning in your final project notebook. For example, you will need to insert actual screen shots, and modify functionality descriptions based on any changes you make to your requirements after the manual is first completed.
The user's manual has the following main components:
For more information, see the template.
Last updated: