As the development proceeds, the 4+1 views can be used to organize the details that accumulate. The idea is to collect the information that belongs outside the narrow focus of docstrings in the code.

The user_stories.rst document is where we can collect user stories, requirements, and other high-level background notes. This might evolve into a directory tree if the user stories become complex.

The logical.rst document is a place to collect our initial OO designs for the class, module, and package. This should be the origin of our design thinking. It might contain alternatives, notes, mathematical backgrounds, proofs of correctness, and diagrams of the logical software design. For relatively simple projects, where the design is relatively clear, this may remain empty. For complex projects, this may describe some sophisticated analysis and design that serves as the background or justification for the implementation.

The final OO design will be the Python modules and classes that belong in the implementation.rst file. We'll take a look at this in a little more detail, as this will become our API documentation. This part will be based in a direct way on our Python code and the RST-markup docstrings.

The process.rst document can collect information about the dynamic, runtime behavior. This would include topics such as concurrency, distribution, and integration. It may also contain information on performance and scalability. The network design and protocols used might be described here.

For smaller applications, it may not be perfectly clear what material should go into the process document. This document may overlap with the logical design and the overall architectural information. When in doubt, we have to strive for clarity based on the audience's need for information. For some users, many small documents are helpful. For other users, a single large document is preferred.

The physical.rst file is where the deployment details can be recorded. A description of the configuration details would go here, specifically, the environment variables, the configuration file format details, the available logger names, and other information required for administration and support. This may also include configuration information such as server names, IP addresses, account names, directory paths, and related notes. In some organizations, an administrator may feel that some of these details are not appropriate for general software documentation.

In the next section, we'll see how to write the implementation document.