2. 工程数字孪生平台的需求分析与业务建模

需求分析是工程数字孪生平台从“想法”走向“可建设系统”的第一道关口。它要回答三个问题：平台为谁服务、要解决哪些具体业务问题、达到什么质量水平才算合格。工程数字孪生平台不同于通用信息化系统，它的需求源头分散在工程运维、施工管控、安全监测等多条业务线上，每条业务线的对象、数据、时序和判断标准都不相同。因此，需求分析不能只靠访谈记录堆砌，而必须通过业务建模把零散诉求转化为结构化、可验证、可追溯的需求条目，最终形成《平台需求规格说明书》。

一、从业务出发识别需求来源

需求识别的第一步是锁定业务域和干系人。以典型工程项目为例，可先划分三类核心业务域：

• 工程运维：关注结构健康、设备状态、能耗与寿命，典型对象是桥梁支座、隧道衬砌、机电设备、管网阀门。核心诉求是“看得见劣化趋势、算得清剩余寿命、排得出维护计划”。
• 施工管控：关注进度、质量、成本、场地与机械协同，典型对象是工区、工序、塔吊、混凝土浇筑仓面。核心诉求是“进度可对比、偏差可预警、资源可调度”。
• 安全监测：关注变形、应力、渗流、人员定位与危险源，典型对象是测点、传感器、阈值、报警链路。核心诉求是“数据不丢、超限必报、处置留痕”。

每个业务域都要明确干系人角色：运维工程师、施工项目经理、安全员、监测值班员、平台管理员、业主代表。不同角色对同一数据的关注点不同，例如安全员关心报警是否在30秒内推送，而运维工程师更关心历史趋势能否按测点导出。需求条目应标注来源角色，避免“人人有需求、无人能验收”。

二、功能需求与非功能需求的分层梳理

功能需求描述“平台做什么”，建议按“数据接入—模型构建—业务应用—交互输出”四层组织。数据接入层要明确支持的协议与频率，例如MQTT、Modbus TCP、OPC UA，测点采样周期从1秒到1小时不等；模型构建层要说明几何模型、机理模型、数据驱动模型的轻量化与更新机制；业务应用层对应监测预警、进度对比、巡检工单、能耗分析等具体功能；交互输出层则规定大屏、Web端、移动端和API的呈现方式。

非功能需求常被忽视，却直接决定平台能否长期运行。应至少覆盖以下维度：

指标必须可量化、可验证，避免“响应快、界面友好”这类无法验收的表述。

三、业务建模：流程图与用例图的分工

业务建模是把需求“画清楚”的过程。业务流程图用于描述跨角色的端到端处理链，重点表达触发条件、判断分支、数据流向和异常路径；用例图用于界定系统边界与参与者关系，重点表达“谁使用系统做什么”。两者互补：流程图回答“事情怎么流转”，用例图回答“系统为谁提供什么服务”。

以“安全监测超限报警”为例，其业务链条可概括为：传感器采集→边缘网关预处理→平台阈值判断→分级报警→推送责任人→现场处置→闭环归档。其中阈值判断存在“一级/二级/三级”分支，推送存在“短信/APP/声光”多通道，处置存在“误报关闭”与“真实警情转工单”两条路径。这些分支正是流程图必须表达的内容，也是后续测试用例的设计依据。

上图把泳道、处理链、异常分支和用例边界放在同一视图中：感知层与边缘层解决“数据怎么来”，平台层解决“怎么判断和分发”，应用层解决“谁来处置和归档”。红色虚线表示超时未确认时的升级重推路径，这是需求规格说明书中必须写明的异常需求，也是测试用例的重要来源。

四、需求规格说明书的组织与追溯

《平台需求规格说明书》不是功能清单的堆砌，而应具备可追溯结构。建议每条需求使用唯一编号，并记录来源、优先级、验收标准和关联模型。例如：

需求编号：REQ-SAFE-012
需求名称：三级报警30秒内推送
来源角色：安全员 / 监测值班员
优先级：高
功能描述：当测点值超过三级阈值时，平台应在30秒内
          通过APP与短信双通道推送至责任人。
验收标准：注入模拟超限数据，记录从数据入库到
          短信网关返回成功的时间戳，P95≤30s。
关联模型：安全监测报警业务流程图、用例UC-03

优先级建议采用MoSCoW法（Must/Should/Could/Won't），避免所有需求都标“高”。验收标准必须可测量，例如“P95≤30s”比“及时推送”更可执行。关联模型字段保证需求与流程图、用例图双向可查，当业务变化时能快速定位受影响的需求条目。

五、常见偏差与纠正

实践中三类偏差最常见。第一类是“功能膨胀”：把大屏炫酷效果当成核心需求，忽视数据接入质量。纠正方法是先确认测点在线率和数据完整率指标，再讨论可视化。第二类是“非功能缺失”：只写功能不写性能、可靠性和安全，导致上线后报警延迟、断网丢数。纠正方法是在需求阶段就定义端到端延迟、缓存时长和权限模型。第三类是“模型与需求脱节”：流程图和用例图只用于汇报，未与需求编号关联。纠正方法是建立需求—模型—测试用例的追溯矩阵，确保每条Must级需求至少对应一个测试用例。

需求分析与业务建模的产出，是后续平台架构设计、数据模型设计和接口设计的输入。只有把业务对象、处理链、判断分支和质量指标写清楚，数字孪生平台才不会沦为“数据看板”，而能真正支撑工程运维、施工管控和安全监测的日常决策。