Although software typically consists of source code and object code, if the code needs to be modified or updated, the task can be very difficult or even impossible if the code structures and purposes cannot be clearly understood by subsequent programmers, or by members of the team not familiar with particular parts of the code. It is generally important to specify that software be properly documented in software development agreements, and documentation should normally be included in any source code delivery or escrow.
Documentation, from legal perspective, is the material that explains how the code works, how different parts of it interact – how it may interact with third party software components like operating systems or applications, what are the so called APIs. Typically technical documentation will include:
- ‘requirements,’ that is to say materials that specify what the software is supposed to do, the contexts and environment it is supposed to work in, the types of user interfaces it should have, etc.;
- ‘architecture,’ or high-level documentation, i.e., a description of the overall design of the software, what its components will be and how they will relate to one another, how it will interact with its environment, etc.; and
- ‘technical’ or low level documentation, i.e., the key details at the code level, so what code does exactly what, what algorithms are used for which purposes, what the interfaces and APIs are, etc.