EARS Requirements Syntax

// Ubiquitous | Event-driven | Unwanted | Optional | Complex

// EARS: Easy Approach to Requirements Syntax
// 5 templates for writing unambiguous requirements

// 1. UBIQUITOUS (always active)
//    "The [system] shall [action]"
"The system shall log all authentication attempts with timestamp and IP address."
"The API shall respond within 500ms for all GET requests."

// 2. EVENT-DRIVEN (triggered by event)
//    "WHEN [trigger], THE [system] shall [action]"
"WHEN a user submits the registration form, THE system shall send a verification email."
"WHEN a payment fails, THE system shall notify the user and preserve their cart."

// 3. UNWANTED BEHAVIOR (condition → response)
//    "IF [condition], THEN THE [system] shall [action]"
"IF a user enters an incorrect password 5 times, THEN THE system shall lock the account for 15 minutes."
"IF the database connection is unavailable, THEN THE system shall return a 503 status with retry instructions."

// 4. OPTIONAL (feature flag or configuration)
//    "WHERE [feature is active], THE [system] shall [action]"
"WHERE two-factor authentication is enabled, THE system shall require a verification code on login."

// 5. COMPLEX (combined conditions)
//    "WHILE [state] WHEN [trigger] THE [system] shall [action]"
"WHILE a payment is being processed WHEN the user attempts to navigate away, THE system shall display a confirmation dialog."

// GOOD vs BAD requirements
// BAD: "The login should be fast" (unmeasurable)
// GOOD: "WHEN a user submits valid credentials, THE system shall complete authentication and redirect within 300ms"