User Manual
There are (at least) two things you can mean by UserManual.
- The document that explains how to operate the software system. Such documents are not usually references, rather descriptions of common operations of the system, introductions to menus and buttons, and maybe some examples of use providing context for the program's operation.
- A more general sense is the complete set of documents delivered with a software system. There might be instruction manuals, readmes, ChangeLogs, on-line help, administrators' guides, reference manuals and all manner of tomes a customer might read to gain information about some operational aspect of the system. There might even be a good reason to share the source code with a customer. It is this second sense of UserManual SkipSailors meant when he wrote WriteTheUserManualFirst.
The distinction between the UserManual and other documents that might be produced for a software project is that the customer is expected to be the primary audience. I wouldn't expect to see a UML scenario included in a UserManual, for instance. A language reference might be part of a UserManual for a compiler, using the second sense.
Some software systems might not have much of a UserManual. Small programs with intuitive interface, like a text editor with nothing fancy in the way of features might need nothing more than a README and a copyright notice. Large systems with many executables and lots of configuration options, say an IntegratedDevelopmentEnvironment, might require so many documents as to require several CDs to hold it.
-- SkipSailors
It has been suggested that the UserManualIsAnAntiPattern, but it seems that most people on this wiki think that a MostApplicationsNeedaUserManual. [DeleteWhenCooked: These two pages are being carved out of UserManualIsAntiPattern.]