- 需求工程
需求工程是软件工程的一个分支。它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
- 需求
- 用户为了解决问题或达到某些目标所需要的条件或能力；
- 系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；
- 对1或2中的一个条件或一种能力的一种文档化表述。
- 问题
当现实的状况与人们期望的状况产生差距时，就产生了问题。
- 问题域
要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。这些实体和状态构成了问题解决的基本范围，称为该问题的问题域.
- 解系统
软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。
- 需求
需求是用户对问题域当中的实体状态或事件的期望描述。
- 需求的层次性
- 业务需求
- 用户需求
- 系统级需求
- 需求的类型
- 功能需求：必要
- 性能需求：速度、容量、吞吐量等
- 质量属性：功能性、可靠性、可移植性、可用性、安全性等
- 对外接口：数据格式、通信接口、界面等
- 约束：构建系统的范围，包括运行环境、商业规则、业内标准等
- 优秀需求
正确性：反映用户意图 可行性：需要分析验证 必要性：满足用户业务需求 无歧义：只有一种解释 可验证：具体化，可以度量
- 判定需求的类型，发现错误并修正（示例：ppt思考题）
- 书写需求（示例：第2章案例题4～6）
需求工程概述，具体见后章节
- 需求获取的子活动
- 研究应用背景，建立初始的知识框架；
- 根据获取的需要，采用必要的获取方法和技巧；
- 先行确定获取的内容和主题，设定场景；
- 分析用户的高（深）层目标，理解用户的意图；
- 进行涉众分析，针对涉众的特点开展工作。
- 需求获取活动的要点
- 获取的内容：范围之内，逐步积累
- 获取的来源：涉众，数据，文档，法律法规，相关产品
- 获取的方法：传统方法，集体获取，原型，认知方法，基于上下文的方法
- 获取的过程：组织方案，维护，不确定性，学会探索，防止需求遗漏
- 获取的结果：笔录，产生文档（项目前景和范围文档和用例文档）
- 前景和范围
定义业务需求和能够满足需求的高层解决方案，包括：业务目标、目的，高层业务功能，每个高层业务功能所关联的高层数据，每个功能相关的项目涉众等等
- 问题分析过程
- 明确问题：对问题达成共识，收集资料，分析不明确的问题；
- 发现业务需求：每一个明确、一致的问题都意味着涉众存在一些相应的期望目标，即业务需求；
- 定义解决方案及系统特性：确定高层次的解决方案，确定系统特性和解决方案的边界（用例图和上下文图，DFD），确定解决方案的约束；
- 建立系统边界：所有问题的解决方案进行综合，就可以得到整个解系统的功能和边界（系统用例图和上下文图）。
- 目标
- 目标是系统被开发的目的，有着明确的定义方式，包括名称、类型、关注、定义（正式与非正式））、优先级、主体、拥有者等；
- 包括功能目标和非功能目标。
- 目标关系：精化关系（And/Or精化），阻碍关系，冲突关系
- 基于目标模型获取非功能需求�（NFR）
将非功能需求建模为目标
- 目标分析、业务过程分析
令牌（Token），具体PPT
- 建立活动图
- 确定活动图的上下文环境：界定业务流程的处理界限
- 分析业务流程中的主要处理步骤
- 分析业务流程中的主要数据流
- 识别参与者，进行职责分配，将业务流程的处理步骤划分到不同的泳道，并将处理步骤和数据流的传递组织起来，建立活动图
- 添加活动图的详细信息，完善活动图描述
- 第5章所有案例题（PPT上有！）
- 项目前景和范围文档
- 涉众分析的主要内容
寻找涉众 理解涉众
- 涉众分析过程
- 总体过程 + 判断涉众类别 + 描述特征 + 分析影响程度 + 描述兴趣和关注点 + 分析影响力 + 选择合适代表
- 识别 + 简单方法：先膨胀后收缩(Expand to Shrink) + 经验方法：Checklist + 经典方法：涉众网络
- 描述 + 个人特征 + 工作特征 + 社会地理特征 + 主要目标 + 态度 + 关注点 + 约束条件
- 评估 + 优先级评估 + 风险评估 + 共赢分析
- 选择 + 代表采样 + 参与策略 + 用户替代源
- 硬数据采样
- 类型 + 定量硬数据：数据收集表 统计报表 + 定性硬数据：描述文档 业务指导文档 备忘
- 采样方法 + 采样数量： + 样本大小＝p×(1－p) ×（确定性因子/可接受的错误）^2 + P是差异样本比例，未知的情况下设为0.25 + 采样方式： + 随机采样 + 分层采样
PPT&书
- 获取的注意事项
- 要保持项目范围，不能有需求遗漏 + 参照系统特性，围绕系统边界设计获取活动计划
- 多轮次获取 + 获取要点的不同 + 前景与范围阶段 + 准备：背景资料获取分析 + 第一轮：问题分析 + 第二轮：高层解决方案制定 + 用户需求获取阶段 + 准备：明确主题内容，准备材料 + 第一轮：明确任务和任务中的主要问题 + 第二轮：明确任务细节，澄清困难内容 + 第三轮：明确解决方案
- 根据内容合理安排获取方法 + 面谈 + 集体面谈 + 头脑风暴 + 原型 + 观察
- 及时组织已获取需求，为后续获取提供指导 + 场景/用例模型
- 场景用例
以场景为单位组织需求 > 1. 差异性 + 方法多样 + 可以处理业务需求和系统级需求 + 可以处理设计问题和测试问题 + 缺点 + 无法描述与其他内容之间的相互关系 + 没有考虑联系的合理性 > 2. 作用 + 用于项目管理 + 业务流程建模 + 需求工程 + 设计 + 实现 + 测试 + 集成 + 等等等等 > 3. 层次性（用例表格）
- 场景的定位
形式（如何描述，外观） 内容 目的 生命周期
- 用例定位
- 静态的结构化文本描述
- 可以是期待的解决方案的描述
- 也用于描述系统和环境的交互
- 用例图
用例 参与者 关联 边界
- 基于场景/用例模型展开需求获取
基于前景范围建立初始的用例模型 迭代展开用例 验证场景/用例模型 维护场景/用例模型
- 需求获取的过程（见上面）
- 使用分析方法澄清场景
- 面谈问题类型
主要是开放式和封闭式，也有探究式、诱导式、双筒问题和元问题
- 面谈过程
- 准备面谈 + 准备资料 + 前期开放式问题为主，决策层和专家为主 + 后期封闭式问题为主，要有针对性，实现面谈记录资料 + 确认主题目标 + 选择面谈对象 + 准备面谈对象 + 确定问题和类型
- 主持面谈 + 握手仪式 + 保持礼貌倾听 + 学会观察 + 总结要点感谢参与者
- 处理面谈结果 + 复查面谈记录 + 总结面谈信息 + 完成面谈报告
- 面谈的优缺点
- 优点 + 展开条件简单 成本低 + 可以获得广泛的内容 + 建立友好关系 + 提高涉众热情
- 缺点 + 耗时长 + 记忆和交流能力制约 + 模糊表述
- 面谈方法
- 群体面谈
- 头脑风暴
- 调查问卷
PPT
- 理解原型的不确定性
- 无法确定某种决策的结果
- 科学的目的是为了限定不确定性
- 软件工程中的不确定性：需求 设计 构造 测试 管理
- 原型类别
- 按照使用方式 + 演示原型 + 严格意义上的原型 + 试验原型 + 引示系统原型
- 按照开发方法 + 探索式 + 实验式 + 演化式
- 按照构建技术 + 水平原型：只注重特定层次 + 垂直原型：考虑所有层次
- 按照介质 + 低保真原型 + 高保真原型
- 按照表现 + 静态画面 + 场景模型 + 动态程序
- 原型方法的风险
工作大 成本高 时间长
PPT&书
- 观察的情境适用性
应用于用户无法完成主动的信息告知的情况下
- 观察方法的应用
- 采样观察 + 时间采样 + 事件采样
- 民族志 + 典型示例也都是复杂的协同问题 + 例如工作的分布式协同，工作的计划程序，工作的意识
- 文档审查方法
- 规格说明文档：需求重用
- 硬数据：文档分析
- 客户的需求文档：需求剥离
示例：第9章案例题1
- 分析模型的基本思想
将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征 和用户达成对信息内容的共同理解 分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息 建模方法：抽象 分解 投影
- 多种技术的综合使用
- 结构化技术 + 数据建模（ERD，实体关系图） + 过程建模（数据流图 上下文图） + 行为建模（状态转换图） + 过程建模
- 面向对象技术 + UML + 用例图 + 类图 + 交互图（顺序图） + 活动图 + 状态图
- 如何为各个视角选择需求分析技术 + 每一种需求分析技术都有自己的特点，具有在应用上的独特性
- 如何实现它们之间的配合 + 只有通过多种需求分析技术的有机结合与集成才能充分的描述复杂应用
- 需求分析方法
- 传统分析：没有方法
- 结构化分析：传统结构化分析和现代结构化分析
- 面向对象分析
- 需求分析活动
- 需求细化：包括标识符，源头，理由，优先级，成本，风险和可变性等；
- 确定需求优先级：投票，区域划分（重要/不重要，紧急/不紧急）；
- 需求协商：明确冲突因素并制定解决方案
第11章所有思考题 判定技术综合 细化需求 优先级划分
-
过程建模是结构化建模的核心方法
-
数据流图DFD
- 基本元素 + 外部实体 + 过程 + 数据流 + 数据存储
- 规则 + 要有输入输出 + 和过程有关 + 有唯一标识
- 层次结构 + 上下文图 + 0层图 + N层图
- 建立 + 创建上下文图 + 发现并建立DFD片段 + 产生0层图 + 功能分解产生N层图
- 验证 + 确保不会发生语法结构语义错误
- 决策表
| 条件和行动 | 规则 |
|---|---|
| 条件声明 | 条件选项 |
| 行动声明 | 行动选项 |
- 条件声明是进行决策时需要参考的变量列表
- 条件选项是那些变量可能的取值
- 动作声明是决策后可能采取的动作
- 动作选项表明那些动作会在怎样的条件下发生
- 决策树
通常是一颗平放的树，树根在左边，树枝从左向右展开。树枝上是有关条件和行动的描述。
- 实体关系模型ERD
- 实体
- 属性
- 关系
- ERD表示法
- 简单情况下的建模
- 从描述信息中辨识实体 + 可以重点关注描述信息中的名词，看系统是否需要收集其相关的特征
- 确定实体的标识符
- 建立实体间关系 + 判断各个关系的建立是否会产生新的关联实体或者影响已有的实体特性
- 添加详细的描述信息 + 实体的详细属性和关系的基数
- 硬数据建模
- 分析表单内容，确定表单主题 + 每个主题描述为一个独立的数据实体
- 建立主题之间的关系
- 围绕主题组织表单的项目
- 根据描述建模
- 用例（Use Case）
- 参与者（Actor）
- 关系（Relationship）
- 系统边界（System Boundary）
- 活动图（PPT）：业务流程建模
- 确定活动图的上下文环境 + 界定业务流程的处理界限
- 分析业务流程中的主要处理步骤
- 分析业务流程中的主要数据流
- 进行职责分配，将业务流程的处理步骤划分到不同的泳道，并将处理步骤和数据流的传递组织起来，建立活动图
- 添加活动图的详细信息，完善活动图描述
- 顺序图（PPT）：用例实现/交互
同步 异步 返回箭头（实线箭头 虚线鱼骨 虚线鱼骨） 系统顺序图
- 状态图（PPT）：行为建模
- 确定上下文环境 + 搞清楚状态的主体常见的状态主体有：类、用例、多个用例和整个系统
- 识别状态，标记初始状态和结束状态 + 可能会不存在确定的初始状态和结束状态
- 建立状态转换
- 补充详细信息，完善状态图
- 状态数量较多时，考虑建立层次结构（状态或）或并发结构（状态与）
- 概念类图
概念类会显式的描述自己的一些重要属性，但不是全部的详细属性，而且概念类的属性通常没有类型的约束； 概念类不显式的标记类的行为，即概念类不包含明确的方法。
- 名词分析
- 行为分析
- CRC
- 行为契约（OCL）
- 类型
- 表达式
- 保留关键字 Operation 操作 Reference 引用 Invariant 不变量 Precondition 前置条件 Postcondition 后置条件
- 给定描述，通过建模发现问题并提出修正方案
###思考题
- 规格说明的基本特征
引言 总体描述 详细需求描述
- 第15章所有思考题
###案例题
- 优秀规格说明特点
- 完备性 + 描述了用户的所有有意义的需求，包括功能、性能、约束、质量属性和对外接口。 + 定义了软件对所有情况的所有实际输入（无论有效输入还是无效输入）的响应。 + 为文档中的所有插图、图、表和术语、度量单位的定义提供了完整的引用和标记。
- 一致性 + 细节的需求不能同高层次的需求相冲突，例如系统需求不能和业务需求、用户需求互相矛 + 同一层次的不同需求之间也不能互相冲突。
- 根据重要性和稳定性分级
- 可修改
- 可跟踪 + 能找到需求的来源，例如和更早期文档的显式关联。 + 能找到需求所对应的设计单元、实现源代码和测试用例等，它要求每个需求都要有唯一的标识或者可供引用的名称。
###思考题 第16章思考题
- 测试用例套件
###思考题 第17章思考题
- 维护活动：状态维护
- 需求跟踪
- 需求变更