A description of the subsystem and what feature or features it provides. At this depth we are a fairly long way away from the customer, but we should still be able to map use cases and sensible actions back to customer needs.
This is the street map of a given city. It follows the same physics as the world, and the laws of the country it resides within, but may have it’s own character due to the town planning or the age of it’s construction.
If there are important words to understand in this area, make them clear and obvious here.
Any key architecture or design decisions (more specific than those at the product or component level) surrounding this subsystem.
One or more links, or inlined details, around the API that this subsystem exposes to other components, subsystems or directly to the outside world.
A list of the source repositories that make up this subsystem. This should include reference to the repository path (it should really be enough to
git clone from) as well as the nature of the repository or subsystem: host, 3rd party, adopted, custom, etc.
A description of things that are important to this subsystem, such as:
A collection of references to important operational aspects of the subsystem. This might include links to support/solutions/end user/documentation guides or may be inline, but aspects include things like:
What test tools, what regression packs, what tests are important to this subsystem. Especially with respect to the quality attributes above, what tests are required running to ensure that this subsystem is still working as intended.
Which team and/or people have ownership over this subsystem. Useful while learning the system to not always have to refer back to the component, but this is just a convenience.
As at the product level, key decisions about the component are recorded chronologically, with enough context to be useful after the fact.