《系统架构设计师教程（第2版）》第5章-软件工程基础知识-02-需求工程-CSDN博客

本文链接：https://blog.csdn.net/xingzuo_1840/article/details/135272401

1. 概述

1.1 需求

1）需求的含义

目前没有统一的定义，但都包含以下几方面的内容：

用户解决问题或达到目标所需条件或权能
系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能
反应上述述条件或权能的文档说明

2）需求的三个层次

业务需求：反映了组织机构或客户对系统、产品高层次的目标要求
用户需求：描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望

业务需求和用户需求两种构成了用户原始需求文档的内容。

功能需求、非功能需求
- 功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求
- 非功能需求：
  - 概述：它对设计和实现提出了限制
  - 包括：
    - 产品必须遵从的标准、规范和合约
    - 外部界面的具体细节
    - 性能要求
    - 设计或实现的约束条件及质量属性
      - 约束：指对开发人员在软件产品设计和构造上的限制，常见的有设计约束和过程约束。
      - 质量属性：通过多种角度对产品的特点进行描述，从而反映产品功能

1.2 需求工程

概述：应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。
目标：确定客户需求，定义设想中系统的所有外部特征
活动
- 需求工程覆盖了体系结构设计之前的各项开发活动
- 主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明
活动的几个阶段
- 需求获取
通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
- 需求分析
为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
- 形成需求规格(需求文档化)
按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述规约作为后续软件系统开发的指南。
- 需求确认与验证
以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
- 需求管理
  - 概述：是一个对系统需求变更、了解、控制的过程
  - 包括：需求文档的追踪管理、变更控制、版本控制等
  - 强调内容：
    - 控制对需求基线的变动
    - 保持项目计划与需求一致
    - 控制单个需求和需求文档的版本情况
    - 管理需求和联系链，或管理单个需求和其他项目可交付产品之间的依赖关系
    - 跟踪基线中的需求状态
  - 需求基线(Baseline)：
    - 形成：软件需求开发的最终文档经过评审批准后
    - 意义：
      - 在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定
      - 是需求开发和需求管理之间的桥梁

1. 需求获取

需求陈述
- 概述：阐明做什么（而不是怎么做）
- 来源：
  - 由用户单方面写出
  - 由业务分析员、系统分析员配合用户共同写出
- 内容：
  - 包括问题范围、功能需求、应用环境、假设条件等
  - 相关软件工程标准、技术方案、将来可能做的扩充、可维护性要求等方面的约束条件

需求

概述：获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束

1.1 需求获取的基本步骤

1）开发高层的业务模型

应用领域：目标系统的应用环境（如银行、电信公司等）。
高层业务模型：
- 开发条件：系统分析员对该领域有充分了解
- 行为：
  - 描述用户的业务过程，确定用户的初始需求。
  - 通过迭代，更深入地了解应用领域，之后再对业模型进行改进

2）定义项目范围和高层需求

项目范围：
- 描述系统的边界
- 描述系统与参与者之间的关系
高层需求：主要表示系统需求的概貌（不涉及过多的细节）
常见的建模手段：系统上下文图、系统顶层用例图

3）识别用户角色和用户代表

涉众
- 概述：即用户和用户代表
- 选取包括：用户、客户、测试人员、维护人员、市场人员等
用户角色
- 人
- 应用程序、硬件
用户代表
- 当用户是应用程序或硬件，则需要以熟悉他的人作为用户代表

4）获取具体的需求

前置
- 确定了项目范围和高层需求
- 确定了所有涉众后
行为：获取每个涉众的具体、完整、详细的需求

5）确定目标系统的业务工作流

6）需求整理与总结

包括：功能需求、性能需求、环境需求、可靠性需求、安全保密需求、用户界面需求、资源使用需求、软件成本消耗与
开发进度需求等

1.2 需求获取方法

1）用户面谈

面谈
面谈后：
需要复查笔记的准确性、完整性和可理解性
把所收集的信息转化为适当的模型和文档
确定需要进一步澄清的问题

2）需求专题讨论会

-参会人员：主持人、用户、技术人员、项目组人员。

3）问卷调查

作用：
- 确认假设
- 收集、统计“倾向数据”
使用时机：完成用户面谈和分析后
存在的问题是：
- 问题背后的假设对答案造成偏颇
- 难以探索一些新领域
- 难以继续用户的模糊响应

4）现场观察

通过观察用户实际执行业务的过程，来直观地了解业务的执行过程，全面了解需求细节

5）原型化方法

作用：解决在早期阶段需求不确定的问题（如人机界面等）

6）头脑风暴法

使用范围：新业务拓展的软件项目
行为：一群人围绕该业务，发散思维，不断产生新的观点，而确定具体的需求

2. 需求变更

变更产生可能的原因
- 需求获取不完整，存在遗漏的需求
- 对需求的理解产生了误差
- 业务变化导致了需求的变化等
变更的注意事项
- 仔细评估已建议的变更。
- 挑选合适的人选对变更做出判定。
- 变更应及时通知所有相关人员。
- 项目要按一定的程序来采纳需求变更，对变更的过程和状态进行控制。

2.1 变更控制过程

作用：用来跟踪已建议变更的状态，使已建议的变更确保不会丢失或疏忽。

1）变更管理过程：

识别问题
问题分析和变更描述
- 时机：已提出一份变更提议
- 行为：检查“识别问题”的有效性，从而产生一个更明确的需求变更提议
变更分析和成本计算
- 接收了一个变更提议
- 行为：如题，没有可说的
变更实现
- 行为根据该变更的影响范围，按照开发的过程模型执行相应的变更。
- 行为：
  - 计划驱动过程模型中：回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤
  - 敏捷开发模型中：将需求变更纳入到下一次迭代的执行过程中

2）常见的需求变更策略

所有需求变更必须遵循变更控制过程
对于未获得批准的变更，不应该做设计和实现工作
变更应该由项目变更控制委员会决定实现哪些变更
项目风险承担者应该能够了解变更的内容
绝不能从项目配置库中删除或者修改变更请求的原始文档
每一个集成的需求变更必须能跟踪到一个经核准的变更请求

2.2 变更控制委员会

概述：
- 变更控制委员会 (Change Control Board,CCB) 是项目所有者权益代表
- 负责裁定接受哪些变更（但不提出变更方案，其是决策机构）
人员：用户和实施方的决策人员。包括如下部门代表：
- 产品或计划管理部门
- 项目管理部门
- 开发部门
- 测试或质量保证部门
- 市场部或客户代表
- 制作用户文档的部门
- 技术支持部门
- 帮助桌面或用户支持热线部门
- 配置管理部门
变更控制委员会总则
- 描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤
- 说明举行会议的频度和事由
- 管理范围描述该委员会能做什么样的决策，以及有哪一类决策应上报到高一级的委员会
行为和步骤
- 制定决策
  - 其过程的描述应确认：
    - 必须到会的人数或做出有效决定必须出席的人数。
    - 决策的方法
    - 委员会主席是否可以否决该集体的决定
  - 利弊权衡
    - “利”：节省资金、额外收入、增强客户满意度、竞争优势、减少上市时间
    - “弊”：接受变更后产生的负面影响，包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意度。
- 交流情况
- 重新协商约定
  - 触发：当项目接受了重要的需求变更时
  - 协商内容：推迟交货时间、要求增加人手、推迟实现尚未实现的较低优先级的需求、者质量上进行折中等

3. 需求追踪

概述
- 编制每个需求同系统元素之间的联系文档
其中系统元素包括：其他需求、体系结构、其他设计部件、源代码模块、测试、帮助文件和文档等
- 在整个项目的工件之间形成水平可追踪性
- 采用专门的配置管理工具来实现需求跟踪
目的：是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。
需求跟踪有两种方式：
- 正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点
- 逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处