TFA-303 — Firmware Requirements Engineering — ISO/IEC/IEEE 29148

← Back to the learning library

Before you begin: Read TFA-102 on state machines and TFA-103 on timing. Bring one requirement containing words such as quickly, reliably or as appropriate.

Reading time and practice time are estimates. Examples use fictional products and illustrative engineering values, not approved product limits.

Publication basis: ISO/IEC/IEEE 29148:2018. Publisher records identify this edition as published and a revision as under development; a draft is not the project baseline unless explicitly adopted for that purpose.

Learning objectives

By the end of this module, you should be able to:

Separate a stakeholder need from an allocated firmware requirement.
Define observable behaviour, limits and exceptional conditions.
Trace derived requirements back to their rationale.
Review requirements for testability without confusing a test method with the requirement itself.

Lesson 1

1. Understand what the standard contributes

ISO/IEC/IEEE 29148 addresses requirements engineering processes and the information produced by them. It supports systems and software work across different project sizes and development approaches. It does not supply the correct deadline, safe state or sensor threshold for a particular device. Those decisions require product knowledge, risk analysis and engineering evidence.

For a fictional environmental chamber, distinguish the user’s need to protect samples from the system requirement to limit excessive temperature and the firmware behaviour allocated to help achieve that limit. The firmware specification should make its contribution explicit. It cannot independently guarantee chamber temperature if the heater switching hardware can fail energised. Review allocation with the people responsible for the physical system.

Lesson 2

2. Allocate behaviour before choosing an implementation

A requirement should identify the required outcome at an appropriate boundary. “Use a 10 ms task” describes an implementation choice; “remove the heater-enable command within the allocated response time after a qualified fault” describes observable behaviour. An architectural constraint can also be a legitimate requirement when its source and rationale are clear.

Separate the two deliberately. If a platform contract fixes an interrupt priority or an RTOS service, record it as a constraint and examine its consequences. Do not ban all implementation detail from requirements, but do not disguise an arbitrary design preference as a user need. Trace derived requirements to the analysis that created them, such as a timing budget, interface limitation or protective function allocation.

Lesson 3

3. Specify conditions, response and limits

Useful firmware requirements identify the operating state, triggering condition, response, applicable limit and recovery behaviour. A timeout statement needs a defined start event and clock basis. An invalid-input requirement needs a definition of invalidity. A communication-loss requirement needs to say what happens to work already in progress.

Split a sentence when it contains independently verifiable behaviours. For the chamber, detecting a stale sensor, disabling heat and requiring an authorised reset can be separate linked requirements. This makes a partial implementation visible. Keep related requirements together through identifiers and rationale rather than hiding several obligations behind a single “handle sensor faults safely” statement.

Lesson 4

4. Make time and units unambiguous

Suppose a system analysis allocates 100 ms from a qualifying sensor fault to physical heater de-energisation. A candidate budget is 20 ms for qualification, 10 ms for dispatch, 5 ms for command propagation and 30 ms for the output device, leaving 35 ms reserve. These are illustrative engineering allocations, not limits supplied by the standard.

State which portion belongs to firmware and which endpoint is physically measured. Include clock tolerance, scheduling variation and observation uncertainty in the analysis. A test that observes a GPIO command cannot by itself prove the relay has opened. If a sampled temperature condition must persist, specify sample freshness, boundary equality and the effects of a missing sample. Milliseconds, sample counts and scheduler ticks are not interchangeable descriptions.

Lesson 5

5. Write interface and persistence requirements

Interfaces include representation as well as values. Define units, byte order, valid ranges, sequence handling, error responses and ownership of buffers or state. For persistent settings, specify compatibility across versions, behaviour after an interrupted write and what happens when a record fails validation. These decisions often outlive the original communications protocol.

Example requirement concern	Question to resolve	Evidence source
Temperature command	Is the value Celsius, scaled integer or floating point?	Interface definition and boundary tests
Stored calibration	Which versions can read it, and how is corruption detected?	Data-format review and recovery tests
Repeated command	Is it rejected, ignored or processed idempotently?	State model and sequence tests

Use one controlled definition for each shared concept so the firmware, test harness and service tool cannot silently use different interpretations.

Lesson 6

6. Use traceability to expose gaps

Traceability should help a reviewer follow a claim in both directions. From a firmware requirement, identify its parent need or analysis, implementation allocation and verification evidence. From a test or code change, identify what behaviour it establishes or modifies. A link is useful only when its meaning is clear.

A derived watchdog requirement may originate in an architectural fault analysis rather than a user request. Record that rationale instead of inventing a parent requirement to fill a database field. Conversely, a requirement without a verification approach might reveal an unobservable endpoint or an unresolved system boundary. Treat these as engineering findings. A fully populated spreadsheet can still contain logically weak or obsolete relationships.

Lesson 7

7. Review and change the baseline

Review requirements with firmware, systems, hardware and verification perspectives. Ask whether each statement is necessary, coherent with neighbouring requirements and assessable under realistic conditions. Try explaining what a counterexample would look like. If reviewers cannot describe a failure, the requirement may be too vague or outside the chosen boundary.

Once agreed, changes need impact analysis. Extending a communication timeout may affect safe behaviour, battery life and a test fixture. Record the changed rationale, affected links and regression decision. Preserve the previous accepted version so field behaviour can be understood later. Clarification that changes observable behaviour is still a change, even if the author describes it as editorial.

Decision guide

What kind of statement belongs in the requirement set?

Statement	Interpretation	Action
Respond quickly	Unbounded expectation	Define event, endpoint and limit
Use a specific RTOS queue	Possible architectural constraint	Record its source or move the choice to design
Disable heat within an allocated interval	Candidate behavioural requirement	Define qualification, states and measured endpoint
Run test HIL-18	Verification activity	Link the test to the behaviour it assesses

Worked example

Worked example — replacing “detect sensor failure quickly”

Problem

The chamber specification says only that sensor faults must be detected quickly. The implementation treats an unchanged reading as a fault, while the tester disconnects a cable. Neither has agreed how a legitimately stable temperature should behave.

Engineering approach

The team separates stale acquisition data, an out-of-range electrical signal and a plausible but stuck sensor. It defines a freshness indicator from the acquisition path, electrical validity limits from hardware analysis, and the system measures needed for plausible sensor failures. It allocates command response time separately from physical de-energisation and defines a latched fault state with a deliberate recovery action.

Result

Each implemented detector has a stated purpose and a testable boundary. The remaining inability to detect every plausible sensor failure is recorded in the system analysis rather than hidden behind the word “quickly”.

Engineering evidence

What should the work produce?

Allocated requirements set

Contains identifiable behaviour and constraints with rationale and source.

Interface and data dictionary

Defines units, representations, freshness and shared terms.

Timing allocation

Connects system endpoints to firmware and hardware contributions.

Traceability and review record

Shows meaningful links, resolved ambiguities and approved changes.

Common failure patterns

What goes wrong?

Using the firmware output command as proof of a physical system response.
Treating a changing sample value as evidence that acquisition is fresh.
Combining detection, response and recovery into one vague statement.
Adding trace links without checking the meaning of each relationship.

Applied exercise · approximately 25 minutes

Rewrite a communication-loss requirement

A controller is instructed to “stop safely if communication fails”. Commands arrive nominally every 50 ms, some operations must finish a bounded safe step, and the host may reconnect automatically.

Identify the missing decisions before choosing a timeout.
Draft three linked requirements covering detection, response and recovery.
Describe one test that would reveal an incorrect interpretation.

Review a suggested approach

Resolve the heartbeat or command-freshness rule, timing reference, allowed jitter, operating states, definition and duration of a safe step, output endpoint and reconnection authority. The nominal 50 ms interval alone cannot justify a safe timeout.

A suitable draft separates detection of excessive valid-message age, transition to a defined stop sequence with a bounded completion time, and the conditions for re-enabling operation after reconnection. Fill numerical limits only after the system allocation is agreed. A useful test interrupts communication during the longest permitted step, then reconnects with a delayed command from the old session. Verify both the bounded stop and rejection of unintended restart. Automatic reconnection need not imply automatic resumption.

Completion criteria

Missing safety and timing decisions are identified before numbers are selected.
Detection, response and recovery are individually assessable.
The test includes an adverse sequence and a physical or justified interface endpoint.

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

Are states, triggering events and exceptional conditions explicit?
Are units, timing endpoints and boundary equality defined?
Do derived requirements have a defensible source?
Can tests observe the required outcome at the correct boundary?

Key takeaway

A good firmware requirement turns an engineering intention into a bounded, observable and traceable commitment.

References and further reading

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.