3. 需求分析（下）：非功能性需求与需求文档撰写

上一节我们把车道保持的功能需求聊透了。但说实话，光有功能需求，项目根本跑不起来。

为什么？

你想想看，一个车道保持系统，功能上能识别车道线、能控制方向盘。但如果它每500毫秒才输出一次控制指令，车早就偏到隔壁车道去了。或者，它在雨天就罢工，那这功能等于没有。

这就是非功能性需求要解决的问题。我个人习惯把非功能性需求分成三大块：实时性、安全性、鲁棒性。咱们一个一个来拆。

3.1 实时性：系统必须“快”

车道保持是典型的实时控制系统。从摄像头采集图像，到算法处理，再到输出方向盘转角，整个链路必须在规定时间内完成。

我在项目中遇到过最典型的场景：某次路测，车辆以120km/h行驶。系统突然延迟了200ms。结果呢？车辆已经偏离车道中心线将近7米。嗯，那次测试直接触发了紧急接管。

所以，实时性指标必须量化。不能只说“要快”，要说“多快”。

指标项	典型值	说明
感知端到端延迟	≤ 50ms	从图像采集到输出车道线
控制周期	≤ 20ms	方向盘转角更新频率
系统总延迟	≤ 100ms	从感知到执行器响应
最大抖动	≤ 10ms	延迟波动范围

我曾经吃过这个亏。某个版本优化了平均延迟，从80ms降到了40ms。但抖动从5ms飙到了25ms。结果车辆在高速上开始“画龙”，方向盘来回修正。后来我们花了整整两周，才把抖动压下来。

3.2 安全性：系统必须“稳”

安全是自动驾驶的底线。车道保持系统如果出问题，轻则偏离车道，重则引发事故。

我习惯把安全性需求分成两个层面：功能安全和预期功能安全。

功能安全，说白了就是系统出故障了怎么办。比如摄像头被遮挡、算法崩溃、执行器卡死。这些都要有对应的降级策略。

预期功能安全，则是系统在正常工作时，会不会因为场景理解错误而做出危险行为。比如把路面积水反光误识别为车道线。

安全性需求清单，我建议至少包含以下内容：

• 故障检测：系统必须在10ms内检测到传感器或算法异常
• 降级策略：检测到故障后，平滑退出车道保持，并发出声光报警
• 安全状态：降级后，车辆应保持当前车道，减速至安全速度
• 人机交互：驾驶员接管请求必须在500ms内完成
• 冗余设计：关键信号（如方向盘转角）应有至少两路独立来源

3.3 鲁棒性：系统必须“扛得住”

鲁棒性，就是系统在各种恶劣条件下还能正常工作。

你想想看，车道保持系统要面对的场景有多复杂：

• 白天、黑夜、黄昏、黎明
• 晴天、雨天、雪天、雾天
• 城市道路、高速公路、乡村小路
• 车道线清晰、模糊、磨损、被遮挡
• 弯道半径从50米到5000米

这些场景，每一个都可能让系统失效。

我记得有一次，项目在重庆做路测。那里的道路弯多、坡陡、车道线磨损严重。我们的系统在高速上表现完美，到了重庆直接“翻车”。后来我们花了大量精力，专门针对低质量车道线做了鲁棒性优化。

鲁棒性需求，我一般这样定义：

场景	要求	测试方法
光照变化	在100lux~100000lux范围内正常工作	实验室光照箱测试
天气条件	中雨以下可正常工作	模拟降雨测试
车道线质量	磨损率≤30%时仍可检测	人工磨损车道线测试
弯道半径	≥50m的弯道可正常控制	封闭场地测试
遮挡情况	单侧车道线被遮挡时，可依靠另一侧维持	实车遮挡测试

3.4 需求文档撰写：把话说清楚

需求分析完了，怎么把它写下来？

我见过太多需求文档，要么太虚（“系统应具有良好的实时性”），要么太细（直接写代码逻辑）。好的需求文档，应该让开发人员一看就知道要做什么，让测试人员一看就知道怎么测。

我习惯用这个模板：

需求编号：LKA-NFR-001
需求类型：非功能性需求 - 实时性
需求描述：系统从图像采集到输出方向盘转角指令的总延迟应不超过100ms
验收标准：在100次连续测试中，95%以上的测试结果≤100ms，且最大延迟≤120ms
优先级：P0
关联功能：车道线检测、横向控制

这里有几个要点：

• 可量化：所有指标必须有具体数值，不能模糊
• 可测试：验收标准要明确，测试人员能直接执行
• 有优先级：P0是必须满足的，P1是尽量满足的
• 有关联：标注这个需求影响了哪些功能模块

嗯，到这里，需求分析的部分就告一段落了。下一节，我们会进入系统设计阶段，看看怎么把这些需求转化成具体的架构和模块划分。

记住一句话：需求分析做得越细，后面踩的坑就越少。我在这个行业干了十年，这句话从来没骗过我。