Provides doctypes to create documentation in software development projects. The focus is on documenting the architecture of the product, but it includes templates for other software development documentation requirements as well.
The Doctypes for Software Development help agile teams to document their software architecture.
Create a space and you have a basic structure, a repository, to add the relevant information for your stakeholders.
After you have created your space use the page blueprints to create documents for project constraints, requirements, views, architecture aspects (aka concepts) and many more.
The different topics are part of a document that comprise usually one wiki page. Since these pages are loosely coupled, they can be combined for different audience groups (e.g. using Tours or Volumes) easily. This makes it natural to run single source documentation principles and employ advanced features like transclusions or automatic lists. If the concepts you want to discuss are complex, you are not limited to a single page. Use the Section or other doctypes to create pages for modular content.
List of Doctypes for Software Development
The following doctypes help to document your software projects.
This list can be overwhelming, but using the templates is usually quite straight forward. To get a quick overview we suggest to open the Prezi presentation (the one we mentioned on the top of the page) which groups the logically closely related document types.
For an introduction to using projectdoc doctypes and macros from the author's point of view, have a look at the following documents:
|#||Name||Short Description||Set||Documentation Type||Categories|
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.
Artifact types categorize artifacts.
Describe as a Blackbox the elements of a view where only the externally visible properties are relevant.
Describe the codes that are part of the product's API.
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.
Document logical or physical groups of nodes.
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.
Interfaces document how elements of the system communicate with elements of this and other systems.
Nodes are part of environments where artifacts are deployed to.
Node types categorize nodes.
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.
Project Constraints limit the options of a project.
Properties are part of the configuration options of a system.
Qualities describe desired aspects of the product.
Quality Scenarios document required qualities.
Documents a quality target for a product.
Documents requirements of a product.
Categorization of requirements for a product.
Technical Debts track issues to be paid back.
Technical Debts are grouped by the area they address.
Document a test case of your project.
Defines a charter to run an exploratory test session.
Document data used for test cases.
Documents the results of a test session for the sponsoring stakeholders.
Defines a document to collect information during a test session.
Defines a use case of the product.
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.
Groups the views at a system.
Frame the vision for a project or iteration.
Describe as a Whitebox the elements of a view where only the relations of internal elements are relevant.
The following macros are provided by this add-on.
- User Story Macro
- Renders a user story of a user story doctype.