3. 功能需求规格：编写功能需求文档（FRD）、用例图与用例描述、需求可追溯性矩阵

好，咱们进入第三章。这一章，说白了就是要把上一章收集来的那些“用户想要什么”，翻译成工程师能看懂的“系统该做什么”。

我个人习惯把这一步叫做“从模糊到精确的翻译过程”。你想想看，用户说“我要在站台看到下一趟车还有几分钟到”，这背后其实藏着几十个技术细节——数据从哪来？刷新频率多少？晚点超过多久要报警？这些，都得在功能需求文档里写清楚。

3.1 功能需求文档（FRD）怎么写？

FRD 不是给用户看的，是给开发、测试、项目经理看的。所以别整那些花里胡哨的形容词，要的是精确、可验证。

我一般把 FRD 拆成三个核心部分：

• 功能编号与名称：每个功能一个唯一 ID，比如 FRD-PIS-001。方便后面做追溯。
• 功能描述：一句话说清楚这个功能干什么。比如“系统应能实时接收ATS发送的列车到站预告信息”。
• 验收标准：这是最关键的。怎么写才算通过？要量化。比如“从ATS发出数据到PIS屏幕显示，延迟不超过2秒”。

下面是一个简化的 FRD 示例片段：

| 功能ID | 功能名称 | 功能描述 | 验收标准 |
|--------|----------|----------|----------|
| FRD-PIS-001 | 实时到站预告 | 系统接收ATS数据，在站台屏显示下一列车预计到站时间 | 数据延迟≤2秒，显示格式为“XX分XX秒” |
| FRD-PIS-002 | 紧急信息插播 | 运营人员可通过控制中心向指定车站/全线发送紧急文本信息 | 从发送到显示≤5秒，支持全屏红色闪烁 |
| FRD-PIS-003 | 列车运行方向指示 | 根据ATS数据，动态显示当前列车运行方向箭头 | 箭头方向与ATS数据一致，刷新率≥1Hz |

3.2 用例图与用例描述

用例图，说白了就是画给项目经理和用户看的。让他们一眼就能明白：谁（角色）能干什么（功能）。

我习惯用三个要素：

• 角色（Actor）：谁在用系统？比如“站务员”、“调度员”、“乘客”。
• 用例（Use Case）：能做什么？比如“查看列车时刻表”、“发布紧急广播”。
• 关系（Relationship）：角色和用例之间的连线，以及用例之间的包含、扩展关系。

举个例子，PIS 系统里最常见的用例：

角色：调度员
用例：
  1. 登录系统
  2. 查看全线列车运行状态
  3. 发布到站信息（包含：选择车站、编辑内容、确认发送）
  4. 发布紧急广播（扩展：触发声光报警）

嗯，这里要注意。用例描述不能只写“用户点击按钮”。要写清楚前置条件、后置条件、主流程、备选流程。

一个标准的用例描述模板：

用例名称：发布紧急广播
角色：调度员
前置条件：调度员已登录，且拥有“紧急广播”权限
主流程：
  1. 调度员选择“紧急广播”功能
  2. 系统显示车站列表
  3. 调度员选择目标车站（可多选）
  4. 调度员输入广播内容（文本）
  5. 系统预览广播内容
  6. 调度员确认发送
  7. 系统向目标车站发送广播指令
  8. 系统返回发送成功状态
备选流程：
  3a. 调度员选择“全线广播”，跳过车站选择
  6a. 调度员取消发送，返回步骤2
后置条件：目标车站PIS屏幕显示广播内容，并触发声光报警

3.3 需求可追溯性矩阵（RTM）

RTM 这东西，说实话，很多小项目不做。但大项目、尤其是轨道交通这种安全相关的项目，不做 RTM 就是给自己埋雷。

RTM 的作用是什么？一句话：确保每个需求都有归宿，每个功能都有来源。

我见过最惨的一次事故：项目验收时，用户问“你们这个紧急广播功能，对应的原始需求是哪个？”我们翻遍了文档，发现需求跟踪矩阵里漏写了。结果用户不认，说“这不是我们要的”。最后返工，多花了两个月。

RTM 一般包含这几列：

需求ID	需求来源	功能ID	用例ID	测试用例ID	状态
REQ-001	用户访谈-站务员	FRD-PIS-001	UC-001	TC-001, TC-002	已实现
REQ-002	招标文件-第3.2节	FRD-PIS-002	UC-002	TC-003	已实现
REQ-003	国标GB/T 22239	FRD-PIS-010	UC-010	TC-010~TC-015	待测试

最后说一句。FRD、用例图、RTM 这三样东西，是 PIS 系统交付的“铁三角”。FRD 告诉你要做什么，用例图告诉你怎么做，RTM 告诉你做完了没有。缺一个，项目就容易翻车。

下一章，咱们聊聊系统架构设计。到时候我会拿一个真实的 PIS 系统架构图出来，拆开揉碎了讲给你听。