ears-requirements

EARS 需求

概述

将需求草稿转换为简洁、符合 EARS 的陈述，在保留原意的同时减少歧义。

工作流

1. 从用户输入中提取需求意图。
2. 确定正确的 EARS 模式：
   • 通用模式
   • 状态驱动模式
   • 事件驱动模式
   • 可选功能模式
   • 非预期行为模式
   • 复杂组合模式
3. 按照严格的子句顺序重写每项需求，并明确说明一种系统响应。
4. 检查需求质量，确保其可衡量、可测试，且不存在条件缺失。
5. 返回：
   • 重写后的需求
   • 每项需求对应的模式标签
   • 如果模式选择可能存在争议，简要说明理由

编写规则

• 每条陈述只包含一项需求。
• 明确指定一个系统主体（例如："the ATM"）。
• 使用 shall 表示强制行为。
• 优先描述可观察到的结果，而非实现细节。
• 明确列出条件；避免隐含触发条件或隐藏状态。
• 避免使用 "as appropriate"、"if possible"、"etc." 等含糊表述。
• 如果数值限制或时间要求未知，请添加明确的占位符（例如：<MAX_LATENCY_MS>）。

EARS 子句顺序

仅使用所选模式所需的子句，并始终按以下顺序排列：

While <state/precondition>, when <trigger>, the <system> shall <response>

非预期行为模式的格式如下：

If <undesired trigger>, then the <system> shall <response>

模式定义和示例请参阅 references/ears-patterns.md。

脚本

使用 scripts/validate_ears.py 对模式进行分类，并快速检查语法和质量问题。

单条需求：

python3 scripts/validate_ears.py --requirement "When mute is selected, the laptop shall suppress all audio output."

批量文件（每行一条需求）：

python3 scripts/validate_ears.py --file requirements.txt

机器可读输出：

python3 scripts/validate_ears.py --file requirements.txt --json

质量门槛

定稿前，请核验每项需求：

• 是否可通过通过／失败标准进行测试。
• 是否明确说明主体、条件和响应，且没有歧义。
• 术语是否一致，且不存在同义词混用。
• 是否避免将多种相互独立的行为合并在一起（明确属于复杂组合的情况除外）。
• 是否符合所选 EARS 模式。

如果任何检查未通过，请提供修正后的版本，并说明所做的最小改动。