Practical requirements engineering for working engineers.
An interactive engineering toolkit for working engineers, thirteen tools across four lifecycle stages, each with a worked example, a step-by-step method, figures throughout, and a copy-ready template. Aligned to INCOSE, ISO 15288, ISO 29148 and IREB CPRE Foundation. Written for engineers from apprentice to engineering manager.
What the toolkit contains
A working engineer's reference for requirements engineering, thirteen tools organised across four lifecycle stages (elicit, write, trace, V&V/change), each with worked examples, interactive figures, and ready-to-use templates.
Elicitation
Five tools for getting requirements out of stakeholders, including the constraints and conflicts they haven't yet articulated.
- Stakeholder identification and analysis, with the Kano model for distinguishing basic, performance and excitement needs
- Concept of Operations and context/boundary diagram templates
- Constraints and assumptions register
- Elicitation techniques for information gathering, design and idea generation, and analytical thinking
- Moore's five conflict types and IREB CPRE's five resolution techniques
Writing good requirements
What separates a useful requirement from one that gets argued over in design reviews.
- EARS, the Easy Approach to Requirements Syntax, with all five patterns and when to use each
- Eight-criterion quality checklist for self-review and peer review
- Requirement attributes and metadata, ID, source, rationale, priority, status, owner, verification method
- Worked rewrites and common anti-patterns, with before-and-after examples
Traceability and verification
Plan V&V from the start, not as an afterthought before delivery, and trace requirements through to evidence.
- Forward and backward traceability matrices
- Requirements decomposition and allocation across a sub-system architecture
- Interface requirements specification
- Verification methods, test, analysis, inspection, demonstration
- Acceptance criteria patterns including Given / When / Then
Change and iteration
Keeping requirements alive and useful through a programme, not just a snapshot at the start.
- Change impact assessment and baseline management
- Differentiated change control for agile and iterative delivery, stable top-level layer vs. an evolving backlog
- A practical "Where do I start" situation picker covering six common engineering situations
Printable EARS quick-reference card
A concise guide to choosing and applying the five EARS requirement-writing patterns.
- Pattern syntax and worked examples
- A short decision guide for choosing a pattern
- Formatted for printing or saving as a PDF
Standards alignment
References used in systems and requirements engineering practice.
- INCOSE Systems Engineering Handbook (5th edition, 2023)
- ISO/IEC/IEEE 15288:2023 system life cycle processes
- ISO/IEC/IEEE 29148:2018 requirements engineering
- IREB CPRE Foundation Level syllabus
- Use your organisation’s assurance, safety, certification and contractual processes alongside the toolkit
Who this is for
The toolkit is written for working engineers at every level, from apprentices and graduates building their foundations, through practitioners and senior engineers, to principal engineers and engineering managers.
Engineers writing or reviewing requirements
Apprentices, graduates, practitioners and senior engineers whose job involves writing, reviewing or agreeing requirements. The toolkit provides practical guidance for day-to-day use and fuller explanations when needed.
Systems engineers and architects
Systems engineers and architects who capture, decompose, allocate, validate and trace requirements through delivery.
Engineering managers
Leaders responsible for the quality of requirements coming out of their teams. The toolkit gives you a shared reference for what good requirements look like and a common language for reviewing the work.
What's inside: two samples
Before you sign up, explore a printable EARS card and one full recipe from the "Where do I start" guide.
Sample 1: Quick-reference card: EARS
This card is based on Tool 6 in the toolkit and is ready to print or save as a PDF.
Five patterns for writing clearer, more consistent requirements
EARS, the Easy Approach to Requirements Syntax, is a structured set of requirement-writing patterns developed at Rolls-Royce. It uses a small number of keywords and sentence forms to make system behaviour and its triggering conditions explicit. Choose the pattern that matches the meaning of the requirement, then check that the result is clear, necessary and verifiable.
The five patterns
| Pattern | Syntax and use |
|---|---|
| Ubiquitous |
An always-true requirement. The <system> shall <response> Example: The braking system shall have a mass of not more than 40 kg. |
| Event-driven |
A response triggered by an event. WHEN <trigger>, the <system> shall <response> Example: WHEN the emergency stop is pressed, the system shall halt all motion within 50 ms. |
| State-driven |
A response that holds for the duration of a state. WHILE <state>, the <system> shall <response> Example: WHILE in service mode, the system shall log all operator inputs. |
| Optional-feature |
A requirement that only applies if a feature is included. WHERE <feature>, the <system> shall <response> Example: WHERE remote monitoring is fitted, the system shall transmit status every 60 s. |
| Unwanted behaviour |
The system’s response to an undesired condition or fault. IF <trigger>, THEN the <system> shall <response> Example: IF the input voltage falls below 18 V, THEN the system shall enter safe mode within 1 s. |
A sixth pattern, Complex, combines the keywords (e.g. While <state>, when <trigger>, the <system> shall <response>) for behaviours that depend on both a state and a trigger. Build it only from the five base patterns and keep the response singular.
How to pick the right pattern
- Is the behaviour conditional on something? If no, Ubiquitous. If yes, go to question 2.
- Is the condition an event, a state, or an exception? Event → WHEN. State (sustained) → WHILE. Exception or abnormal trigger → IF/THEN.
- Is it a feature that may or may not be present? WHERE.
Sample 2: A worked recipe: starting from scratch
One of the six situations from the Where do I start with RE guide. Each situation has signs that identify it, a do-these-first list for the first hour or two, a then-do-these list for the first few days, watch-outs, and a list of the toolkit tools to reach for. Below is Situation A in full.
You are starting a new project from scratch
Signs this is you
- You have been handed a project with no existing requirements document
- There is a brief, a vision document, or a verbal description, but no “shall” statements yet
- You may or may not have a clear customer; you may or may not have a clear scope
- The pressure is on to “start writing requirements” quickly
Do these first (in the first hour or two)
- Confirm which document the customer expects: a requirements specification, Concept of Operations or statement of need. The required work differs for each.
- Identify the “upstream” constraints, the parent system, the regulatory regime, the existing assets that constrain your project. List them. Do not yet try to formalise them as requirements.
- Block out a half-day to a day in the next two weeks to do proper stakeholder identification (Tool 1).
Then do these (over the first few days)
- Run the stakeholder identification (Tool 1). Be thorough. Include the operators, the maintainers, the regulators, the suppliers, and the through-life support function, not just the customer.
- Draft a Concept of Operations (Tool 2) to agree how the system will be used before writing detailed requirements. Confirm with the customer whether a ConOps or an equivalent operational description is expected.
- Draw a context and boundary diagram (Tool 3). Identify the external entities and the flows across the boundary so the project scope and interfaces are explicit.
- List your constraints and assumptions explicitly (Tool 4). Distinguish the two so unverified assumptions are not treated as fixed constraints.
- Plan and run an elicitation activity (Tool 5), choosing techniques for information gathering, design and idea generation, and analytical thinking. Develop a small set of use cases, user stories or scenarios for the most important interactions. Resist the urge to be exhaustive at this stage; you will iterate.
Watch out for
- Starting detailed requirements before the operating concept is clear can produce precise wording for the wrong scope.
- Treating a stakeholder’s first statement as the complete need. Use elicitation to test assumptions, context and underlying objectives.
- Designing in the requirements (“the system shall use a 24V DC supply” when the real requirement is about powering the system), see the constraint-vs-requirement test in Tool 4
- Relying on the first stakeholder you meet without checking for operators, maintainers, regulators, suppliers and through-life support
- Treating all stakeholder needs as equal. The Kano model in Tool 1 helps you distinguish basic, performance and excitement needs, and consider what happens if a basic need is missed.
Toolkit tools to reach for: 1, 2, 3, 4, 5, 6, 7, 8, 9 (in roughly that order, iterating between them).
Frequently asked questions
Common questions about the toolkit, free access, and what you get.
Is this really free? What's the catch?
The toolkit is free. A free account is required for access, but no payment details are collected.
What do I get access to?
Thirteen tools across four lifecycle stages, elicit, write, trace, V&V/change, each with a worked example, a step-by-step method, figures and a copy-ready template. You also get a "Where do I start" guide with six situation-based recipes and a printable EARS quick-reference card. Everything runs in the browser and requires no software installation.
Does this need a paid AI subscription like the CSEP and Professional Registration Helpers?
No. The Requirements Engineering Toolkit runs in the browser and does not use an AI service.
Who is this written for?
Working engineers at any level, apprentices and graduates learning the discipline, practitioners and senior engineers who want a working reference, principal engineers and engineering managers who need a shared vocabulary for their teams' requirements work. The worked examples sit in defence, rail, aerospace, manufacturing and other industry contexts.
Get free access to the Requirements Engineering Toolkit
Use all thirteen tools, worked examples, figures and copy-ready templates at no cost. I use your email to operate the account and send essential service messages. I will not use it for marketing unless you separately opt in.
Get free access →