系统需求分析：需求捕获技术、需求分析方法论、需求管理工具、需求到架构的映射

各位同学，今天我们聊聊系统需求分析。说实话，这一章是整个课程里最容易被低估的环节。我见过太多项目，架构师上来就画框图、分模块，结果做到一半发现需求根本对不上——那叫一个痛苦。所以，咱们先把需求这块地基打牢。

一、需求捕获技术：别等着用户告诉你

很多人觉得需求捕获就是开会、记笔记。其实远不止这些。我个人习惯把捕获技术分成三类：主动型、被动型和推导型。

• 主动型：访谈、问卷、原型演示。说白了，你得追着客户问。
• 被动型：日志分析、用户反馈、售后数据。客户不会主动说，但数据会。
• 推导型：场景分析、用例建模、领域调研。从业务逻辑反推需求。

为什么会这样？因为客户往往只描述理想场景。你需要用场景分析法，把边界条件一个个挖出来。我建议你画一个需求捕获矩阵，把“谁、什么场景、什么条件、期望什么行为”列清楚。

二、需求分析方法论：结构化才是王道

需求捕获回来，一堆零散的描述。怎么变成可用的系统需求？这里我推荐三种方法论，你根据项目规模选。

方法论	适用场景	核心产出
结构化分析（SA）	功能明确、流程固定的系统	数据流图、状态机、实体关系图
面向对象分析（OOA）	复杂系统、多模块交互	用例图、类图、顺序图
基于模型的需求分析（MBRA）	安全关键系统（如ISO 26262）	Simulink/Stateflow模型、形式化规约

我个人最常用的是MBRA。为什么？因为汽车软件里，一个需求歧义就可能引发安全事故。你想想看，用自然语言写“刹车响应要快”，不同工程师理解可能差200毫秒。但用模型定义，从事件触发到执行器动作，每一步都是确定的。

三、需求管理工具：别让需求“丢了”

工具选得好，需求管得牢。汽车行业里，常见的需求管理工具有这些：

• IBM DOORS：老牌工具，功能强大，但学习曲线陡。适合大型OEM。
• Polarion：基于Web，协作方便。我最近几个项目都在用。
• Jama Software：界面友好，适合敏捷团队。
• Codebeamer：与ALM集成好，适合ASPICE流程。

嗯，这里要注意：工具只是载体。真正重要的是需求的可追溯性。每个需求都要能追溯到来源（客户需求、法规、内部标准），也要能追溯到实现（架构元素、组件、测试用例）。

我建议你建立需求-架构双向追溯矩阵。比如：

需求ID: REQ-1024
描述: 当车速超过120km/h时，LDW功能自动激活
来源: 客户功能清单
架构映射: 
  - 感知层: 车速信号模块
  - 功能层: LDW状态机
  - 执行层: HMI报警模块
测试用例: TC-LDW-012, TC-LDW-013

四、需求到架构的映射：从“是什么”到“怎么做”

这是最难的一步。需求是“系统要做什么”，架构是“系统怎么实现”。怎么搭桥？我总结了一个四步法：

1. 需求聚类：把功能相似、时序相关、数据耦合的需求归为一组。
2. 抽象层级划分：系统级→子系统级→组件级。每个层级只关注该层级的职责。
3. 接口定义：需求之间的交互，映射为架构中的接口。包括数据接口、信号接口、服务接口。
4. 分配与权衡：把需求分配给具体的架构元素。如果出现冲突（比如两个需求争同一个资源），需要权衡。

举个例子。一个需求是“车辆上电后，中控屏在3秒内显示开机画面”。映射到架构时，你会怎么分？

• 电源管理模块：负责上电时序
• SoC启动模块：负责系统初始化
• 显示驱动模块：负责画面渲染
• HMI应用层：负责画面内容

你看，一个需求拆成了四个模块的协作。如果某个模块启动慢了，3秒的指标就达不成。这就是架构设计要解决的时序约束问题。

最后说一句：需求分析不是一次性工作。随着项目推进，需求会变，架构也会变。你需要建立变更影响分析机制——每次需求变更，都要评估对架构的影响。我曾经因为一个“增加语音提示”的小需求，没做影响分析，结果导致CAN总线负载超标。嗯，从那以后，我再也不敢跳过这一步了。

好了，这一章的内容就到这里。记住：好的架构，始于清晰的需求。下一章我们讲功能架构设计，到时候会用到今天学的映射方法。