⚡

EARS需求模式编写Skill ears-authoring

此技能用于使用EARS（简易需求语法方法）模式进行软件需求的编写、验证和管理，提供模式模板、验证指南和示例，帮助用户创建精确、可测试的需求。关键词包括EARS、需求工程、模式编写、SHALL关键字、软件需求、需求分析、需求验证、模式选择、EARS模式、需求质量管理。

需求分析 0 次安装 0 次浏览 更新于 3/11/2026

名称: ears-authoring 描述: EARS需求模式编写。用于使用EARS模式（普遍、状态驱动、事件驱动、不想要行为、可选、复杂）编写需求。提供模式模板、验证和示例。 允许工具: Read, Glob, Grep, Write, Edit

EARS需求模式编写

EARS（简易需求语法方法）模式编写，用于精确、明确的需求。

何时使用此技能

关键词: EARS模式、普遍需求、状态驱动需求、事件驱动需求、不想要行为、可选功能、复杂需求、SHALL关键词、需求语法

在以下情况下使用此技能：

  • 使用EARS语法编写新需求时
  • 将非正式需求转换为EARS格式时
  • 验证EARS模式正确性时
  • 为需求选择正确的EARS模式时
  • 理解EARS反模式时

快速模式参考

模式 关键词 模板
普遍模式 （无） <entity> SHALL <action>
状态驱动模式 WHILE WHILE <condition>, <entity> SHALL <action>
事件驱动模式 WHEN WHEN <trigger>, <entity> SHALL <action>
不想要行为模式 IF…THEN IF <condition>, THEN <entity> SHALL <action>
可选功能模式 WHERE WHERE <feature>, <entity> SHALL <action>
复杂模式 多个 模式组合

模式选择决策树

从这里开始：此需求何时适用？

  1. 始终适用（无条件） → 使用普遍模式：“系统 SHALL…”

  2. 在特定状态下 → 使用状态驱动模式：“WHILE 在维护模式中，系统 SHALL…”

  3. 当某事发生时（事件/触发器） → 使用事件驱动模式：“WHEN 用户点击提交，系统 SHALL…”

  4. 处理不想要行为时（错误/异常） → 使用不想要行为模式：“IF 认证失败，THEN 系统 SHALL…”

  5. 仅当功能启用时（可选/可配置） → 使用可选功能模式：“WHERE 暗黑模式启用，系统 SHALL…”

  6. 多个条件适用时 → 使用复杂模式：“WHILE 激活，WHEN 超时发生，系统 SHALL…”

模式详情

普遍模式

使用时机： 需求无条件适用，始终活跃。

模板：

<entity> SHALL <action>

关键词： 无（无需WHILE、WHEN、IF、WHERE）

示例：

  • “系统 SHALL 加密所有静态数据”
  • “API SHALL 以JSON格式响应”
  • “应用程序 SHALL 记录所有用户操作”

常见错误：

  • 当行为是通用时添加不必要条件
  • 使用"should"而非"SHALL"

状态驱动模式

使用时机： 行为适用于系统处于特定状态时。

模板：

WHILE <condition>, <entity> SHALL <action>

关键词： WHILE（在开头）

示例：

  • “WHILE 在维护模式中，系统 SHALL 显示横幅”
  • “WHILE 连接激活，系统 SHALL 发送心跳”
  • “WHILE 用户已认证，系统 SHALL 显示仪表板”

常见错误：

  • 使用WHEN代替WHILE（WHEN = 事件，WHILE = 状态）
  • 描述事件而非状态

事件驱动模式

使用时机： 由特定事件或用户操作触发的行动。

模板：

WHEN <trigger>, <entity> SHALL <action>

关键词： WHEN（在开头）

示例：

  • “WHEN 用户提交表单，系统 SHALL 验证输入”
  • “WHEN 错误发生，系统 SHALL 记录详情”
  • “WHEN 会话过期，系统 SHALL 重定向到登录”

常见错误：

  • 使用WHILE代替WHEN（WHILE = 状态，WHEN = 事件）
  • 描述状态而非事件

不想要行为模式

使用时机： 处理异常、错误或不想要条件。

模板：

IF <condition>, THEN <entity> SHALL <action>

关键词： IF…THEN（两者都需）

示例：

  • “IF 认证失败，THEN 系统 SHALL 锁定账户”
  • “IF 数据库不可用，THEN 系统 SHALL 队列请求”
  • “IF 输入验证失败，THEN 系统 SHALL 显示错误消息”

常见错误：

  • 使用IF-THEN处理正常行为（应使用事件驱动模式）
  • 遗漏THEN关键词
  • 用于积极条件（保留给消极/不想要条件）

可选功能模式

使用时机： 行为取决于功能标志或配置。

模板：

WHERE <feature/config>, <entity> SHALL <action>

关键词： WHERE（在开头）

示例：

  • “WHERE 暗黑模式启用，系统 SHALL 使用暗黑主题”
  • “WHERE 审计日志配置，系统 SHALL 记录访问”
  • “WHERE 双因素认证启用，系统 SHALL 要求OTP”

常见错误：

  • 使用IF代替WHERE（IF = 不想要，WHERE = 可选）
  • 将强制功能描述为可选

复杂模式

使用时机： 需求结合来自不同模式的多个条件。

模板：

<Pattern1>, <Pattern2>, <entity> SHALL <action>

示例：

  • “WHILE 激活，WHEN 超时发生，系统 SHALL 重新连接”
  • “WHILE 在生产模式中，IF 错误发生，THEN 系统 SHALL 通知运维”
  • “WHERE 缓存启用，WHEN 数据变更，系统 SHALL 使缓存无效”

常见错误：

  • 使用复杂模式时，当更简单模式足够
  • 嵌套条件过深（推荐最多2层）

编写质量需求

SHALL关键词

始终使用SHALL 表示需求：

  • ✅ “系统 SHALL 验证输入”
  • ❌ “系统应该验证输入”
  • ❌ “系统必须验证输入”
  • ❌ “系统将验证输入”

原因： SHALL指示强制行为。其他词具有模糊性。

主动语态

始终使用主动语态：

  • ✅ “系统 SHALL 加密数据”
  • ❌ “数据应被加密”
  • ❌ “加密应被执行”

每个语句单一需求

每个需求一个行动：

  • ✅ “系统 SHALL 验证输入”
  • ✅ “系统 SHALL 记录验证错误”
  • ❌ “系统 SHALL 验证输入并记录错误”

可测试需求

需求必须可测试：

  • ✅ “系统 SHALL 在200毫秒内响应”
  • ❌ “系统 SHALL 快速响应”
  • ✅ “系统 SHALL 支持1000个并发用户”
  • ❌ “系统 SHALL 扩展良好”

要避免的反模式

反模式 问题 修复方法
使用"should"而非"SHALL" 义务模糊 使用"SHALL"
被动语态 执行者不明确 使用主动语态
多个需求 不可测试复合 拆分为单独需求
实现细节 指定"如何" 聚焦于"什么"
模糊术语 不可测量 添加具体指标
错误模式关键词 语义混淆 将模式匹配到行为

验证清单

完成EARS需求前：

  • [ ] 使用"SHALL"（而非should/must/will）
  • [ ] 使用主动语态（实体执行行动）
  • [ ] 每个语句单一行为
  • [ ] 可测试且有可测量标准
  • [ ] 模式关键词匹配行为类型
  • [ ] 无实现细节（做什么，而非如何做）

与规范集成

EARS需求映射到规范：

requirements:
  - id: "REQ-001"
    text: "WHEN 用户提交表单，系统 SHALL 验证输入"
    priority: must
    ears_type: event-driven  # 匹配使用的模式
    acceptance_criteria:
      - id: "AC-001"
        given: "用户在表单页面"
        when: "用户点击提交"
        then: "系统验证所有输入"

参考

详细文档：

相关技能：

  • canonical-spec-format - 规范结构
  • spec-management - 规范工作流导航
  • requirements-quality - INVEST标准和质量评估

最后更新： 2025-12-24

版本历史

  • v1.0.0 (2025-12-26): 初始发布