This table of contents should allow users to quickly find any information they are looking for (by looking up page or section numbers).
Provide a short description of the product, including issues such as the purpose of the software, the target users of this system, etc. Take a user-oriented view here describing what services your software will offer to a potential user.
Describe your conventions both with respect to the mean of the terms you use (e.g., what is a user versus an administrator), as well as with respect to typographical conventions. For example, you may choose to denote all user input by a bold font, all system messages by an italic font, and so on.
Give a clear description of all software and hardware requirements. Also give step-by-step instructions for installing your system, if that is needed. Make this as easy as possible for your future user, otherwise he or she will not use your system.
This section is the most detailed portion of your manual. It should provide a complete listing of all functions of your product, and how to use each of them. These functions in effect correspond to a subset of the methods you may have implemented for your classes, namely, those public methods that users would want to work with when using your system.
This should include at a minimum the function name, all possible input and output values, how the system will respond to given input values, a description of the purpose of each function, what class a function belongs to, possible error messages, and so on.
This section should correspond to a quick reference guide indexed by the names of the commands (functions) available to the users. The most preferred format would be a compact lookup table where users that understand the system and its functions simply want to remind themselves what functions are available.
List here all error messages that a user may receive when using your system in a possibly unexpected manner. In particular you need to include with each error type the meaning of each message and the necessary action in order to continue using your system (e.g., ranging from "hit-return" to "all-lost-reboot-the-system").
An example of an error message may be:
E100: This value
does not correspond to the expected input data type.
E101: This value does not exist in the current database.
Error E100 may be raised if the user entered a phone number instead of a street address into the traveler system, while error E101 may be raised if the user entered a street address that is not part of the map database currently loaded into your system.
Here is where your team participation description goes, i.e., give a statement describing the roles and level of contributions of each team member in the development of user manual.
Your user manual needs to include all sections listed above. If one of the sections does not at all apply to your product, then give the section heading and explicitly state that it does not apply.
In addition, you are free to list any other supporting documents (charts, figures, screen-dumps of the main interfaces you have developed thus far).