Beyond Good Intentions: The Mechanics of Rapport in Stakeholder Conversations
21 April 2026
Harmon Matrix – Not Every Process Needs Redesign
5 May 2026You have gathered your stakeholder interviews, filled several pages with notes, and you are ready to write your first requirements. You type: “The system shall handle user logins.”
It sounds reasonable. But what does “handle” mean, exactly? Handle how? Under what conditions? What if the login fails? Without answers to those questions, developers will make assumptions, testers will guess at the expected behavior, and your stakeholders will be surprised by the result.
This is where EARS requirements templates come in. If you are interested in other requirements documentation techniques, take a look at our post on the Snow Card.
What Is EARS?
EARS stands for Easy Approach to Requirements Syntax. It was developed by Alistair Mavin and colleagues at Rolls-Royce as a lightweight approach to writing clear, consistent, and testable textual requirements. The approach uses a small set of keywords that signal the structure of each requirement: what kind of situation it applies to, what triggers it, and what the system must do in response.
EARS gives you five templates. Each one handles a different type of system behavior. Learn these five patterns, and you will already write better requirements than most people working on their first project.
To make each template concrete, we will use a single running scenario throughout this post: MediBook, a fictional online appointment booking system for a GP clinic.
Template 1: Ubiquitous
Pattern: The <system name> shall <system response>.
Use this template for requirements that are always true, regardless of any event or state. These are the baseline properties of the system: things it must do all the time, without exception.
Example:
The MediBook system shall store each patient data record using encryption that conforms to NIST FIPS 197, the Advanced Encryption Standard.
There is no trigger here, no special condition. Encryption is a constant property of the system. If a requirement describes something the system must always do or always be, the ubiquitous template is the right choice.
Template 2: Event-Driven
Pattern: When <trigger>, the <system name> shall <system response>.
Use this template when a requirement is activated by a specific event. The “When” keyword signals the trigger, making it clear that the system response only happens because something happened first.
Example:
When a patient confirms a booking, the MediBook system shall send a booking-confirmation email to the patient registered email address within 60 s.
Without the “When,” you might write: “The system shall send a confirmation email.” That raises an immediate question: when, exactly? The event-driven template removes that ambiguity by making the trigger explicit.
Template 3: Unwanted Behavior
Pattern: If <unwanted condition>, then the <system name> shall <system response>.
Use this template to specify how the system must respond to errors, failures, and undesirable situations. The “If…then” structure makes it easy to spot requirements that deal with exceptions, which are often the most overlooked part of a specification.
Example:
If the selected time slot is unavailable at the time of booking confirmation, then the MediBook system shall display an availability error and present exactly three alternative available appointment time slots sorted by earliest start time.
Requirements authors who skip this template often leave the development team with no guidance on error handling, which means the team invents its own behavior. That is rarely what stakeholders wanted.
Template 4: State-Driven
Pattern: While <system state>, the <system name> shall <system response>.
Use this template when a requirement only applies while the system is in a particular state. The “While” keyword signals that the behavior is ongoing for as long as that state persists.
Example:
While a patient is logged in, the MediBook system shall display the patient’s upcoming appointments on the home screen.
The moment the patient logs out, this requirement no longer applies. The state-driven template captures that conditional persistence clearly.
Template 5: Optional Feature
Pattern: Where <feature is included>, the <system name> shall <system response>.
Use this template when a requirement only applies if a particular feature or configuration has been enabled. This is common in products that are deployed with different options for different clients.
Example:
Where the clinic has enabled video consultations, the MediBook system shall provide a video call option during the booking process.
Clinics that do not offer video consultations will never see this feature. The “Where” keyword signals that this is a conditional capability, not a universal one.
Combining Templates
Once you are comfortable with the five patterns, you can combine them to write more precise requirements for complex behaviors. EARS calls these “complex requirements.”
For example, suppose you want to describe a rebooking flow that is only available to logged-in patients:
While a patient is logged in, when the patient cancels an appointment, the MediBook system shall display a rebooking option with three alternative available appointment time slots sorted by earliest start time.
This combines the state-driven (“While”) and event-driven (“When”) patterns. The clauses always appear in the same order: precondition first, then trigger, then system response. That consistent ordering makes requirements easier to read and review.
Watch the Author Explain EARS
Alistair Mavin, the author of EARS, explains the approach clearly and with real-world examples. Watch his introduction before you put the templates into practice on your own project.
Putting It All Together
EARS will not write your requirements for you. What it does is give you a reliable structure so that each requirement answers the right questions: What type of behavior is this? What triggers it? What must the system do? When does it apply?
Start with the five templates. Use them on a small set of existing requirements you have already written and notice how the rewrite forces you to answer questions you may have left open. That exercise alone will sharpen your thinking about requirements quality.
For the original EARS documentation, patterns, and published research, visit Alistair Mavin’s website: alistairmavin.com/ears.
These Templates Are Also Available in Dutch
Working in a Dutch-speaking context? The EARS templates translate well into Dutch, and using them in your native language makes it even easier to apply them consistently with local stakeholders and development teams.
