tomevault-io 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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.