When to run it
A requirements baseline in DOORS, Polarion or Jama for a feature on a regulated or safety-relevant device, with traceability required for release.
Requirements in.Traceable firmware out.
From DOORS requirements to verified firmware
The playbook in one paragraph
A new feature arrives as a set of requirements. Ana designs the change, writes the firmware, runs it through unit, SIL and HIL tests, and keeps a trace from every requirement to the code and test that satisfy it.
Works with
- Requirements: DOORS, Polarion or Jama
- C, C++ or Rust toolchains
- RTOS (FreeRTOS, Zephyr, QNX and others)
- SIL/HIL rigs and CI
What Ana needs from you
- Requirements baseline
- Target hardware and RTOS
- Coding standard (for example MISRA C) and safety class
How Ana runs it
Step by step.
5 steps from trigger to done - each one visible to your team as it happens.
- 01
Analyze requirements
Ana reads the requirements, flags ambiguity and conflicts back to the author, and derives testable acceptance criteria for each one.
- 02
Design the change
Ana proposes the module design, task and interrupt changes, and memory and timing budgets for engineering review.
- 03
Implement to standard
Ana writes the firmware against your coding standard and runs static analysis, fixing violations before review.
- 04
Verify on SIL and HIL
Ana writes unit tests, runs software-in-the-loop, then hardware-in-the-loop on your rigs, and investigates failures with logs and traces.
- 05
Close the trace
Every requirement links to its design element, code and passing test, ready for the design history file.
Who approves what
Approval gates
- Design
- Embedded lead
- Merge
- Code review per your process
- Release baseline
- Quality / regulatory
What you get
Deliverables
- 01Firmware changes with static-analysis clean results
- 02Unit, SIL and HIL test results
- 03Requirement-to-code-to-test trace matrix
- 04Review-ready change package
What usually goes wrong
And how Ana handles it.
Risk
Ambiguous requirements implemented literally
Ana raises ambiguity before writing code and records the clarification against the requirement.
Risk
Timing and memory regressions
Budgets are measured on target, not assumed, and reported in the change package.
FAQ
Common questions.
Yes, through your HIL rigs and CI agents connected to them.
Keep going
Related playbooks.
Embedded
Patching a firmware CVE and shipping it over the air
A vulnerability lands in a component your devices ship. Ana finds every affected firmware build from the SBOM, patches and tests it, and stages an OTA rollout that stops itself if devices misbehave.
Read the playbook →Software
Upgrading a framework across dozens of services
A major framework or runtime version is going end-of-life and it touches every service. Ana plans the migration, upgrades each service in its own branch, fixes what breaks, and hands your team small, tested pull requests instead of one terrifying diff.
Read the playbook →Software
Burning down a stale bug backlog
Every team has a backlog of real but low-priority bugs that never win a sprint. Ana triages them, reproduces the ones that are still real, fixes them with tests, and closes the rest with evidence.
Read the playbook →See it in your stack
Run this playbook on your systems.
Thirty minutes, your repositories and cloud, one real instance of this job.