2、需求分析（上）：从用户故事到系统需求，定义LKA的功能边界

好，咱们正式开始第二讲。

上一章我们聊了LKA的整体课程规划。今天要干的事，说白了就是——把“人话”翻译成“机器话”。

你想想看，产品经理跟你说：“我要一个车道保持功能，车别跑偏。” 这句话能直接给开发吗？不能。你得先搞清楚：什么叫“跑偏”？偏离多少算“跑偏”？是压线了才纠正，还是快压线了就纠正？

这就是需求分析要干的事。

我个人习惯，拿到一个功能需求，第一步不是写代码，而是写用户故事。别小看这一步，我在项目中遇到过太多次，因为需求边界没划清楚，开发到一半产品经理又改口，最后加班改代码的惨案。

2.1 从用户故事开始

用户故事是什么？简单说，就是站在用户角度，描述他想要什么。

格式其实很固定：

作为 <角色>
我想要 <功能>
以便 <价值>

对于LKA，我们至少能写出三个核心用户故事：

• 故事一：作为驾驶员，我想要车辆在高速上自动保持在车道中央行驶，以便减轻长途驾驶的疲劳。
• 故事二：作为驾驶员，当我无意中偏离车道时，我想要系统主动帮我纠正方向，以便避免碰撞风险。
• 故事三：作为驾驶员，我想要系统在无法工作时及时提醒我，以便我能接管车辆。

嗯，这里要注意。用户故事不是需求文档。它只是起点。它告诉我们“为什么做”，但没告诉我们“怎么做”。

2.2 从故事到功能需求

有了用户故事，下一步就是把它拆成具体的功能需求。

怎么拆？我一般用“5W1H”法来追问：

• Who：谁在用？——驾驶员。
• What：做什么？——保持车道、纠正偏离。
• When：什么时候做？——车速多少？白天还是晚上？
• Where：在什么场景？——高速还是城市道路？车道线清晰吗？
• Why：为什么做？——安全、舒适。
• How：怎么做？——控制方向盘、发出警告。

你看，这么一问，需求就清晰多了。我们拿“故事一”来举例，拆解后的功能需求可能是这样的：

需求编号	需求描述	优先级
REQ-LKA-001	系统应在车速≥60km/h时激活车道保持功能	高
REQ-LKA-002	系统应能识别清晰的车道线（实线、虚线）	高
REQ-LKA-003	系统应控制车辆保持在车道中心线±0.3m范围内	高
REQ-LKA-004	系统应能在弯道半径≥250m的道路上正常工作	中

2.3 定义功能边界：什么该做，什么不该做

这是需求分析里最容易踩坑的地方。

很多团队只定义了“系统要做什么”，却忘了定义“系统不做什么”。结果呢？用户期望过高，出了事故怪系统没反应。

我曾经在一个项目里，产品经理说LKA要“在所有道路上都能用”。我当时就反问了一句：“那没有车道线的土路呢？” 他愣住了。

所以，我们必须明确LKA的功能边界：

2.3.1 激活条件（什么时候工作）

• 车速：≥60 km/h（高速场景）
• 车道线：至少一侧车道线清晰可见
• 驾驶员：双手未离开方向盘（检测到扭矩）
• 道路类型：结构化道路（高速、城市快速路）

2.3.2 退出条件（什么时候不工作）

• 车速＜50 km/h
• 车道线丢失超过3秒
• 驾驶员主动打转向灯
• 驾驶员大力干预方向盘（扭矩＞3Nm）
• 系统检测到故障（摄像头遮挡、传感器失效）

2.3.3 明确不做的功能

• 不处理无车道线的道路
• 不处理急弯（半径＜250m）
• 不处理施工区域（临时标线）
• 不处理恶劣天气（暴雨、大雪、大雾）

2.4 需求优先级：MVP思维

功能需求写了一大堆，但资源有限，不可能全部在第一版实现。

我建议用MoSCoW方法来排优先级：

• Must have（必须有）： 车道线识别、横向控制、安全退出机制
• Should have（应该有）： 弯道适应、驾驶员状态监测
• Could have（可以有）： 个性化设置（如偏离灵敏度调节）
• Won't have（这次不做）： 与导航联动的预测性控制

说白了，第一版LKA，先保证“能用、安全”。那些花里胡哨的功能，等第二版再说。

2.5 需求文档的最终输出

经过以上步骤，我们最终会产出一份系统需求规格说明书。它的结构大致如下：

1. 引言： 背景、范围、术语定义
2. 用户故事： 3-5个核心故事
3. 功能需求： 编号、描述、优先级（表格形式）
4. 功能边界： 激活条件、退出条件、不做的功能
5. 性能指标： 响应时间、控制精度、可用性
6. 接口需求： 传感器输入、执行器输出、人机交互

嗯，到这里，需求分析的上半部分就差不多了。你可能会问：“这些需求怎么落地到代码？” 别急，下一章我们会讲系统架构设计，把需求拆成模块，再一步步变成代码。

最后留个思考题：

如果LKA在弯道中因为车道线丢失而退出，系统应该怎么做？是直接放手，还是保持最后一次的控制指令？

这个问题，我们下章揭晓。