- 普遍要求始终处于活动状态，并具有以下结构：应例如手机的质量应小于 XX 克。
- 只要指定的状态保持为真，状态驱动要求就会处于活动状态，用关键字 While 表示并具有以下语法 While ，应例如当 ATM 中没有卡时，ATM 应显示“插入卡以开始”。
- 事件驱动需求指定了触发事件发生时系统必须如何响应，用关键字 When 表示，语法如下： When ，则必须，例如：选择“静音”时，笔记本电脑应抑制所有音频输出。
- 可选功能需求适用于包含指定功能的产品或系统，用关键字 Where 表示，语法如下： Where ，则必须，例如：如果汽车有天窗，则汽车驾驶员侧车门上应有天窗控制面板。
- 不良行为需求用于指定系统对不良情况的响应，用关键字 If 和 Then 表示，语法如下： If ，则必须，例如：如果输入了无效的信用卡号，则网站应显示“请重新输入信用卡详细信息”。
- EARS 模式的简单构建块可以组合起来，以指定更丰富的系统行为需求。包含多个 EARS 关键字的需求称为复杂需求，其语法如下：While、When、shall，例如：当飞机在地面上时，当命令反向推力时，发动机控制系统应启用反向推力。针对不良行为的复杂需求还包括 If-Then 关键字。
- EARS 减少甚至消除了文本 NL 需求中常见的常见错误。
- EARS 需求更简单、更一致，即使是由不同的作者编写的。简单性意味着 EARS 需求是普遍可以理解的，即使对于那些可能没有接受过 EARS 符号培训的人来说也是如此。这种一致性还确保每个需求都得到平等的评判，没有任何风格或表达偏见。事实证明，EARS 对母语不是英语但必须用英语写作的人特别有效。
- 几乎不需要培训；许多组织在半天甚至更短的时间内训练 EARS，并立即看到书面需求标准的提高。由于 EARS 接近自然语言，因此不需要学习新的符号。与以更专业的符号编写的需求相比，EARS 需求更容易审查。 EARS 需求在风格上与测试用例相似，这意味着系统更容易根据 EARS 需求进行验证。
- EARS 可帮助新手和经验丰富的需求作者，因为这两组人都倾向于更快地编写更好的需求。大多数需求都是迭代编写的；需求草案经过多次迭代后得到详细阐述和改进。使用 EARS 时，第一稿需求往往更接近最终需求。
- EARS 可与一系列模型（包括活动图和状态图）配合使用，因为 EARS 需求的元素也存在于此类模型中。EARS 是一种有效的手段，可将严谨性引入需求和系统工程流程；这被称为“隐形严谨性”。
- EARS 的许多好处在个人和团队层面都有效。个人编写的需求更好，但 EARS 需求的一致性对整个项目团队、整个组织甚至供应链都有更广泛的好处。需求更广泛、更容易理解。团队内部沟通得到改善，团队成员在项目之间的可移植性更强。EARS 有助于建立团队，产生共同的理解，从而减少孤岛心态。这降低了项目风险，因为缺失的信息被更早地识别出来，需求被写得更精确。
- 当一个项目团队开始使用 EARS 时，就会发生一些神奇的事情。由于使用 EARS 可以澄清和简化需求的语法，因此它释放了认知能力来考虑需求的语义。通俗地说，这意味着人们不再需要考虑结构，而是专注于含义。由于某些元素对于编写 EARS 需求是必需的，因此作者可以清楚地知道这些信息的缺失。例如，需求作者可能知道系统必须表现出某种行为，但他们（还）不知道这种行为将如何启动。这将促使作者调查应该导致系统响应的情况；这可能是触发事件或先决条件。
- EARS 的特性意味着开发团队可以更快地识别尚不清楚但必须识别才能完成需求的内容。其他符号可能会在模糊的需求陈述中隐藏缺失或不完整的信息，而 EARS 会揭示必须发现的内容。因此，EARS 使团队能够“在开始之前开始”。
- 甚至在您完全定义流程或选择工具之前，如上所述，EARS 有助于在系统开发过程的早期（甚至在您完全定义开发流程或选择工具之前）协调人员、流程和技术。一旦您的团队了解了 EARS，他们就知道生成需求所需的元素。因此，即使在项目的最早阶段，他们也会收集编写良好需求所需的基本元素。如果不知道 EARS 需求所需的某些东西，显然缺少了某些东西，需要发现这个元素。因此EARS 适用于整个系统工程范围。
- 由于需求基本上是（轻微约束的）自然语言，因此 EARS 可以在没有任何工具支持的情况下有效使用。然而，对于更复杂的项目，尤其是大型或分布式项目团队，拥有一些工具支持会很有利。Jama Connect® for 需求、风险和测试管理就是这样一种工具，可以有效地帮助您的团队建立和扩展对 EARS 符号的使用。此外，Jama Software Requirements Advisor 可以通过对 EARS 使用的建议来优化您对 EARS 符号的使用。
需求工程基础和固有挑战
需求工程 (RE) 是一项以人为本的活动，从根本上讲就是沟通。在某些方面，需求工程很简单：您需要确定谁会受到产品、系统或服务的影响，找出他们希望它做什么并记录下来。您需要管理他们对可以实现的目标的期望。解决方案构建完成后，您需要检查它是否符合人们的要求。这听起来很简单，但并不一定容易。
需求工程是一项跨学科活动，包括软技能和技术方面。没有两个开发是相同的；规模、复杂性、风险、新颖性和项目团队的组成在项目之间都有所不同。在开发新产品、系统或服务时，有许多未知的东西必须被发现。由于这些和许多其他因素，需求工程不是一门精确的科学；它不是一个完全系统和可重复的“工程过程”。成功的需求工程遵循可重复使用的方法以提高效率，但不是一个完全复制的过程。需求工程流程必须根据每个单独开发程序的细微差别进行调整或定制。
继承挑战
收集新产品、系统或服务的一系列需求面临许多挑战。人们并不总是知道自己想要什么，因此这些需求可能并不容易获得；可能需要去发现它们。即使他们知道自己想要什么，人们也可能发现很难清楚地表达这些需求。每个人都有不同的经历，并根据他们已知的知识做出假设。因此，人们通常不会说出对他们来说显而易见的事情。此外，人们并不总是知道什么是可能的，所以他们不会想到去问。
对于任何新的开发项目，利益相关者几乎总是比最初显而易见的要多。需求来自广泛的利益相关者，他们将以某种方式受到拟议的新产品、系统或服务的影响。即使是“用户”也不是一个同质群体；他们将拥有不同程度的知识和经验，并希望使用新系统实现许多目标。开发团队通常包括软件、硬件、安全、验证、维护和支持工程师、项目经理和行政人员。更广泛的项目将涉及项目发起人、产品经理、顾问、客户、供应商、监管机构和公众。所有这些不同的角色都可能对产品、系统或服务有要求。即使这里包括的角色也不构成详尽的利益相关者列表。
利益相关者可能有高层次的抱负、愿望、需求和需要，他们希望未来的系统或产品能够满足这些需求。但是，这些目标不应被视为“需求”，因为它们通常不是系统可以提供的东西。捕捉和记录利益相关者的目标是明智的，但管理利益相关者对拟议系统实际能实现的目标的期望也很重要。利益相关者的目标总是会存在冲突，因此目标永远不可能完全满足。然而，系统需求集必须完整、一致且没有冲突；必须能够构建一个满足所有系统需求的系统。
为了有效地开展需求工程 (RE) 活动并降低项目风险，您需要人员、流程和技术共同努力来捕捉需求并在整个系统开发过程中清楚地传达给所有相关利益相关者。
本章将讨论 RE 期间出现的一些问题，并描述如何通过简易需求语法方法 (EARS) 语法符号帮助您改进需求工程实践，从而实现预期结果并克服许多常见的开发挑战。
简易需求语法方法
简易需求语法方法 (EARS) 使用几个关键字和一个简单的底层规则集来温和地约束自然语言 (NL) 需求。EARS 需求有几个子句，它们始终按照时间逻辑以相同的顺序排列。这意味着这些需求反映了英语的常见用法，同时优化了清晰度和准确性。因此，EARS 需求直观易懂。
EARS 的起源
EARS 最初于 2009 年在劳斯莱斯航空发动机公司开发。一组跨学科工程师分析了适航法规，以确定航空发动机控制系统的要求。团队查看了法规文件的每个条款，并确定它是否明确或隐含地推断了对发动机控制系统的要求。对于包含要求的每个条款，使用一组初始“规则”来澄清和简化要求。在分析过程中，规则被反复细化。在此分析过程中，很明显，最终的需求在语法上都相似，并且遵循少数模式之一。这项工作促成了《需求语法简易方法》论文在 IEEE“RE09”国际需求工程会议上的发表。
EARS 认识到大多数需求都是用自然语言 (NL) 编写的，并且许多需求作者没有接受过编写系统需求的正式培训。但是，系统需求中的问题往往会在系统开发过程中传播。这可能导致波动性和风险增加等问题，进而影响质量、项目进度和成本。EARS 已被证明可以减少甚至消除 NL 要求中的许多常见问题。EARS 轻量级，几乎不需要培训费用。因此，EARS 易于采用，这使其受到从业者的欢迎。EARS 被博世、戴姆勒、戴森、霍尼韦尔、英特尔、NASA、劳斯莱斯和西门子等组织广泛使用，并且也在世界各地的许多大学教授。
EARS 模式
EARS 要求的条款始终以相同的顺序出现。EARS 要求的基本结构是：当、何时、应
EARS 规则集规定要求必须具有：零个或多个先决条件；零个或一个触发器；一个系统名称；一个或多个系统响应。应用 EARS 符号会产生少量模式的要求，具体取决于所使用的条款。下面将解释每个 EARS 模式。
使用 EARS 的十大好处
使用 EARS 有助于在系统开发过程的早期阶段协调人员、流程和技术，甚至在您完全定义流程或选择工具之前，但应用 EARS 还有很多其他好处。
一家大型工程公司的高级工程师曾经说过：“如果你不能用 EARS 写出来，那么你就不理解它。”
