在GJB5000标准框架下，需求管理强调过程的规范性、产品的合规性与双向可追溯性。为了在实践中满足这一要求，并实现从用户意图到开发任务的精准转换，我们必须建立一个工程化的需求分层与分解模型。这个模型不仅遵循“自上而下、逐层细化”的经典系统工程原则，更在每一层定义了明确的工作产物与验收标准，确保需求在流动过程中不失真、可验证。

（一）分层逻辑：从用户意图到实现任务的四层分解模型

一个完整的用户需求，需要经过以下四个层级的精炼与转化，才能成为开发与测试团队可执行的明确指令。

第一层：用户需求——定义“作战价值”

定义与内容：这是需求的原始出发点，由用户（军方）提出，侧重于从作战使命、业务流程和效能提升的角度进行描述，通常使用自然语言和业务术语。例如：“我需要系统能够实时预警来自不同方向的饱和攻击，并给出优先拦截方案。”

载体与产出：主要通过《作战需求文档》、《用户需求规格说明》等文件承载。在工具平台中，它作为最顶层的“Epic”或“业务需求”工单存在，是所有下游需求的根源。

第二层：系统需求——定义“系统能力”

定义与内容：在GJB5000中，这是承上启下的关键层。系统需求在用户需求的基础上，从整个系统（含软件、硬件、人员、流程）的视角，定义为实现用户需求所必须具备的功能、性能、接口及物理约束。它开始引入工程化语言，但不过早涉及软件实现细节。例如，针对上述用户需求，系统需求可能是：“系统应能同时接收并处理≥50个来袭目标信息”、“系统融合识别后，应在500毫秒内生成火力分配建议”。

载体与产出：《系统需求规格说明》。在工具平台中，每个系统需求作为独立的“Feature”或“系统需求”工单，并与上层的用户需求建立明确的父子链接。

第三层：软件需求——定义“软件行为”

定义与内容：这是GJB5000“需求开发”过程域的核心产出。软件需求精准地从系统需求中剥离出纯软件部分的责任，是软件设计与编码的直接依据。它需要被清晰地定义为“系统在特定条件下，对特定输入，应产生的特定输出或行为”。例如，对应上述系统需求，软件需求可能是：“目标处理模块应提供API，每秒可接收并缓存100个目标航迹”、“融合算法服务输入N个目标航迹，输出目标类型、威胁等级和置信度”。

关键要求：此层级需求必须是原子化的、可测试的、无歧义的。它应明确功能、性能、安全性、可靠性等质量属性。

载体与产出：《软件需求规格说明》。在工具平台中，它们作为“Story”或“软件需求”工单，链接到父级的系统需求。

第四层：技术任务——定义“实现与验证单元”

定义与内容：此层级是需求谱系与具体工程实践的交接面，将软件需求拆解为可直接分配给工程师或小型团队的技术工作项。它不再描述软件的外部行为，而是聚焦于实现该行为所需的内部构造活动和验证该行为是否正确的具体手段。它具体分为两类：

• 开发任务：源于软件需求的技术实现方案。例如，针对上述软件需求，可拆解为：“开发MessageParser类，实现parseTrackMessage()方法”、“设计并实现TargetCacheDAO接口及其数据库访问逻辑”。

• 测试任务：源于软件需求的直接验证活动。例如：“设计并编写‘目标报文解析’的边界值测试用例”、“编写‘目标缓存并发读写’的性能测试脚本”。

价值：此层级实现了需求到具体编码和测试活动的最终转换，其完成状态直接关联到CI/CD流水线的触发与质量门禁，是实现“需求即代码、需求即测试”的DevOps 闭环的关键。

载体与产出：在平台中，它们作为“Task”（任务）或“Bug”（缺陷）类型的工单，严格地链接到其父级的软件需求（Story）。

（二）系统需求与软件需求的交叉矩阵

在GJB5000的框架下，系统需求定义了整个系统（包括硬件、软件、人员、流程）应具备的能力。而软件需求则是这些能力在软件部件上的具体映射和实现。系统需求与软件需求之间不是简单向下分解的概念，而是一种多对多的交叉继承关系。如图1所示，1个系统可以分解为多个软件需求，而1个软件需求有可能被多个系统需求“共享”。这种看似复杂的需求层级关系，其实是需求分析深入和架构设计合理的体现。在GJB5000的实施中，我们通过建立需求追溯矩阵的方式来管理这种复杂性。

在需求管理矩阵中“行”是系统需求，“列”是软件需求，在每个交叉的格子里，标明该软件需求是如何满足对应的系统需求的。这确保了每一个系统需求都有软件需求来覆盖，同时每一个软件需求都有其存在的业务价值（即至少追溯到一个系统需求）。以下我们将以“无人机集群协同侦察系统”为例，详细的阐述系统需求与软件需求之间如何建立需求矩阵，从而通过需求矩阵追溯相应的功能（所提供的需求描述为样本举例，不涉及实际业务）。

首先我们对“无人机集群协同侦察系统”拆分出以下表1结构的系统需求。

表1  系统需求列表

基于以上的系统需求，将继续往下拆解不同的软件需求，在拆解过程中，发现要实现协同控制（SYS-001），你首先需要知道集群里有哪些成员，这正是SW-001的功能。同时，当发生通信中断（SYS-003）时，你需要更新集群成员列表，移除失效的单元，这同样依赖于SW-001。因此，SW-001作为一个基础服务，被多个上层系统能力所共享。从而体现了架构的复用性和低耦合。

表2  软件需求列表

有了系统需求和软件需求清单后，我们可以将系统需求作为“行”，软件需求作为“列”，形成直观的需求矩阵，暂时彼此间的追溯关系。其中"●"表示追溯链接

表3 需求矩阵表

此时，当某个系统需求发生变更时，通过追溯矩阵可以立刻定位到所有受影响的软件需求，从而准确评估变更范围、工作量和成本。反之，当修改某个软件模块时，也能清楚知道会影响到系统的哪些顶层能力。这种追溯关系帮助我们验证软件架构是否合理。如果发现一个软件需求被过多的、不相关的系统需求所依赖，可能意味着它承担了过多的职责，违反了“高内聚、低耦合”的原则，需要考虑进行拆分。

（三）建立端到端的需求与代码的追溯链

在GJB5000框架下，建立需求矩阵确保了需求层级内部的可追溯性。然而，所有需求的最终载体是代码。为了确保“需求即代码，代码即需求”的精准兑现，必须建立一条从需求到代码的数字化、自动化的追溯链条。这条链条的核心，在于将软件需求（第三层）作为与代码关联的最佳锚点。

1、为何选择“软件需求”作为关联锚点？

用户需求（Epic）和系统需求（Feature）过于宏观，一个需求对应大量代码文件，关联粒度太粗，失去追溯的精确意义。

技术任务（Task）虽然粒度细，但它描述的是“活动”而非“价值”，关联代码只能证明“工作完成了”，无法直接证明“需求被满足了”。

软件需求（Story）是定义明确、可独立验证的软件行为规格，其粒度与一个或多个代码模块/服务接口相匹配。将其与代码关联，既能清晰界定开发范围，又能精准验证实现效果。

2、如何在软件工厂平台中绑定需求与代码分支？

在软件工厂平台的支持下，我们通过以下标准化流程建立并维护需求与代码的追溯链：

在需求管理界面，增加可关联研发数据的插件，此插件可以命名为“研发数据链”，用于当前需求与各种研发数据之间建立关联关系，当一条软件需求完成设计后，可直接在研发数据链上创建对应需求ID的代码分支，软件工厂平台自动将需求与代码分支进行关联，为了便于直观了解代码分支的对应关系，在分支命名时可选择与需求ID挂钩，例如：feature/SW-001-Add-Target-Parser。

开发人员在该分支上的所有代码提交，必须在提交信息（Commit Message）中显式提及需求ID（如：git commit -m "feat: [SW-001] Implemented the core logic of message parsing."）。

提交后，软件工厂平台会自动解析提交信息，并将本次提交的代码变更集、代码作者、提交时间等信息，自动评论到对应的需求工单（SW-001）下方。这使得需求成了一个活的、汇聚了所有实现过程的“档案页”。

当代码被合并并触发持续集成（CI）流水线时，构建状态（成功/失败）、构建产物、以及后续的部署状态，也会自动同步回需求工单。

这样，在任何一个软件需求工单的详情页上，项目成员（产品经理、测试工程师、项目经理）可以一目了然地看到如下信息：

• 为了实现这个需求，创建了哪些代码分支？
  

• 有哪些相关的代码提交？每次提交具体改了哪些文件？

• 这些代码的构建是否成功？制品是什么？

• 这条需求关联的代码是否已经部署到测试或生产环境？

上述追溯链催生了一种高效的质保实践——基于需求的代码审查。

传统方式：代码审查者面对一个充满技术细节的合并请求，很难快速理解这段代码的业务意图和价值。

新方式：审查者直接点击合并请求中关联的需求工单（如SW-001），首先回顾该软件需求的详细描述和验收标准。然后，再结合需求来审视代码，判断点非常明确：

• 代码是否完整实现了需求描述的所有功能点？

• 代码逻辑是否涵盖了需求中定义的所有异常流程和边界条件？

• 代码中是否有与本需求无关的“镀金”或额外修改？

这种方法将代码审查从纯粹的技术逻辑检查，升级为一次对“需求实现准确性”的最终验证，极大地提升了审查的质量和效率。

通过建立这条从需求到代码的自动化研发数据链，软件工厂实现了价值流动的全程透明。它不仅回答了“这个需求是由哪段代码实现的？”（正向追溯），也回答了“这次代码提交是为了完成哪个需求？”（反向追溯），为变更影响分析、缺陷根因定位和项目审计提供了无价的数据支撑，最终确保了软件产品与设计规格的绝对一致。

信息来源：余仁  软件研发之DevOps