Topics / Standards and assurance
ISO/IEC/IEEE 29148 is about engineering requirements, not just writing “shall.”
A useful requirement has a purpose, an authority, a clear boundary and a way to determine whether it holds. Manage those facts throughout change.
Use the lifecycle perspective.
ISO/IEC/IEEE 29148:2018 describes requirements-engineering processes and the information produced by them. Its scope covers systems and software across the lifecycle, rather than prescribing a sentence template alone.
Source: ISO: ISO/IEC/IEEE 29148:2018. Scope and edition reviewed 3 October 2026.
Treat a recovered statement as a candidate until its intended meaning and authority are established. Formal-looking language does not resolve a conflict between a customer promise and current code.
Make one vague promise testable.
Illustrative example
“The service shall respond quickly.”
This leaves the operation, load, measurement point and threshold undefined. A team might agree on a specific response deadline for a named operation under a declared load, with explicit handling of unavailable dependencies. Those values require a product decision; an agent should not invent them to complete the sentence.
| Question | Information to retain |
|---|---|
| Why is this needed? | Source, stakeholder need and rationale |
| When does it apply? | Conditions, scope and assumptions |
| What must happen? | Observable behavior and boundary values |
| How will we check it? | Verification method and expected result |
| Who may change it? | Approval and revision history |
Keep the agreement alive after the ticket closes.
Proof retains requirements in a layered graph connected to code, hazards and evidence. A later agent can retrieve the obligation even if its new prompt omits it. Relevant changes still require renewed evidence or an authorized amendment.
A useful first exercise is to take one ambiguous requirement through clarification, implementation and verification. Judge the result by whether another engineer can understand and check it.
Try it on your software
Bring one requirement your team interprets differently.
We can clarify its authority, scope and expected observation without writing an entire specification first.