7.1 设计阶段：把需求变成可施工的图纸

7.1 设计阶段：把需求变成可施工的图纸

本节摘要：设计阶段的产出不是几张图，是一套互相咬合的交付物：需求与点表定义「做什么」，通信契约定义「怎么传」，画面规范定义「怎么呈现」，验收大纲定义「怎么算数」。本节讲四类交付物的深度要求、设计评审的查法，以及设计冻结与变更管理的纪律。

图纸不是设计的结束

一个常见误会：设计就是画图，图画完设计就完了。以这种口径交付的设计，联调时必然出事——因为施工队拿着图接线没问题，但组态员没有点表、通信工程师没有契约、验收组没有大纲，「做什么」与「怎么算数」都没定义。设计阶段的完整性要用交付物清单衡量，而不是图纸张数。水厂项目的经验：设计阶段多花两周把点表和验收大纲做深，联调与验收就能省下两个月扯皮。

一、四类交付物与深度要求

需求与点表。 需求文档回答监控范围与控制方式：哪些站、哪些工艺系统、哪些量进系统、哪些操作走遥控、就地与远程的权限边界。点表按 3.4 节规范编制到「可接线、可组态」的深度：每行有编码、描述、类型、量程、死区、报警配置——只有点名的「铅笔点表」不算交付。深度检验标准很朴素：施工队按表接线不需要再来问你，组态员按表建点不需要猜语义。

通信契约。 按 4.2 节口径逐通道写明：规约与版本、轮询与上送参数、超时与重试、断链缓存时长、对时方式、带宽与风暴假设。这份文件同时约束中心与站端两侧厂商——它是集成项目里最重要的「中间件」。

画面规范。 按 5.2 节的三条主线落地：灰度契约与配色表、层级导航结构、报警分级矩阵。画面规范的作用是让 N 个工艺系统的画面像出自一人之手，验收时不至于逐张吵架。

验收大纲。 把「怎么算数」前置到设计期：功能验收逐项对应需求条目，性能验收写明口径（刷新周期、报警时延、切换时间），试运行写明考核周期与中断事件的处理规则。验收大纲是甲乙双方的共同承诺，设计期不定，验收期就变成谈判。

图 7-1 设计交付物之间的咬合关系

二、设计评审：查咬合，不查文笔

设计评审最容易开成「朗读会」——各方轮流表态。有效的评审围绕咬合关系查四组一致：点表与需求一致（每个需求条目有对应测点或功能项）；通信契约与点表一致（点数、站数、带宽假设同源）；画面规范与点表一致（报警矩阵与报警配置同源）；验收大纲与前两者一致（每项验收能追溯到需求与契约条目）。四组一致的核对表准备好，评审会就能在半天内查完实货。另一个实操建议：评审会请运行班组代表到场——画面导航顺不顺手、报警分级合不合值班习惯，使用者十分钟就能给出评审专家一小时的意见。

三、设计冻结与变更管理

设计冻结不是「不许改」，而是「改要走流程」。变更管理三要素：影响分析——一个测点变更会牵动点表、通信、画面、验收四份文件，变更单要列全受影响项；版本对齐——受影响文件同批升版，杜绝「点表改了契约没改」的漂移（2.2 节演练案例的教训）；节奏控制——设立变更截止线（如联调前两周），截止后的变更默认顺延到二期。变更纪律的真相很朴素：设计期变更是最便宜的，联调期变更以周计价，投运后变更以事故风险计价。

四、需求梳理的两个实用工具

设计阶段的起点是把需求问清楚，两个工具比任何模板都管用。工具一：场景走查。 让运行班组把「一个班次」从头走一遍——接班看什么、巡检什么、出警怎么处置、交班交接什么——每一步问「系统该给你什么」。场景走查产出的是带场景语境的需求清单，比「需要监控哪些参数」式的清单少一半返工。水厂项目的走查有个经典收获：值班员提出交接班要一页纸看完全厂关键指标与未处置事件——这条需求催生了总貌页的「交班视图」，后来成为运行人员最喜欢的功能。

工具二：反需求清单。 明确写出系统「不做」什么：不接管哪些既有联锁、不替代哪些就地操作、不对哪些数据负责。反需求看似消极，实则是边界契约——它预防的是投运后无限蔓延的「顺手加一个」。反需求清单与 1.1 节的边界感一脉相承，是设计期就要画下的楚河汉界。

五、设计阶段的沟通节奏

设计期的沟通频率比沟通时长更重要。三个节奏点值得制度化：每周碰头（十五分钟，只对差异——点表增量、变更单、风险清单），里程碑评审（交付物四件套各一次，按咬合清单查），冻结确认会（设计冻结前最后一次，所有各方签字确认冻结版本）。节奏的价值在于把「问题发现时间」前移：周碰头暴露小分歧，里程碑评审暴露结构分歧，冻结会清点遗留项——问题越早暴露，处理成本越低。反过来，指望「最后一次性评审」的项目，评审会上堆满攒了几个月的分歧，谁也不敢签，工期全耗在等待与返工上。

六、通信契约模板：一页纸的骨架

给出通信契约的骨架供直接套用（按通道填空）：

通道编号与名称：CH-02 取水头部至中心
规约与版本：IEC 60870-5-104（双方软件版本注明）
链路方式：主用光纤环网 备用 4G APN 专线
轮询计划：遥测 2 s 遥信变化上送 总召每日 03:00
看护参数：超时 8 s 重试 3 次 连续 2 轮失败报中断
缓存与补传：站端缓存 72 h 恢复后按时间序补传 补传完成为通道恢复标志
对时：中心下发 周期 10 min 站端偏差告警阈值 500 ms
风暴假设：同站全遥信变位加两成遥测越限 带宽余量按此校核
变更记录：版本、日期、变更单号、双方确认人
​

一页纸九项，评审半小时就能对完。契约的价值密度与篇幅成反比——能落到数字的条款才有约束力，形容词在集成项目里不值钱。

七、评审记录怎么写才算数

评审记录不是会议纪要的流水账，它是决策的存证。合格的评审记录四要素：结论（通过、有条件通过、不通过，每个交付物单独给结论）；问题清单（每条有编号、提出方、责任方、关闭时限）；偏离说明（评审中达成的与原规范不同的处理，写明理由——这些偏离就是未来的「口口相传」，写下来才不会失真）；签字（各方对结论与问题清单的确认）。两个星期后没人记得会上说了什么，能依赖的只有这份记录——设计阶段积累的每一份评审记录，都是 7.3 节验收证据链的上游支流。记录模板统一、存放位置统一，是项目管理里性价比最高的一件小事。

本节要点回顾

• 交付物四件套：需求点表、通信契约、画面规范、验收大纲，完整性按清单衡量。
• 点表深到可施工：施工不用问、组态不用猜，是深度检验的朴素标准。
• 评审查咬合：四组一致性核对，比逐章朗读有效十倍。
• 冻结不是禁止变更：影响分析、版本对齐、节奏控制三要素让变更有序。

考卷出好了。下一节进联调现场：组态纪律、仿真环境与问题闭环。