在完成了需求的分层与结构化分解之后（如上文章），下一个关键步骤是让这些需求“流动”起来。我们需要为每一个层级的需求定义清晰、标准的价值流流程，并利用软件工厂平台的自动化能力，实现跨层级的状态驱动的自动化流转，从而减少人工干预、加速价值交付、并确保流程的合规性。
每一层级的需求，都应根据其职责和生命周期，拥有专属的价值流状态定义。这确保了从战略规划到战术执行，每个环节都有明确的工作焦点和产出标准。
（一）用户需求价值流：聚焦于“价值定义与验证”
用户需求价值流管理的是最为顶层的作战意图与业务价值，其生命周期贯穿从概念提出到最终形成战斗力的全过程。理解并管理好此流程，是确保软件工厂“做正确的事”的根本保障。该价值流包含一系列严谨的状态，其完整的状态流可以如下示例：
提案→ 论证中 → 已批准 → 已分解 → 实现中 → 待验收 → 已验收 → 已关闭
提案：价值的原始触点。“提案”状态是所有用户需求的起点，它负责广泛收集来自各方的原始想法与作战诉求，这些想法的来源是多渠道的。在此阶段，核心任务并非进行深入分析，而是确保“不漏项”，将所有潜在的价值点以结构化工单的形式，规范地录入需求管理平台的“需求池”中，为后续筛选奠定基础。
论证中：价值的筛选与聚焦。当需求结束初步收集进入“论证中”状态后，便启动了价值的评估与筛选机制。在此状态下，需要由领域专家、系统架构师、产品经理等角色组成的跨职能团队，共同对提案进行多维度审视。评估内容包括但不限于：该需求的价值高低、与战略目标的对齐程度、在技术上的可行性、以及所需投入的资源与成本估算。这个过程的目的在于去芜存菁，从大量的原始提案中，识别出那些价值最高、最值得投入资源进行开发的候选项。
已批准：价值的正式承诺。一个需求若经过充分论证并被认定为应予实施，其状态将推进至“已批准”。这一状态具有重要的管理意义，它代表组织正式对该需求做出了承诺，并将其纳入某个产品或系统的版本规划中。此时，该需求已被赋予了明确的业务优先级和预期的交付时间窗口。项目资源可以据此进行调配，它是需求从“规划域”进入“实施域”的官方凭证。
已分解：价值的工程化翻译。处于“已批准”状态的需求，其描述往往是宏观的。为了使其能够被开发实现，必须对其进行工程化的分解与翻译。“已分解”状态即标志着这一翻译工作的完成。具体来说，就是由系统架构师和需求分析人员，将宏观的用户需求拆解为一系列具体的、可设计的系统需求，并在平台中建立清晰的父子关联。
实现中：价值的实质构建。当某个用户需求下属的任意一个系统需求进入开发阶段（例如，状态变为“开发中”或“设计中”）时，该用户需求的状态应自动联动为“实现中”。这个状态是一个强烈的可视化信号，表明针对该顶层价值的实质性构建工作已经启动，价值正在被创造。它让所有干系人，特别是提出需求的用户方，能够直观地看到价值的推进情况，而非停留在计划层面。
待验收：价值的成果待验。当用户需求下属的所有系统需求均已实现并达到“已交付”状态时，该用户需求的状态应自动联动至“待验收”。这标志着为实现该作战价值所需的所有软件功能均已开发、集成并测试完毕，形成了一个完整的、可交付的软件版本。此阶段的核心工作是组织正式的验收评审，包括准备交付件、组织定型鉴定或部队试验，等待用户方（军方）的最终确认和接收。
已验收：价值的最终兑现。“已验收”状态是用户需求价值流的顶峰，它需要由授权人员（如军代表）手动确认。当软件产品顺利通过所有验收流程，完成在目标环境（如指定型号的装备、指挥系统）中的部署，并正式交付用户使用时，即可更新至此状态。这代表该用户需求所承载的作战价值已经实实在在地兑现，形成了预期的战斗力。此状态的转变，是整个研发流程的终极目标。
已关闭：价值的归档沉淀。在确认需求交付物稳定运行一段时间后，该用户需求即可进入“已关闭”状态。在此阶段，项目团队应完成所有相关的文档归档、经验总结与数据沉淀工作。关闭需求并非简单的结束，而是将实践中获得的宝贵知识反馈至组织资产库，为未来需求的分析与实现提供参考，形成一个闭环的、持续改进的价值管理生态系统。
（二）系统需求价值流：聚焦于“能力设计与交付”
系统需求价值流是连接顶层作战构想与底层软件实现的核心桥梁。它管理的不再是抽象的价值，而是具体的、可设计的“系统能力”。此流程确保每一项被承诺的系统能力，都能通过严谨的工程过程被实现、集成并最终交付。其完整的状态流可以如下示例：
待分析→ 设计中 → 已评审 → 已拆解 → 集成中 → 测试中 → 待交付 → 已交付
待分析：能力的澄清与界定。“待分析”是系统需求生命周期的起点。当系统需求从上级用户需求分解并初步定义后，其描述往往仍处于相对宏观的层面。此状态的核心任务，就是对该系统需求本身进行深入的剖析、澄清和细化，将其从一句“能力声明”转化为清晰、完整、无歧义且可作为设计输入的技术规格说明。
设计中：能力的方案规划。当需求分析明确后，状态进入“设计中”。这是将需求转化为技术方案的创造性阶段。系统架构师会在此阶段制定实现该系统能力的技术架构、接口规范、数据流设计以及关键的算法模型。此阶段的产出是系统设计文档，它是后续开发和集成的“蓝图”。
已评审：方案的质量与决策关口。设计完成后，方案必须进入评审状态，这是一个质量控制与集体决策的关键关口。评审会由资深架构师、领域专家、开发代表及测试代表共同参与，旨在评估技术方案的合理性、可行性、可维护性，以及其是否完全覆盖了原始需求。只有通过正式评审的设计方案，才能获得继续实施的许可，确保项目建立在坚实的技术基础之上，当评审通过后，状态可流转至“已评审”。
已拆解：能力的任务转化。通过评审的设计方案，需要被转化为开发团队可以执行的具体软件需求。“已拆解”状态即标志着这一转化工作的完成。在此状态下，系统架构师或项目经理会根据设计方案，创建出一系列具体的、原子化的软件需求，并在需求管理平台中与父级的系统需求建立明确的链接。至此，一项系统能力已被成功翻译为一组待开发的软件功能清单。
集成中：能力的组装与验证。当该系统的下属软件需求开始被实现，并且其代码开始被合并、构建和组装时，系统需求的状态应自动联动至“集成中”。此状态标志着该能力已从“图纸”阶段进入“实物”组装阶段。核心工作是持续集成，确保不同软件模块之间能够正常协作，接口调用准确，数据传递无误。这是发现和解决接口兼容性问题的主要阶段。
测试中：能力的全面检验。当集成后的系统构件形成一个初步可测试的整体时，状态进入“测试中”。此阶段不再关注单个软件功能是否正确，而是从整体视角验证该系统需求所定义的能力是否被完整、正确地实现。测试团队会执行严格的系统级测试，包括功能测试、性能测试、可靠性测试以及与外部系统的联调测试，确保其能在模拟的真实环境中稳定运行。
待交付：能力的就绪状态。当系统测试全部通过，并且该能力已被集成到一个正式的系统发布版本中时，系统需求的状态应推进至“待交付”。这标志着实现该项系统能力的所有工程活动均已圆满完成，产出的软件制品已就绪，等待被作为系统正式基线的一部分，交付给下一环节（如总装集成）或用于支撑用户需求的最终验收。
已交付：能力的正式移交。“已交付”是系统需求价值流的终点。当包含该能力的系统版本通过所有必要的评审，被正式签署放行，并成功部署到目标环境（如仿真环境、试验靶场或实际装备）中后，由授权人员将其状态更新为“已交付”。这代表该能力已经过全面验证，并已作为一项稳定的资产纳入整个武器系统中，为其上一级的用户需求提供了坚实的支撑。
（三）软件需求价值流：聚焦于“功能开发与验证”
软件需求价值流是需求实现链条中最贴近开发实践的环节，它管理的是单个可交付软件功能的完整生命周期。这条价值流体现了敏捷与DevOps的核心思想，通过精细化的状态管理确保每个功能都能快速、高质量地交付。其完整的状态流可以如下示例：
就绪→ 开发中 → 测试中 → 待验收 → 已完成
就绪：功能的准备状态。"就绪"状态是软件需求进入开发流程的"起跑线"。在此状态下，需求必须完成所有的准备工作，达到"就绪定义"的标准。这包括确保需求描述清晰无歧义，并包含明确、可验证的验收标准；技术设计方案和接口规范已经完成并通过评审；该功能所依赖的外部服务、数据接口或上游模块均已就位；开发团队能够基于清晰的信息进行工作量评估并做出交付承诺。只有完全满足这些条件的需求，才会被放入"就绪"队列，等待开发团队认领。
开发中：功能的实现过程。当开发人员从"就绪"队列中认领需求后，其状态转为"开发中"。这标志着该功能的实质性构建工作正式启动。在此状态下，开发人员会基于需求ID创建特性分支，并开始进行详细的编码实现。同时，他们会编写并执行单元测试用例，确保代码基础质量。在开发过程中，代码需要通过同行评审，确保符合项目的编码规范和质量要求。
测试中：功能的自动化验证。当代码完成开发并通过审查，合并到集成分支后，需求状态自动转为"测试中"。此阶段的核心特征是自动化验证。持续集成流水线会被自动触发，执行一系列自动化测试，包括单元测试、集成测试和API测试等。代码会被自动部署到测试环境，为后续的集成测试做好准备。在此过程中，系统设有多重质量门禁，只有通过所有自动化测试的代码才能进入下一阶段。测试结果会实时反馈给团队，确保发现问题能够立即修复。
待验收：功能的功能性确认。当代码通过所有自动化测试后，需求状态转为"待验收"。需要特别说明的是，此处的"验收"特指对软件功能本身是否满足需求规格的功能性验收，执行主体是产品经理或业务分析员。他们依据需求工单中明确的验收标准，在测试环境中对功能进行验证，确认其行为符合业务预期。这与系统需求的"待交付"（关注能力集成和系统级验证）和用户需求的"待验收"（关注顶层价值实现和作战效能）有本质区别，各层级关注点不同。
已完成：功能的交付闭环。当产品经理确认功能通过验收，且所有相关文档、代码都已就绪时，需求状态转为"已完成"。这标志着一个软件功能的完整交付闭环，可以为准生产环境提供价值。同时，该状态的转变会向上游触发系统需求的状态更新，推动价值向更高层级流动。
在完成各层级需求价值流程的定义后，如何高效、准确地推动状态流转成为关键实践问题。如果完全依赖人工手动更新状态，不仅会增加团队负担，还容易出现状态更新不及时、与实际进展脱节的情况，这将直接影响价值流动的可视性和后续度量的准确性。为此，软件工厂平台需要通过其自动化引擎，建立智能化的状态联动机制，让价值流能够基于实际工程进展自动推进，形成自我驱动的高效运转体系。
（一）系统需求到用户需求的价值联动
表1 用户需求流转规则
（二）软件需求到系统需求的进度联动
表2 系统需求流转规则
（三）软件需求流转
表3 软件需求流转规则
信息来源：余仁 软件研发之DevOps
