Product > Component > Subsystem

Product > Component > Subsystem

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.

Glossary

If there are important words to understand in this area, make them clear and obvious here.

Architecture & Design Principles

Any key architecture or design decisions (more specific than those at the product or component level) surrounding this subsystem.

API Reference

One or more links, or inlined details, around the API that this subsystem exposes to other components, subsystems or directly to the outside world.

Sources

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.

Quality Attributes

A description of things that are important to this subsystem, such as:

  • Performance metrics
  • Resource utilisation (CPU, memory)
  • Desired unit coverage
  • “Fragility” – eg is it okay for this to be fragile, is that all there is to it?

Deployment & Operations

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:

  • How to run / restart / make it work
  • Location of log files
  • Putting this subsystem into debug mode
  • Location of diagnostics
  • Other help-type docs

Testing

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.

Owners

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.

Decision Log

As at the product level, key decisions about the component are recorded chronologically, with enough context to be useful after the fact.