These are examples of some of the kinds of system documentation that should be written along with any substantial programing project. This includes both programmer and user documentation.
These are two examples of programmer's documentation, which are materials that provide guidance to how the software works from the perspective of a person who could write or modify the source code for the project. Programmer's documentation should at the very least include a high-level description of how a system works at the source-code level, and any major or important data structures (such as classes and class hierarchies).
1. World Tax Planner Programmer's Documentation (PDF). I wrote this document over twenty years ago when I was working in industry and was given a project that had no documentation whatsoever. It took me about a month of studying the source code to figure out and write this most basic overview of how the program worked. The documentation is relatively simple and brief, but after I wrote it, it meant a month of time saved for all subsequent programmers. Which also meant that we could then transfer development of the software to another set of programmers without embarrassment, which was extremely helpful in terms of the company's business plan. (There is an interesting story here, if you ask me in class. Just ask me about the World Tax Planner project.) If you skim through the document, you can imagine what a difference it would make having versus not having this document. Note that it is actually very short, but that it provides a useful, concise description of each of the major components, and how they fit together. Remember: I was given raw source code with no such explanations whatsoever. Imagine the difference this document would make. Also, see the World Tax Planner Compiling Instructions (PDF)
2. EyeDraw Programmer's Documentation (PDF) - My lab is a bit unusual in terms of the development of research software in that I require my students to write programmer's documentation for their projects. This specific document then made it possible for other students - and an eye tracking manufacturer that we collaborate with - to pick up this code and extend it for other purposes that then further extended the impact and scientific contribution. Without the documentation, after the students finished and left, all of these ideas would have been lost forever. The source code is also quite well-commented and downloadable at the EyeDraw Website at: https://www.cs.uoregon.edu/research/cm-hci/EyeDraw/
User documentation, or the "user manual", is completely different from programmer's documentation. User documentation explains to the user—the person with the human need that motivated the construction of the system—how to accomplish specific tasks with the system. In general, it is best to organize user documentation around tasks that software is intended to support, such as "To create a drawing with your eyes, these are the steps that you need to take....", rather than a list of commands that the user can issue, such as listing what each button can do.
A good SRS (software requirement specification) should include detailed step-by-step operational scenarios (or "use cases") that describe real-world user tasks that the system should support. The user documentation could be organized around these. Here are two examples of user documentation:
1. Connect to VAX from Tokyo with NetModem (PDF) shows instructions that written to permit an office in Tokyo to connect via telephone lines to a "VAX" computer in New York City. (This was in 1990, before the Internet.) Note how the instructions are task-oriented. The user is directed to specific commands within the interface only as needed to accomplish one of two tasks: (a) making the connection and (b) hanging up the phone after the call. These instructions would not serve as a complete user manual, but they are task-oriented instructions rather than command-oriented.
2. EyeDraw User Documentation (PDF) can be contrasted with the EyeDraw Programmer's Documentation above. Note how the two documents are so different that, if it were not for the title of the document, it would be hard to know that they were about the same piece of software. The EyeDraw documentation first just labels each button on the main screen, and then goes through five user-oriented tasks, and the steps required for the user to accomplish those tasks. The user documentation also includes a page on how to troubleshoot the software—again from the end-user's perspective—if the software is not behaving as the user would likely expect.
3. VizFix User Documentation (PDF) is user documentation for a piece of laboratory software used to see where people moved their eyes while doing tasks in psychological experiments. (You can contrast the user documentation with the VizFix Software Requirements Specification (PDF) that specifies what the software should do, and a little of how it might be designed, from a programmer's perspective.