这一文章是由Allistair Maven（Mav）撰写的，他是一位英国的需求工程管理专家，他的需求培训、辅导和咨询在国际上广为人知。
一、需求工程基础和内在挑战
需求工程（RE）是一个以人为中心，以沟通为基础的活动。需求工程也是一项很直接的活动：你需要找出哪些人将受到产品、系统或服务的影响，找出他们希望它做什么，并进行记录。你需要管理他们对能达成的目标的期望。一旦解决方案被构建出来，你需要检查它是否做到了人们所要求的。这听起来简单，但并不一定容易。
需求工程是一项跨学科活动，涉及到不同技术领域和软技能。由于不同项目的规模、复杂性、风险情况、创新程度和参与成员都不一样，因此我们在开发新产品、系统或服务时会遇到很多不可预知的问题。而需求工程并不是精确的科学工程，也不是一个可以完全被系统化、可被重复循环“工程过程”。需求工程流程可被参照，但不能被完全复制。每个项目都有其独特之处，我们必须要根据项目的差异对需求工程流程进行调整或定制。
内在挑战
获取新产品、系统或服务的需求并非易事，人们并不总是知道他们想要什么，所以需求可能并不容易获得；它们可能需要被挖掘。即使他们知道自己想要什么，人们可能也会发现难以清楚地表达需求。每个人都有不同的经历，并基于他们已知的东西做出假设。因此，人们通常不会陈述对他们来说显而易见的事情。另外，人们并不总是知道什么是可能的，所以他们不会想到去询问。
软件开发项目通常会涉及很多利益相关者，其数量往往超过最初的预想。这些利益相关者以不同方式与新产品、系统或服务产生关联，因此他们的需求多种多样。即使是”用户”这一群体也并非一个同质化的群体，他们的知识和经验都不同，希望通过产品实现的目标也不同。
除此之外，开发团队通常会由来自各个领域的专业人员组成，包括软件、硬件、安全、验证、维护和支持工程师，项目经理和行政人员等。一些规模更大的项目可能还会涉及到项目发起人、产品经理、顾问、客户、供应商、监管机构和公众等更多角色。这些不同角色的参与者都可能就产品、系统或服务提出自己的需求。实际上，以上已经提到的角色仍不能完全覆盖所有可能存在的利益相关者。
利益相关者可能会就系统或产品的功能提出各种高屋建瓴的期望、愿望和要求，他们希望未来的系统或产品能解决。然而这些目标并不应该归集为”需求”，因为它们往往不能直接转化为系统可以交付的具体成果。获取并记录利益相关者的目标是明智的，但更重要的是要管理利益相关者所提议的目标落地的可能性。利益相关者设定的目标常常存在冲突，我们不可能满足他们设定的所有目标。但是，系统需求的集合必须是完整的、一致的并且没有冲突的；必须能够构建出一个满足所有系统需求的系统。
为了有效地进行需求工程（RE）活动并降低项目风险，你需要人员、流程和技术一起工作，以捕获需求并在整个系统开发过程中清晰地向所有相关利益相关者进行沟通。
接下来的章节将探讨在RE过程中可能出现的问题，同时会为大家介绍”Easy Approach to Requirements Syntax” (EARS)需求表法句法。EARS通过改进需求工程实践，可帮助团队克服挑战，实现既定目标。
二、简洁需求句法（EARS)
简单需求句法通过设定一组关键词和基本句式来约束自然语言下的需求描述。”EARS”以特定逻辑句式来表达需求，提高了需求表达的清晰度和准确性。
EARS 的起源
EARS是英国罗尔斯·罗伊斯公司于2009年创造，该公司工程师通过分析适航法规，确定了对航空发动机控制系统的需求表述。该团队仔细阅读了所有规范文件，并对每个明示或暗示发动机控制系统需求的条款逐一分析。为了明确和简化这些需求，工程师团队设定了一组初始的需求表述”规则”。在不断分析过程中，他们不断完善这些规则，发现需求在句法上都很相似，可遵照一定模式来表达。随后，该团队将自己的成果整理成论文，最终在IEEE的”RE09″国际需求工程会议上得以发表。
EARS句法的核心理念是：大部分的需求都是用自然语言表述的。许多编写这些需求的人并没有接受过关于系统化需求编写的正式培训，如果需求中存在的问题在系统开发过程中得不到解决，可能会引发一系列问题，如波动性增加、风险增加等，进而影响项目的质量、进度和成本。而许多实践已经证实EARS可以减少甚至避免此类问题，原因在于EARS是一个轻量级的方法，所需培训成本较小，较容易上手。目前，包括Bosch、Daimler、Dyson、Honeywell、Intel、NASA、Rolls-Royce和Siemens等在内的多个组织都在使用EARS，世界上很多大学也把它纳入教学内容。
EARS 句法
EARS句法有固定句式，比如“当…时…应…”，“在…情况下…应…”
在EARS句法中，需求必须具备以下要素：零个或多个先决条件、零个或一个触发器、一个系统名称以及一个或多个系统响应。EARS定义了一些表达需求的特定句式，所选择句式不同，生成的需求会呈现出不同的模式。以下是对EARS每种模式的含义和用法的解释。
1.通用性需求
在系统的运行过程中都需要满足的功能需求。它们不受事件或输入调用影响，适用于系统的所有操作状态，而不仅仅是某个特定状态下的需求。
模板：xxx应该xxx
示例：手机的质量应该小于XX克。
2.状态驱动需求
状态驱动的功能需求，在定义的状态下都保持为真的整个时间内都处于活动状态。在Mavin的EARS方法中，状态驱动的需求用关键词WHILE标识。
模板：在xxx情况下xxx应xxx
示例：当飞机处于飞行状态且发动机在运行的情况下，控制系统应保持发动机燃油流量高于xx磅/秒。
3.事件驱动需求
事件驱动的需求描述了系统在特定事件发生时应该如何响应和处理。在Mavin的EARS方法中，事件驱动的需求使用关键字“当…时”来标识
模板：当xxx时，xxx应xxx
示例：当飞行器发出连续点火指令时，控制系统应启动连续点火。
4.可选功能需求
可选特性功能需求描述了系统在可选特性启用时，应该如何响应和提供相应的功能。这些需求仅在可选特性作为系统的一部分存在时才适用，并且只有在特定的配置或设置下才会生效。关键字是“在…条件下”
模板：在xxx条件下，xxx应该xxx
示例：在控制系统具有超速保护功能的条件下，在飞机起飞前，控制系统应测试超速保护功能的有效性。
5.异常行为需求
异常行为需求关注的是系统在异常或错误条件下应如何运行。这包括系统应如何处理错误，如何从错误中恢复，以及如何通知用户或者其他系统关于错误的信息。优秀的设计可以预测并处理这些异常情况，减少对系统的不良影响。
在系统状况不佳或发生异常情况时，通常需要定义异常行为需求。异常行为需求描述了系统应该如何响应触发器（trigger）以处理异常情况。在EARS方法中用“如果，然后…”标记，旨在减轻异常行为需求带来的影响。
模板：“如果xxx，那么xxx”，“应该xxx”
示例：如果计算空速不可用，那么控制系统应使用模型空速
6.复杂需求
在许多情况下，特定事件的触发需要满足一组或多组特定的先决条件，这些条件可以是系统状态或可选功能。只有在这些先决条件被满足之后，系统才能对事件做出相应的响应。EARS模板用一组关键字来标识。
模板：（期望行为）在…情况下…，当…时…, 当…时…应
模板：（异常行为）在…情况下, 当…时…, 如果…应..
示例：当飞机位于地面的情况下，当收到反推力指令时，控制系统应启动反推力装置。
三、使用EARS的十大关键益处
使用EARS能在系统开发过程的早期阶段，甚至在完全定义你的流程或选择工具之前，就帮助人员、流程和技术达成一致。除此以外，应用EARS还有许多其他的好处，比如：
- EARS减少或甚至消除了文本自然语言需求中的常见错误。
- EARS语式描述的需求更简单，更一致，即使是由不同的作者写的。这种简单性意味着EARS的需求更易于理解，即使是那些可能没有接受过EARS符号训练的人。这种一致性还确保了每个需求都被平等评审，没有任何风格或展示偏见。
- 需要的培训很少，许多组织在半天甚至更短的时间内就能熟练使用EARS。由于EARS接近自然语言，所以没有新的概念要学习。EARS的需求比那些用更专业的符号写的需求更容易审查。EARS的需求与测试用例在风格上相似，这反过来意味着系统更容易根据EARS的需求进行验证。
- EARS能够帮助新手和有经验的需求作者，因为这两个群体都倾向于更快地写出更好的需求。平常情况下，大多数需求是迭代多次的，草稿需求在几次迭代中被详述和改进。但是使用EARS时，第一稿需求往往更接近最后的需求。
- EARS与一系列模型（包括活动图和状态图）配合得很好，因为EARS需求的元素也可以在这些模型中找到。
- EARS的许多好处在个人和团队层面都有作用。比如个人能写出更好的需求，更容易被理解。团队内部的沟通得到改善，团队成员在项目之间的流动性更强。EARS也有助于建立团队，产生共享的理解，因此减少了孤岛心态。因为遗漏的信息更早地被发现，需求被更精确地编写，让需求更易于理解和评审，同时减少了误解的可能性，这都大大降低了项目风险。
- EARS是一种极为实用的工具，对于那些已经实践过但未必得心应手的专业需求工程师来说，EARS能提供一种易于理解和使用的语言框架。
- 使用EARS，你可以以更系统和一致的方式处理复杂需求，这让产品的需求更明确，更易于实现。
- 与某些需求捕捉技术相比，EARS的学习曲线相对较低，新手可以快速上手并看到明显的改进。
- 最后，EARS已经被许多大型组织，如Bosch, Daimler, Dyson, Honeywell, Intel, NASA, Rolls-Royce和Siemens等广泛使用，它的有效性和实用性已经得到了广泛的验证和认可。
某大型工程公司的高级工程师曾经说过：“如果你不能用EARS写，那么你就看不懂。这强调了 EARS 的隐藏优势；它可以防止作者编写不完整的需求。
结语
美国著名的职业棒球运动员、教练和经理Yogi Berra曾说，“在理想状态下，实践应该和理论不会有太大出入，在实际操作中，两者通常会有明显的差异。”需求工程领域也是如此。理论上，需求工程很简单，然而在实践中往往会遇到很多复杂的问题。EARS就是让问题变简单的有效方式。
EARS是一个轻量级的工具，可快速带来投资回报，语言表述直观且贴合日常用语。建议异地办公的团队、规模较大的团队以及开展复杂项目的团队，都能使用 PingCode 等需求管理工具，因为这些工具可对EARS的应用进行评估。
EARS是一种简单且有效的需求表述方法。使用EARS句法时，团队不需要在决定如何编写需求上浪费时间，而可以专注于需求内容本身，即我们希望系统或产品实现什么功能。
PingCode 等需求管理平台与EARS方法的结合使用，可以提高产品需求编写的质量，并且能够提高团队内部以及团队间的沟通效率，从而优化团队协作、工作流程和技术应用。由于协作能力的提高，团队可以更专注于交付质量，降低整体项目风险。
