musubix-ears-validation
Guide for validating and creating EARS-format requirements. Use this when asked to write requirements, validate requirement syntax, or convert natural language to EARS format.
When & Why to Use This Skill
The MUSUBIX EARS Validation skill is a specialized tool designed to streamline the creation and validation of software requirements using the Easy Approach to Requirements Syntax (EARS). It helps engineering teams eliminate ambiguity, ensure testability, and transform informal natural language into structured, professional-grade technical specifications across five core patterns: Ubiquitous, Event-Driven, State-Driven, Unwanted Behavior, and Optional.
Use Cases
- Requirement Transformation: Automatically convert vague natural language descriptions or informal user stories into structured, EARS-compliant requirement statements.
- Syntax Validation: Audit existing requirement documents to ensure they adhere to standardized EARS patterns and use mandatory keywords like 'SHALL' correctly.
- Quality Assurance: Use the built-in validation checklist to verify that requirements are measurable, atomic, and free of ambiguous language before they reach the development phase.
- Standardization: Implement a unified requirement document template across engineering teams to maintain consistency in priority levels, traceability, and acceptance criteria.
| name | musubix-ears-validation |
|---|---|
| description | Guide for validating and creating EARS-format requirements. Use this when asked to write requirements, validate requirement syntax, or convert natural language to EARS format. |
| license | MIT |
MUSUBIX EARS Validation Skill
This skill helps you create and validate requirements using EARS (Easy Approach to Requirements Syntax) format.
EARS Pattern Reference
1. Ubiquitous Pattern
Use for: Requirements that must always be satisfied.
Syntax:
THE [system name] SHALL [requirement]
Example:
THE AuthService SHALL authenticate users with valid credentials.
2. Event-Driven Pattern
Use for: Requirements triggered by specific events.
Syntax:
WHEN [trigger event], THE [system name] SHALL [response]
Example:
WHEN a user submits login credentials, THE AuthService SHALL validate the credentials within 2 seconds.
3. State-Driven Pattern
Use for: Requirements that apply while in a specific state.
Syntax:
WHILE [system state], THE [system name] SHALL [behavior]
Example:
WHILE the system is in maintenance mode, THE API SHALL return 503 Service Unavailable.
4. Unwanted Behavior Pattern
Use for: Behaviors that must be prevented.
Syntax:
THE [system name] SHALL NOT [unwanted behavior]
Example:
THE AuthService SHALL NOT store passwords in plain text.
5. Optional Pattern
Use for: Conditional requirements.
Syntax:
IF [condition], THEN THE [system name] SHALL [response]
Example:
IF two-factor authentication is enabled, THEN THE AuthService SHALL require a verification code.
Validation Checklist
When validating EARS requirements, check:
- Pattern Compliance: Does it follow one of the 5 EARS patterns?
- System Name: Is the system/component clearly identified?
- SHALL Keyword: Is "SHALL" used for mandatory requirements?
- Measurable: Is the requirement testable and measurable?
- Atomic: Does it describe a single requirement?
- No Ambiguity: Is the language clear and unambiguous?
CLI Commands
# Validate EARS syntax
npx musubix requirements validate <file>
# Convert natural language to EARS
npx musubix requirements analyze <file>
# Map to ontology
npx musubix requirements map <file>
Conversion Examples
Natural Language → EARS
Input: "Users should be able to login"
Output:
THE AuthenticationModule SHALL authenticate users with valid credentials.
Input: "Show error when password is wrong"
Output:
WHEN invalid credentials are provided, THE AuthenticationModule SHALL display an error message.
Input: "Don't allow SQL injection"
Output:
THE InputValidator SHALL NOT accept input containing SQL injection patterns.
Priority Levels
| Priority | Description | Usage |
|---|---|---|
| P0 | 必須 (Must Have) | Release blocker |
| P1 | 重要 (Should Have) | Implement if possible |
| P2 | 任意 (Nice to Have) | Time permitting |
Requirement Document Template
### REQ-[CATEGORY]-[NUMBER]: [Title]
**種別**: [UBIQUITOUS|EVENT-DRIVEN|STATE-DRIVEN|UNWANTED|OPTIONAL]
**優先度**: [P0|P1|P2]
**要件**:
[EARS形式の要件文]
**検証方法**: [Unit Test|Integration Test|E2E Test|Manual]
**受入基準**:
- [ ] Criterion 1
- [ ] Criterion 2
**トレーサビリティ**: DES-XXX, TEST-XXX
**憲法準拠**: Article IV (EARS Format)
Common Mistakes to Avoid
- ❌ Using "should" instead of "SHALL"
- ❌ Combining multiple requirements in one statement
- ❌ Vague or unmeasurable criteria
- ❌ Missing system name
- ❌ Using implementation details in requirements