软件工程——学堂在线学习笔记四

一. 需求工程师

1. 分析问题和解决问题的能力
2. 人际沟通及交流能力
3. 软件工程知识和技能
4. 应用领域有关知识
5. 书面语言组织和表达能力

1. 优秀需求⼯程师的目标

• 识别错误假设
• 确保一致性
• 提升依从性
• 减少彼此误解
• 提高支持速度和效率
• 提升客户满意度
• 撰写优质需求文档

二. 需求定义

1. 概述

“需求”是对外可见的系统特征。— Alan M. Davis

“需求管理” 有三项任务：

• 学习 ——需求获取
• 剪枝 ——需求优选
• 文档化 ——撰写需求规格说明书

需求, 是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的正式文档依据。—— IEEE 610.12, 1990

2. 需求难度在？

将机器领域（内部环境）用来描述应⽤领域（外部环境）

3. 需求的内容

为什么要设计该系统
系统由谁使⽤
系统要做什么
系统涉及哪些信息
对解决⽅案有何额外限制
如何使⽤该系统
质量需达到何种程度

4. 将问题与解决⽅案分开

三. 需求分类

1. 按产品需求分类

(1). 功能性需求

系统的功能性需求是指满⾜系统需求需要提供的功能有时，功能需求也被称为“⾏为需求”

(2). 非功能性需求

⾮功能性需求定义软件系统以及软件开发过程为满⾜系统功能需求要满⾜的
其他约束条件

2. 按抽象层次详细程度分类

(1). 业务需求

业务需求是指那些可以帮助企业达成组织⺫标(包括策略目标)的需求项

(2). ⽤户需求

系统的⽤户需求指的其满⾜会影响系统的⽤户接受程度的需求有时候，⽤户需求被称作“⽤户接⼝需求”

(3). 系统需求

系统需求的满⾜使得系统实现预期的功能，它从⽤户的⾓度描述系统在做什么，与系统是由什么硬件和软件实现⽆关。

(4). 软件设计规约

三. 需求工程活动

1. 需求抽取（Elicitation）

目标： 主动与干系人协同工作，找出他们的需求，识别潜在的冲突，磋商解决矛盾，定义系统范围与边界

实质：了解待解决的问题及其所属领域

关键：确保该问题的解决是有商业价值的

方法：

• 协同工作（Collaborative sessions）
• 面谈 （Interviewing techniques）
• 问卷调查（Questionnaires）
• 观察法 （Ethnography）
• 原型法 （Prototyping）
• 文档分析（Documentation）
• 建模 （Modeling）
• 角色扮演（Roleplaying）
• 非功能性需求列表（Checklists of NFRs）

2. 需求分析（Analysis）

目标：对产品及其与环境的交互进行更深入的了解，识别系统需求，设计软件体系结构，建立需求与体系结构组件间的关联，在体系结构设计实现过程中进一步识别矛盾冲突，并通过干系人之间的协调磋商解决问题。

实质：概念建模———选择常用的建模语言，进行功能建模和信息建模

关键：体系结构设计与需求分配

3. 需求规约（Specification）

需求建模方法

4. 需求管理（Management）

贯穿从需求获取到软件系统下线的全过程。需求管理涉及软件配置管理、需求跟踪、影响分析和版本控制

• 需求跟踪 （Requirements traceability）
  描述和追踪一条需求的来龙去脉的能力，包括向前追踪到软件制品，向后追踪到需求来源
• 变更请求管理 （Change Requests）
  系统化的变更管理
• 需求属性管理 （Requirements attributes）

5. 需求验证（Validation）

对其他需求工程活动的质量的保证。通过数学的形式化工具或工程化的测试
过程来确保系统满足干系人的要求。

验证方法

• 评审（Review）
• 原型化（Prototyping）
• 模型验证（Model validation）
• 确认测试（Acceptance Tests）

四. 需求来源

1. 四世界模型

2. 获取方法

确定干系人

• 这里需要强调与客户之间的联络关系
• 系统的设计到底与谁的利益息息相关

定义边界

• 怎样界定问题的范围？

定义目标与情景实例

• 目标与情景实例是组织原始需求信息的有效手段

分析可行性

• 如何进行可行性研究
• 如何选择好的项目

分析风险

• 风险管理应长期、持续进行，而非阶段性、一次性的任务
• 进行灾难及事故分析，以确定风险

五. 需求获取

需求获取过程中，最困难的不是记录用户需求，而是与用户探讨磋商，发现真正要解决的问题，确定适用的方案。

1. 需求获取技术

(1). 主要

面谈

• 一样的地点，一样的时间
• 少量人参与，分析师驱动

问卷调查

• 不同的时间，不同的地点
• 很多人参与，分析师观察

群体诱导技术

• 相同或不同的地点，同样的时间
• 20人左右，分析师参与

参与调查法

• 同样的时间，同样的地点
• 分析师参与

(2). 次要

• ⽂档分析
• 头脑⻛暴
• 情景分析
• 原型化⽅法
• 建模⽅法
• 需求讨论会

六. 撰写需求文档

1. 软件需求规格说明 （SoftwareRequirements Specifica4on, SRS)

• 是具有一定法律效力的合同文档
• 清楚地描述软件在什么情况下，需要做什么，以及不能做什么
• 以输入/输出、输入到输出之间的转换方式来描述功能性需求
• 描述经过干系人磋商达成共识的非功能性需求
• 一般参考需求定义模板，覆盖标准模板中定义的所有条目
• 作为后续的软件评估依据和变更的基准

2. 需求文档的组织形式

文档需要有逻辑组织结构
• 例如：参照IEEE的模板

典型的组织形式包括
• 按系统能够响应的各种外部环境情况来组织
• 按系统特征来组织
• 按系统的响应方式来组织
• 按所管理的外部数据对象来组织
• 按用户类型来组织
• 按软件的工作模式来组织
• 按子系统的划分来组织

3. 软件需求规格说明SRS的风格

• 描述性的自然语言文本
• 从用例模型产生
• 从需求数据库中生成
• 从混合模型中生成

4. 需求规格说明生成过程