论系统需求工程之需求获取与变更管理

学业导师点评：本篇论文严格按照国家软考高级《系统架构设计师》论文大纲编写，以您的核心开发项目——“基于多智能体（Multi-Agent）协同的企业级 AI 需求自动化与流程协同管理中台”为背景。全文巧妙解构了面对 AI 大模型快速迭代与业务方高频需求变更时，架构师如何应用“需求跟踪矩阵 (RTM)”和“敏捷变更管理流程”，消除了学术化 AI 的空洞，填充了丰富的 QPS、延迟与接口契约等实战工程细节。

📝 论文正文

摘要

本文以我主持研发的“基于多智能体（Multi-Agent）协同的企业级 AI 需求自动化与流程协同管理中台”项目为背景，探讨了软件系统需求工程中需求获取与变更管理的应用与实践。该系统旨在将非结构化的用户业务陈述，通过 LLM 推理自动提炼并生成标准的 UML 图与软件需求规格说明书。针对项目开发中“AI 算法表现与用户感知偏差大”、“多系统对接接口多”导致需求频繁变动的痛点，我们设计了以“用户场景分析结合联合需求计划 (JRP)”的需求获取模式，并引入了“双向需求跟踪矩阵 (RTM)”实施需求变更控制。通过规范的变更管理，系统成功解决了中期的需求蔓延，确保了系统的顺利交付。系统上线后单次需求解析响应延迟从 4.5 秒降至 1.5 秒内，UML 自动生成准确率提升至 95% 以上，取得了显著的成效。

正文

2025年10月，我作为系统架构师主导了某软件外包巨头的核心重构项目——“基于多智能体（Multi-Agent）协同的企业级 AI 需求自动化与流程协同管理中台”。该系统的建设目标是变革传统的需求调研模式，利用大语言模型的自然语言理解能力，自动接收业务分析师的原始对话或会议纪要，并利用多智能体编排（包含解析 Agent、验证 Agent、建模 Agent 等）协同生成标准的类图、状态机图、时序图等，且支持向 Jira、GitLab 等下游研发系统自动分发任务。系统的技术栈为前端 React、后端 FastAPI、大模型编排基于 Python 异步协程，向量存储使用 Milvus，缓存及消息队列采用 Redis。在项目启动之初，我们发现需求获取面临巨大挑战。该系统的目标用户是业务部门与研发团队，双方语言体系完全不同：业务人员描述需求往往是非结构化、感性且随意的；而开发小组则需要极其严密的逻辑约束。为了拉齐认知，我没有采用传统的发放调查问卷方式，而是联合了项目经理、产品专家以及两个核心客户部门的主管，组织了三次“联合需求计划 (JRP)”工作会议。在 JRP 会议中，我们通过原型演练法，将早期构建的“AI 需求转化 MVP”直接运行展示，让用户实时看到输入一段话后系统自动绘制出 UML 图的整个过程。通过这种直观的场景还原，我们成功梳理出系统的核心功能性需求，并明确了单次 AI 需求解析延迟必须小于 2 秒、并发处理 QPS 必须达到 30 以上等关键非功能性需求（Quality Attribute）。然而，由于多智能体协同涉及到大模型（如 Qwen2.5-72B）的 Prompt 调优以及温度参数（Temperature）的调整，系统的输出具有一定的随机性，这导致项目中期业务方频繁提出需求变更。例如，用户在看到系统生成的时序图后，频繁要求“支持更多层级的递归循环分支解析”、“支持根据不同语言框架生成对应的代码骨架”等。如果所有变更全部无条件接收，项目必然陷入严重的“需求蔓延”深渊，导致无法按期上线。为了应对频繁的需求变更，我作为架构师主导建立了规范的**变更控制管理机制**，并设计了**双向需求跟踪矩阵 (RTM)**。我们通过 Excel 与内部的敏捷管理工具，建立起“原始用户诉求 - 智能体规划策略 - FastAPI 微服务模块 - Milvus 向量查询 key - 测试用例”之间的双向映射。在项目进入第三个敏捷 Sprint 时，业务主管紧急提出了一项高优先级的变更请求：“系统必须支持在生成 UML 时序图时，自动识别并生成微服务网关的 OAuth2.0 鉴权流图”。面对这一变更，我并未让开发人员直接动手改代码，而是立即启动了变更控制流程。首先，我利用 RTM 进行了**关联影响分析 (Impact Analysis)**。通过矩阵定位，我发现该变更不仅涉及建模 Agent 的 Prompt 更新，还会影响底层的网关图绘制模块，且会对现有的 Swagger 契约文件产生破坏。评估表明，该变更若直接实施，将导致开发工期延误 3 天，且可能导致高并发网关的 QPS 下降 15%。我将这份量化的影响评估报告提交给了项目变更控制委员会 (CCB)。CCB 成员包括项目总监、客户方负责人及我本人。经过会议论证，我们认为自动鉴权流图对于外包交付具有极高的商业价值，通过了该变更。但为了保障系统的性能，我主导对网关绘制模块进行了重构：我们利用 Redis 缓存了常用的 UML 图模版，将频繁的模版拼接操作从大模型推理链路中剥离出来。通过这一重构，变更得以顺利落地的同时，系统的 QPS 依然稳定在 35，单次时延控制在 1.5 秒内。通过严格的需求开发与变更管理，该 AI 需求自动化中台项目于 2026 年 4 月成功上线运行。在后续的实际使用中，系统日均处理需求文档 800 余份，UML 自动生成率达到 95% 以上，需求转化效率提升了 60% 以上。回顾该项目，我深刻体会到，软件需求工程绝非一成不变的文档撰写，而是架构师利用技术与流程管理工具（如 RTM、CCB、混合生命周期）在变化莫测的业务环境与健壮的系统架构之间寻找最佳平衡点的系统工程。

🎧 播客对谈版

[大福]：各位架构师朋友，欢迎来到《系统架构师考前冲刺百天特训》。我是你们的星路指引兔大福。今天是{CURRENT_WEEKDAY}，时间是{CURRENT_TIME}，非常开心能在电波里陪伴大家。第二天，我们攻克“需求工程与变更管理”这一核心考点。苏老师，您好！

[苏老师]：大福你好，各位备考的小伙伴们好。第二天的考点非常有针对性。无论是上午的客观题，还是下午的论文，需求工程都是架构师拉开分差的关键阵地。

[大福]：确实。很多考生在写需求管理时，只知道说“建立 CCB 委员会，遵循变更流程”，听起来非常空洞。苏老师，我们在论文中要如何把这个过程写得生动而专业呢？

[苏老师]：关键是要有“关联性影响分析”的真实步骤。比如在我们的 AI 需求自动化中台中，当业务方提出增加“OAuth2.0 鉴权流图自动生成”的变更时，我们要写出我们是如何通过需求跟踪矩阵 (RTM)，反向定位到影响了哪些 Agent Prompt、哪些微服务契约以及测试用例。并且要给出具体的工程指标，比如对网关并发 QPS 的影响评估。这种量化的分析过程，是拿高分的秘诀。

[大福]：哦！原来如此。不仅要有流程，还要有具体受影响的技术组件 and 性能指标！那在需求获取阶段，面对大模型输出的不确定性，我们是采用什么方法来拉齐业务方与研发方的认知的呢？

[苏老师]：我们采用了“联合需求计划 (JRP)”以及“原型法”的结合。在 JRP 会议上，直接运行一个 AI 需求转换的 MVP 原型，让业务方直接看到输入一段陈述后自动绘图的局限性与表现。这极大地减少了“鸡同鸭讲”的现象，把双方的需求期望拉到了同一水平线上。

[大福]：太妙了！用原型法和 JRP 解决 AI 系统中特有的“输出随机性带来的沟通障碍”。苏老师，今天是{CURRENT_DATE}，听完这期的小伙伴们一定要去错题本里复习一下正向跟踪和反向跟踪的区别，这可是上午题必考的哦！

[苏老师]：是的，祝大家备考顺利，加油！

[大福]：明天见，大家晚安！