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
|
72storybook
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.
12dotnet-development
|
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.
11mobile-app-ux
Mobile app UX/UI best practices for smartphone interfaces. Use for designing touch-friendly interfaces, mobile navigation patterns, gesture handling, and optimizing user experience on small screens. Triggers on requests for mobile UX, app design, touch interfaces, mobile patterns, or smartphone UI best practices.
9