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

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

1. ❌ Using "should" instead of "SHALL"
2. ❌ Combining multiple requirements in one statement
3. ❌ Vague or unmeasurable criteria
4. ❌ Missing system name
5. ❌ Using implementation details in requirements