The first chapter of the arc42 Template with information on requirements, quality goals, and stakeholders.

The second chapter of the arc42 Template with information on constraints and conventions.

The third chapter of the arc42 Template with information on context and external interfaces.

The fourth chapter of the arc42 Template explains the solution idea.

The fifth chapter of the arc42 Template with information on the local building blocks, and their dependencies and relationships.

The sixth chapter of the arc42 Template with runtime information about the architecture.

The seventh chapter of the arc42 Template with information about how the system is deployed.

The eighth chapter of the arc42 Template with conceptional information about the system.

The ninth chapter of the arc42 Template that explains the architecture decisions that led to the system.

The tenth chapter of the arc42 Template that lists scenarios to systematically evaluate the architecture against the quality requirements.

The eleventh chapter of the arc42 Template lists risks and technical debt.

The last chapter of the arc42 Template lists terms of the domain and explains them.

The blueprint of the arc42 Template creates a tree of pages in the Confluence space.

Document a possible option for an architecture decision. Choose this document type to describe the alternative for a decision in more detail. This is typically a subpage of an architecture decision document.

Document an aspect of your architecture. Something orthogonal or cross-functional like logging, exception handling or configurability.

Document a architecture decision for an option. This is useful to state the reasons and the options that have been evaluated. Later other team members will have it easier to understand the decision.

Architecture decisions are group by their types. A commonly used decision type is 'Architecture'.

Document requirements you impose on artifacts. Artifacts are created by processes defined and used by the team. This includes assemblies created by the build process, source code artifacts or reports.

Describe as a Blackbox the elements of a view where only the externally visible properties are relevant.

Code types categorize codes, used in logging or exception handling.

Components are part of a view on a system. A component may refer to a enclosed element or to a complete system of its own.

Type of an environment used by the project to deploy the application or the solution.

Documents a feature of the product. The top features define the main aspects of the product.

There is no one-size-fits-all for documenting software projects. What we do is giving you an introduction on how to get started with the projectdoc Toolbox and the Software Development Add-on to define your documentation requirements with Confluence.

Interfaces document how elements of the system communicate with elements of this and other systems.

Out Items record topics that are out of the scope of the project. This is useful for project inception and for reference in the future.

Property types categorize properties of products, such as parameters or configuration options.

Documents the results of a test session for the sponsoring stakeholders.

Overview over the most relevant information for software developers to create their documentation on Confluence with the projectdoc Toolbox.

User Characters are the actors of user stories. They include personas and extreme characters.

Different views on the product help to document the system and its architecture. Typical views are building block, runtime, or deployment.

Describe as a Whitebox the elements of a view where only the relations of internal elements are relevant.