3. 工业装备需求工程与模型化需求管理

工业装备的研制失败，很少源于结构强度算错，更多源于需求本身没被正确捕获、分解和验证。一台六轴工业机器人，客户说“要快、要准、要能连续干活”，这句话无法直接驱动设计。需求工程的任务，就是把这句模糊的期望，转化为可分配、可追溯、可验证的工程条目，并用 SysML 需求图把它们组织成模型，而不是散落在文档里的段落。

一、从利益相关者期望到系统需求

需求捕获的第一步是识别利益相关者，而不是急着写需求。以某型工业机器人为例，典型利益相关者包括：终端用户（关心节拍与易用性）、产线集成商（关心接口与通信协议）、设备维护方（关心可维护性与备件）、安全监管方（关心安全等级）、制造与装配部门（关心可制造性）、以及企业自身的产品规划（关心成本与平台化）。每一类利益相关者都有各自的关注点，这些关注点构成需求的来源。

捕获手段上，访谈、现场观察、竞品拆解、历史故障数据分析和标准法规解读应组合使用。例如，从历史售后数据中发现“关节减速器早期磨损”占比高，就会催生一条关于寿命与工况的需求；从 GB 11291 等标准中，会导出安全相关的强制需求。捕获阶段要区分“期望”与“需求”：期望是主观、模糊的，需求是经过确认、可验证的。建议用一张利益相关者—关注点矩阵先做梳理，再逐条转化为需求条目。

一条合格的需求应具备可验证性、无歧义、单一性、可追溯性。例如“机器人应快速运动”不合格；“机器人在额定负载 6 kg 下，最大合成速度不低于 2.0 m/s，重复定位精度优于 ±0.05 mm”才是可验证的需求。这里必须明确参照条件：负载、姿态、温度、测量方法，否则验证时无法判定通过与否。

二、系统需求分解与分配

捕获到的是利益相关者需求（Stakeholder Requirement），属于“要什么”；系统需求（System Requirement）则回答“系统要满足什么指标”，并进一步分解到分系统、部件。分解不是简单拆句，而是沿着系统架构逐层分配，并保持指标的可追溯与可验证。

以节拍需求为例：客户要求“单件搬运节拍 ≤ 8 s”。系统层将其分解为运动时间、抓取时间、通信与等待时间预算。假设抓取 1.2 s、通信与等待 0.8 s，则留给运动的时间预算为 6.0 s。再按关节分配：大臂、小臂负责主要行程，腕部负责姿态调整。若某段轨迹由 J2、J3 联动完成，就需要把 6.0 s 的时间预算按轨迹规划分配到各关节的速度、加速度约束上，并检查是否与电机扭矩、减速器额定转速冲突。这种“预算—分配—校核”的过程，正是需求分解的实质。

分解中常见的错误是“指标丢失”和“指标冲突”。前者指上层需求在下层没有对应条目，后者指速度与精度、节拍与寿命之间互相矛盾。解决办法是建立需求—架构的分配关系，并在 SysML 中用 «satisfy»、«derive» 关系显式表达，让冲突在模型里可见，而不是等到样机测试才暴露。

三、SysML 需求图建模

SysML 需求图（Requirement Diagram）的核心元素是需求（requirement）、包含关系（containment）、派生关系（«deriveReqt»）、满足关系（«satisfy»）、验证关系（«verify»）和精化关系（«refine»）。需求以带 «requirement» 构造型的矩形表示，内部可写 id 和 text。包含关系用带十字圆圈的线表示“由……组成”，派生关系用虚线箭头表示“由……导出”。

建模时建议给每条需求唯一 ID，例如 SR-001、SR-002，并保持 id 与 text 分离，便于工具检索和变更影响分析。需求图不追求画得漂亮，而追求关系完整：每条系统需求应能向上追溯到利益相关者需求，向下分配到架构元素，并关联到至少一条验证用例。缺少任一环节，追溯链就断了。

下面这张图给出该型工业机器人需求模型的核心片段：左侧是利益相关者需求，中间是系统需求及其分解，右侧是架构元素与验证用例，箭头方向表示派生、满足与验证关系。

四、需求追溯与验证确认

追溯的价值在于变更影响分析。当客户把节拍从 8 s 收紧到 7 s，如果模型里存在完整的派生链，就能立刻定位到受影响的是 SR-01、SR-02，进而影响运动控制模块和 TC-01 测试用例，而不是靠人翻文档。追溯关系应双向可查：正向从需求到实现与验证，反向从测试失败回到需求条目。

验证（Verification）回答“是否正确地构建了系统”，确认（Validation）回答“是否构建了正确的系统”。前者对应 TC-01、TC-02 这类测试用例，检查指标是否达标；后者需要回到利益相关者，确认节拍、精度、安全等需求是否真正解决了客户问题。两者不能互相替代：一台机器人可能精确满足了自己写的需求，但需求本身写错了，确认环节才能发现。

验证方法通常有四类：检验（Inspection）、分析（Analysis）、演示（Demonstration）、测试（Test）。精度指标一般用测试，安全等级可用分析与检验结合，节拍可用演示或测试。每条需求都应指定验证方法和验收准则，并记录验证状态（未验证、通过、失败、部分通过）。

五、实战任务：某型工业机器人需求管理

以本节机器人项目为例，可交付一份需求追溯矩阵（RTM）作为阶段成果。矩阵行是需求条目，列包括：需求 ID、需求文本、来源利益相关者、派生自、分配到架构元素、验证方法、验证用例、当前状态。填写时要求每条系统需求至少有一行来源和一行验证记录，不允许出现空白的“验证方法”列。

一个可参考的片段如下（示例数据，用于说明字段填写方式，非实测结果）：

完成矩阵后，用 SysML 工具把需求、架构、测试用例建成模型，并检查三条规则：每条利益相关者需求至少派生出一条系统需求；每条系统需求至少被一个架构元素满足；每条系统需求至少关联一个验证用例。三条规则全部满足，需求模型才算闭环。后续设计变更时，只需在模型中修改对应条目，追溯链会自动暴露受影响范围，这正是模型化需求管理相对于文档管理的核心优势。