Give a brief description of the design and the usage of the component.

In contrast to the short description this section may contain any formatting and text elements required. This section is intended to be transcluded by other documents that refer to this component.

May contain a context diagram centred on the component, but keep it very small. Also note that in case such a diagram is included, make sure to include it in every component description. Documents may transclude the abstract information from different components. Nonetheless these documents should appear monolithic to the reader. If in doubt, add the context diagram to the view section.

Provide an overview description of the component. This summary should cover every aspect of the component from a higher level.

The summary is intended to be transcluded in overview documents.

Provide a list of configuration options of the component.

Use cases allow to define how the component is used. This section may also show use cases where the component plays only a small role. Add a reference to a use case document for each identified use case.

Quality scenarios document the important quality aspects of the component. Add a reference to a quality scenario document for each important quality of the component.

With architecture aspects the team documents aspects that have impact on all components of the system. List the aspects that are most important for the component.

Components are important to the system. To explain their construction, runtime behaviour or deployment use view documents.

This section may also contain a context diagram.

List how other components may communicate with this component over its interfaces.

List the artifacts that manifest this component.

List subcomponents within this component.

A components design or implementation may be based on some architectural decisions. List those that are important to understand the component.