shield_lock
JinDaGe
← Back to skills
extension
Category: Development & EngineeringNo API key required

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.

personAuthor: jakexiaohubgithub
open_in_newRepositorydownloadDownload package

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

  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