第4章需求文档编写（上）

第4章：需求文档编写（上）——功能需求与非功能需求定义、用例图与场景描述、需求追溯矩阵（RTM）

大家好，我是老张。今天咱们聊聊需求文档怎么写。

说实话，我在ADAS这行干了十几年，见过太多项目因为需求没写清楚而翻车。有的团队上来就写代码，结果做到一半发现功能定义有歧义；有的需求文档写得像天书，开发看不懂，测试更看不懂。嗯，今天这堂课，我就把我在项目里踩过的坑、总结的经验，一次性讲清楚。

4.1 功能需求与非功能需求：别搞混了

先问大家一个问题：你写的需求文档里，功能需求和非功能需求分开了吗？

我见过不少团队，把这两类需求混在一起写。结果呢？开发只关注功能实现，忽略了性能指标。等系统集成测试时才发现，AEB功能虽然能触发，但响应延迟超过了200毫秒——这在高速场景下，基本等于没用。

4.1.1 功能需求：系统要做什么

功能需求，说白了就是系统对外表现的行为。比如：

ACC自适应巡航：当目标车辆减速时，本车应自动跟随减速
LKA车道保持：当车辆偏离车道时，系统应施加转向扭矩
AEB自动紧急制动：当碰撞时间TTC小于2.5秒时，系统应触发全制动

我个人习惯，每个功能需求都要带上触发条件、系统响应、预期结果。这样开发拿到手，直接就能写代码。

功能需求模板（我常用的）：

ID: FR-ACC-001
名称: 目标车辆跟随减速
触发条件: 本车ACC激活，且前方存在目标车辆
系统响应: 本车减速，与前车保持设定时距
预期结果: 本车速度降至与前车一致，时距误差±0.2秒
验收标准: 在30-120km/h范围内，减速过程平顺，无突兀感

4.1.2 非功能需求：系统要做到什么程度

非功能需求，很多人容易忽略。其实它决定了系统好不好用、稳不稳定。

我记得有一次，客户验收时发现我们的LKA系统在弯道中表现不稳定。查了半天，发现需求文档里只写了「车道保持功能」，没写「在多大曲率的弯道上能正常工作」。这就是非功能需求缺失的典型问题。

常见的ADAS非功能需求包括：

性能指标：系统响应时间、目标检测准确率、误报率
可靠性：MTBF（平均无故障时间）、系统可用性
安全性：功能安全等级（ASIL）、故障容错机制
可用性：人机交互的易用性、告警的清晰度
可维护性：软件升级方式、诊断接口

我的经验：非功能需求最好用可量化的指标来描述。比如「系统响应时间小于100ms」，而不是「系统响应要快」。你想想看，开发看到「要快」两个字，他该怎么做？

4.2 用例图与场景描述：让需求可视化

光有文字需求还不够。我建议每个功能需求都配上用例图和场景描述。为什么？因为文字容易产生歧义，但图不会。

4.2.1 用例图：谁在用系统

用例图的核心是回答三个问题：谁在用？做什么？和谁交互？

在ADAS系统中，常见的参与者包括：

驾驶员：主要使用者，负责监控和接管
车辆系统：提供车速、转向、制动等执行能力
环境感知系统：提供摄像头、雷达、激光雷达的感知数据
云端平台：提供地图更新、远程诊断等服务

举个例子，ACC功能的用例图可以这样描述：

用例名称: 自适应巡航控制
主要参与者: 驾驶员
前置条件: 车辆启动，车速大于30km/h
基本流程:
  1. 驾驶员按下ACC激活按钮
  2. 系统检测前方目标车辆
  3. 系统根据设定速度或前车速度自动调节本车速度
  4. 驾驶员可通过拨杆调整设定速度或时距
后置条件: ACC功能激活，车辆自动巡航
备选流程:
  2a. 未检测到目标车辆 → 系统按设定速度巡航
  4a. 驾驶员踩下制动踏板 → ACC退出，转为人工驾驶

4.2.2 场景描述：把需求讲成故事

我个人特别喜欢用场景描述来补充用例图。场景描述就像讲故事，把用户的操作步骤、系统的反应、环境的变化都串起来。

举个例子，AEB功能的典型场景：

场景名称: 城市道路前车急刹
环境条件: 白天、干燥路面、车速40km/h
初始状态: 本车与前车距离约30米
事件触发: 前车突然急刹车
系统响应:
  1. 系统检测到前车减速，TTC计算为2.0秒
  2. 系统发出视觉和听觉告警（第一级预警）
  3. TTC降至1.2秒，系统开始部分制动（第二级部分制动）
  4. TTC降至0.8秒，系统触发全制动（第三级紧急制动）
最终状态: 本车在距离前车2米处完全停止

注意：场景描述要覆盖正常场景、异常场景和边界场景。我曾经在一个项目里只写了正常场景，结果测试时发现系统在雨天、夜间、弯道等场景下表现很差。后来补了30多个异常场景，才把问题都暴露出来。

4.3 需求追溯矩阵（RTM）：别让需求丢了

需求追溯矩阵，英文叫Requirements Traceability Matrix，简称RTM。这东西听起来高大上，其实说白了就是一张表，用来记录每个需求从提出到实现、测试的全过程。

我见过最惨的一个项目，需求文档写了200多条，结果开发做了150条，测试测了120条，最后交付时发现还有30条需求根本没人碰。为什么？因为没有RTM，没人知道哪些需求实现了，哪些还没做。

4.3.1 RTM的结构

一个标准的RTM至少包含以下列：

需求ID	需求描述	来源	设计文档	代码模块	测试用例	状态
FR-ACC-001	目标车辆跟随减速	客户需求V1.2	SDD-ACC-01	acc_control.c	TC-ACC-001~005	已实现
FR-LKA-002	车道偏离告警	法规要求	SDD-LKA-02	lka_warning.c	TC-LKA-010~015	已测试
NFR-PERF-003	系统响应时间<100ms	性能指标	SDD-PERF-01	perf_monitor.c	TC-PERF-001	已验证

4.3.2 RTM的维护时机

很多团队喜欢在项目结束时才补RTM。我告诉你，这基本等于没做。RTM应该贯穿整个项目生命周期：

需求评审时：建立初始RTM，确保每个需求都有唯一ID
设计阶段：关联设计文档，确认每个需求都有对应的设计方案
开发阶段：关联代码模块，追踪实现进度
测试阶段：关联测试用例，确保每个需求都被测试覆盖
验收阶段：更新状态，标记已实现、已验证、已交付

我的建议：RTM最好用工具来管理，比如Jira、Doors或者Excel。我个人习惯用Excel，因为灵活，但要注意版本控制。我曾经因为Excel版本混乱，导致RTM数据丢失，后来花了两周才补回来。嗯，血的教训。

4.4 本章小结

今天咱们讲了需求文档编写的三个核心内容：

功能需求与非功能需求：功能需求定义系统做什么，非功能需求定义做到什么程度。两者缺一不可。
用例图与场景描述：用图讲故事，让需求可视化。别忘了覆盖正常、异常、边界三类场景。
需求追溯矩阵（RTM）：一张表管住所有需求，从提出到交付全程可追溯。

下一章，我会继续讲需求文档编写的下半部分，包括需求评审、变更管理和文档版本控制。到时候见。

课后作业：找一个你熟悉的ADAS功能（比如ACC或AEB），写一份包含功能需求、非功能需求、用例场景和RTM的完整需求文档。下次课我会挑几份好的来点评。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录