← Back to the learning library
Before you begin: TFA-101 and TFA-109. Choose an example requirement and test result from a fictional or authorised project.
Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.
Learning objectives
By the end of this module, you should be able to:
- Build a proportionate hierarchy of firmware design records.
- Trace requirements, risks, architecture, implementation and tests.
- Record reviews, anomalies and release decisions objectively.
- Recognise evidence gaps before an audit or submission exposes them.
Lesson 1
1. Design evidence should answer engineering questions
A useful record explains why the firmware exists, what it must do, how it is structured, how critical behaviour works and how interfaces are controlled. The hierarchy may include requirements, architecture, detailed design, interface specifications and generated design information. Combine records where that improves clarity; separate them where ownership or review needs differ.
Evidence should be contemporaneous enough to guide decisions. A polished document reconstructed after release may describe the product but cannot fully demonstrate controlled development.
Lesson 2
2. Traceability demonstrates coverage and impact
Bidirectional traceability lets a reviewer see how a requirement and risk control were implemented and verified, and lets an engineer determine what a proposed change might affect. Trace at meaningful engineering granularity: requirement to design element to test, with code-level trace where risk or process demands it.
Automate link extraction where possible, but review orphan requirements, unverified controls and tests without an approved source.
Lesson 3
3. Verification evidence needs context
A pass verdict is meaningful only with the tested version, environment, equipment, procedure, acceptance criterion and observed result. Retain raw logs or measurements where interpretation may matter. Record deviations and anomalies; do not edit expected results after execution to fit what happened.
Reviews are verification activities too. Record participants, material reviewed, findings, resolutions and approval.
Lesson 4
4. Close with a release dossier
The release record identifies source baseline, toolchain, dependencies, configuration, binary hashes, completed verification, unresolved anomalies, risk status and approval. It should allow support or an auditor to determine exactly what was released and why the residual issues were acceptable.
Evidence quality is judged by consistency across the set. Contradictory versions or dates undermine confidence even when every expected document exists.
Lesson 5
5. Build a small but complete evidence chain
Start with one consequential claim and follow it to the delivered image. Each link must answer a question: why the behaviour is needed, what is specified, who implements it, how it is verified and which configuration the evidence describes. Meaningful traceability also supports change impact in the reverse direction.
| Record | Illustrative content |
|---|---|
| SYS-017 | Loss of sensor validity shall inhibit heating within the allocated system time. |
| FW-042 | A stale sample exceeding the defined age causes a latched output inhibit. |
| DES-008 | Validity owner, timestamp source, monitor period and output interface. |
| TEST-063 | Inject stale samples and measure output inhibition at boundary phases. |
| RESULT-063 | Procedure revision, raw trace, measured delay, verdict and anomaly links. |
| REL-004 | Firmware hash, build manifest and approval referencing RESULT-063. |
These identifiers illustrate a structure, not an obligatory naming convention. A database or linked repository can hold the record if its versioning, review and retrieval controls are adequate.
Lesson 6
6. Write reviewable results and decisions
A verification report should distinguish observations from interpretations. “The output dropped at 14.2 ms” is an observation with instrument context; “the requirement passed” is a conclusion based on an acceptance rule. Retain enough raw information for another reviewer to evaluate the conclusion.
When an anomaly is accepted for release, record its affected configuration, impact, investigation, compensating controls, user/service implications, risk acceptance and planned resolution. An email saying “fine to ship” without a linked technical assessment is weak evidence.
Reviews need the material version, reviewers’ roles, findings, actions and closure. Record disagreements that change the decision. Approval does not erase a known gap; it makes responsibility for the decision visible.
Lesson 7
7. Maintain evidence without duplicating it
Choose an authoritative source for each fact. Repeating a toolchain version in five uncontrolled documents makes inconsistency likely. A controlled manifest referenced by design and verification records is easier to maintain, provided archived versions remain accessible.
Automated links should be checked for semantic correctness. A test linked to a requirement might exercise the nominal path but not its timeout or fault clause. Review the coverage argument, not merely whether a hyperlink exists. Detect requirements without evidence and tests whose purpose cannot be explained.
For retrospective remediation, preserve original records and distinguish contemporary evidence from later reconstruction. A newly written architecture can describe an old build, but cannot prove that the architecture guided the original development. Address that process gap explicitly and perform the review or verification still needed.
Decision guide
How much design detail is enough?
| Situation | Appropriate evidence | Avoid |
|---|---|---|
| Simple low-risk component | Clear interface, algorithm description and focused tests. | Repeating obvious source code in prose. |
| Safety-related state/control logic | States, transitions, timing, faults, interfaces and rationale. | Relying on code review alone. |
| Complex generated or model-based code | Controlled model, generator, configuration and equivalence evidence. | Treating generated output as self-documenting. |
Worked example
Worked example — audit-ready firmware release
The code and raw tests exist, but the team cannot show a consistent line from system risk controls to the shipped controller binary.
The team establishes a deliverable index, baselines existing records and maps each software requirement and risk control to an architecture element and verification result. Missing interface decisions are documented and reviewed. Test logs are tied to rig and firmware versions. Known anomalies receive impact decisions. A release report records binary hashes and approvals.
The evidence tells one consistent engineering story and exposes genuine gaps rather than hiding them behind document volume.
Engineering evidence
What should the work produce?
Evidence index
Defines required records, owners and approval state.
Traceability matrix
Links requirements, risk controls, design and verification.
Review records
Demonstrate independent evaluation and closure.
Verification dossier
Combines procedures, configurations, results and anomalies.
Firmware release report
Identifies the approved binary and residual issues.
Common failure patterns
What goes wrong?
- Documents contain incompatible firmware versions or terminology.
- A traceability matrix is populated mechanically but orphan links are not reviewed.
- Only pass/fail is retained when measured evidence matters.
- Unresolved anomalies are absent from the release decision.
Applied exercise · approximately 25 minutes
Repair an inconsistent release dossier
The architecture references version 1.8, the test report says 1.9, the released binary says 1.9-hotfix, and a spreadsheet reports every test as passed without raw results. Two anomalies remain open.
- Define the minimum investigation needed before claiming verification coverage.
- Create an evidence index for the actual released build.
- Write the structure of a release decision that leaves remaining uncertainty visible.
Review a suggested approach
Identify the exact hotfix source, build inputs and delivered hash. Determine the change from the tested baseline and whether architecture and test evidence still apply. Recover original observations where they exist; a pass column cannot substitute for missing data when the acceptance claim needs measured evidence.
The evidence index should state record version, applicable configuration, owner, approval state and gap. Perform justified regression for the hotfix and evaluate both anomalies for product impact. The release decision cites this assessment, any acceptance authority and limitations. If the evidence cannot support a release claim, state that clearly rather than correcting document version labels cosmetically.
Completion criteria
- Configuration mismatch is resolved technically.
- Trace links establish coverage, not just document presence.
- The release decision identifies unresolved issues and accountable approval.
This is a self-directed engineering exercise, not an accredited examination. Compare the rationale as well as the final answer.
Practical check
Questions for your next design review
- Can every released binary be linked to an approved baseline?
- Can each risk control be followed to implementation and verification?
- Do results identify environment, procedure and observed outcome?
- Are review findings and anomalies closed or accepted explicitly?
- Does the release record reconcile all residual issues?
Good evidence is a coherent, reviewable chain of decisions—not the greatest possible number of documents.
References and further reading
- FDA — Content of Premarket Submissions for Device Software Functions
- IEC 62304:2006 + Amendment 1:2015 — consolidated publication
- ISO/IEC/IEEE 29148 — Requirements engineering
Educational guidance only. Apply the authorised standards editions, regulations and approved procedures relevant to your product and market. Linked publications support further study; the fictional exercises do not demonstrate compliance.