2、需求分析与系统定义：功能需求与软件需求的区别、需求管理工具（DOORS、Polarion）、需求可追溯性矩阵（RTM）的建立

好，咱们进入第二章。说实话，需求分析这块，是V模式开发流程里最容易被低估的一环。很多人觉得写需求就是“把客户的话记下来”，结果到了集成测试阶段才发现，哦豁，原来大家理解的根本不是一回事。我在项目里见过太多次这种翻车现场了。

2.1 功能需求 vs 软件需求：到底差在哪？

先问个问题：客户说“我要一个自动雨刮”，这是功能需求还是软件需求？

答案是——功能需求。它描述的是“系统要做什么”，不关心具体怎么实现。而软件需求呢，是“软件要怎么做才能实现这个功能”。

我举个例子你就明白了：

类型	描述	例子
功能需求	系统对外表现的行为	当雨量传感器检测到降雨时，雨刮应自动启动
软件需求	软件模块的具体实现要求	雨量传感器ADC值超过阈值200时，雨刮控制信号置高

你看，功能需求是写给客户和系统工程师看的。软件需求是写给软件开发人员看的。两者之间是“翻译”关系，不是“复制”关系。

我个人习惯的做法是：先写功能需求，再逐条分解成软件需求。每条功能需求至少对应一条软件需求，但一条软件需求可能来自多条功能需求的组合。嗯，这里要注意，千万别搞成1:1的硬映射，那样反而会丢失信息。

2.2 需求管理工具：DOORS vs Polarion

说到工具，我最早用的是Excel。后来项目复杂度上来了，Excel根本扛不住。我记得有一次，一个需求变更了，我手动改了20多个地方，结果还是漏了一个。从那以后，我再也不敢用Excel管需求了。

现在主流的就是IBM DOORS和Siemens Polarion。我两个都用过，说说我的感受。

2.2.1 DOORS：老牌劲旅

DOORS在汽车行业里地位很高。它的优势是：

• 模块化强：需求可以按模块分文件夹，层级清晰
• 链接机制成熟：需求之间可以建立“父-子”、“派生”、“验证”等关系
• 基线管理：每次变更都能生成基线，方便追溯

但说实话，DOORS的界面确实有点老气。我第一次用的时候，感觉回到了90年代。而且它的权限管理比较死板，多人协作时容易冲突。

2.2.2 Polarion：后起之秀

Polarion是Siemens的产品，基于Web的。它的亮点是：

• 界面现代：浏览器打开就能用，不用装客户端
• 与ALM集成好：需求、测试、缺陷管理都在一个平台上
• 工作流灵活：可以自定义审批流程

我在一个项目里用过Polarion，当时团队分布在不同时区，Web端的优势就体现出来了。不过Polarion的报表功能我个人觉得不如DOORS强大，尤其是生成RTM的时候，DOORS的导出更干净。

2.3 需求可追溯性矩阵（RTM）的建立

RTM，说白了就是一张“谁跟谁有关系”的表。它的核心价值是：当需求变更时，你能快速知道哪些设计、哪些测试用例、哪些代码会受影响。

我曾经在一个项目里吃过亏。客户在SOP前一个月改了某个功能需求，我们以为只改软件就行，结果发现测试用例、标定参数、甚至硬件接口都要改。为什么？因为没有RTM，没人知道这个需求牵连了多少东西。

RTM的建立步骤，我一般这么来：

1. 列出所有功能需求：从客户需求文档里提取，每条一个ID
2. 分解为软件需求：每条功能需求对应若干条软件需求
3. 建立链接：在工具里把功能需求和软件需求关联起来
4. 扩展链接：继续关联到设计文档、测试用例、代码模块
5. 定期审核：每次需求变更后，更新RTM

一个典型的RTM表格长这样：

功能需求ID	功能需求描述	软件需求ID	软件需求描述	测试用例ID
FR-001	雨刮自动启动	SR-001	ADC阈值判断	TC-001
FR-001	雨刮自动启动	SR-002	雨刮电机控制	TC-002
FR-002	雨刮速度可调	SR-003	PWM占空比控制	TC-003

你想想看，如果没有RTM，你怎么证明“所有功能需求都被实现了”？怎么证明“所有测试用例都覆盖了需求”？这就是为什么ASPICE和ISO 26262都要求建立需求可追溯性。

最后说一句，工具只是辅助。DOORS也好，Polarion也好，甚至Excel也行，关键是流程要跑起来。我见过用Excel把RTM做得比DOORS还好的团队，也见过买了DOORS却当Word用的团队。工具是死的，人是活的。

好，这一章就到这。下一章我们聊聊系统架构设计，看看怎么把需求变成真正的软件架构。