EARS.md

EARS (Easy Approach to Requirements Syntax) Guidelines

Table of Contents

1. Overview
2. Core Principles
3. EARS Ruleset
4. The Five EARS Patterns
5. Writing Quality EARS Requirements
6. Pattern Selection Guide
7. Integration with INCOSE Guidelines
8. Implementation Recommendations
9. Advanced Considerations
10. Quick Reference Card
11. Summary

---

1. Overview

EARS is a lightweight, structured methodology for writing clear and precise requirements using constrained natural language. Developed by Alistair Mavin and colleagues at Rolls-Royce PLC in 2009, EARS provides patterns that enable authors to write high-quality textual requirements with minimal training overhead.

Key Benefits

• Reduces ambiguity in natural language requirements
• Eliminates common problems found in unconstrained requirements
• Easy to learn with minimal training overhead
• No specialist tools required for basic implementation
• Intuitive syntax that matches common English usage
• Particularly effective for non-native English speakers

2. Core Principles

2.1 Why Use EARS?

Problem Statement:

• System requirements are typically written in unconstrained natural language (NL), which is inherently imprecise
• Requirements authors often lack formal training in requirements writing
• Requirements problems propagate to lower development levels
• This creates unnecessary volatility and risk, impacting schedules and costs

EARS Solution:

• Provides structured guidance for writing requirements
• Maintains readability while increasing precision
• Reduces or eliminates common requirement defects
• Enables consistent quality across teams and projects

2.2 Core Structure

The basic EARS template follows temporal logic:

While <optional pre-condition(s)>, when <optional trigger>, the <system name> shall <system response>

Key Characteristics:

• Clauses always appear in the same order
• Follows temporal/chronological logic
• Keywords match common English usage
• Structure is intuitive and easy to understand

---

3. EARS Ruleset

3.1 Mandatory Elements

Each EARS requirement MUST contain:

Element	Quantity	Description
Pre-conditions	Zero or many	Conditions that must be true for requirement to be active
Trigger	Zero or one	Discrete event detected by the system
System name	One (required)	Explicit identification of the system/component
System responses	One or many	What the system must do when requirement becomes active

3.2 Clause Ordering

CRITICAL RULE: Clauses always appear in the same order:

1. Pre-condition(s) (if any)
2. Trigger (if any)
3. System name (always)
4. System response(s) (always)

This ordering follows temporal logic and makes requirements easier to read and understand.

3.3 Syntax Rules

• Use keywords consistently (While, When, Where, If...Then)
• Maintain explicit system name in every requirement
• Follow the "shall" construction for obligations
• Keep one requirement per statement
• Avoid combining patterns incorrectly

---

4. The Five EARS Patterns

4.1 Ubiquitous Requirements

Definition: Requirements that are always active throughout system operation.

Characteristics:

• No EARS keyword used
• Fundamental, constant properties
• No conditions or triggers
• Always enforceable

Syntax:

The <system name> shall <system response>

Examples:

✅ Good Examples:

The mobile phone shall have a mass of less than 150 grams.
The software shall be written in Python.
The ATM shall support withdrawal amounts in multiples of $20.
The user interface shall display text in Arial font, 12pt minimum.
The database shall encrypt all stored passwords using SHA-256 algorithm.

❌ Bad Examples (not ubiquitous):

The system shall display error messages.
(Missing: when/under what conditions?)

The app shall be fast.
(Vague, not measurable)

When to Use:

• Fundamental system properties (size, weight, material)
• Constant constraints (standards compliance, encoding)
• Persistent characteristics (always-on features)
• Universal rules (formatting, protocols)

---

4.2 State-Driven Requirements

Definition: Requirements active while a specified state or condition remains true.

Keyword: While

Characteristics:

• Activated by continuous states
• Remain active as long as condition persists
• Deactivated when state changes
• Pre-conditions define system/transaction states only

Syntax:

While <pre-condition(s)>, the <system name> shall <system response>

Examples:

✅ Good Examples:

While there is no card in the ATM, the ATM shall display "insert card to begin".
While in Do Not Disturb mode, the software shall silence incoming calls.
While the engine temperature exceeds 90°C, the system shall activate the cooling fan.
While the vehicle is in reverse gear, the backup camera shall display the rear view.
While battery level is below 20%, the device shall activate power saving mode.
While the user is logged in, the application shall display the user's dashboard.

❌ Bad Examples:

While the user clicks login, the system shall authenticate.
(This is an event, not a state - use "When" instead)

While processing, the system shall work correctly.
(Vague response, not measurable)

When to Use:

• Continuous monitoring situations
• Mode-dependent behaviors
• Threshold-based activations
• State-dependent operations

Key Distinction:

• State: A condition that persists over time (logged in, temperature above X, mode active)
• Event: A discrete occurrence at a point in time (button clicked, message received)

---

4.3 Event-Driven Requirements

Definition: Requirements triggered by a specific discrete event.

Keyword: When

Characteristics:

• Activated by discrete, detectable events
• One-time trigger causing specific response
• Response occurs after trigger is detected
• Used for normal system operations

Syntax:

When <trigger>, the <system name> shall <system response>

Examples:

✅ Good Examples:

When "mute" is selected, the laptop shall suppress all audio output.
When the payment is received, the app shall send a confirmation notification.
When the user presses the emergency stop button, the machine shall halt all operations within 2 seconds.
When the door is opened, the refrigerator shall activate the interior light.
When a new email arrives, the system shall display a notification badge.
When the user logs out, the system shall clear all session data.

❌ Bad Examples:

When the temperature is high, the fan shall run.
(This is a state, not an event - use "While" instead)

When the user wants to save, the system shall save.
("Wants to" is vague - be specific about the trigger)

When to Use:

• Button presses and user actions
• System events (startup, shutdown, messages)
• External triggers (signals, communications)
• Completion of operations

Key Distinction:

• Use When for normal operational events
• Use If...Then for error conditions and unwanted behaviors

---

4.4 Optional Feature Requirements

Definition: Requirements that apply only when a specific optional feature is present in the system configuration.

Keyword: Where

Characteristics:

• Conditional on feature presence
• Applies to product variants
• Feature may or may not be included
• Enables modular requirement sets

Syntax:

Where <feature is included>, the <system name> shall <system response>

Examples:

✅ Good Examples:

Where the car has a sunroof, the car shall have a sunroof control panel on the driver door.
Where the DisplayPort is present, the software shall allow users to select the maximum supported refresh rate.
Where GPS functionality is enabled, the device shall update location data every 5 seconds.
Where the premium package is purchased, the application shall provide access to advanced analytics.
Where wireless charging is available, the device shall indicate charging status via LED.
Where the vehicle includes adaptive cruise control, the system shall maintain a minimum 2-second following distance.

❌ Bad Examples:

Where the user has admin rights, the system shall allow file deletion.
(This is about user state, not an optional feature - use "While" instead)

Where possible, the system shall optimize performance.
(Escape clause, not an optional feature specification)

When to Use:

• Product line variations
• Optional hardware components
• Feature tier differentiation
• Add-on modules and packages
• Regional variants

Important Notes:

• Feature must be binary (present/absent)
• Not for conditional user permissions or runtime states
• Not an escape clause ("where possible", "where appropriate")

---

4.5 Unwanted Behavior Requirements

Definition: Requirements specifying system response to undesired situations, errors, faults, or exceptional conditions.

Keywords: If ... Then

Characteristics:

• Handle error conditions
• Manage fault scenarios
• Address exceptional situations
• Specify recovery behaviors
• Different from normal When events

Syntax:

If <trigger>, then the <system name> shall <system response>

Examples:

✅ Good Examples:

If an invalid credit card number is entered, then the website shall display "please re-enter credit card details".
If the password is entered incorrectly three times, then the app shall lock the account for 15 minutes.
If network connection is lost, then the system shall save all unsaved data locally.
If the sensor detects smoke, then the alarm shall activate within 3 seconds.
If disk space falls below 10%, then the system shall display a warning message.
If the database connection fails, then the application shall retry the connection every 30 seconds for up to 5 minutes.

❌ Bad Examples:

If the user clicks save, then the system shall save the file.
(This is normal operation, not unwanted - use "When" instead)

If error occurs, then system shall handle it.
(Too vague - specify the error type and response)

When to Use:

• Error handling
• Fault detection and recovery
• Invalid input scenarios
• System failures
• Security violations
• Resource exhaustion
• Timeout conditions

Critical Distinction:

Use Case	Pattern	Example
Normal operation	When	When the user clicks submit, the form shall be processed.
Error/fault	If...Then	If the form validation fails, then the system shall display error messages.

---

4.6 Complex Requirements

Definition: Requirements combining multiple EARS patterns for richer, multi-conditional system behavior.

Characteristics:

• Multiple EARS keywords combined
• Layered conditions and triggers
• More sophisticated scenarios
• Maintains temporal ordering

Syntax (Normal Operations):

While <pre-condition(s)>, When <trigger>, the <system name> shall <system response>

Syntax (Unwanted Behaviors):

While <pre-condition(s)>, If <trigger>, then the <system name> shall <system response>

Examples:

✅ Good Examples - Normal Operations:

While the aircraft is on ground, when reverse thrust is commanded, the engine control system shall enable reverse thrust.
While the system is in maintenance mode, when the diagnostics button is pressed, the system shall display the full diagnostic report.
While the vehicle speed exceeds 60 mph, when the driver applies brakes, the ABS system shall activate within 100 milliseconds.
While connected to external power, when the battery reaches 100% charge, the charging system shall switch to trickle charge mode.
While in night mode, when motion is detected, the camera shall activate infrared illumination.

✅ Good Examples - Unwanted Behaviors:

While the engine is running, if oil pressure drops below 20 psi, then the system shall illuminate the warning light and sound an alarm.
While data is being transmitted, if the connection is interrupted, then the system shall buffer the data and retry transmission.
While the user is editing a document, if the application crashes, then the system shall auto-save the current state.
While operating in automatic mode, if an obstacle is detected within 2 meters, then the vehicle shall initiate emergency braking.

❌ Bad Examples:

While logged in, when the user clicks save, where auto-save is enabled, the system shall save.
(Too complex - split into separate requirements)

When the button is pressed and the mode is active, the system shall respond.
(Use EARS keywords, not "and" - restructure as: While the mode is active, when the button is pressed...)

When to Use:

• Multi-conditional scenarios
• Context-dependent events
• Sophisticated control logic
• Safety-critical systems requiring multiple safeguards

Complexity Guidelines:

• Limit to 2 EARS keywords when possible
• If more complexity needed, consider splitting into multiple requirements
• Maintain readability - if it's confusing, simplify
• Follow temporal ordering strictly

---

5. Writing Quality EARS Requirements

5.1 Best Practices

1. Be Explicit About System Name

Always clearly identify what system/component is being specified.

✅ Good:

When the user clicks login, the authentication service shall verify credentials.

❌ Bad:

When the user clicks login, credentials shall be verified.
(Who verifies? System name missing)

2. Use Active Voice

The system performs the action.

✅ Good:

The system shall encrypt the data.

❌ Bad:

The data shall be encrypted by the system.
(Passive voice)

3. Be Specific and Measurable

Use concrete values, thresholds, and timing.

✅ Good:

When the download completes, the application shall display a confirmation message within 1 second.

❌ Bad:

When the download completes, the application shall quickly confirm.
(Vague - what is "quickly"?)

4. One Requirement Per Statement

Avoid combining multiple requirements with "and".

✅ Good:

Requirement 1: The system shall validate the email format.
Requirement 2: The system shall validate the password strength.

❌ Bad:

The system shall validate the email format and password strength.
(Two requirements - split them)

5. Use Consistent Terminology

Maintain uniform language across all requirements.

✅ Good:

Req 1: When the user clicks "Submit", the form shall be validated.
Req 2: When the user clicks "Cancel", the form shall be cleared.

❌ Bad:

Req 1: When the user presses "Submit", the form shall be validated.
Req 2: When the user selects "Cancel", the form shall be cleared.
(Inconsistent: clicks vs presses vs selects)

6. Avoid Vague Quantifiers

Replace subjective terms with measurable criteria.

❌ Avoid	✅ Use Instead
quickly	within 2 seconds
efficiently	using less than 50MB RAM
user-friendly	requiring no more than 3 clicks
reliable	with 99.9% uptime
secure	encrypted with AES-256

7. Follow Temporal Order

Pre-conditions → Triggers → System name → Response

✅ Good:

While in edit mode, when the save button is clicked, the application shall commit changes to the database.
(State → Event → System → Response)

❌ Bad:

The application shall commit changes when save is clicked while in edit mode.
(Confused ordering)

8. Be Unambiguous

Eliminate words that allow multiple interpretations.

❌ Avoid	Why?	✅ Use Instead
appropriate	Subjective	Specify exact criteria
reasonable	Undefined	Define specific threshold
adequate	Vague	State exact requirement
normally	Unclear frequency	Specify exact conditions
may/might	Optional?	Use "shall" for requirements

5.2 Common Pitfalls to Avoid

❌ DON'T:

1. Mix EARS keywords incorrectly

   When the system is running and if error occurs... ❌
   

2. Use passive voice constructions

   Data shall be processed by the system. ❌
   

3. Include unnecessary implementation details

   The system shall use a Redis cache to store session data. ❌
   (Unless technology choice is a requirement)
   

4. Create requirements with multiple "shall" statements

   The system shall validate input and shall display errors and shall log attempts. ❌
   

5. Use escape clauses

   The system shall respond quickly, if possible. ❌
   The system shall, where appropriate, validate data. ❌
   

6. Rely on implied context

   The system shall display the result. ❌
   (Which result? When? Under what conditions?)
   

7. Use "and" to combine requirements

   The system shall validate and save data. ❌
   

8. Omit units for numerical values

   The response time shall be less than 5. ❌
   (5 what? Seconds? Milliseconds?)
   

✅ DO:

1. Follow established EARS patterns consistently
2. Make all conditions and triggers explicit
3. Focus on what the system must do, not how
4. Use one "shall" per requirement
5. Define clear, testable criteria
6. State all necessary context
7. Include units for all measurements
8. Verify each requirement is verifiable

5.3 Transformation Examples

Example 1: Adding Clarity

Before (ambiguous):

The system shall break network connection.

After (EARS - Event-Driven):

When the disconnect button is pressed, the software shall terminate the network connection.

Enhanced (EARS - Complex with timing):

While connected to the network, when the disconnect button is pressed, the software shall terminate the network connection within 2 seconds.

Example 2: Making Measurable

Before (vague):

The system shall respond quickly to user input.

After (EARS - Event-Driven with measurement):

When the user submits a form, the system shall display confirmation within 500 milliseconds.

Example 3: Separating Concerns

Before (multiple requirements):

The system shall validate email and password and display errors.

After (separate EARS requirements):

Requirement 1: When the user submits the login form, the system shall validate the email address format.

Requirement 2: When the user submits the login form, the system shall validate the password meets complexity requirements.

Requirement 3: If email validation fails, then the system shall display "Invalid email format" below the email field.

Requirement 4: If password validation fails, then the system shall display "Password does not meet requirements" below the password field.

Example 4: Defining State vs Event

Before (confused):

When the temperature is high, the fan runs.

After (EARS - State-Driven):

While the CPU temperature exceeds 80°C, the cooling system shall operate the fan at maximum speed.

Example 5: Error Handling

Before (unclear):

The system handles errors appropriately.

After (EARS - Unwanted Behavior):

If the database query times out after 30 seconds, then the system shall log the error and display "Service temporarily unavailable" to the user.

5.4 Verification Checklist

Use this checklist to verify each requirement:

• Follows correct EARS pattern
• Has explicit system name
• Uses active voice
• Contains only one "shall"
• Is verifiable/testable
• Includes units for numerical values
• Contains no escape clauses
• Contains no vague terms
• Follows temporal ordering
• Is grammatically correct
• Is unambiguous
• Is necessary (not nice-to-have)
• Is achievable
• Uses consistent terminology with other requirements

---

6. Pattern Selection Guide

6.1 Decision Tree

Use this flowchart to select the appropriate EARS pattern:

START
  │
  ├─ Is the requirement always active?
  │  └─ YES → UBIQUITOUS PATTERN
  │       The <system> shall <response>
  │
  ├─ Does it depend on a continuous state or condition?
  │  └─ YES → STATE-DRIVEN PATTERN
  │       While <condition>, the <system> shall <response>
  │
  ├─ Is it triggered by a discrete event?
  │  │
  │  ├─ Is it normal operation?
  │  │  └─ YES → EVENT-DRIVEN PATTERN
  │  │       When <trigger>, the <system> shall <response>
  │  │
  │  └─ Is it an error/fault/unwanted behavior?
  │     └─ YES → UNWANTED BEHAVIOR PATTERN
  │          If <trigger>, then <system> shall <response>
  │
  ├─ Does it only apply to optional features?
  │  └─ YES → OPTIONAL FEATURE PATTERN
  │       Where <feature>, the <system> shall <response>
  │
  └─ Does it require multiple conditions/triggers?
     └─ YES → COMPLEX PATTERN
          Combine patterns as needed

6.2 Pattern Selection Examples

Scenario 1: Maximum Weight Requirement

Question: The phone must weigh less than 200g.

Analysis:

• Always active? YES
• No conditions or triggers

Pattern: Ubiquitous

The mobile phone shall have a mass of less than 200 grams.

Scenario 2: Low Battery Warning

Question: Show warning when battery is low.

Analysis:

• Always active? NO
• Continuous state? YES (battery level)
• Below threshold is a persistent state

Pattern: State-Driven

While the battery level is below 15%, the device shall display a low battery warning.

Scenario 3: Save Button

Question: Save the document when user clicks save.

Analysis:

• Always active? NO
• Continuous state? NO
• Discrete event? YES (button click)
• Normal operation? YES

Pattern: Event-Driven

When the user clicks the save button, the application shall save the document to persistent storage.

Scenario 4: Invalid Password

Question: Handle incorrect password entry.

Analysis:

• Always active? NO
• Continuous state? NO
• Discrete event? YES
• Normal operation? NO (error condition)

Pattern: Unwanted Behavior

If an incorrect password is entered three consecutive times, then the system shall lock the account for 30 minutes.

Scenario 5: Premium Features

Question: Premium users get advanced analytics.

Analysis:

• Always active? NO
• Optional feature? YES (premium subscription)

Pattern: Optional Feature

Where the premium subscription is active, the application shall provide access to advanced analytics dashboards.

Scenario 6: Emergency Stop While Running

Question: Stop machine immediately if emergency button pressed while operating.

Analysis:

• Multiple conditions? YES
• State (operating) + Event (button press)
• Safety-critical

Pattern: Complex

While the machine is in operation, when the emergency stop button is pressed, the control system shall halt all moving parts within 500 milliseconds.

6.3 Quick Pattern Selector

If the requirement...	Use Pattern	Keyword(s)
Is always true/active	Ubiquitous	(none)
Depends on a lasting state or mode	State-Driven	While
Responds to a user action or system event	Event-Driven	When
Handles errors, faults, or problems	Unwanted Behavior	If...Then
Applies only to certain product variants	Optional Feature	Where
Needs multiple conditions combined	Complex	Multiple

---

7. Integration with INCOSE Guidelines

EARS works synergistically with INCOSE (International Council on Systems Engineering) Guidelines for Writing Requirements. Together, they provide comprehensive guidance for high-quality requirements.

7.1 INCOSE Quality Characteristics

Every requirement should exhibit these characteristics:

1. Unambiguous

• Only one interpretation possible
• No subjective terms
• Clear pronouns and references

EARS contribution: Structured patterns eliminate structural ambiguity

2. Verifiable

• Can be tested or inspected
• Has measurable acceptance criteria
• Observable outcomes

EARS contribution: Clear trigger-response format enables test case derivation

3. Complete

• Fully describes the capability or constraint
• All necessary information present
• No missing context

EARS contribution: Explicit pre-conditions and triggers ensure completeness

4. Consistent

• No conflicts with other requirements
• Uniform terminology
• Aligned with system architecture

EARS contribution: Consistent keyword usage and structure

5. Traceable

• Can be traced to source (stakeholder needs, regulations)
• Can be traced forward to design and tests
• Unique identification

EARS contribution: Clear structure enables automated traceability

6. Feasible

• Technically achievable
• Within budget constraints
• Within schedule constraints

EARS contribution: Clear specification helps assess feasibility

7. Necessary

• Truly required for the system
• Not nice-to-have
• Adds value

EARS contribution: Explicit triggers help identify truly necessary requirements

7.2 INCOSE Rules to Apply with EARS

Avoid Passive Voice

❌ Bad:

Data shall be validated by the system.

✅ Good (EARS + INCOSE):

When the user submits the form, the system shall validate the input data.

Eliminate Superfluous Infinitives

❌ Bad:

The system shall be able to process transactions.

✅ Good (EARS + INCOSE):

When a transaction is initiated, the system shall process the transaction within 3 seconds.

No Immeasurable Quantification

❌ Immeasurable	✅ Measurable (EARS)
quickly	within 2 seconds
efficiently	using less than 100MB memory
user-friendly	requiring no more than 3 clicks to complete task
robust	handling 10,000 concurrent users without degradation
secure	encrypted using AES-256 with key rotation every 90 days

Avoid Optional Escape Clauses

❌ Bad:

The system shall, if possible, save user preferences.

✅ Good (EARS + INCOSE):

When the user modifies preferences, the system shall save the changes to persistent storage.

Use Consistent Terminology

Create and maintain a project glossary. Use the same term throughout all requirements.

Example:

• Choose "user" OR "operator" (not both)
• Choose "terminate" OR "end" OR "close" (pick one)
• Choose "display" OR "show" (be consistent)

One Requirement Per Statement

❌ Bad:

The system shall validate input, log the validation result, and notify the user of any errors.

✅ Good (EARS + INCOSE):

Requirement 1: When the user submits input, the system shall validate the data format.

Requirement 2: When input validation completes, the system shall log the validation result with timestamp.

Requirement 3: If input validation fails, then the system shall display specific error messages to the user.

Include Units for Numerical Values

❌ Bad:

The response time shall be less than 5.

✅ Good (EARS + INCOSE):

When the user requests a page, the server shall deliver the response within 5 seconds.

7.3 Combined EARS + INCOSE Quality Checklist

Use this comprehensive checklist for maximum quality:

Structure (EARS):

• Uses correct EARS pattern
• Keywords used properly
• Temporal ordering followed
• System name explicit

Content (INCOSE):

• Unambiguous language
• Verifiable/testable
• Complete information
• Consistent terminology
• Traceable to source
• Technically feasible
• Truly necessary

Language Quality (INCOSE):

• Active voice
• No escape clauses
• No passive constructions
• Measurable criteria
• Units specified
• No superfluous infinitives
• Grammatically correct

Best Practices:

• One requirement per statement
• Unique identifier assigned
• Properly categorized
• Reviewed by stakeholders
• Version controlled

7.4 EARS and INCOSE: Synergistic Benefits

EARS Provides	INCOSE Adds	Combined Benefit
Structural patterns	Content quality rules	Well-formed, high-quality requirements
Temporal logic	Verification guidance	Testable specifications
Keyword consistency	Terminology standards	Uniform documentation
Pattern templates	Quality characteristics	Complete, traceable requirements
Easy adoption	Comprehensive guidelines	Professional requirements engineering

---

8. Implementation Recommendations

8.1 Getting Started with EARS

Phase 1: Preparation (Week 1)

Activities:

1. Form a Requirements Working Group

   • Include requirements authors, reviewers, and key stakeholders
   • Assign an EARS champion

2. Conduct Initial Training

   • 2-hour workshop on EARS fundamentals
   • Review the five patterns with examples
   • Practice exercises transforming bad requirements to EARS

3. Create Organization-Specific Templates

   • Develop fill-in-the-blank templates for each pattern
   • Include domain-specific examples
   • Create quick reference cards

4. Set Up Supporting Infrastructure

   • Choose requirement management tool (if needed)
   • Create requirement ID scheme
   • Establish review process

Deliverables:

• Trained team
• Template library
• Quick reference materials
• Implementation plan

Phase 2: Pilot Project (Weeks 2-4)

Activities:

1. Select Pilot Project

   • Choose a small, manageable project
   • Ensure team commitment
   • Define success criteria

2. Apply EARS to New Requirements

   • Use templates for all new requirements
   • Conduct peer reviews for EARS compliance
   • Document lessons learned

3. Transform Existing Requirements

   • Select 20-30 existing requirements
   • Rewrite using EARS patterns
   • Compare clarity and quality

4. Collect Feedback

   • Survey team members
   • Identify pain points
   • Gather improvement suggestions

Deliverables:

• Pilot requirements set
• Comparison metrics (before/after)
• Lessons learned document
• Updated templates based on feedback

Phase 3: Organization Rollout (Weeks 5-12)

Activities:

1. Refine Approach

   • Update templates based on pilot feedback
   • Create domain-specific examples library
   • Develop advanced training materials

2. Train All Requirements Authors

   • Conduct workshops across organization
   • Provide hands-on practice
   • Offer one-on-one coaching

3. Establish Standards

   • Make EARS mandatory for new requirements
   • Set quality gates in review process
   • Define compliance metrics

4. Provide Ongoing Support

   • Office hours for questions
   • Internal community of practice
   • Regular refresher training

Deliverables:

• Organization-wide standards document
• Training materials
• Examples library
• Support structure

8.2 Creating Templates

Template Structure

Each template should include:

1. Pattern name and description
2. Syntax template with placeholders
3. Domain-specific examples (3-5)
4. Common mistakes to avoid
5. Verification checklist

Example: Event-Driven Template

## Event-Driven Requirement Template

**Use when:** A discrete event triggers a system response

**Syntax:**
When <trigger>, the <system name> shall <system response>

**Fill-in Guide:**
- <trigger>: Specific event that activates this requirement (button click, message received, timer expires)
- <system name>: Explicit name of system/component
- <system response>: What the system must do (include timing, values, units)

**Examples for [Your Domain]:**
1. When the user clicks "Submit Order", the e-commerce system shall process the payment within 5 seconds.
2. When a sensor detects motion, the security system shall activate the alarm within 500 milliseconds.
3. When the download completes, the application shall display a success notification.

**Common Mistakes:**
❌ When the system is running... (This is a state, use "While")
❌ When the user wants to... (Be specific about the actual trigger)
❌ When clicked... (Include explicit trigger: "When the Save button is clicked")

**Verification:**
- [ ] Trigger is a discrete event (not a continuous state)
- [ ] System name is explicit
- [ ] Response is measurable
- [ ] Timing/values specified where relevant

8.3 Conducting EARS Training

Training Session Outline (2 hours)

Part 1: Introduction (20 minutes)

• Why requirements matter
• Common requirements problems
• Introduction to EARS
• Benefits and adoption

Part 2: The Five Patterns (60 minutes)

• Present each pattern (10 min each)
  • Definition and syntax
  • When to use
  • Good and bad examples
  • Practice exercise
• Interactive Q&A

Part 3: Hands-On Practice (30 minutes)

• Provide 10 poorly-written requirements
• Teams transform them using EARS
• Groups present and discuss
• Instructor feedback

Part 4: Implementation (10 minutes)

• Template usage
• Review process
• Where to get help
• Next steps

Practice Exercises

Exercise Set 1: Pattern Identification

Identify the correct EARS pattern for each requirement:

1. "The system shall authenticate users."
   Answer: Ubiquitous or Event-Driven (need more context)
   Better: "When the user clicks login, the system shall authenticate the credentials."

2. "When low on fuel, the car should warn the driver."
   Answer: State-Driven (continuous condition)
   Better: "While fuel level is below 10%, the vehicle shall display a low fuel warning."

3. "If the user enters wrong password, lock them out."
   Answer: Unwanted Behavior
   Better: "If incorrect password is entered three times, then the system shall lock the account for 15 minutes."

Exercise Set 2: Requirement Transformation

Transform these requirements using EARS:

1. "The system processes payments quickly."
   Answer: "When the user confirms payment, the system shall process the transaction within 3 seconds."

2. "Error messages should be displayed."
   Answer: "If input validation fails, then the system shall display specific error messages below the relevant input fields."

3. "Premium users get extra features."
   Answer: "Where premium subscription is active, the application shall provide access to advanced reporting features."

8.4 Tool Support

Requirements Management Tools with EARS Support

QVscribe

• Automated EARS templating
• Fill-in-the-blank scenario selection
• INCOSE compliance checking
• Quality analysis
• Integration with requirements tools

Jama Connect Advisor

• EARS pattern verification
• Real-time quality checking
• Integrated with Jama Connect platform
• INCOSE guideline compliance
• Team collaboration features

Visure Requirements ALM

• Predefined EARS templates
• AI-powered assistance (Vivia)
• EARS and INCOSE rule enforcement
• Customizable workflows
• Compliance management

RAT-AUTHORING Tool

• EARS pattern implementation
• Integration with any RMS
• Template-based authoring
• Quality metrics

Tool Selection Criteria

Consider these factors:

1. Integration: Does it integrate with your existing tools?
2. Automation: What level of automation do you need?
3. Team Size: Does pricing scale with your team?
4. Training: How much training is required?
5. Support: What support options are available?
6. Compliance: Does it support your industry standards?

Starting Without Tools

You can implement EARS successfully without specialized tools:

1. Use Templates in Document Processors

   • Create Word/Google Docs templates
   • Use styles for consistency
   • Create macros for common patterns

2. Spreadsheet-Based Approach

   • Requirement ID | Pattern Type | Requirement Text | Status
   • Use data validation for pattern types
   • Conditional formatting for quality indicators

3. Plain Text with Version Control

   • Markdown files in Git
   • Use templates for each pattern
   • Code review process for requirements review

4. Collaborative Platforms

   • Confluence/SharePoint with templates
   • Wiki-based requirements
   • Comment-based reviews

8.5 Review Process

EARS Compliance Review Checklist

Structural Review:

• Correct EARS pattern used
• Keywords used properly (While/When/Where/If-Then)
• Temporal ordering followed
• System name is explicit
• One requirement per statement

Content Review:

• Requirement is verifiable
• All conditions clearly stated
• Triggers are specific
• Responses are measurable
• Units specified for all values
• No vague terms (fast, efficient, user-friendly)
• No escape clauses (if possible, where appropriate)

Language Review:

• Active voice used
• Consistent terminology
• Grammatically correct
• No passive constructions
• Clear and concise

Traceability Review:

• Unique ID assigned
• Source documented
• Category assigned
• Priority set

Peer Review Process

1. Self-Review: Author checks against EARS patterns
2. Peer Review: Colleague reviews for compliance
3. Technical Review: Domain expert reviews for correctness
4. Stakeholder Review: End users/customers validate intent
5. Final Approval: Requirements lead approves

Review Metrics

Track these metrics to measure improvement:

Metric	Target	Measurement
EARS Pattern Compliance	>95%	% requirements following correct pattern
First-Pass Acceptance	>80%	% requirements passing initial review
Defect Density	<5 per 100 req	Defects found per 100 requirements
Review Cycle Time	<3 days	Average time from submission to approval
Requirement Volatility	<10%	% requirements changed after baseline

8.6 Organizational Adoption Strategy

Change Management Approach

1. Secure Leadership Support

• Present business case (reduced rework, lower risk)
• Show ROI from pilot project
• Get executive sponsorship

2. Communicate Benefits

• Clearer requirements = fewer defects
• Faster reviews = quicker delivery
• Better traceability = easier compliance
• Reduced training time for new team members

3. Address Resistance Common objections and responses:

Objection	Response
"It's too rigid"	EARS provides structure while allowing flexibility in content
"We don't have time"	Initial investment saves time through fewer rework cycles
"Our domain is different"	EARS is domain-agnostic; adapt examples to your context
"Our customers won't like it"	Customers prefer clear requirements; EARS improves clarity

4. Celebrate Successes

• Share success stories
• Recognize early adopters
• Publish metrics showing improvement
• Award "best EARS requirement" monthly

Scaling Across Organization

For Small Teams (5-20 people):

• Single training session
• Informal peer reviews
• Shared template library
• Weekly office hours for questions

For Medium Organizations (20-100 people):

• Multiple training sessions
• Formal review process
• Tool-supported templates
• EARS champions in each team
• Monthly community of practice meetings

For Large Enterprises (100+ people):

• Training program with certification
• Centralized requirements team
• Enterprise tool deployment
• Standards and governance board
• Dedicated EARS support team
• Integration with corporate processes

8.7 Continuous Improvement

Lessons Learned Process

After Each Project:

1. Conduct retrospective focused on requirements quality
2. Identify EARS patterns that worked well
3. Identify areas for improvement
4. Update templates and examples
5. Share learnings organization-wide

Questions to Ask:

• Which requirements had the most defects?
• Which EARS patterns caused confusion?
• What domain-specific examples should we add?
• How can we improve our templates?
• What additional training is needed?

Template Evolution

Regular Template Reviews (Quarterly):

1. Analyze requirement defect patterns
2. Gather user feedback on templates
3. Add new domain-specific examples
4. Remove or clarify confusing examples
5. Update based on EARS best practices
6. Version and publish updated templates

Knowledge Base Development

Build an organizational knowledge base containing:

1. Pattern Library

   • Template for each EARS pattern
   • 10+ examples per pattern from your domain
   • Anti-patterns (what not to do)

2. FAQ Database

   • Common questions and answers
   • Tricky scenarios and solutions
   • Edge cases and how to handle them

3. Training Materials

   • Presentation slides
   • Video tutorials
   • Practice exercises with solutions
   • Case studies from your organization

4. Quality Metrics Dashboard

   • EARS compliance rates
   • Review cycle times
   • Defect trends
   • Before/after comparisons

---

9. Advanced Considerations

9.1 Multi-Language Support

EARS translates effectively across languages because of its structured approach.

Translation Guidelines

1. Keyword Consistency Establish standard translations for EARS keywords:

English	Spanish	German	French	Mandarin
While	Mientras	Während	Tandis que	当...时
When	Cuando	Wenn	Lorsque	当
Where	Donde	Wo	Où	在...情况下
If...Then	Si...Entonces	Wenn...Dann	Si...Alors	如果...那么
shall	deberá	muss	doit	应

2. Structure Preservation Maintain the same clause ordering regardless of language:

• Pre-conditions first
• Trigger second
• System name third
• Response last

3. Translation Best Practices

• Translate each clause independently
• Preserve measurable values and units
• Keep system names in original language (if technical terms)
• Maintain temporal logic
• Verify with native speaker

Example Multi-Language Requirement

English:

When the user clicks the save button, the application shall save the document within 2 seconds.

Spanish:

Cuando el usuario hace clic en el botón guardar, la aplicación deberá guardar el documento dentro de 2 segundos.

German:

Wenn der Benutzer auf die Schaltfläche Speichern klickt, muss die Anwendung das Dokument innerhalb von 2 Sekunden speichern.

French:

Lorsque l'utilisateur clique sur le bouton d'enregistrement, l'application doit enregistrer le document dans les 2 secondes.

Benefits for Non-Native English Speakers

EARS particularly helps teams where English is not the primary language:

1. Clear Structure: Pattern templates reduce grammar confusion
2. Consistent Format: Same structure reduces ambiguity
3. Keyword Simplicity: Limited vocabulary to learn
4. Translation Ease: Structure translates directly
5. Quality Consistency: Same quality regardless of language proficiency

9.2 Requirements Traceability

EARS enhances traceability through its structured approach.

Traceability Links

Upstream Traceability (to sources):

Business Need → Stakeholder Requirement → System Requirement (EARS)

Example:

Business Need: Reduce customer wait time
  ↓
Stakeholder Req: System shall provide fast transaction processing
  ↓
EARS System Req: When the user submits a payment request, the payment system shall process the transaction within 3 seconds.

Downstream Traceability (to implementation):

EARS Requirement → Design Element → Test Case → Code

Example:

EARS Requirement: When the user clicks logout, the system shall clear all session data.
  ↓
Design: SessionManager.clearSession() method
  ↓
Test Case: TC-101: Verify session cleared on logout
  ↓
Code: logout_handler.py::clear_session()

Automated Traceability with EARS

EARS patterns enable automated traceability:

1. Parse Requirement Structure

When <trigger> → Maps to → Use Case Trigger
the <system> → Maps to → Component/Module
shall <response> → Maps to → Test Assertion

2. Generate Test Cases Automatically

EARS: When the user enters invalid email, the system shall display "Invalid email format".

Auto-generated Test Case:
  Test ID: TC-REQ-123
  Preconditions: User registration form displayed
  Test Steps:
    1. Enter invalid email (e.g., "notanemail")
    2. Click submit
  Expected Result:
    Display message: "Invalid email format"

3. Link to Code Components

System name "authentication service" → maps to → auth_service module
Response "validate credentials" → maps to → validate() method

Traceability Matrix Example

Req ID	EARS Pattern	Business Need	Design Element	Test Case	Code Module
REQ-001	Event-Driven	Fast login	AuthController.login()	TC-001	auth.py
REQ-002	Unwanted	Secure access	AuthController.lockAccount()	TC-002	auth.py
REQ-003	State-Driven	Session mgmt	SessionManager.monitor()	TC-003	session.py

9.3 Use Case Derivation from EARS

EARS requirements can be systematically transformed into use cases.

Mapping EARS to Use Cases

EARS Component → Use Case Element:

EARS Element	Maps To	Example
System name	Actor or System	"authentication service" → System
When/If trigger	Use Case Trigger	"user clicks login" → Trigger
While condition	Precondition	"while logged in" → Precondition
Response	Main Success Scenario step	"shall validate credentials" → Step

Automated Use Case Generation

Example EARS Requirement:

When the user clicks the checkout button, the shopping cart system shall calculate the total price including taxes and shipping.

Generated Use Case:

Use Case: Calculate Cart Total
Actor: User
Trigger: User clicks checkout button
Preconditions: Shopping cart contains items
Main Success Scenario:
  1. System retrieves cart items
  2. System calculates subtotal
  3. System calculates applicable taxes
  4. System calculates shipping cost
  5. System displays total price
Postconditions: Total price calculated and displayed

Complex Example

EARS Requirements Set:

REQ-1: When the user clicks checkout, the system shall validate the cart contains items.
REQ-2: If the cart is empty, then the system shall display "Your cart is empty".
REQ-3: While items are in cart, when checkout is clicked, the system shall calculate the total.
REQ-4: When total is calculated, the system shall display the payment form.

Generated Use Case:

Use Case: Checkout Process
Actor: User
Trigger: User clicks checkout button

Main Success Scenario:
  1. System validates cart contains items [REQ-1]
  2. System calculates total price [REQ-3]
  3. System displays payment form [REQ-4]

Alternate Flow 1: Empty Cart [REQ-2]
  1a. If cart is empty
  1b. System displays "Your cart is empty"
  1c. Use case ends

9.4 Automation Opportunities

Automated Quality Analysis

Tool Capabilities:

1. Pattern Recognition: Identify which EARS pattern is used
2. Compliance Checking: Verify correct pattern structure
3. Keyword Detection: Ensure proper keyword usage
4. Completeness Analysis: Check for required elements
5. Consistency Verification: Compare terminology across requirements

Example Automated Checks:

def validate_ears_requirement(req_text):
    checks = {
        'has_system_name': False,
        'has_shall': False,
        'pattern_identified': None,
        'issues': []
    }
    
    # Check for system name
    if 'the <system>' in req_text.lower():
        checks['issues'].append("System name not specified (still using placeholder)")
    
    # Check for shall
    if 'shall' not in req_text.lower():
        checks['issues'].append("Missing 'shall' - requirement may not be obligatory")
    else:
        checks['has_shall'] = True
        # Check for multiple shalls
        if req_text.lower().count('shall') > 1:
            checks['issues'].append("Multiple 'shall' statements - split into separate requirements")
    
    # Identify pattern
    if req_text.lower().startswith('when'):
        checks['pattern_identified'] = 'Event-Driven'
    elif req_text.lower().startswith('while'):
        checks['pattern_identified'] = 'State-Driven'
    elif req_text.lower().startswith('where'):
        checks['pattern_identified'] = 'Optional Feature'
    elif req_text.lower().startswith('if'):
        if 'then' in req_text.lower():
            checks['pattern_identified'] = 'Unwanted Behavior'
        else:
            checks['issues'].append("If statement missing 'then' - incomplete pattern")
    elif 'when' not in req_text.lower() and 'while' not in req_text.lower():
        checks['pattern_identified'] = 'Ubiquitous'
    
    return checks

Automated Test Generation

From EARS requirements, automatically generate:

1. Test Case Templates

   EARS: When X happens, system shall do Y within Z time
   
   Test Template:
   - Setup: Prepare conditions
   - Action: Trigger X
   - Assert: Verify Y occurs
   - Assert: Verify timing <= Z
   

2. Acceptance Criteria

   EARS: While A is true, when B occurs, system shall C
   
   Acceptance Criteria:
   ✓ Verify condition A is detectable
   ✓ Verify event B triggers response
   ✓ Verify response C is measurable
   ✓ Verify response only occurs when A is true
   

3. Boundary Tests

   EARS: While temperature exceeds 80°C, system shall activate cooling
   
   Boundary Tests:
   - Temperature = 79°C → cooling off
   - Temperature = 80°C → cooling on
   - Temperature = 81°C → cooling on
   

AI-Assisted Requirements

AI Applications with EARS:

1. Requirement Suggestions

   • AI suggests EARS pattern based on informal description
   • Provides fill-in templates
   • Offers similar examples from repository

2. Quality Improvement

   • Identifies vague terms and suggests specific values
   • Detects passive voice and suggests active alternatives
   • Recommends terminology from project glossary

3. Completeness Checking

   • Identifies missing preconditions
   • Suggests timing requirements
   • Highlights missing error handling

4. Automated Review

   • Checks EARS compliance
   • Verifies INCOSE rule adherence
   • Generates review comments

9.5 Domain-Specific Adaptations

Aerospace Domain

Typical Patterns:

• Heavy use of state-driven requirements (flight phases)
• Complex requirements with multiple safety conditions
• Precise timing requirements

Example:

While the aircraft is in flight, if an engine failure is detected, then the flight control system shall transfer control to remaining engines within 500 milliseconds and alert the pilot.

Medical Devices

Typical Patterns:

• Unwanted behavior requirements for safety
• State-driven for operational modes
• Precise measurement requirements

Example:

While in patient monitoring mode, if heart rate drops below 40 bpm, then the device shall trigger an audible alarm within 1 second and alert the nursing station.

Automotive

Typical Patterns:

• State-driven for vehicle modes
• Event-driven for user interactions
• Complex requirements for safety systems

Example:

While the vehicle speed exceeds 30 mph, when the driver applies the brake pedal, the Anti-lock Braking System shall modulate brake pressure to prevent wheel lockup.

Financial Systems

Typical Patterns:

• Event-driven for transactions
• Unwanted behavior for error conditions
• Precise value requirements

Example:

When a withdrawal request exceeds the account balance, then the system shall reject the transaction and display "Insufficient funds" to the user.

IoT/Embedded Systems

Typical Patterns:

• State-driven for power modes
• Event-driven for sensor inputs
• Timing-critical requirements

Example:

While in sleep mode, when motion is detected, the sensor shall wake the system within 100 milliseconds and transmit the event data.

---

10. Quick Reference Card

Pattern Quick Reference

Pattern	Keyword(s)	Template	Use For
Ubiquitous	(none)	The shall	Always-active properties, constants
State-Driven	While	While , the shall	Continuous state dependencies, modes
Event-Driven	When	When , the shall	Discrete events, user actions
Optional Feature	Where	Where , the shall	Product variants, optional modules
Unwanted Behavior	If...Then	If , then shall	Errors, faults, exceptions
Complex	Multiple	Combine patterns	Multi-condition scenarios

Common Keywords

Keyword	Meaning	Position
While	During continuous state/condition	Beginning (pre-condition)
When	At discrete event occurrence	Beginning (trigger)
Where	If optional feature present	Beginning (feature)
If...Then	In unwanted/error situation	Beginning (error trigger)
shall	Mandatory obligation	Before response
the	Explicit system identification	Before shall

Quality Checklist (Short Form)

Structure:

• Correct EARS pattern
• Proper keywords
• Temporal ordering
• Explicit system name

Content:

• Verifiable/testable
• Measurable criteria
• Complete information
• No vague terms

Language:

• Active voice
• One "shall"
• Units specified
• No escape clauses

Decision Tree (Simplified)

Always active? → Ubiquitous (no keyword)
Continuous state? → State-Driven (While)
Normal event? → Event-Driven (When)
Error/fault? → Unwanted Behavior (If...Then)
Optional feature? → Optional Feature (Where)
Multiple conditions? → Complex (combine)

Common Mistakes

❌ Avoid	✅ Use Instead
quickly, fast	within X seconds
user-friendly	requiring no more than X clicks
efficient	using less than X memory/CPU
appropriate, reasonable	specific measurable criteria
if possible	remove escape clause, make firm requirement
Data shall be validated	System shall validate data (active voice)
System shall X and Y	Split into two requirements
When temperature is high	While temperature exceeds 80°C (be specific)

EARS + INCOSE Rules

1. Active voice only
2. No escape clauses
3. Measurable criteria
4. Include units
5. One requirement per statement
6. Consistent terminology
7. Explicit system name
8. Verifiable/testable

Pattern Examples (One-Liner)

Ubiquitous: The mobile phone shall have a mass of less than 200 grams.

State-Driven: While battery is below 15%, the device shall display low battery warning.

Event-Driven: When save is clicked, the app shall save the document within 2 seconds.

Optional Feature: Where GPS is enabled, the device shall update location every 5 seconds.

Unwanted Behavior: If password is incorrect 3 times, then system shall lock account for 15 minutes.

Complex: While aircraft is on ground, when reverse thrust is commanded, the engine shall enable reverse thrust.

---

11. Summary

Key Takeaways

1. EARS provides structure without complexity

   • Five simple patterns cover most requirements
   • Intuitive keywords match natural language
   • Minimal training required

2. EARS improves requirement quality

   • Reduces ambiguity through consistent structure
   • Eliminates common defects
   • Enhances verifiability and testability

3. EARS enables better collaboration

   • Consistent format aids communication
   • Clear for technical and non-technical stakeholders
   • Effective across languages and cultures

4. EARS integrates with industry standards

   • Complements INCOSE guidelines
   • Supports regulatory compliance
   • Enables automated quality checking

5. EARS scales across organizations

   • Works for teams of any size
   • Applicable to any domain
   • Supports both simple and complex systems

Implementation Success Factors

1. Leadership Support: Executive sponsorship ensures adoption
2. Proper Training: Invest in comprehensive training programs
3. Good Templates: Domain-specific examples accelerate learning
4. Tool Support: Consider tools but start simple
5. Continuous Improvement: Evolve practices based on feedback

Recommended Next Steps

1. Learn the Patterns

   • Study the five EARS patterns
   • Practice with examples
   • Transform existing requirements

2. Start Small

   • Pilot with one project
   • Gather feedback
   • Refine approach

3. Build Templates

   • Create pattern templates
   • Develop domain examples
   • Distribute to team

4. Establish Process

   • Define review procedures
   • Set quality standards
   • Track metrics

5. Scale Gradually

   • Expand to more projects
   • Train more people
   • Build organizational capability

Long-Term Benefits

Quality Improvement:

• Fewer requirement defects
• Reduced rework
• Higher customer satisfaction

Cost Reduction:

• Less time in requirements reviews
• Fewer design changes
• Reduced testing effort

Risk Mitigation:

• Clearer specifications
• Better traceability
• Improved compliance

Team Efficiency:

• Faster onboarding
• Better communication
• Consistent quality

Resources

Official EARS Information:

• Alistair Mavin's website: https://alistairmavin.com/ears/
• Original paper: Mavin, A., et al. (2009). "Easy Approach to Requirements Syntax (EARS)"

INCOSE Resources:

• INCOSE Guide for Writing Requirements (Version 3, 2019)
• INCOSE Requirements Working Group

Tools:

• QVscribe: Automated EARS templating
• Jama Connect Advisor: EARS compliance checking
• Visure Requirements ALM: EARS templates with AI support

Training:

• EARS workshops available worldwide
• University courses in requirements engineering
• Online tutorials and webinars

---

Appendix: Additional Examples by Domain

Software Applications

Ubiquitous: The web application shall support concurrent access by 10,000 users.

State-Driven: While a file upload is in progress, the application shall display a progress bar showing percentage complete.

Event-Driven: When the user clicks "Forgot Password", the system shall send a password reset email within 30 seconds.

Optional Feature: Where two-factor authentication is enabled, the system shall require a verification code after password entry.

Unwanted Behavior: If the database connection fails, then the application shall display a maintenance page and log the error.

Complex: While the user is logged in, when the session exceeds 30 minutes of inactivity, the system shall automatically log out the user.

Embedded Systems

Ubiquitous: The microcontroller shall operate on a power supply between 3.0V and 3.6V.

State-Driven: While in low-power mode, the device shall consume less than 10 microamperes.

Event-Driven: When an interrupt signal is received on GPIO pin 4, the processor shall execute the interrupt service routine within 50 microseconds.

Optional Feature: Where the external temperature sensor is connected, the system shall read temperature every 100 milliseconds.

Unwanted Behavior: If the watchdog timer expires, then the system shall perform a hardware reset.

Complex: While battery voltage is below 3.2V, if a high-power operation is requested, then the system shall reject the request and alert the user.

Telecommunications

Ubiquitous: The VoIP system shall support the G.711 audio codec.

State-Driven: While a call is active, the system shall maintain less than 150ms end-to-end latency.

Event-Driven: When an incoming call is received, the system shall ring all registered devices simultaneously.

Optional Feature: Where call recording is enabled, the system shall store recordings in WAV format with 16-bit depth at 48kHz sample rate.

Unwanted Behavior: If network packet loss exceeds 5%, then the system shall switch to a lower bitrate codec.

Complex: While the SIP account is registered, when a call invitation is received, the system shall respond with a 180 Ringing message within 500 milliseconds.

Medical Devices

Ubiquitous: The blood pressure monitor shall have an accuracy of ±3 mmHg.
State-Driven: While measurement is in progress, the device shall prevent user interface interactions.
Event-Driven: When the measurement is complete, the device shall store the reading with timestamp in non-volatile memory.
Optional Feature: Where Bluetooth connectivity is available, the device shall transmit readings to the paired smartphone app.
Unwanted Behavior: If the cuff pressure exceeds 300 mmHg, then the device shall immediately release pressure and display an error message.
Complex: While the patient is being monitored, if heart rate drops below 40 bpm or exceeds 150 bpm, then the device shall trigger an audible alarm within 1 second and log the event.