7.1 需求分析与方案设计

7.1 需求分析与方案设计

本节摘要：需求阶段把工艺意图翻译成三方签字的控制规格书与IO分配表，是全项目防返工的第一道闸。本节以青线的图纸转化过程为教具，讲清IO表的生成规则、规格书的必备章节与需求确认的签字纪律——图纸上每一根线，都要在表里有自己的户口。

翻开青线的电气图纸那天，我们的第一件事不是打开编程软件，是做翻译：把图上的每个符号翻译成程序语言里的一行户口。7.1节的工作看起来不"高级"，翻车项目的尸检报告里，一半的病灶能追到这一步的含糊——某个信号"应该有人负责"，某个联锁"大家以为对方做了"。翻译的产出有两份：IO分配表给机器看，一行一个点位；翻译备忘给同行看，一句一条"图上没写清楚、我们如何裁定"——两份合起来，才是这叠图纸在控制世界的完整户口。

图纸翻译成IO表：规则先行

从图纸到IO表的转化不是抄写，是仲裁。青线的转化规则一页纸：每台设备的每个动作与反馈一一登记，编号规则统一（站号加设备号加信号类型），每个DI点标注常开常闭与失电语义，每个DO点标注失电后设备状态；模拟量登记量程、单位与报警限。3.1节与3.3节的类型与地址纪律在这里落地成表格。规则的价值在"让争议有出处"：两个班组对同一信号理解不一致时，翻规则条文而不是比嗓门——规则一页纸的分量，全在争议时刻兑现。

翻译中的价值在"仲裁"二字：图纸与工艺现实对不齐的地方，必须在表格阶段逼出来。青线翻译阶段共登记十七处仲裁——缺反馈点、语义不清、型号不符——每一处都记录在案并四方会签（工艺、机械、电气、控制）。这十七处若拖到联调，每一处都是一次"现场停下来开会"。仲裁记录本身也是资产：同类项目开工前翻一遍上次的仲裁清单，一半的新坑可以提前绕开——青线的第二期工程就是靠这份清单把仲裁数量压到了六处。

规格书：让三方言说一种话

IO表管点，规格书管行为。青线的控制规格书六章：工艺流程描述（用水线的话说清每步做什么）、控制方式定义（自动、半自动、手动的边界与切换条件）、联锁逻辑清单（每条联锁写明条件、动作、恢复条件）、报警分级与响应要求、HMI画面清单、验收标准引用。每章都有一功：工艺评审流程章，机械评审联锁章，电气评审点表章，控制评审全部。六章的排序也藏了心思：先讲正常世界（流程），再讲边界世界（方式切换），再讲异常世界（联锁与报警），最后是人与界面（HMI）和出口（验收）——读者顺着人的认知顺序走，评审时提问自然分层。

规格书的语言纪律只有一条：写行为，不写实现。"暂存仓满仓时输送段降速至三分之一并分流"是合格条款；"调用Jam_Detect_FB输出分流标志"是越权——实现是第4章的事，规格书只承诺行为。这条边界让规格书在两次设计变更后依然有效，无需改写。

签字纪律：模糊的终点

需求阶段最贵的词是"以后再说"。青线的规矩：规格书版本冻结会上，三方对每一章签字，有分歧当场写进"开放问题清单"并指定裁决人与期限——分歧允许带病进入清单，但只许存在于不影响主线的边缘地带；凡涉及安全与流程主干的分歧，必须在冻结前解决。签字不是仪式，是把"大家以为"变成"白纸黑字"的终点站。7.3节现场验收时，这张签字的规格书就是对照的原文——当年签得多清楚，验收就多顺。

签字之后规格书就进了7.4节的版本管理：任何修改走变更单，影响面（改哪些IO、哪些联锁、哪些用例）逐项评估后再重新会签。需求文档与程序同一套纪律管起来，是青线与老项目最大的差别之一——老项目的规格书签完字就进了抽屉，三个月后没有人记得里面的承诺，验收时的扯皮大多源于此。需求不是写完就完的一次性动作，是一条与程序并行、同版本、共命运的文档生命线。

方案设计：在规格书与代码之间

规格书冻结后、动笔写码前，还有一层"方案设计"常被跳过——它是规格到实现之间的桥。青线的方案设计产出三样东西。架构小图：程序层的块划分与调用关系（2.4节的调用树草图），一页纸，让所有人在同一张图上讨论。任务预算初表：哪些逻辑进主循环、哪些进中断，各占多少毫秒（2.4节分账的初稿）。接口预定义：设备类的接口草案（3.4节），写出每个功能块的引脚清单。三样东西加起来不过三页纸，却让后续编码期几乎没有"写到哪里发现结构不对"的返折——结构争议在纸面上解决的成本，是代码里解决的百分之一。

方案设计还有一个隐性收益：它是新成员融入的最佳教材。青线中途加入的工程师半天读懂三页纸，就能在评审上提出有效意见——三页纸的密度，胜过三万字的开发周报。方案文档与规格书一样进版本库、随变更同步，7.4节的同源纪律对它一视同仁：纸上画的结构与仓库里的代码一旦脱节，方案就从资产变成了误导。

需求阶段的三个高频疑问

问：工艺给的流程图已经很细了，控制规格书还要写什么？ 流程图讲"工艺要什么"，规格书讲"控制怎么响应一切"——正常流程只是其中一页，启动与停止的边界条件、每种故障时的动作、手动与自动的切换规则、报警后的恢复路径，这些"非晴天条款"才是规格书的主体。流程图越细，规格书越好写，但不能互相替代。

问：需求变更免不了，冻结还有什么意义？ 冻结冻结的不是变更，而是变更的自由态。冻结后的每次变更走书面流程：影响分析、代价声明、重新会签——变更依然会发生，但从"随时插队"变成"排队审批"。青线规格书冻结后发生两次重大变更，都因流程在而有序落地；同期的自由变更项目，同期改了十一次，每次都是口头的。

问：小项目也要全套文档吗？ 文档的"套"可以缩，"份"不能省。十个回路的改造项目，IO表加一页联锁清单加半页验收标准，一样构成完整契约——规模决定厚度，不决定有无。判断标准只有一条：三个月后的人拿着你留下的纸，能否独立回答"它该怎么动作、验过没有"。

本节要点回顾

• 翻译即仲裁：图纸到IO表不是抄写，十七处仲裁在表格阶段逼出并会签；
• 户口三要素：位号规则统一、DO登记失电语义、模拟量登记量程与限值；
• 行为边界：规格书只写行为不写实现，实现变更不废规格；
• 签字终点：冻结会签字加开放问题清单，主干分歧不过夜。

点与行为都有了户口，下一节把程序在办公室里先跑起来：离线开发、仿真与虚拟调试。