ARTICLE · 1105186

详细讲解项目管理软件工程的软件需求

发布时间：2026-09-30 19:14:28 最近访问：2026-09-30 19:14:29

详细讲解项目管理软件工程的软件需求

软件工程包括软件工程定义，软件需求，软件设计，软件实现，部署交付，软件质量管理，软件过程能力成熟度等。

系统需求是从系统角度说明软件的需求，包括 3 类内容：

1. 功能需求(行为需求) = 规定开发人员必须在系统中实现的软件功能；用户利用这些功能来完成任务，满足业务需要；通常通过系统「特性」的描述表现出来。所谓特性：一组逻辑上相关的功能需求

2. 非功能需求：系统展现给用户的行为和执行的操作等；包括产品必须遵从的标准、规范和合约；指系统必须具备的属性或品质，又可细分为软件「质量属性」(如易用性、可维护性等)和其他非功能需求

3. 约束：系统设计或实现的限制条件

速记方法系统需求「内 3 类」对照「外 3 层次」：

- 内：功能和非功能和约束(系统需求内部)

- 外：业务和用户和系统(软件需求 3 层次)

关键不要混淆「层次分类」和「层次内部分类」。

质量功能部署(Quality Function Deployment, QFD)将软件需求分为 3 类：

1. 常规需求：用户认为系统应该做到的功能或性能，「实现得越多用户越满意」

2. 期望需求：用户「想当然」认为系统应具备的功能或性能，但「未必能正确描述」；如果未实现，会让用户感到「不满意」

3. 意外需求：兴奋需求；用户「要求范围外」的功能或性能(但通常是软件开发人员很乐意赋予的技术特性)；「实现会让用户更高兴，不实现也不影响其购买决策」

速记方法QFD 3 类按用户满意度梯度：

- 常规(应有的)→ 多多益善

- 期望(想当然的)→ 没有就不爽

- 意外(额外的)→ 有了惊喜，没有也不亏

口诀：常 · 期 · 意。

常见的需求获取方法 5 种：

1. 用户访谈：一对一或小组面对面交流

2. 问卷调查：通过问卷大规模收集需求

3. 采样：通过抽取代表性样本数据 / 用户分析

4. 情节串联板：通过故事板形式呈现用户场景

5. 联合需求计划：多方合作的需求规划会议

需求获取的核心特点：用户往往很难给出完整正确的原始需求，因此需要与用户有效合作和软件人员协助和多次沟通讨论。

速记方法5 种方法口诀：访 · 问 · 采 · 情 · 联

- 访(用户访谈)→ 一对一深聊- 问(问卷调查)→ 大面积撒网- 采(采样)→ 抓典型分析- 情(情节串联板)→ 故事板呈现- 联(联合需求计划)→ 多方圆桌

结构化分析(Structured Analysis, SA)方法：

- 核心：数据字典

- 3 层次模型：

1. 数据模型 → 一般使用实体关系图(E-R 图)表示

2. 功能模型 → 一般使用数据流图(DFD)表示

3. 行为模型(也称状态模型)→ 一般使用状态转换图(STD)表示

SA 方法的主要工作：给出一组帮助系统分析人员产生功能规约的原理与技术。

速记方法3 层次模型口诀：数 · 功 · 行(数据 / 功能 / 行为)

联想 3 个视角：- 数据 → 系统里有什么(E-R)- 功能 → 系统能做什么(DFD)- 行为 → 系统怎么变(STD)

SA 3 层次模型与对应建模图()：

1. 数据模型：实体关系图(Entity-Relationship Diagram, E-R 图)→ 描述实体、属性，以及实体之间的关系

2. 功能模型：数据流图(Data Flow Diagram, DFD)→ 从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各部件的功能和数据传递

3. 行为模型 / 状态模型：状态转换图(State Transform Diagram, STD)→ 描述系统的状态和引起系统状态转换的事件

对照检查：

- 数据 ↔ E-R 图(实体关系)- 功能 ↔ DFD(数据流)- 行为 ↔ STD(状态转换)

速记方法3 模型对应图记忆诀：

- 数据 → 看实体(E-R 图，画方块)

- 功能 → 看流动(DFD，画箭头)

- 行为 → 看状态(STD，画圆圈)

口诀：数 · 功 · 行 → E-R · DFD · STD(一一对应)

DFD 检查规则 4 条：

1. 父子图一致性：父图中描述过的数据流必须要在相应的子图中出现

2. 处理的输入输出：一个处理至少有一个输入流和一个输出流

3. 存储的输入输出：一个数据存储必定有流入的数据流和流出的数据流

4. 数据流端点：一个数据流至少有一端是处理端(不能两端都是数据存储或外部项)

模型整体要求：信息全面、完整、正确、一致。

速记方法DFD 4 检查规则按对象分组：

- 父子图 → 数据流要传承(规则 1)

- 处理 → 必有输入输出(规则 2)

- 存储 → 必有输入输出(规则 3)

- 数据流 → 至少一端是处理(规则 4)

关键反陷阱：数据流不能「飞过处理」直接从存储到外部项——必须经过加工。

OOA 的全称是 Object-Oriented Analysis，中文叫面向对象分析。

OOA 即面向对象分析（Object-Oriented Analysis），是软件需求分析阶段的核心方法，目的是弄清楚系统“做什么”，而不是“怎么做”。

OOA 的核心任务

在需求调研基础上，从业务问题域中识别对象、类、属性、行为及其关系，建立独立于实现技术的概念模型。

它关注的是：系统里有哪些业务实体、它们有什么属性和行为、它们之间如何协作、系统应提供哪些功能。

OOA 的 5 个基本步骤：

1. 确定对象和类：对象是数据及其处理方式的抽象；类是多个对象的共同属性和方法集合的描述

2. 确定结构：问题域的复杂性和连接关系(类成员结构：泛化-特化关系；整体-部分结构：整体和局部关系)

3. 确定主题：主题是事物的总体概貌和总体分析模型

4. 确定属性：属性就是数据元素，可用来描述对象或分类结构的实例

5. 确定方法：方法是在收到消息后必须进行的处理方法

五步骤逻辑：先有「物」(对象和类)，再有「关系」(结构)，再有「视角」(主题)，最后填充「数据和行为」(属性和方法)。

速记方法5 步骤口诀：对 · 结 · 主 · 属 · 方

联想「认识一个新事物」：

- 对(确定对象和类)→ 这是什么东西？

- 结(确定结构)→ 它和别的东西什么关系？

- 主(确定主题)→ 总体看是什么样？

- 属(确定属性)→ 它有哪些特征？

- 方(确定方法)→ 它能做什么？

OOA 5 个基本步骤的标准顺序与场景对应：

- 步骤 1 确定对象和类 → 场景(数据抽象和类归集)

- 步骤 2 确定结构 → 场景(泛化-特化和整体-部分关系)

- 步骤 3 确定主题 → 场景(总体概貌和总体分析模型)

- 步骤 4 确定属性 → 场景(数据元素描述对象)

- 步骤 5 确定方法 → 场景(消息后必须进行的处理方法)

速记方法5 步骤逻辑链：先「物」→「关系」→「视角」→「数据」→「行为」

- 物(对象和类)→ 系统里有哪些东西

- 关系(结构)→ 这些东西怎么连

- 视角(主题)→ 总体看是什么

- 数据(属性)→ 每个东西有哪些特征

- 行为(方法)→ 每个东西能做什么

软件需求规格说明书(Software Requirement Specification, SRS)8 个组成部分(GB/T 8567)：

1. 范围：系统和软件的完整标识、用途、特性、运行现场等

2. 引用文件：列出 SRS 中引用的所有文档

3. 需求：SRS 的主体部分，详细描述软件需求

4. 合格性规定：定义合格性方法，确保需求得到满足

5. 需求可追踪性：从 SRS 每个软件配置项需求到系统需求的双向可追踪性

6. 尚未解决的问题：说明软件需求中尚未解决的遗留问题

7. 注解：包含有助于理解 SRS 的一般信息(背景、词汇表、原理等)

8. 附录：提供为便于维护 SRS 而单独编排的信息(图表、分类数据等)

SRS 是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。

速记方法8 部分按写作顺序口诀：范 · 引 · 需 · 合 · 追 · 遗 · 注 · 附

- 范(范围)→ 系统是什么

- 引(引用文件)→ 参考依据

- 需(需求)→ 主体部分

- 合(合格性规定)→ 验证方法

- 追(需求可追踪性)→ 双向追踪

- 遗(尚未解决的问题)→ 留待解决

- 注(注解)→ 背景词汇

- 附(附录)→ 补充资料

需求变更管理过程的标准流程(5 个环节)：

1. 识别出问题：提出一份变更提议

2. 问题分析和变更描述：对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议

3. 变更分析和成本估算：对需求变更提议进行影响分析和评估；变更成本应包括所有改动的成本(修改需求文档、相应的设计、实现等工作成本)

4. 变更实现：当确定执行该变更后，根据该变更的影响范围按开发的过程模型执行

5. 修改后的需求：流程的最终产出物

变更控制过程的本质：不是给变更设置障碍，而是一个渠道和过滤器，确保采纳最合适的变更，使变更产生的负面影响降到最低。

不同开发模型的变更实现方式：

- 计划驱动过程模型：往往需要回溯到需求分析阶段开始，重新做对应的需求分析、设计和实现

- 敏捷开发模型：往往会将需求变更纳入到下一次迭代的执行过程中

速记方法变更管理 5 个节点口诀：识 · 析 · 估 · 行 · 改

- 识(识别问题)→ 提出变更

- 析(问题分析和变更描述)→ 检查有效性

- 估(变更分析和成本估算)→ 评估影响

- 行(变更实现)→ 执行变更

- 改(修改后的需求)→ 最终产出

常见的需求变更策略 6 条：

1. 所有需求变更必须遵循变更控制过程

2. 对于未获得批准的变更，不应该做设计和实现工作

3. 应该由项目变更控制委员会(CCB)决定实现哪些变更

4. 项目风险承担者应该能够了解变更的内容

5. 绝不能从项目配置库中删除或者修改变更请求的原始文档

6. 每一个集成的需求变更必须能跟踪到一个经核准的变更请求

控制需求变更与项目其他配置的管理决策有着密切的联系。项目管理应该达成一个策略，用来描述如何处理需求变更，而且策略应具有现实可行性。

速记方法6 条策略关键词：

- 守流程(变更必须遵循控制过程)

- 不批不动手(未批准不做设计实现)

- CCB 决定(变更控制委员会拍板)

- 干系人知情(风险承担者了解内容)

- 原始文档不可改(配置库保护)

- 集成必跟踪(变更跟踪到核准请求)

变更控制委员会(Change Control Board, CCB)核心特征：

1. 角色：项目所有者权益代表

2. 职责：负责裁定接受哪些变更

3. 组成：项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员

4. 性质：决策机构(不是作业机构)

5. 工作方式：通过评审手段决定项目是否能变更，但不提出变更方案

CCB 可能包括的部门：产品 / 计划管理部门、项目管理部门、开发部门、测试或质量保证部门、市场部或客户代表、用户文档编制部门、技术支持部门、桌面或用户服务支持部门、配置管理部门。

速记方法CCB 关键定位(三看)：

- 看角色：所有者权益代表

- 看性质：决策机构(评审和裁定，不操办)

- 看产出：批不批，不出方案

需求工程 4 个相关阶段的辨析：

1. 需求变更= 在软件开发过程中，由于多种原因(需求获取不完整 / 理解误差 / 业务变化等)导致需求发生改变，需要通过变更控制过程进行管理

2. 需求获取= 收集和理解项目干系人对系统的需求和约束的过程

3. 需求确认：也称需求验证，对 SRS 的正确性进行验证

4. 需求跟踪= 编制每个需求同系统元素之间的联系文档，形成水平可追踪性

场景分析：

- 触发原因：「业务变化」和「B 公司更改了需求」→ 需求发生了变化

- 关键动作：「项目组及相关干系人发起决策是否执行该修改」→ 走变更控制过程

→ 这是典型的「需求变更」场景。

速记方法4 阶段判断诀：

- 收集需求 → 需求获取

- 验证 SRS → 需求确认(验证)

- 改变需求 → 需求变更

- 跟踪需求与产出 → 需求跟踪

关键判断：场景里有「修改 / 改变需求」和「决策是否执行」：需求变更。

需求跟踪的核心概念：

1. 概念：编制每个需求同系统元素之间的联系文档(其他需求、体系结构、设计部件、源代码模块、测试、帮助文件、文档等)，形成「水平可追踪性」

2. 目的：建立与维护「需求 → 设计 → 编程 → 测试」之间的一致性，确保所有的工作成果符合用户需求

3. 2 种跟踪方式：

- 正向跟踪：检查 SRS 中的每个需求是否都能在后继工作成果中找到对应点

- 逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在 SRS 中找到出处

4. 双向跟踪：正向跟踪和逆向跟踪

5. 需求跟踪矩阵：不论采用何种跟踪方式都要建立与维护；保存需求与后继工作成果的对应关系；跟踪能力是优秀 SRS 的一个特征

实施特点：需求跟踪是手工操作和劳动强度大的任务，需要组织提供支持；实际项目中常采用专门的配置管理工具。

速记方法正向 vs 逆向辨析(关键判断：起点是 SRS 还是工作成果)：

- 正向(SRS → 后继)：检查需求是否实现(防漏)

- 逆向(后继 → SRS)：检查实现是否对应需求(防偏)

双向：正和逆，缺一不可。

需求工程 5 大阶段对照：

1. 需求获取= 通过用户访谈、问卷调查、采样、情节串联板、联合需求计划等方式收集需求

2. 需求分析= 将杂乱的用户要求转化为用户需求；包括 SA(数据 / 功能 / 行为模型)和 OOA

3. 需求验证，也称需求确认)= 对 SRS 的正确性进行验证；包括需求评审和需求测试

4. 需求变更= CCB 评审决定接受 / 拒绝变更，走变更控制过程

5. 需求跟踪= 检查 SRS 中每个需求是否在后继工作成果中找到对应点(正向跟踪)；或检查工作成果是否在 SRS 中找到出处(逆向跟踪)→ 场景④

注：场景「CCB 评审决定接受变更」属于需求变更，与需求验证不同——前者管「变化」，后者验「正确性」

速记方法需求工程 5 阶段判断诀：

- 用户访谈 / 问卷调查 → 需求获取

- 杂乱要求转化为用户需求(SA / OOA)→ 需求分析

- 评审 SRS / 测试 → 需求验证(确认)

- CCB 评审变更 → 需求变更

- 正向 / 逆向跟踪 → 需求跟踪

SRS 的全称是 Software Requirements Specification，中文叫软件需求规格说明书。

SRS 是「需求分析阶段的最终结果」文档，主要职责是描述「软件需求是什么」，不包括「需求变更如何管理」的策略——后者属于变更管理或配置管理范畴(5.2.6 节内容)。

速记方法SRS 是「需求快照」，不是「变更管理」：

- SRS 内容 → 描述「软件需求是什么」(静态)

- 变更策略 → 管理「需求如何变化」(动态)

两者职责清晰分离。