EARS（Easy Approach to Requirements Syntax，易于理解的需求语法
EARS（Easy Approach to Requirements Syntax，易于理解的需求语法）是一种在软件工程和系统工程领域用于编写清晰、简洁且无歧义需求的方法。它通过一套简单的模板和规则来约束自然语言（Natural Language, NL）需求描述，帮助开发团队减少需求中的歧义、复杂性和模糊性，从而提升需求质量、降低开发风险。EARS 特别适用于高可靠性系统，如航空航天、汽车、医疗设备等领域，但也可广泛用于一般软件开发项目。本教程将从基础概念入手，逐步深入，提供详细解释、示例和实践指导。内容基于 EARS 的原始论文和相关资源，力求全面。
1. EARS 的背景与历史
EARS 由 Alistair Mavin（简称 Mav）和 Rolls-Royce PLC 的团队开发，于 2009 年在 IEEE 国际需求工程会议（RE09）上首次提出。 该方法源于对航空发动机控制系统需求提取的实际经验：在分析空气适航性法规文档时，团队发现传统自然语言需求容易出现八大常见问题，包括歧义（ambiguity）、复杂性（complexity）、模糊性（vagueness）、重复性（duplication）等。为了解决这些问题，他们开发了一套结构化规则，将所有需求归纳为有限的模板模式。
EARS 的核心理念是“轻轻约束”（gently constrain）自然语言，而不是完全取代它。这使得非专业需求编写者（如产品经理或领域专家）也能轻松上手。EARS 已广泛应用于工业界，如 Rolls-Royce、NASA 和其他高安全系统开发中。 它与 INCOSE（国际系统工程理事会）等组织的需求工程实践相结合，常用于需求分析、验证和测试阶段。
为什么需要 EARS？
- 传统需求往往用 unconstrained NL 编写，导致歧义：例如，“系统应在紧急情况下关闭”——什么是“紧急情况”？如何“关闭”？
- 问题传播：歧义需求会向下游（如设计、编码、测试）传播，导致成本增加（据统计，需求错误占软件项目失败的 40-60%）。
- EARS 的优势：模板化确保一致性、易读性、可验证性；减少重工；适用于敏捷或瀑布模型。
2. EARS 的核心规则与语法
EARS 使用一套底层规则集（underlying ruleset），将需求分为五个基本模式（patterns）。每个模式遵循时序逻辑（temporal logic），即子句总是按固定顺序出现：前提条件（可选） + 触发/状态 + 系统响应。这模仿英语的自然用法，但优化了清晰度。
基本规则：
- 使用主动语态（active voice），避免被动语态。
- 每个需求仅描述一个行为或功能。
- 避免复杂从句；如果需求太复杂，不适合 EARS（详见第 6 节）。
- 关键词（如“当”、“如果”、“当...时”）用于引导模式。
- 所有需求都应可测试（measurable and testable）。
- EARS 支持组合：简单模式可构建复杂行为。
五个核心模式：
- Ubiquitous（普遍需求）：描述始终有效的功能，无触发条件。
- Event-driven（事件驱动需求）：当外部事件发生时，系统响应。
- 模板：当 [触发事件] 时，系统应 [功能描述]。
- Unwanted Behavior（非预期行为需求）：处理异常或故障条件。
- State-driven（状态驱动需求）：系统在特定持续状态下的行为。
- 模板：当 [系统状态] 时，系统应 [功能描述]。
- Optional Features（可选功能需求）：描述可选或条件性功能。
有些变体（如 EARS+）添加了更多模式，但标准 EARS 以这五个为主。
3. 每个模式的详细解释与示例
以下是对每个模式的深入剖析，包括语法细节、适用场景、常见错误及修正示例。示例基于软件系统（如智能家居或汽车控制系统）。
3.1 Ubiquitous（普遍需求）
- 解释：适用于系统核心功能，这些功能始终存在，无需触发。强调“应”（shall）表示强制性。
- 适用场景：基本属性、常量行为。
- 常见错误：添加不必要条件，导致模式混淆。
- 示例：
- 原始歧义需求：“系统需要记录日志。”
- EARS 修正：系统应记录所有用户操作日志。
- 扩展示例（智能恒温器）：恒温器应实时显示当前室内温度。 这确保了显示功能始终可用。
3.2 Event-driven（事件驱动需求）
- 解释：焦点在“当”（when）触发事件上，事件通常是外部输入（如用户动作、传感器信号）。响应必须即时或在指定时间内。
- 适用场景：用户交互、传感器触发。
- 常见错误：事件描述模糊（如“当有问题时”）。
- 示例：
- 原始歧义需求：“用户登录失败时显示错误。”
- EARS 修正：当用户输入无效密码时，系统应显示“密码错误”提示，并在 3 秒内重置输入框。
- 扩展示例（汽车系统）：当驾驶员按下刹车踏板时，车辆应激活 ABS（防抱死制动系统）。
3.3 Unwanted Behavior（非预期行为需求）
- 解释：使用“如果”（if）处理异常、故障或风险场景。强调恢复或缓解措施。
- 适用场景：错误处理、安全机制。
- 常见错误：忽略响应，导致需求不完整。
- 示例：
- 原始歧义需求：“如果网络断开，系统要处理。”
- EARS 修正：如果网络连接中断，则系统应切换到离线模式并保存本地数据。
- 扩展示例（医疗设备）：如果电池电量低于 10%，则设备应发出警报并进入低功耗模式。
3.4 State-driven（状态驱动需求）
- 解释：使用“当”（while）描述持续状态下的行为。状态是系统内部的持久条件。
- 适用场景：模式切换、循环操作。
- 常见错误：与事件驱动混淆（事件是瞬时，状态是持续）。
- 示例：
- 原始歧义需求：“在飞行模式下，系统降低功耗。”
- EARS 修正：当系统处于飞行模式时，系统应禁用 Wi-Fi 并降低 CPU 频率至 50%。
- 扩展示例（无人机）：当无人机处于悬停状态时，系统应维持高度稳定在 ±0.5 米内。
3.5 Optional Features（可选功能需求）
- 解释：使用“如果...可”（where）表示非强制功能，通常取决于配置或用户选择。
- 适用场景：扩展功能、自定义选项。
- 常见错误：将可选功能写成强制，导致过度设计。
- 示例：
- 原始歧义需求：“系统可以支持夜间模式。”
- EARS 修正：如果用户启用夜间模式，系统可降低屏幕亮度至 30%。
- 扩展示例（手机 App）：如果设备支持 NFC，则应用可启用联系less 支付功能。
4. EARS 编写教程：步步指南
以下是使用 EARS 编写需求的完整教程。假设你是一个需求工程师，正在为一个在线银行系统编写需求。
步骤 1: 准备阶段
- 收集原始需求：从利益相关者（如用户、经理）获取 NL 描述。
- 识别问题：检查歧义、复杂句、使用工具（如 QVscribe 或 Jama Connect）分析。
- 定义术语：创建词汇表（glossary），如“用户”=注册账户持有者。
步骤 2: 分类需求
- 遍历每个原始需求，匹配模式：
- 无条件？→ Ubiquitous。
- 有触发事件？→ Event-driven。
- 异常处理？→ Unwanted Behavior。
- 持续状态？→ State-driven。
- 可选？→ Optional Features。
- 如果不匹配，拆分需求（一个需求一个行为）。
步骤 3: 应用模板
- 按模板重写：确保子句顺序（前提 → 触发 → 响应）。
- 添加量化：如时间（“在 5 秒内”）、阈值（“超过 80°C”）。
- 示例流程（银行系统）：
- 原始：“用户转账时检查余额，如果不足显示错误。”
- 拆分：
- Event-driven: 当用户发起转账请求时，系统应检查账户余额。
- Unwanted Behavior: 如果账户余额不足转账金额，则系统应显示“余额不足”错误并取消操作。
步骤 4: 审查与验证
- 检查一致性：所有需求使用相同关键词。
- 验证可测试性：每个需求有验收标准（e.g., 测试用例）。
- 工具支持：使用 Jama Connect 的 Requirements Advisor 或 Inflectra 的 AI 工具检查 EARS 符合性。
- 团队审查：阅读大声，确保无歧义。
步骤 5: 文档化
- 使用表格呈现：
| ID | 模式 | 需求描述 |
|---|
| REQ-001 | Ubiquitous | 系统应加密所有传输数据。 |
| REQ-002 | Event-driven | 当用户登录时，系统应验证双因素认证。 |
- 集成到需求管理工具（如 DOORS、Polarion）。
5. 案例研究：航空发动机控制系统
在原始 EARS 论文中，团队从空气适航性法规（EASA CS-E）提取需求。 原始 NL 需求复杂，应用 EARS 后：
- 数量减少 20%，歧义降低 50%。
- 示例：原始：“发动机在故障时必须安全关闭。” → EARS: 如果检测到重大故障，则发动机控制系统应启动安全关闭序列。
结果：需求更易验证，项目成本降低。
6. 高级主题：EARS 的扩展与局限
- EARS+：扩展版添加复杂组合，如多前提（e.g., “如果 A 且 B，则...”）。
- 组合模式：构建 richer 行为，例如：当系统处于待机模式且用户按下按钮时，系统应激活主功能。
- 何时不使用 EARS：如果需求涉及多重条件（>3 个），使用表格、决策树或 UML 图表代替。 示例：复杂权限系统用矩阵表示。
- 与其它方法集成：结合用户故事（User Stories）或 SysML 建模。
- 最佳实践：
- 培训团队：从简单示例开始。
- 避免过度模板化：保持 NL 的自然性。
- 处理非功能需求（NFR）：EARS 主要用于功能需求，但可扩展（如“系统应在 99.9% 时间可用”作为 Ubiquitous）。
7. 结论与资源推荐
EARS 是一种高效、易学的工具，能显著提升需求工程质量。通过模板化，它将复杂任务简化成可重复过程，适用于从初学者到专家的各种水平。实践 EARS 需要迭代：从小型项目开始，逐步扩展。
进一步资源：
- 原始论文：《Easy Approach to Requirements Syntax (EARS)》（IEEE Xplore）。
- 教程视频：YouTube 上 “EARS: The Easy Approach to Requirements Syntax”。
- 书籍：《Competitive Engineering》 by Tom Gilb（EARS 灵感来源）。
- 社区：Reddit 的 r/ReqsEngineering 或 INCOSE 工作组。