Describe systems and subsystems so that no knowledge of its implementation is necessary.
Also Known as
- Block (SysML)
- Class (UML)
- Limit propagation of changes
- Allow exchange of implementation technology
- Support modularization
Use the Black-Box System pattern when:
- You need to decompose a structure
- Define clear channels of communication or interaction
- At a minimum, you need to describe the behavior of interfaces of the subsystem.
- More complex systems benefit of a clear functional description.
- If physical elements are involved, you need to describe the relevant physical characteristics
The Black Box Pattern has the following benefits and liabilities:
- Create clear boundaries.
- Clarifies functional thinking
- Automation allows the detection of inconsistencies and gaps
- If not done right, the structure can create more problems, "get in the way"
- Without a proper tie-back to customer requirements, the purpose can get lost.
- If you are using a formal modeling language (SysML, UML), not all stakeholders may be willing/capabile to understanding the model.
The Black-Box pattern can be realized in various levels of formality. The following list is not exhaustive:
- One-Pager: If you work with documents, create the key information of the system on a single page, outlining the structural elements. Think of a product description in a technical catalog.
- In a modern requirements tool, structures can be used to guide the breaking down of the system into subsystems or components that will then be treated like black boxes (see image). This requires skilled authors that ensure that the description is problem-oriented. The items can then have down-stream traceability to the design.
- If you practice MBSE, use SysML Blocks and Ports for describing the black box. This provides you with a (much) more formal framework. In that case, you would want to combine it with functional modeling
- In software systems, consider building a domain model using classes.