需求分析阶段：系统需求捕获技术、需求规格说明书编写、需求评审流程、需求基线化管理

各位工程师朋友，欢迎来到第二章。上一章我们聊了V模型的整体骨架，这一章咱们要往里面填第一块肉——需求分析。

说实话，我见过太多项目栽在需求上。有的团队代码写了一半，客户突然说“我要的不是这个功能”。为什么会这样？说白了，需求没抓牢。在V模型里，需求分析是整个开发流程的源头，源头歪了，后面再怎么校正都费劲。

这一章我会把需求捕获、规格编写、评审和基线管理这四块内容串起来讲。你想想看，如果连客户到底要什么都没搞清楚，后面的设计、编码、测试不就成了瞎忙活吗？

2.1 系统需求捕获技术

需求捕获不是坐在办公室里拍脑袋。我个人的习惯是，先搞清楚需求来自哪里，再用对的方法去挖。

2.1.1 需求来源与分类

需求一般分两类：

• 功能需求：系统“做什么”。比如“ECU必须能在100ms内响应刹车信号”。
• 非功能需求：系统“做得怎么样”。比如“系统在-40°C到85°C环境下稳定运行”。

我在做车载项目时，客户经常只提功能需求，非功能需求得靠我们主动去问。比如“你这设备在高温下能撑多久？”——你不问，客户可能压根没想过。

2.1.2 常用捕获技术

下面这张表是我常用的几种方法，各有各的适用场景：

技术	适用场景	我的经验
用户访谈	早期探索，了解用户痛点	别只问“你想要什么”，多问“你现在怎么做的”
场景分析	梳理典型使用流程	画用例图比写文字管用得多
原型演示	验证理解是否一致	低 fidelity 原型就够了，别在原型上花太多时间
文档分析	已有系统升级或对标	注意文档版本，我吃过旧文档的亏
头脑风暴	探索创新功能	控制人数，5-7人最有效

2.1.3 需求捕获的常见坑

我曾经在一个医疗项目中，客户说“要一个报警功能”。我们理解成“声音报警”，结果客户要的是“灯光闪烁+短信通知”。你看，一个词就能差出十万八千里。

避坑指南：

• 不要假设客户懂技术术语
• 不要跳过“为什么”这个追问
• 不要只记录结论，要记录上下文

2.2 需求规格说明书编写

需求捕获完了，得写下来。这就是需求规格说明书（SRS）。

我记得刚入行时，觉得写文档就是走形式。后来有一次，因为需求描述模糊，开发组和测试组吵了一个星期——从那以后，我再也不敢糊弄SRS了。

2.2.1 SRS的核心结构

一份合格的SRS，至少包含以下内容：

1. 引言：项目背景、范围、术语定义
2. 总体描述：系统上下文、用户特征、约束条件
3. 具体需求：功能需求、接口需求、性能需求、安全需求
4. 附录：参考文档、变更记录

这里有个关键点：每条需求都要有唯一编号。我习惯用“REQ-模块-序号”的格式，比如REQ-ECU-001。这样评审和测试时，大家能精确引用。

2.2.2 需求编写的质量属性

好的需求长什么样？我总结了四个字：清、完、一、可。

属性	含义	反例	正例
清晰	无歧义	“系统响应要快”	“系统响应时间≤50ms”
完整	不缺信息	“系统支持OTA升级”	“系统支持通过Wi-Fi进行OTA升级，升级包大小≤100MB”
一致	不矛盾	“功耗≤5W”和“性能全开时功耗≤10W”	统一为“全速运行时功耗≤10W，待机时≤5W”
可验证	能测试	“界面要美观”	“界面按钮间距≥8px，字体≥12pt”

2.2.3 需求编号与追溯

我习惯在SRS里加一个需求追溯矩阵的雏形。比如：

REQ-ECU-001: 刹车信号响应时间 ≤ 100ms
  来源: 客户访谈记录 v2.3, 第5页
  关联: 系统架构设计 SA-03
  测试: TC-ECU-001, TC-ECU-002

这样做的好处是，后面做测试用例时，每一条需求都能找到对应的测试。V模型左半边的需求，直接对应右半边的验收测试，就是这个道理。

2.3 需求评审流程

写完了SRS，别急着往下走。评审是必须的。

我曾经在一个项目中，SRS写了200页，结果评审时发现30%的需求有歧义。如果当时不评审，这些歧义就会一路传递到代码里，最后变成bug。

2.3.1 评审的三种形式

形式	特点	适用阶段
同行评审	同级工程师互查，效率高	初稿完成后
正式评审会	多方参与，有记录有结论	定稿前
走读	作者逐条讲解，听众提意见	需求复杂时

我个人比较推荐“先同行评审，再正式评审会”的组合。同行评审能过滤掉低级问题，正式评审会集中解决争议。

2.3.2 评审检查清单

下面是我每次评审必查的清单：

• 每条需求是否都有唯一编号？
• 是否有歧义或模糊的表述？
• 功能需求和非功能需求是否都覆盖了？
• 需求之间是否有冲突？
• 每条需求是否都可验证？
• 是否有遗漏的边界条件？

2.4 需求基线化管理

需求定下来之后，不是不能改，而是不能随便改。这就引出了基线化管理。

我记得有一次，客户在开发中期说“加一个功能”。项目经理觉得小改动，直接让开发做了。结果这个“小改动”影响了三个模块的接口，最后返工花了两周。如果当时走了变更流程，至少能评估出影响范围。

2.4.1 什么是需求基线

需求基线，就是经过评审并正式批准的需求版本。一旦基线建立，所有变更都要走正式流程。

基线通常包含：

• SRS文档（带版本号）
• 需求追溯矩阵
• 评审记录
• 批准签字

2.4.2 变更控制流程

变更不是不让改，而是要有规矩。我常用的流程是：

1. 提交变更申请：说明变更内容、原因、优先级
2. 影响分析：评估对进度、成本、质量的影响
3. 变更控制委员会（CCB）评审：决定是否批准
4. 更新基线：批准后，更新SRS并发布新版本
5. 通知相关方：确保所有人都用最新版本

2.5 本章知识体系图

下面这张图把需求分析阶段的核心流程串起来了。你可以把它贴在工位旁边，做项目时对照着看。

这张图展示了需求分析的五个核心步骤。注意那个红色的虚线箭头——评审发现问题后，要回到需求捕获或分析阶段去修正。这不是一条单行道，而是一个闭环。