EO 3.2.1 了解基于自然语言的制品以及它们的优点和缺点(L1)
自然语言的效果：
- 名词化
- 无参考索引的名词
- 全称量词
- 未完全规格说明的条件
- 未完全规格说明的动词
优点和缺点
为什么自然语言是需求工程中最常用的工具，却又永远无法被单独信任？
结合现实项目中的血泪教训 ，让你彻底吃透为什么需要自然语言 + 图形模型双管齐下：
一、优点（为什么我们离不开它？）------ 主打"低门槛"与"高包容"
1. 不受约束、具有极强的表现力和灵活性
现实意义：你可以用自然语言描述任何天马行空的想法，比如"系统界面风格要像苹果官网一样简洁大气"，或者"支付失败时的报错要带点幽默感"。这些东西你用形式化语言（如数学公式或严格的代码逻辑）根本没法写，但自然语言可以。
2. 几乎任何可以想象到的需求都可以表达
现实意义：无论是描述复杂的业务流程（"审批人出差时，自动转交其直属上级"），还是描述模糊的愿景（"我们要打造一个全球领先的生态平台"），自然语言都能覆盖。它没有"语法死角"。
3. 阅读和理解不需要专项训练
现实意义（最重要） ：业务方（客户、老板）不需要学UML（统一建模语言）或数理逻辑 ，就能看懂需求文档。这保证了需求工程师能把写好的文档直接扔给用户确认，用户能马上反馈："不对，这个地方不是我想要的。"------这是模型图（如类图、状态图）永远做不到的沟通效率。
二、缺点（为什么它"成也萧何，败也萧何"？）------ 主打"高成本"与"高风险"
1. 经常能够以不同的方式解释（歧义性）
血的教训 ：你写"系统应支持多用户登录"，开发理解为"允许多人同时登录同一账号"，产品经理理解为"一人一个账号，但能切后台"。双方都觉得对方懂自己，结果验收时炸锅。
本质 ：自然语言的上下文依赖太强，而需求文档往往无法穷尽所有上下文。
2. 检测歧义、遗漏以及不一致是困难且代价高昂的
为什么难且贵？ 因为靠人眼去读几百页的纯文本 ，就像玩"大家来找茬"。前10页写的"订单金额=商品总额+运费"，后面第80页写的"VIP免运费且打9折"，这两条在逻辑上可能冲突，但纯文本很难通过肉眼扫描自动发现。
代价高昂 ：这种矛盾通常不会在写文档时被发现，而是在编码阶段 程序员发现写不下去了，或者在测试阶段 测试人员写了两条矛盾的用例，才暴露出来。发现得越晚，改需求的成本呈指数级上升（从改一行字，变成改代码、改数据库、重测）。
三、终极解决方案（IREB的推荐策略）：不做选择题，做"组合题"
正是基于上述优缺点，IREB才反复强调（正如你之前学到EU 3.1.4那样）：
自然语言用来"定大局、讲人话"，图形/形式化模型用来"定细节、堵漏洞"。
| 使用场景 | 推荐用自然语言 | 推荐用模型（如用例图/状态机/类图） |
|---|---|---|
| 跟业务方确认业务目标 | ✅ 首选（老板只看得懂这个） | ❌ 老板看不懂图，会觉得你在炫耀技术 |
| 描述系统边界和参与者 | ✅ 辅助（写文字说明） | ✅ 首选（用例图一眼看清谁跟谁交互） |
| 描述复杂的状态流转（如订单生命周期） | ❌ 写文字要写好几页，且容易产生歧义 | ✅ 首选（状态机图一张图胜过千言万语） |
| 描述异常处理逻辑（如网络超时怎么办） | ✅ 首选（用"如果......那么......否则......"说清楚） | ❌ 流程图能画，但异常分支太多会导致图极度混乱 |
| 作为最终验收的唯一依据 | ✅ 必须要有（合同只认白纸黑字的文字，不认图） | ✅ 作为附件参考（图表辅助解释文字） |
总结一句
自然语言是需求工程的"面子"------它让所有人都能参与对话；模型是需求工程的"里子"------它确保对话的结果没有逻辑漏洞。专业的需求工程师，就是能用自然语言把故事讲圆（确保可理解），再用模型把故事里的每个细节钉死（确保无歧义）的人。 😊
自然语言的效果 1-5
这段内容非常实战，它直接指向需求工程中最棘手的问题：如何把模糊的"人话"翻译成精准的"需求话"。
IREB 在这里不是不让你用自然语言（毕竟自然语言最通用），而是给你标出了 "雷区" 和 "警戒区" 。你提供的第二段文字（自然语言的效果 1-5）其实是第一段的具体技术拆解，我帮你把它们合并成一张 "避坑与排雷表"。
第一类：绝对要避免的"硬伤"（结构性缺失）
这类问题会导致需求逻辑不闭环，读者必须"猜"才能懂。原文归为"需要避免"：
1. 不完整的描述 / 未完全规格说明的动词
- 典型雷句 ："系统应处理用户的订单。"（"处理"是个万能筐，到底是指"创建"、"修改"、"删除"还是"发货"？）
- 技术拆解（对应 5. 未完全规格说明的动词）：动词模糊，动作边界不清。
- 排雷方案 ：用原子性的动词代替。改为："系统应在收到支付回调后，将订单状态由'待支付'更新为'已支付'。"
2. 未指明的名词 / 无参考索引的名词（代词指代不明）
- 典型雷句 ："系统应将此信息发送给用户。"（"此信息"指什么？是订单号？是物流单？还是优惠券？）
- 技术拆解（对应 2. 无参考索引的名词）：名词没有明确的"源头"或"定义"。
- 排雷方案 ：强制指代 。改为："系统应将当前订单的物流单号通过短信发送给用户。" 或者引入编号引用："如 3.2 节定义的'物流信息'。"
3. 不完整的条件 / 未完全规格说明的条件
- 典型雷句 ："当库存不足时，系统应提示用户。"（"库存不足"怎么定义？是等于0，还是小于安全库存线？）
- 技术拆解（对应 4. 未完全规格说明的条件） ：条件缺少阈值 或判定公式。
- 排雷方案 ：量化边界 。改为："当商品库存数量 ≤ 0 时，系统应弹出'缺货'提示，并禁止用户提交订单。"
4. 不完整的比较
- 典型雷句 ："新系统的响应速度应更快。"（比谁快？快多少？跟老系统比，还是跟竞品比？）
- 技术拆解 ：缺少参照物 和具体度量值。
- 排雷方案 ：设立基准 。改为："新系统在并发 100 用户时，首页加载速度应比旧系统提升 50%，即 ≤ 1.5 秒。"
第二类：必须小心使用的"软刀子"（语法与结构陷阱）
这类问题不一定会让需求"逻辑错误"，但极容易引入歧义 或难以测试。原文归为"需要小心使用"：
5. 被动语态
- 典型雷句 ："错误信息应被显示。"（被谁显示？系统主动弹窗，还是前端被动渲染？隐藏了真正的执行主体"系统"或"用户"。）
- 危害：丢失责任分配，导致开发和测试找不到"主语"。
- 排雷方案 ：主动语态 。改为："系统应在登录失败时，主动显示错误提示框。"
6. 全称量词（比如"所有"或"从未"）
- 典型雷句 ："所有用户都必须在 5 分钟内完成支付。"（包括黑名单用户？包括测试账号？）
- 技术拆解（对应 3. 全称量词）：绝对的断言往往有例外，测试人员只要找到一个例外，这条需求就被"证伪"了。
- 排雷方案 ：限定范围 。改为："除黑名单用户外 ，所有已登录用户必须在 5 分钟内完成支付，否则订单自动取消。"
7. 名词化（即由动词派生的名词，例如："鉴定"、"验证"、"实施"）
- 典型雷句 ："系统应负责用户身份鉴定。"（"鉴定"是动词"鉴定"变来的名词。这句话把动作"怎么鉴定"和动作的结果"谁来做"藏起来了。）
- 技术拆解（对应 1. 名词化） ：名词化使需求静态化，丢失了"谁（主语）对谁（宾语）做了什么动作"的动态信息。
- 排雷方案 ：还原为强动词 。改为："系统应验证 （动词）用户输入的密码与数据库中的加密哈希值是否匹配。"
终极记忆口诀（帮你拿下 L2 考点）
把这 7 个雷点串成一句话，考试或写文档时拿出来过一遍：
"描述要完整，条件要量化；
名词要指代，比较要基准；
语态用主动，全称要限定；
名词化动词，统统拉出来！"
总结核心思想 ：
自然语言写需求，靠的是**"把抽象的变具体，把隐藏的变显式"**。不要怕字多，只怕意思飘。每写一句话，问自己一句："这句话，是否只有一种解释？测试人员能根据这句话写出唯一的通过/不通过判据吗？" 能过关，就是好需求。😊