写需求写了十来年，我越来越发现一个反常识的规律：项目烂不烂，往往从第一条需求就注定了。很多团队抱怨“需求不清、开发反复改、测试没法验”，根子不在需求数量，而在需求句子的写法。EARS标准（Easy Approach to Requirements Syntax，需求语法简易方法）就是来解决这个问题的。它不是像IEC、ISO那样需要下载整本PDF的参数规范，它是一套关于“需求句子怎么写”的语法标准。就在这几年，它从航空、汽车电子逐步渗透到嵌入式、医疗器械、金融系统等领域，几乎成了需求评审会上默认的语言规范。
这套标准干的事很简单：强制你把“及时、合理、尽量、充分”这类模糊词扔掉，换成“什么条件触发、系统对谁做什么动作、做到什么程度可以验收”这样的结构化句子。对产品经理、需求分析师、软硬件工程师和测试工程师来说，掌握EARS标准，相当于拿到了一把统一需求语言的钥匙。这篇会讲清楚EARS标准到底怎么用、六种句式怎么套、每一步怎么落地，以及我在实际项目里踩过的坑。
1. EARS标准到底是什么：不是参数标准，而是“需求语法”标准
1.1 从“及时”这类词说起：为什么需求会烂掉
“系统应能及时处理报警信号。”这句需求你看着眼熟不？我几乎在每个项目里都见过。你拿着它去问开发，开发会问什么叫“及时”？是秒级还是毫秒级？你再拿着它去问测试，测试会反问验收算“及时”还是算“处理”？最后评审会上所有人都觉得自己听懂了，但是每个人理解的版本都不一样。
这种需求真正的问题是：第一，没有明确的触发条件，“报警信号”什么时候来、系统处于什么状态才需要处理，全没说；第二，动作不够具体，“处理”到底是记录、转发、弹窗还是声光提示？第三，结果不可验证，“及时”是一个主观感受，不是客观标准。需求一旦写成这样，后续的开发排期、测试用例、验收交付全部都会变成扯皮现场。
我见过一个真实的案例：团队花了三天监控报警模块，开发和测试对“及时”的定义差距是十倍。开发觉得2秒就算及时，测试觉得500毫秒才合格，最后项目经理出来和稀泥，定了1秒。但1秒这个数是怎么来的？没有任何依据。这就是需求模糊导致的“标准拍脑袋”。EARS标准的一个核心价值，就是逼着你把藏在模糊词背后的真实标准挖出来。
1.2 EARS标准的核心要素：触发条件 + 系统应 + 动作 + 可验证结果
EARS标准起源于系统工程领域，最初是为了解决复杂系统需求撰写不一致的问题。它的核心句式可以概括为一个固定骨架：
<前置状态或触发条件> + 系统应 + <具体动作行为> + <可量化验证结果>当然实际使用时，不同场景有不同变体，后面我会逐个拆解。但先记住这个骨架，你会发现它解决了一个本质问题：需求句子从“描述性语言”变成了“可执行契约”。
举个例子，把“系统应能及时处理报警信号”按照EARS标准改写，一般会变成这样：
当系统检测到火灾报警信号且系统处于正常供电状态时，系统应在3秒内将报警记录写入本地日志，并向监控平台发送确认消息。
你看，这句话里没有“及时”，因为“3秒内”就是及时的标准；没有“处理”，因为“写入日志、发送消息”才是处理；没有“各种情况都想当然”，因为“正常供电状态”是触发前提。整句话就变成了一个可以被测试用例逐字验证的契约。
有人会问，EARS标准是不是只是把文字变啰嗦？当然不是。它改变的是需求的分析过程。写“及时”容易，但写“3秒内”你得先想清楚业务期望；写“处理”容易，但写“写入日志、发送消息”你得先识别出系统真正的行为。这一个过程中产生的所有追问，才是EARS标准真正值钱的地方。
我自己的感受是，EARS标准更像是一种“需求审计工具”。它的语法本身没有技术含量，但每当你写出一条需求却套不进这个标准句式时，你就要警惕了，不是句式不行，而是需求本身还没想清楚。
2. EARS标准的六种句式模式：把需求“装进模板”
2.1 普遍型需求（Ubiquitous）：全程成立，不需要触发
有些需求从系统启动那一刻到关机，任何时候都必须成立，不存在触发条件。这种就叫普遍型需求，句式最简单：
系统应 <动作> <可量化指标>举例来说：
系统应在运行期间每100毫秒采集一次温度传感器数据。
这句话没有触发条件，因为它要求的是不间断的周期行为。写普遍型需求时要注意一个陷阱：凡是说“系统应支持某某功能”的，十有八九不是普遍型需求，因为“支持”是一个能力描述，不是一个行为。比如“系统应支持用户修改密码”这句话就不合格，应该改成“当用户在设置页点击修改密码按钮时，系统应显示密码输入窗口”。普遍型需求适合写那些真正全天候成立的基础行为，不要一上来就把所有需求都写成普遍型。
2.2 事件驱动需求（WHEN）：一时触发的响应
这是EARS标准里最常用、也最好用的一种模式，对应外部事件或内部事件发生的瞬间响应。句式是：
当 <触发事件> 时，系统应 <系统响应>例如：
当系统收到上位机发送的启动指令时，系统应在500毫秒内返回启动成功标志。
WHEN模式要求你能准确回答“什么事件”和“什么响应”这两个问题。写这条需求的时候，你自然而然就会去核对协议、接口、时序，因为这些细节才是触发事件的一部分。你如果写“当系统收到指令时，系统应作出响应”，那就等于没写。事件本身要可识别，响应结果要可观测，这是WHEN模式的两条硬规矩。
很多从传统需求文档转过来的团队，最容易犯的毛病是把所有需求都写成“当……系统应……”的形式，但这其实不对。一个需求是WHEN还是WHILE，取决于触发点是瞬时事件还是持续性状态，需要仔细区分。
2.3 状态驱动需求（WHILE）：只要状态成立就持续生效
和WHEN模式很像，但WHILE模式描述的不是某个瞬间的触发，而是一段时间内系统处于某个状态时持续发生的行为。句式是：
当系统处于 <某状态> 时，系统应 <持续行为>举个例子：
当系统处于产线调试模式时，系统应关闭所有与外部监控平台的自动报警发送功能。
这里“调试模式”是一个持续存在的前提状态，只要系统还处于这个状态，后面这个行为就得一直维持，一旦退出该状态，行为也随之终止。WHEN和WHILE的区别，我常用一个生活类比：门铃响了，你会去开门，这是WHEN；你生病在家躺着，你一直在休息，这是WHILE。前者是事件触发一次，后者是状态持续生效。很多需求写手把WHENE和WHILE混用，写出来的需求表面通顺，实际上测试设计完全没法落地。你连“这是瞬间行为还是一段持续行为”都没想清楚，怎么可能设计出有效的测试用例？
2.4 可选功能需求（IF...THEN）：只在功能被选用时生效
有些需求不是系统的基本行为，而是某个可选项、某个开关、某种配置启用后的行为。这种场景用IF...THEN模式：
如果系统支持 <可选功能或配置> ，则系统应 <行为>例如：
如果系统启用了夜间静默模式，则系统应在22点到次日6点之间，将报警提示音量降至20%。
IF条件描述的是产品变体选项，而不是运行时状态。也就是说，这句话的意思是“只有当系统采购、部署或配置中包含夜间静默模式这个功能时，这条需求才生效”。它特别适合处理产品标配和选配的区分。一套产品线如果有基础版和高级版，高级版多出来的那些行为，全部建议用IF...THEN模式写，这样需求与产品配置一一对应，后续做配置管理的时候会轻松很多。
2.5 异常处理需求（IF...THEN）：把“坏场景”也写进需求
EARS标准里另一类IF...THEN用法是异常行为，专门用来描述系统遇到错误、故障、越界情况时该怎么办。格式通常写成：
当系统检测到 <异常事件> 时，系统应 <保护性响应>例如：
当系统检测到温度传感器数据超过85摄氏度时，系统应在1秒内停止加热输出并触发过温告警。
几乎每个系统都有异常逻辑，但传统需求里最常见的写法就是“系统应具备异常处理能力”或“如发生异常，系统应给出提示”。这种需求写了等于白写。什么异常？哪个子系统检测？响应是提示还是停机？几秒内响应？提示给谁？EARS标准把异常需求拉到了和正常需求同等重要的位置。我觉得这是EARS被低估的一大价值：它强迫大家把失效场景加入需求文档，而这些场景恰恰是开发和测试最容易遗漏的。
2.6 组合句式与WHERE：复杂条件怎么拼
真实系统很少有单一条件就能说清楚的需求，往往要同时满足多个条件。EARS标准允许组合，常见形式是：
当 <事件或状态A> 且 <条件B> 时，系统应 <响应>也有人喜欢用WHERE来引入环境条件或平台约束，比如：
当设备处于自动巡检模式且网络通信正常时，系统应按预设巡检路线执行数据采集。
WHERE一般用于表示“在特定范围、特定平台、特定版本下”，本质上是对前面条件的一个限定。我的建议是，一个需求条目里的条件组合别超过两个。条件一旦超过两个，可读性急剧下降，逻辑分支反而增加，这时候与其硬拼一个长句子，不如拆成两条需求。组合句式是最后的兜底手段，不是所有的复杂度都该往一条句子里塞。这是我在很多文档评审里反复强调的一点。
3. 在真实项目中落地EARS标准：从需求条目到评审清单
3.1 团队先立规矩：把EARS语法写进《需求编写规范》
EARS标准不是看一遍就会自动生效的，它需要一个团队层面的落地过程。第一步就是定义自己团队的“需求语法规范”，而且一定要白纸黑字写下来。我建议规范里至少包含三块内容：
首先，规定六种EARS模式分别长什么样、什么场景用什么模式，每种模式配一个本团队业务领域的真实示例。其次，规定术语使用，比如主语统一用“系统”“控制器”“引擎模块”这类具体名词，不许出现“它”“该平台”“相关模块”这种指代不明的主语。最后，规定关键词黑名单，把“及时”“合理”“尽可能”“有效”“支持”等词列为需求写作禁用词，凡是出现这些词的条目一律打回重写。
这一步看起来像形式主义，实际作用非常大。因为需求评审一旦有了明确检查红线，评审效率会高很多。以前评审会上大家都在讨论业务逻辑，以后评审会上先过语法关，过不了语法关的连讨论的资格都没有。这种“机械式检查”恰恰能挡住绝大多数低质量需求。
3.2 一份可直接复用的需求条目模板
光有语法还不够，我建议每条需求都用一个固定表格格式管理，这样不仅方便追溯，还能和测试用例自动映射。下面是我常用的一份字段模板：
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 需求编号 | 唯一ID，按模块缩写+序号 | SRS-ALM-001 |
| 需求标题 | 一句话概括 | 火灾报警日志记录 |
| EARS模式 | 属于六种模式中哪一种 | 事件驱动（WHEN） |
| 前置/触发条件 | 状态或事件描述 | 系统检测到火灾报警信号且正常供电 |
| 系统响应 | 主语 + 动作动词 + 对象 | 系统应在3秒内写入本地日志 |
| 验收标准 | 如何证明需求被正确实现 | 日志写入时间戳与报警时间差≤3秒 |
| 需求来源 | 客户编号、会议纪要素材编号 | 会议纪要2026-03-12 |
这个表格看起来简单，但它强制每个需求都具备可追溯性和可测试性。尤其是“验收标准”这一列，很多团队以前根本不写，现在必须填，一填就把模糊词暴露出来了。比如验收标准如果填的是“处理速度较快”，那你这条需求本质上还是没写清楚。
3.3 需求评审检查清单：让“标准”真正被检查
EARS标准落地的关键是评审环节。我整理过一份评审检查清单，团队每次评审新需求直接按这个清单打分，省去了大量无休止的讨论。清单核心条目如下：
- 主语是否明确？是否落在系统边界内？是否出现了“相关人员”“模块A/B”这种模糊指代？
- 是否使用了EARS标准模式？还是皱着眉头硬憋了一句非结构化长句？
- 触发条件是否完整？外部事件、内部状态、前置条件、异常分支是否都有对应条目？
- 动作动词是否可观测？是否出现了“支持”“实现”“管理”这一类不产生可观测结果的动词？
- 是否存在“及时”“合理”“充分”“尽量”等禁用模糊词？
- 验收标准是否量化？哪怕是定性标准，也应该有可观测的判定规则，比如“界面弹出错误提示”就是可观测的。
- 一条需求是否只描述一个行为？有没有把日志、告警、转发、显示四个行为塞进同一句话？
- 是否存在设计实现细节？比如“通过调用xxx接口”“使用静态变量保存”这类语句，应该从需求文档拿走，丢给设计文档。
- 需求之间是否冲突？检查两个同类需求的动作、条件、时间指标是否自洽。
这张清单用多了之后，团队会形成条件反射。我见过最夸张的场景是评审会上有人念了一条需求，另外一个人脱口而出“这是WHEN还是WHILE都不清楚，打回重写”。听起来很像杠精，但实际上评审效率高得不可思议。
3.4 与ISO/IEC/IEEE 29148、CMMI/GJB 5000B类体系如何共存
有人会问，我们已经按ISO/IEC/IEEE 29148做了需求工程，按CMMI或GJB 5000B建了过程管理体系，还需要EARS标准吗？我的理解是：体系标准负责解决“过程怎么设计”，EARS负责解决“需求条目怎么写得能验证”。两者是上下层关系，不是替代关系。
ISO/IEC/IEEE 29148强调需求要具备正确性、完整性、一致性、可验证性等质量属性，但它不会教你每一个句子怎么写才算可验证。CMMI/GJB 5000B这类软件能力成熟度模型关注的是需求开发、需求管理过程域有没有建立，也不会落到一个具体句式上。EARS标准恰恰就是填补这最后一百米的东西：用固定语法把质量属性变成写作约束。所以每次有人问我“我们公司已经过了各种体系认证，要不要学EARS”，我的回答都是：如果你正在被“需求模糊、测试难做”困扰，那和过没过体系无关，EARS照样值得试。
4. 实操过程：把一段“烂需求”改成EARS标准需求全记录
4.1 一份“反面教材”和它的病灶诊断
先放一段我从真实项目里脱敏后的原始需求：
系统应能及时处理报警信号，并支持多种报警类型，以便运维人员掌握现场情况。
这句话表面上信息量很大，实际上几乎没有传递任何可执行信息。我在项目现场通常会带着团队做四步诊断：
第一步，圈出模糊词。这里最明显的是“及时”和“多种报警类型”。“及时”缺量化，“多种”至少要说清楚是哪几种：是火警、入侵、设备故障，还是温度越限、通信异常？第二步，圈出非行为动词。“处理”这个词看似是动作，实际上是垃圾桶，什么都装得进去。第三步，判断主语和边界。“系统”是完整系统还是报警子系统？如果写了等于没写。第四步，检查需求间的隐含逻辑。“以便运维人员掌握现场情况”这句话暴露了功能目的，但目的不是需求，你得把这条目的翻译成一个具体的动作，比如“向运维人员展示报警详情”。
4.2 拆解步骤：找触发、找动作、找指标、找异常
避免凭空改写，我建议按以下顺序操作，这也是我在团队内部固定的四步法：
第一步，先列出所有可能的触发场景。报警信号从哪来？传感器上报、外部协议接入、还是操作人员手动触发？触发之后系统要做什么？记录日志、更新界面、发出通知、同时联动其他设备？第二步，给每个动作设定时间指标。这个指标不一定一开始就有，需要和业务方谈判。可以直接问一句：从报警发生到运维人员看到界面提示，您能接受的最长延迟是几秒？这个问题一旦问出口，业务方就被迫从“尽快”切换到具体数值。第三步，明确系统状态。设备是不是处于正常运行状态？是否在静音模式？是否处于调试模式？不同的状态可能要求不同的行为。第四步，把异常路径补上。报警处理过程中，如果日志写入失败怎么办？如果通信断线怎么办？这些异常场景不补，需求就还有暗坑。
4.3 改写后的EARS需求条目，以及怎么继续拆
上面那段“烂需求”，按照四步法拆分后，会得到一组EARS需求条目。我这里直接列出结果，并附上分析：
SRS-ALM-001（事件驱动）：当系统检测到任一已配置的报警事件时，系统应在2秒内将报警信息和时间戳写入本地日志。
这一条拆掉了“及时”，把“处理”定格成“写入本地日志”这个可测试动作。“报警事件”被定义成了“已配置的”，意味着系统需要维持一份报警配置表，这也是一个隐含需求，后续应该单独补一条。
SRS-ALM-002（状态驱动）：当系统处于报警静默状态时，系统应停止播放报警提示音，并继续在界面显示报警状态。
这条说明用户不想被打扰但有告警时，系统仍要存在可感知的信息，“状态驱动”选了WHILE。
SRS-ALM-003（普遍型）：系统应在运行期间每30秒巡检一次所有已配置报警通道的连接状态。
这条把“支持多种报警类型”落成具体巡检行为。如果不定义“报警通道”，打回去重写。
SRS-ALM-004（异常处理）：当系统向监控平台发送报警消息失败时，系统应在5秒内触发重传，并在连续3次重传失败后将消息缓存至本地待发送队列。
这条是异常路径的典型写法，把所有“如果出错了怎么办”的模糊预期变成了硬性逻辑。
改造完成后你会发现，原先一句话拆成了四句话，并且每一句都能直接推导出测试用例。比如SRS-ALM-001的测试就是：构造一条已配置的报警事件，判读日志写入时间戳与报警时间差是否小于等于2秒。这就是EARS标准带来的可测试性溢价。
5. 常见问题与避坑技巧：我这些年踩过的坑
5.1 五个高频坑：从句子到管理，逐个排雷
我这几年评审过无数需求文档，有些坑几乎每个团队都会踩一遍。整理成一张速查表，方便大家直接对照自查。
| 坑点 | 典型表现 | 根因 | 解决思路 |
|---|---|---|---|
| 状态与事件混淆 | 把“当系统处于应急模式时”写成WHEN | 没有区分瞬时触发和持续状态 | 先问自己：这个条件是一次性事件还是持续状态？状态用WHILE模式 |
| 需求变成设计 | “通过调用MQTT消息队列上报数据” | 把实现方案混入需求 | 需求只写“系统应向监控平台上报报警数据”，实现方案放设计文档 |
| 动作动词太虚 | “应支持”“应实现”“应允许” | 用能力描述代替行为描述 | 替换为“显示”“写入”“启动”“返回”“停止”等可观测动作 |
| 过度拆分 | 一条报警需求拆了八个原子条目 | 把“单一逻辑”理解成了“最小动作” | 单一逻辑的标准是一条需求只有一个功能意图，而不是只做一件事 |
| 指代混乱 | “该模块”“相关组件”“其他设备” | 没有全局术语管理 | 建术语表，主语禁用代词，所有名词唯一化 |
这五个坑里面，我认为“需求变成设计”是伤害最大的。需求文档一旦写入了实现细节，不仅限制了设计空间，还会把测试重点带偏。比如“通过调用MQTT队列上报”这条，万一硬件方案变了，MQTT不适用了，需求就得改，但你真正需要的只是“上报报警数据”而已。EARS标准对这一点有天然的抑制作用，因为它的句式是标准的，你很难把设计细节塞进去，硬塞进去会出现明显的不协调感。
5.2 工具层面：从Word到需求管理平台，怎么把EARS固化成流程
EARS标准可以完全用Word落地，团队小的时候没问题。但随着需求数量增长，我建议至少采用带表格结构的需求管理工具，比如禅道、Jama、DOORS或者企业内部的Confluence。关键不是工具多高级，而是能不能做到三件事。
第一，把EARS的六种模式做成需求模板下拉框。写需求时必须先选模式，选不上来就没办法填写其他字段，这个机制逼迫每个人在动笔前做模式判断。第二，把禁用词做成自动检查规则。现在很多工具支持自定义脚本或正则检查，每写一条需求自动扫描“及时、合理、尽快”等词汇，发现就标红。这个功能极其有效，我从上线那天起，文档模糊词比例直接下降了一大半。第三，把需求编号和测试用例ID绑定。需求表格里的“验收标准”字段自动映射到测试用例的“前置条件”“测试步骤”“预期结果”，在工具层面形成追溯链路。
5.3 团队推行的现实经验：先试点，再画红线
如果你想把EARS标准引入一个已经习惯了传统写法的团队，我不建议一上来就全面铺开，那样阻力会非常巨大。我推荐的做法是选一个正在开发的、规模适中的模块作为试点，拉着核心开发、测试、产品三方一起，把这个模块的新增需求全用EARS标准改写。跑上一两个迭代之后，大家看到测试用例更容易写了、开发问的澄清问题变少了、评审扯皮时间缩短了，这个效果会自己说话。
第二步是把“需求语法检查”写入项目定义完成的条件。也就是说，没有通过EARS语法检查的需求，不允许进入迭代计划。这一步相当于画红线，画红线不是要刁难人，而是给所有人一个清晰的标准：什么样的需求算“完成”。需求完成的定义如果只是“有人写出来了”，那项目质量肯定没人管；但需求完成的定义是“符合EARS语法、验收标准可执行”，那后面开发、测试的压力都会小很多。这套标准推广初期一定会有人抱怨“太死板、限制发挥”，但实际操作一段时间后，抱怨的人往往是受益最大的人。
还有一个小技巧：评审会上遇到写得很差的原始需求时，不要直接帮对方改写，而是先用提问的方式把触发条件、动作、指标、异常这四件事问出来。你要相信，对方只要能把这四个问题回答完整，一条高质量需求就已经成型了，剩下要做的只是套模板。EARS标准最大的杠杆不是写作，而是提问。
6. 最后分享一点个人体会
我自己刚开始接触EARS标准的时候，觉得这就是把“人话”翻译成“机器话”，很别扭，也怀疑到底有没有必要。真正让我转变的，是一次需求评审：一条关于“系统异常时自动重启”的需求，开发认为重启后应该回到默认配置，测试认为应该保留现场数据，产品则认为要确保业务连续性，三个人在会议桌上争了一个下午。后来我按EARS标准把这条需求拆成了三条，一条写触发条件，一条写重启后的恢复动作，一条写异常报警通知，整个争议瞬间就消失了。那次之后，我才明白EARS标准不是什么高深理论，它就是一把让所有人对齐认知的尺子。
如果你现在正准备尝试，我建议别贪多求全，第一周只做一件事：从现有需求文档里找出所有带“及时、合理、大概、尽快”这类词的需求，用WHEN模板逐个改写一遍。改完十条，你大概率就能体会到那种“需求终于落地了”的踏实感。等这个动作变成肌肉记忆，再慢慢引入WHILE、IF-THEN和其他模式，最后你们团队自然会形成属于自己的EARS标准版本。这个投入很小，但带来的收益，远比你想象中大。
