The term documentation is a collective term for many different documents in the field of software. What they all have in common is that they offer a reference point for different target groups on the structure, function, use or development of the software under consideration. The same terms are not always used for the different types of documentation, though, so it helps to sort them.
Process documentation vs. product documentation
The main distinction between the different types of documentation is whether they describe the process or the product.
Process documentation describes the course of the software project, from its creation to the end of maintenance. It serves as a guide during the development of the system and ensures that internal knowledge is retained. Its goal is to structure and organise software development, to make the project more transparent and to reduce administrative effort. Typical process documents are forecasts, schedules, and organisational and process standards. Many of them go out of date quickly, because they are only needed for a specific phase of the project. They remain useful when a similar task comes up, or during later maintenance.
Product documentation describes the software product itself. It splits into two sub-types: user documentation and system documentation.
User documentation
User documentation describes how the software is installed, operated and maintained, written for the different groups of people who use it. The best-known form is end-user documentation, usually called the user manual. The audience largely decides its content and scope. In large projects it can help to hand the writing to a specialised company or an internal department; in any case the focus should be on descriptive examples rather than technical subtleties.
A second form that gets far less attention is administrator documentation. It holds everything needed to install and maintain the software: how the system behaves in different environments and together with other systems, which requirements apply, and what the error messages mean.
System documentation
System documentation covers all documents that describe the software system itself. It usually contains:
- requirements documentation,
- architecture documentation,
- source code documentation,
- quality assurance documentation,
- interface documentation.
The requirements documentation summarises what the software does: user stories, use cases, and the essential information about purpose, properties, functions and behaviour. The architecture documentation records the most important decisions on the structure and design of the software and lists the planned components and their significance. The source code documentation explains to developers how the code works. The quality assurance documentation contains the test cases that ensure the required function, and the procedures used to run them. The interface documentation summarises all interfaces the system offers and uses, and gives an overview of the options the software provides.
Conclusion
Every area of the development process needs adequate documentation. Too little and too much both damage the project. Depending on the system, the focus is on different areas, and whatever is written has to be kept current and reflect the actual state of the software.
That last point is where most documentation fails, because hand-written documents age from the day they are finished. Sysparency takes a different route: the system documentation, the business explanations and the interface inventory are generated from the source code itself and regenerated on every upload, so they never fall behind the system. This works for software that is being developed now as well as for systems that have existed for decades without any documentation. For SAP custom code, every program, table, interface and screen gets its own page, placed in its module and business process, cited down to the line.
Originally published in January 2021, revised in September 2026.