2. 平台需求分析与功能规划

数字孪生平台不是“把三维模型搬到网页上”这么简单。它要同时服务现场运维、工艺优化、设备管理、领导决策等多类使用者，还要接入实时数据、驱动模型、承载告警与仿真。因此，在动手写代码之前，必须先把“谁用、用来干什么、必须达到什么质量、如何确认做对了”这四件事讲清楚。本节围绕用户角色、核心功能模块、非功能需求和需求文档编写与评审展开，并给出可直接参考的需求规格说明片段。

一、先识别用户角色，再谈功能

需求分析的第一步是角色识别。角色不是按部门名称罗列，而是按“与平台的交互方式”划分。以某智能制造车间的设备数字孪生平台为例，可归纳为四类角色：

• 现场运维人员：关心设备当前状态、告警位置、历史曲线，操作以“查看+确认+派单”为主，使用移动端或大屏。
• 工艺工程师：关心参数趋势、工况对比、仿真结果，需要调取历史数据、设置仿真边界条件。
• 设备管理员：关心设备台账、维保计划、备件寿命，需要维护模型与实体设备的映射关系。
• 平台管理员：关心数据源接入、模型发布、权限分配、系统运行指标，负责平台自身的配置与运维。

角色确定后，每个功能模块都应能回答“主要服务哪个角色”。若一个功能找不到明确角色，通常说明它是伪需求或应合并到其他模块。

二、核心功能模块的划分

数字孪生平台的功能可归纳为五条主线：数据接入、模型管理、孪生映射、可视化交互、分析与仿真。它们之间存在明确的依赖关系：数据接入为孪生映射提供实时值，模型管理为孪生映射提供几何与语义，孪生映射把两者绑定后，才支撑可视化、告警和分析。下图给出模块之间的数据流与依赖关系。

图中橙色模块“孪生映射”是平台的核心枢纽。它把左侧的数据流与模型流汇聚，再向右侧输出渲染数据和分析输入。平台管理模块以虚线方式对分析仿真模块进行配置下发，体现其支撑性而非数据主链路角色。

三、非功能需求：容易被忽略但决定成败

功能需求回答“做什么”，非功能需求回答“做到什么程度”。数字孪生平台常见的非功能指标包括：

这些指标必须在需求阶段就量化，否则验收时无法判断“是否达标”。例如“实时性”若只写“较快”，开发与测试就会各执一词；写成“P95 ≤ 2 s”后，测试用例可以直接围绕该阈值设计。

四、需求文档编写与评审

需求文档建议采用“用户故事 + 验收条件”的结构，每条需求可追溯、可测试。以下是一份可直接参考的需求规格说明片段：

需求编号：DT-REQ-012
需求名称：设备实时状态孪生映射
用户角色：现场运维人员
用户故事：作为运维人员，我希望在三维场景中看到每台设备的
          实时运行状态，以便快速定位异常设备。
验收条件：
  1. 设备状态（运行/停机/告警）在三维模型上以颜色区分，
     颜色图例固定为：绿=运行，灰=停机，红=告警。
  2. 状态变化后，三维模型颜色更新延迟 ≤ 2 s（P95）。
  3. 点击设备模型可弹出属性面板，显示设备编号、当前
     转速、温度、最近一次告警时间。
  4. 当测点数据中断超过 10 s，模型显示为“数据失联”灰色
     闪烁，并在告警列表生成一条记录。
优先级：高
依赖：DT-REQ-003（设备台账）、DT-REQ-007（实时数据接入）

评审时重点检查四类问题：完整性（是否覆盖所有角色与主流程）、一致性（术语、单位、颜色约定是否统一）、可测试性（每条验收条件能否转化为测试用例）、可追溯性（需求能否对应到设计模块与测试项）。评审输出应形成问题清单，明确责任人与关闭时间，而不是只写“评审通过”。

把角色、功能、非功能和文档评审四件事做扎实，后续的模型接入、数据绑定和三维开发才有稳定的依据。需求阶段的每一处模糊，都会在开发阶段被放大成返工。