第2章：需求工程基础：需求层次、需求属性与开发流程

好，咱们正式开始聊需求工程。说实话，很多刚入行的朋友觉得需求就是“客户说要什么，我们就记下来”。嗯，如果真这么简单，那ADAS系统就不会有那么多召回和OTA升级了。

我个人习惯把需求工程比作盖房子。你不能上来就砌砖，得先搞清楚：这是给谁住的？要几层？承重墙在哪？水电怎么走？需求工程就是干这个的。今天咱们重点聊三个核心：需求层次、需求属性、开发流程。

2.1 需求层次：从“想要什么”到“怎么做”

我在项目中遇到过最头疼的事，就是团队里大家说的“需求”根本不是一回事。产品经理说“我要自动泊车”，系统工程师说“我要超声波雷达信号”，软件工程师说“我要CAN报文解析”。你看，同一个功能，三个层次。

所以，需求必须分层。ADAS领域通常分三层：

• 用户需求：说白了就是“用户想要什么”。比如“车辆能在30秒内完成平行车位泊入”。这是从用户视角出发的，不涉及技术细节。
• 系统需求：这是把用户需求翻译成“系统该干什么”。比如“系统应通过12个超声波传感器检测车位，规划路径并控制转向/油门/刹车”。注意，这里开始有技术约束了。
• 软件需求：这是给程序员看的。比如“当车速低于10km/h且挡位为R挡时，激活泊车功能；传感器数据采样周期为20ms”。非常具体，直接指导代码怎么写。

你想想看，如果这三层混在一起会怎样？我见过一个项目，需求文档里写着“系统应智能避障”，结果软件工程师写了个if-else判断，测试工程师说“这不够智能啊”。嗯，这就是没分层的后果。

2.2 需求属性：给每个需求贴上标签

光分层还不够。每个需求本身得有“身份证”。我记得有一次评审，大家争论一个需求到底算不算“关键安全需求”，吵了半小时。后来我提议：咱们给每个需求加几个属性，一查就知道。

常用的需求属性包括：

属性名称	说明	举例（AEB功能）
ID	唯一标识	REQ-AEB-001
优先级	高/中/低	高（安全相关）
来源	哪个文档或干系人	ISO 15623
状态	草稿/已评审/已批准/已实现	已批准
验证方法	测试/评审/分析	实车测试
安全等级	ASIL A/B/C/D	ASIL B

我个人习惯在DOORS里给每个需求至少配5个属性。为什么？因为后期做追溯、做变更影响分析时，这些属性就是救命稻草。我曾经因为一个需求没标“安全等级”，导致变更时漏掉了安全分析，差点被审核开不符合项。

2.3 需求开发流程：别想着一步到位

需求不是写出来的，是“开发”出来的。我见过最天真的做法是：产品经理写一版需求，扔给开发，然后就不管了。结果呢？开发到一半发现需求矛盾，返工。

一个靠谱的需求开发流程，至少包含这几个阶段：

1. 需求获取：跟客户、法规、竞品聊。ADAS领域特别要注意法规，比如UN R157对LKA的要求。
2. 需求分析：把模糊的描述变成清晰的条目。比如“泊车要快” -> “泊车时间不超过60秒”。
3. 需求规格：写成文档，用DOORS或Polarion管理。每条需求都要可测试。
4. 需求验证：让评审团（包括测试、安全、系统）过一遍。我建议至少两轮评审。
5. 需求确认：跟客户或产品经理确认，确保没理解错。
6. 需求变更管理：这是最容易被忽略的。需求变了，影响分析做了吗？

嗯，这里要注意：流程不是死板的。我做过一个快速原型项目，需求获取和需求分析几乎是同步进行的。但无论如何，需求验证和变更管理绝对不能省。

2.4 工具怎么用：DOORS vs Polarion

说到工具，DOORS和Polarion是ADAS领域的两大主流。我两个都用过，简单说说感受。

DOORS：老牌工具，稳定，但界面嘛...嗯，你懂的。适合大型项目，需求追溯做得特别好。我习惯用DOORS做需求基线管理，每次变更都生成一个新基线，方便回滚。

Polarion：更现代，基于Web，协作方便。我最喜欢它的工作流引擎，可以自定义需求状态流转。比如“草稿 -> 评审中 -> 已批准”，每一步都能设置审批人。

不管用哪个工具，核心思路是一样的：需求要有唯一ID、要有属性、要有追溯。工具只是辅助，别本末倒置。

好，今天就到这。有什么问题，咱们评论区见。