软考-10.2需求工程-分析-获取-定义-验证-管理
前言
内容：
- 需求工程
中论
软件需求
软件需求：指用户在功能、行为、性能、设计约束等方面的期望。是用户解决问题或达到目标所需的条件或能力；是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。
分为需求开发和需求管理两大过程
业务需求：反映企业或客户对系统高层次的目标要求
用户需求：用户的具体目标，或用户要求系统必须能完成的任务，描述了用户能使用系统来做什么
系统需求：从系统的角度来说明软件的需求
- 功能需求：规定了开发人员必须在系统中实现的软件功能
- 非功能需求：系统必须具备的属性或品质
- 设计约束：对系统的一些约束说明
需求获取
需求获取：一个确定和理解不同的项目干系人的需求和约束的过程
常见的需求获取法
- 用户访谈：
- 用户调查：
- 采样：
- 情节串联板：一系列图片，通过这些图片来讲故事
- 联合需求计划：联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求
- 需求记录技术：任务卡片、场景说明、用户故事、Volere白卡
需求分析
一个好的需求必须具备无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特征，因此需要分析人员把杂乱无章的用户要求和期望转化为用户需求。
需求分析的任务
- 位置系统上下文范围关系图
- 创建用户界面原型
- 分析需求的可行性
- 确定需求的优先级
- 为需求建立模型
- 创建数据字典
- 使用QFD（质量功能部署）
结构化的需求分析
结构化特点：自顶向下、逐步分解、面向数据
三大模型：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典
数据流图DFD
基本图形元素：外部实体、加工、数据存储、数据流
- 数据流：有一组固定成分的数据组成，表示数据的流向，在DFD中，数据流的流向必须经过加工
- 加工：描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误：
- 有输入但是没有输出：黑洞
- 有输出但是没有输入：奇迹
- 输入不足以产生输出：灰洞
- 数据存储：存储数据
- 外部实体（外部主体）：存在于软件系统之外的人员或组织
数据字典DD
数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工以及组成数据流或文件的数据项做出说明。
数据字典有四类条目：数据流、数据项、数据存储和基本加工
加工逻辑也被称为“小说明”，常用的加工逻辑：结构化语言、判定表和判定树
需求定义
需求定义（软件需求规格说明书SRS）：是需求开发活动的产物，目的是使项目干系人和开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
需求定义方法
- 严格定义（预先定义）：需求的严格定义建立在以下的基本假设之上：所有的需求都能够被预先定义
- 原型方法：迭代的循环型开发方式，原型提供了克服该困难的一个手段
需求验证
也称为需求确认，目的是与用户一起确认需求无误
步骤：
- 需求评审
- 需求测试
需求验证通过后，要请用户签字确认，作为验收标准之一
需求管理
定义需求基线：通过了评审的需求说明书就是需求基线，如果下次需要变更需求，就需要按照流程一步步执行。需求的流程及状态如下：
需求变更和风险：主要关心需求变更过程中的需求风险管理，带有风险的做法：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。
变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化
变更控制委员会CCB：也称为配置控制委员会。
双向追踪，两个层次
- 正向追踪：表示用户原始需求是否都实现了
- 反向追踪：软件实现的是否都是用户要求的
- 若原始需求和用例有对应，则在对应栏中打对号，若某行都没有对号，表明原始需求未实现，正向追踪发现问题；若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向追踪发现问题
