软件需求工程
1 软件需求概述
1.1 软件需求定义
软件需求：是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
1.2 需求分类
| 需求层次 | 说明 |
|---|---|
| 业务需求 | 反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围 |
| 用户需求 | 描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么 |
| 系统需求 | 从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等 |
1.3 系统需求细分
-
功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能
-
非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求
-
设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明
1.4 质量功能部署（QFD）
质量功能部署（QFD）：一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。
QFD将软件需求分为三类：
| 需求类型 | 说明 |
|---|---|
| 常规需求 | 用户认为系统应该做到的功能或性能，实现越多用户会越满意 |
| 期望需求 | 用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意 |
| 意外需求 | 也称为兴奋需求，是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策 |
1.5 FURPS+模型
在统一过程（UP）中，需求按照”FURPS+“模型进行分类：
| 需求类型 | 说明 |
|---|---|
| F - 功能性 | 特性、功能、安全性 |
| U - 可用性 | 人性化因素、帮助、文档 |
| R - 可靠性 | 故障频率、可恢复性、可预测性 |
| P - 性能 | 响应时间、吞吐量、准确性、有效性、资源利用率 |
| S - 可支持性 | 适应性、可维护性、国际化、可配置性 |
| + | 辅助性的和次要的因素，如实现、接口、操作、包装、授权等 |
1.6 PIECES框架
PIECES框架是系统非功能性需求分类的技术：
| 类型 | 说明 |
|---|---|
| P - 性能 | 描述企业当前的运行效率，可以分析当前业务的处理速度 |
| I - 信息 | 信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种问题 |
| E - 经济 | 从成本和收益的角度分析企业当前存在的问题 |
| C - 控制 | 提高信息系统的安全和控制水平 |
| E - 效率 | 提高企业的人、财、物等的使用效率 |
| S - 服务 | 提高企业对客户、供应商、合作伙伴、顾客等的服务质量 |
2 需求获取
2.1 需求获取定义
需求获取：是一个确定和理解不同的项目干系人的需求和约束的过程。
2.2 需求获取方法
| 方法 | 说明 | 适用场景 |
|---|---|---|
| 用户访谈 | 1对1-3，有代表性的用户。形式包括结构化和非结构化两种 | 灵活性好，应用范围广，但信息量大、记录困难 |
| 问卷调查 | 用户多，无法一一访谈 | 用户群体大，需要快速收集信息 |
| 采样 | 从种群中系统地选出有代表性的样本集的过程 | 基于数理统计原理，可减少数据收集偏差 |
| 情节串联板 | 一系列图片，通过这些图片来讲故事 | 可视化展示需求 |
| 联合需求计划（JRP） | 通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求 | 高度组织的群体会议来分析企业内的问题 |
| 需求记录技术 | 任务卡片、场景说明、用户故事、Volere白卡 | 记录需求的技术 |
采样数量计算公式：
样本数量 = 0.25 × (可信度因子 / 错误率)²
3 需求分析
3.1 需求分析定义
需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求。
3.2 需求分析任务
- 绘制系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求建立模型
- 创建数据字典
- 使用QFD（质量功能部署）
4 统一建模语言（UML）
4.1 UML概述
统一建模语言（UML）：是一种用于描述、构造和文档化系统制品的可视化语言。
4.2 UML图分类
结构图（静态图）：
- 类图
- 对象图
- 构件图
- 部署图
- 包图
行为图（动态图）：
- 用例图
- 活动图
- 状态机图
- 序列图
- 协作图
- 定时图
- 交互概览图
4.3 常用UML图
用例图：描述系统的功能，由系统、用例和角色构成
类图：描述系统中类的结构和类之间的关系
序列图：描述对象之间的交互顺序
活动图：描述从一个活动到另一个活动的控制流
状态机图：描述对象在其生命周期内响应事件所经历的状态序列
5 需求定义
5.1 需求规格说明书（SRS）
需求规格说明书（SRS）：是需求开发阶段的成果，是系统用户与开发者之间的一份契约。
5.2 SRS内容
- 引言
- 信息描述
- 功能描述
- 行为描述
- 质量保证
- 接口描述
- 其他
6 需求验证
6.1 需求验证方法
- 需求评审：正式的技术评审会议
- 原型验证：通过原型系统验证需求
- 模型验证：通过需求模型验证
6.2 需求验证内容
- 正确性
- 无二义性
- 完整性
- 一致性
- 可验证性
- 可修改性
- 可跟踪性
7 需求管理
7.1 需求管理过程
需求管理：是一个对系统需求变更了解和控制的过程。
7.2 需求管理活动
- 变更控制：管理需求的变更
- 版本控制：管理需求文档的不同版本
- 需求跟踪：跟踪需求从提出到实现的过程
- 需求状态跟踪：跟踪需求的状态变化
7.3 需求跟踪
需求跟踪：是跟踪一个需求从提出到实现的过程。
需求跟踪矩阵：用于记录需求与设计、实现、测试之间的对应关系。
8 考试真题
真题1：
软件需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为获取情况、分析、（）和评审四个阶段。
A. 制订规格说明
B. 形成需求基线
C. 跟踪需求变更
D. 控制需求版本
答案：A
真题2：
某软件公司正在承担开发一个字处理器的任务。在需求分析阶段，公司的相关人员整理出一些相关的系统需求，其中：
“找出文档中的拼写错误并提供一个替换项列表来供选择替换拼错的词”属于（）；
“显示提供替换词的对话框以及实现整个文档范围的替换”属于（）；
“用户能有效地纠正文档中的拼写错误”属于（）。
选项：A. 业务需求 B. 用户需求 C. 功能需求 D. 性能需求
答案：B（用户需求）、C（功能需求）、A（业务需求）
真题3：
需求获取是确定和理解不同的项目干系人的需求和约束的过程，需求获取是否科学、准备充分，对获取出来的结果影响很大。在多种需求获取方式中：
（）方法具有良好的灵活性，有较宽广的应用范围，但存在获取需求时信息量大、记录较为困难、需要足够的领域知识等问题。
（）方法基于数理统计原理，不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户，并可以减少数据收集偏差。
（）方法通过高度组织的群体会议来分析企业内的问题，并从中获取系统需求。
选项：A. 用户访谈 B. 问卷调查 C. 联合需求计划 D. 采样
答案：A（用户访谈）、D（采样）、C（联合需求计划）
参考资源
- 系统分析师教材（第二版）第11章
- 文老师软考教育