Practical requirements engineering for working engineers.
An interactive, on-site requirements 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, plus a printable quick-reference card pack in preparation (see the sample below). 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 technique taxonomy, gathering, design and idea-generating, and thinking tools
- 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
Fourteen quick-reference cards
One-page summaries of the techniques you'll reach for most, read them on the site or print them to pin at your desk.
- EARS patterns, the quality checklist, stakeholder analysis, traceability, acceptance criteria, the change loop
- The Kano model and conflict resolution
- The requirement-vs-constraint-vs-assumption decision aid
- Each cross-referenced to the relevant tool
Standards alignment
Mapping the toolkit's methods to the standards that govern industry 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
- Suitable for use in regulated environments, safety, certification, contract
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 arguing over requirements. The toolkit gives them the foundations and the depth, quick-reference cards for daily use, fuller treatments for when they need them.
Systems engineers and architects
Anyone working in SE roles where requirements are a major part of the job, capturing them, decomposing them, allocating them, validating them, tracing them through to 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 to review your team's work against.
What's inside: two samples
Before you sign up, two pieces from the toolkit: a quick-reference card and one full recipe from the "Where do I start" guide.
Sample 1: Quick-reference card: EARS
The first of the quick-reference cards, designed to be printed and pinned, or referenced digitally. The planned set covers stakeholders, context, EARS, quality, attributes, traceability, decomposition, verification, acceptance criteria, change management, the requirement-vs-constraint-vs-assumption decision, the Kano model, and conflict resolution.
Five patterns that remove a large class of requirement ambiguity
EARS is a small grammar, developed at Rolls-Royce, that constrains how requirements are written. Used well, it removes most of the ambiguity that causes requirements to be argued over in design reviews. Used badly, it becomes a template-completion exercise. The trick is to pick the right pattern for what the requirement means.
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, keeping 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)
- Identify the named individual or role responsible for the project on the customer side, and confirm what document they are expecting to receive from you. The answer might be “a requirements specification”, but it might be “a Concept of Operations” or “a statement of need”, and the work to produce each is very different.
- 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). This is the document that lets everyone agree what they think the system is for, before anyone writes a single “shall”. If your customer expected a requirements spec, write this anyway, you can extract requirements from it.
- Draw a context and boundary diagram (Tool 3). Identify every external entity the system interacts with, and every flow across the boundary. This is your cheapest scope-control device.
- List your constraints and assumptions explicitly (Tool 4). Distinguish the two, confusing them is one of the most common early-project failures.
- Plan and run an elicitation activity (Tool 5), choosing techniques deliberately from the three categories, gathering, design and idea-generating, and thinking tools. 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
- Writing requirements before you have a Concept of Operations, you will write fluent prose for the wrong system
- Confusing what the user wants with what they say they want, the two are often different and need elicitation, not transcription
- 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
- Treating the first stakeholder you meet as the only one, there are always more
- Treating all stakeholder needs as equal. Some are basic (taken for granted; their absence is resented but their presence is unremarkable), some are performance (more is better, linearly), and some are excitement (delights when present, no complaint when absent). The Kano model classification, in Tool 1’s supplementary section, is the prompt for thinking about which is which. Missing a basic need is the most common cause of in-service disappointment.
Toolkit tools to reach for: 1, 2, 3, 4, 5, 6, 7, 8, 9 (in roughly that order, iterating between them).
Current status
The Requirements Engineering Toolkit is live and free for working engineers. All thirteen tools, four lifecycle stages, and six "Where do I start" recipes are available on the site, with a printable quick-reference card pack in preparation. Click below for access, first-time visitors are asked to create a free account.
An account lets me notify you when new tools or chapters are added, and gives me a sense of who's finding the work useful. No spam, and you can unsubscribe with one reply.
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 for working engineers. There's no payment and no upsell. The "catch" is that you need a free account so I can let you know when new tools or chapters are added, that's the only ongoing relationship, and you can unsubscribe with one reply.
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 throughout, and a copy-ready template. Plus a "Where do I start" guide with six situation-based recipes, and a printable quick-reference card pack in preparation. Everything runs in the browser, no downloads, no installs.
Does this need a paid AI subscription like the CSEP and PR Helpers?
No. The RE Toolkit is a self-contained reference, methodology, examples, and templates that you read, copy, and use. There's no AI Project setup, no system prompt to load, no per-message context to pay for. It works with no AI subscription at all.
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.
Will new tools or chapters be added?
Yes. The first release covers the core lifecycle and the most-used techniques. Future additions are likely to include domain-specific patterns (safety cases, regulated environments, agile delivery at scale) and deeper treatments of techniques that are introduced more briefly in v1. Signed-up users get update emails when new material lands.
Get free access to the Requirements Engineering Toolkit
One click. Free: first-time visitors will be asked to create a free account so I can let you know when new tools or chapters are added.
Get free access →If you're already signed in, you'll go straight to the toolkit. Otherwise you'll be taken to the free signup form first.