EARS Notation
EARS Notation for Requirements Engineering
EARS (Easy Approach to Requirements Syntax) is a formal notation for writing unambiguous, testable acceptance criteria.
Core Principle
Every acceptance criterion follows a strict pattern with uppercase keywords. The keyword SHALL is mandatory - never use "should", "must", "will", "can", or "may".
The Six EARS Patterns
1. Ubiquitous (Always True)
THE [System] SHALL [behavior]
Use for requirements that are always active, with no preconditions.
Example: THE System SHALL encrypt all passwords using bcrypt
2. Event-Driven (Triggered by Action)
More from ibutters/claudecodeplugins
maui-blazor-development
|
72dotnet-development
|
12storybook
Storybook 8 for React component documentation and testing. Use for creating stories, documenting components with Controls/Actions, visual testing, and MDX documentation. Triggers on requests for Storybook stories, component documentation, visual testing, or interactive component demos.
12react-typescript
Modern React 19 with TypeScript development. Use for creating React components, hooks, context providers, and applications with strict TypeScript typing. Triggers on requests for React components, functional components, hooks, state management, event handling, or TypeScript interfaces/types for React.
12responsive-design
Responsive web design patterns for mobile-first development. Use for creating fluid layouts, breakpoint systems, responsive typography, flexible grids, and adaptive components. Triggers on requests for responsive layouts, mobile-first CSS, breakpoints, media queries, fluid design, or multi-device support.
11atomic-design
Atomic Design methodology for React component architecture. Use for structuring component libraries, organizing UI hierarchies, and creating scalable design systems. Triggers on requests for component organization, design system structure, UI hierarchy, or questions about Atoms/Molecules/Organisms/Templates/Pages.
9