Day 02：架构师的必修课 —— 需求工程与变更管理

导师寄语：在系统架构设计师上午的选择题中，需求工程（需求开发与需求管理）是年年必考的稳定得分点（通常 2-3 题）；而在下午的案例分析和论文写作中，如何应对“业务部门朝令夕改的需求”、“如何从零提取多角色协同的非功能性需求”则是极好的论述素材。今天我们将深入探讨需求工程的核心框架，并将其映射到我们 AI 需求中台的项目实践中。

1. 需求工程核心考点归纳

需求工程主要分为需求开发与需求管理两大维度。

graph TD
    RE[需求工程] --> RD[需求开发]
    RE --> RM[需求管理]
    RD --> REQ_EL[1. 需求获取 Elicitation]
    RD --> REQ_AN[2. 需求分析 Analysis]
    RD --> REQ_SP[3. 需求规格说明 Specification]
    RD --> REQ_VA[4. 需求验证 Validation]
    RM --> REQ_CH[1. 变更控制 Change Control]
    RM --> REQ_TR[2. 需求跟踪 Traceability]
    RM --> REQ_ST[3. 版本控制 Version Control]

1.1 需求开发 (Requirement Development)

需求获取 (Elicitation)：通过用户访谈、问卷调查、联合需求计划 (JRP)、原型法等手段，把用户的非正式诉求挖掘出来。
需求分析 (Analysis)：对获取的需求进行分类、建构，解决其中的冲突。常用的分析方法有结构化分析 (DFD、ERD、STD) 和面向对象分析 (UML 用例图、类图、顺序图)。
需求规格说明 (Specification - SRS)：编写《需求规格说明书》，将非结构化诉求转化为结构化、无歧义的契约文件。
需求验证 (Validation)：通过评审、测试用例生成以及模拟运行等，确保 SRS 准确、完整地反映了用户的期望，并获得利益相关者的签字认可，形成需求基线 (Baseline)。

1.2 需求管理 (Requirement Management)

变更控制 (Change Control)：建立需求变更控制委员会 (CCB)，遵循严格的变更流程，对变更请求进行关联性分析与评估。
需求跟踪 (Traceability)：使用需求跟踪矩阵 (RTM)，建立“用户原始需求 - 系统功能 - 设计构件 - 代码实现 - 测试用例”之间的双向跟踪关系，防止需求偏离或遗漏。

2. 架构选型分析矩阵 (Syllabus Key Check)

在实际项目中，针对不同类型的需求，我们需采用不同的获取和建模方法：

需求层次 / 维度	业务需求 (Business)	用户需求 (User)	系统需求 (System)	非功能需求 (NFR)
主要目标	确定系统建设的商业价值与愿景	描述用户使用系统的具体操作场景	定义软件的具体功能与技术规格	约束系统的性能、安全、可用性等
获取方法	头脑风暴、JRP、高层访谈	用户访谈、问卷、场景分析	领域分析、原型演练	质量属性场景法 (QAS)、效用树
表示方法	愿景说明书、业务上下文图	用例图 (Use Case)、用户故事	结构化 SRS、系统接口契约	性能/可用性指标表、架构约束文档
变更敏感度	极低	中等	高	极高（影响系统底层设计）

3. 实战映射（您的 AI 需求中台项目）

案例分析与论文中的需求变更管理话术示范：

“...在本项目（基于多智能体协同的企业级 AI 需求自动化与流程协同管理中台）的建设过程中，由于该系统旨在打通业务部门与研发团队之间的需求沟壑，业务方对于‘利用 AI 自动生成 UML 状态图和时序图’的精确度要求极高，这导致在项目中期面临了频繁的算法迭代与界面变更。为此，我们架构组建立了双向需求跟踪矩阵 (RTM)。当业务人员提出‘增加时序图中条件分支的 AI 解析能力’这一变更请求时，我们通过 RTM 快速定位了受影响的模块：包括前端交互组件、FastAPI 中的 Agent 规划处理器，以及 Milvus 中存储的 UML 示例向量库。随后，我们将该分析结果提交至变更控制委员会 (CCB) 进行工期与性能损失评估，并在通过后，通过敏捷 Sprint 的 Backlog 调整，将该变更纳入最新的开发周期中，同时自动更新了相关的测试用例，避免了变更导致的技术债堆积与需求偏离...”

4. 🧠 历年真题交互特训

（请点击选项直接答题。若答错，题目会自动同步至您的【错题追踪本】中，方便复习）

【题目 1】（2020年上系统架构设计师真题）在需求工程中，需求跟踪是指对需求生命周期的追踪。若要检查系统是否实现了所有定义好的原始需求，应该使用（）关系进行校验。

【题目 2】（2022年上系统架构设计师真题）在对系统非功能性需求（如吞吐量、响应时间、安全性）进行获取与分析时，架构师通常应使用（）进行系统化的场景描述与优先级评估。

【题目 3】（2023年下系统架构设计师真题）软件开发过程中，需求变更是不可避免的。当需求变更请求提出后，变更控制流程的第一步通常应该是（）。

🎨 今日学习手账（心境与掌握度记录）

本模块为您的 ISFP 专属手账卡片，您的选择将本地存入浏览器，并点亮您的【成长手账】星图看板。

1. 您今天的心流状态 is？

2. 您对今天考点的体感温度是？