4、系统需求规范（SRS）：需求编写原则、需求属性定义、需求追溯矩阵、需求评审流程
好，咱们进入第四讲。系统需求规范，也就是SRS。这玩意儿说白了，就是整个制动系统的“宪法”。
我见过太多项目，最后出问题，往回一查，根子都在需求上。要么写得不清楚，要么需求本身就有矛盾。你想想看，地基没打好，上面盖的房子能稳吗？
4.1 需求编写原则
写需求不是写小说，不能有文学色彩。我个人的习惯是，一条需求拿出来，要让一个刚毕业的工程师也能看懂，而且只有一种理解方式。
核心原则就三条：
- 唯一性： 每条需求只有一个编号，且只描述一个功能。别把“制动响应时间小于200ms且踏板力小于500N”写成一条，拆开！
- 可验证： 写完之后问自己一句：“这玩意儿我怎么测？” 如果答不上来，那就是废纸。比如“制动感觉良好”这种话，千万别写。要写成“在0.3g减速度下，踏板行程在30mm-50mm之间”。
- 无歧义： 避免“大概”、“可能”、“通常”这类词。我记得有一次评审，看到一条需求写“制动液位低时报警”，结果大家吵了半天——多低算低？是低于MIN线，还是低于某个百分比？后来改成了“当制动液位低于主缸储液罐MIN刻度线2mm时，点亮红色报警灯”。
避坑指南：
我曾经吃过一次亏。一条需求写“系统应具备故障诊断功能”。结果开发团队只做了被动诊断，而测试团队认为需要主动诊断。最后扯皮了两个月。所以，一定要把“诊断”的具体行为写清楚——是上电自检，还是周期性检测，还是两者都要？
4.2 需求属性定义
光把需求写出来还不够，你得给每条需求贴上“标签”。这些标签就是属性。我习惯把属性分成两类：核心属性和管理属性。
核心属性（必须要有）：
| 属性名 | 说明 | 举例 |
|---|---|---|
| 需求ID | 唯一标识，建议用层级编码 | SRS-BRAKE-001 |
| 需求类型 | 功能/性能/接口/安全/约束 | 性能需求 |
| 优先级 | 高/中/低 或 1/2/3 | 高（影响安全） |
| 来源 | 来自哪个上层文档或客户 | 客户需求文档第3.2节 |
| 状态 | 草稿/已评审/已批准/已变更 | 已批准 |
管理属性（建议加上）：
- 责任人： 谁写的这条需求？出了问题找谁？
- 版本号： 需求改过几次？每次改了什么？
- 关联风险： 这条需求如果没实现，会有什么风险？
我的小技巧：
我习惯在需求属性里加一个“验证方法”字段。比如“台架测试”、“实车测试”、“仿真分析”。这样在写测试用例的时候，直接照着这个字段来就行，省得再分析一遍。
4.3 需求追溯矩阵
需求追溯矩阵，英文叫RTM。说白了，就是一张“谁是谁的爹”的表格。
为什么要做这个？我举个例子。有一次项目后期，客户突然说要改一个制动辅助功能。我打开RTM一看，好家伙，这条需求关联了3条系统需求、5条软件需求、2条测试用例。如果没有RTM，你根本不知道这一刀砍下去会伤到谁。
RTM的核心作用：
- 正向追溯： 从客户需求出发，能找到对应的系统需求、子系统需求、测试用例。确保每个客户要求都被覆盖了。
- 反向追溯： 从测试用例出发，能找到它验证的是哪条需求。确保没有“无源之水”。
- 变更影响分析： 改一条需求，立刻知道哪些设计文档、代码、测试用例需要跟着改。
RTM的格式，我一般这样写：
| 客户需求ID | 系统需求ID | 子系统需求ID | 测试用例ID | 验证状态 |
|---|---|---|---|---|
| CR-001 | SRS-BRAKE-001 | SSR-BRAKE-001 | TC-BRAKE-001 | 已通过 |
| CR-001 | SRS-BRAKE-002 | SSR-BRAKE-002 | TC-BRAKE-002 | 待测试 |
| CR-002 | SRS-BRAKE-003 | SSR-BRAKE-003 | TC-BRAKE-003 | 未通过 |
注意：
RTM不是一次性写完就完事的。它是个活文档。每次需求变更，都要同步更新RTM。我见过最惨的情况是，项目验收时发现RTM里20%的测试用例对应的需求已经删了，但测试用例还在跑。白白浪费了人力物力。
4.4 需求评审流程
需求写完了，别急着往下走。先评审。评审不是走过场，是真刀真枪地找问题。
我习惯的评审流程分三步：
- 个人预审： 评审会之前，把文档发给大家。每个人自己看，把问题记下来。我要求至少提前3天发，别搞“当天发当天审”这种把戏。
- 正式评审会： 会上不读文档，只讨论问题。作者先过一遍主要变更点，然后逐条讨论预审时收集的问题。注意，会上只做决策——这个需求改还是不改？不改的理由是什么？改的话谁负责？什么时候改完？
- 问题跟踪与闭环： 评审会开完，会有一堆Action Item。必须有人跟踪，直到所有问题都关闭。我一般用一张表来跟踪：
| 问题编号 | 问题描述 | 提出人 | 责任人 | 解决措施 | 状态 |
|---|---|---|---|---|---|
| #001 | 需求SRS-BRAKE-001中“响应时间”定义不明确，未说明是从哪个信号开始计时 | 张三 | 李四 | 修改为“从制动踏板开关信号有效到制动主缸压力达到目标值的10%” | 已关闭 |
| #002 | 需求SRS-BRAKE-005与SRS-BRAKE-010存在矛盾，一个要求延时1s，一个要求立即响应 | 王五 | 李四 | 与客户确认后，删除SRS-BRAKE-005，统一按SRS-BRAKE-010执行 | 已关闭 |
评审时最容易踩的坑：
我曾经遇到过一个项目，评审会上大家都很客气，没人提问题。结果到了测试阶段，发现需求里漏了一条关键的性能指标——高温环境下的制动响应时间。最后只能紧急补需求，导致整个项目延期了一个月。所以，评审时一定要有人唱黑脸，专门挑刺。我建议评审组里至少有一个“毒舌”角色，专门负责找茬。
嗯，关于SRS，今天就聊这么多。记住，需求写得越清楚，后面的开发、测试、维护就越省心。别怕在需求阶段花时间，这其实是整个项目里性价比最高的投入。