Views and Evidence¶
The model is the source; a view is a purposeful selection of it. Build each view for a review question, not simply to display every element.
| Review question | Useful view |
|---|---|
| Who and what interact with the device? | System context |
| How does a clinical scenario unfold? | Operational sequence |
| Which functions cooperate for an outcome? | Functional chain |
| Which component owns each responsibility? | Function allocation |
| How are components connected? | Logical or physical interconnect |
| How does a hazard lead to harm and where is it controlled? | Risk chain |
| Which requirements lack tests? | Verification coverage |
| Which software depends on which third-party packages? | Software architecture or SBOM view |
A view is not a second model¶
Do not copy elements into diagram-specific packages merely to make a picture. Reference canonical elements and relationships. Layout metadata may change without changing engineering meaning.
Depth is a view decision, not a model decision¶
Composite states and composite actions are model structure: a state owns substates, an action owns steps, and those relationships are real. How much of that depth a reader unfolds is not.
Keep the two apart. Declaring depth on a view says what it offers by
default; folding a composite to a single box, or drilling into one so it
becomes its own diagram, is a reading move made at the renderer. Neither
rewrites the model, and neither should be recorded as if it did. A deep
hierarchy is not a modelling error to be flattened — it is content the reader
navigates.
Evidence closes the loop¶
A useful assurance path is:
flowchart LR
Claim[Requirement or RiskControlMeasure] -->|VerifiedBy| Case[VerificationCase]
Case -->|ProducesEvidence| Evidence[Evidence]
Evidence --> Result[Result, version, approval, and location]Record enough metadata to reproduce and review the result:
- procedure and version;
- tested configuration;
- acceptance criteria;
- actual result;
- anomalies or deviations;
- evidence location and approval status.
Use views to expose missing links, then use the underlying model to correct them.
Continue the story¶
Read the GPCA case study to see the same path—from clinical scenario through architecture, risk, and evidence—in a complete reference model, documented as an ISO/IEC/IEEE 42010 architecture description.