需求工程概述.pptVIP

FAST基本原则 在中立的地点举行由开发者和用户出席的会议； 建立准备和参与会议的规则； 建议一个足够正式的议程以便可以进行自由的交流； 一个“协调者”(他可以是用户、开发者或其他外人)来控制会议； 使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)； 目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。 */63 用况(Use Case) 分析员可以根据所获取的需求创建一组标识一串待建造系统的使用场景 创建用况模型的主要步骤如下： 确定谁会直接使用该系统，即参与者（Actor） 选取其中一个参与者 定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况 对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程 描述该用况的基本过程 */63 用况的描述方法 摘要方式：简洁的一段式概要，通常用于主成功场景，例如《处理销售》 快速了解主题和范围 非正式方式：以非正式的段落方式覆盖用例中的不同场景，例如《处理退货》 进一步细化用户需求并与用户进行确认 详述方式：在需求分析阶段还将进一步细化 处理销售：顾客携带所购商品到达收银台。收银员用POS系统记录每件商品。系统逐行显示细目并显示总价。顾客输入支付信息。系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物收据并携带商品离开。 处理退货： 主成功场景： 顾客携带商品到收银台退货。收银员使用POS系统记录并处理每件退货商品。 替换场景： 如果顾客使用信用卡付款，而其信用卡账户退款交易被拒绝，则告知客户并使用现金退款。 如果…… */63 内容摘要 需求工程概述 需求获取 需求分析、协商与建模 需求规约与验证 需求管理 */63 需求分析原则 必须能够表示和理解问题的信息域(数据) 必须能够定义软件将完成的功能 必须能够表示软件的行为(作为外部事件的结果) 必须划分描述数据、功能和行为的模型(分离描述)，从而可以分层次地揭示细节 分析过程应该在基本信息基础上不断细化 */63 信息域 信息域：包括信息内容、信息流、以及信息结构 信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成 例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等 */63 信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出 例如用数据流图表示的数据加工处理的全过程 信息结构表示了各种数据和控制项的内部组织(数据之间的关系) 数据或控制项将被组织为n维表还是树形结构？ 在结构的语境内，什么信息是和其他信息相关的？ 信息包含在单个结构中，还是使用不同的结构？ 在某信息结构中的信息如何和在另一个结构中的信息相关？ */63 抽象、分解与多视点分析 问题抽象分析方法：要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系 首先关注一般问题的解决途径，进而指导特殊问题的解决方法 过程抽象：例如超市收银的总体过程包括启动销售、依次输入商品ID/数量、汇总/付款、票据打印 商品ID输入：扫描或手动输入；支付：信用卡或现金… 数据抽象：收银单包括客户ID、商品明细、总金额 超市活动期间有折扣优惠，收银条上可能需要折扣情况 */63 问题分解分析方法：以层次化的方式对问题进行分解和不断细化 较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析 分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分 典型例子：分层数据流图… 例如 横向分解 纵向分解 */63 多视点分析：尽量全面地考虑系统中不同干系人的需求和期望 例如围绕着超市收银系统 顾客希望计价过程透明、快捷 收银员希望手工输入少，减少失误 经理希望得到全面的统计分析支持 系统管理员希望提供日志功能、保障安全 最终的软件系统是相关方的综合体，各种期望可能存在冲突，需要进一步分析权衡 */63 需求协商 协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案 协商不是简单的逻辑或技术上的争论 要注意组织和行政方面的因素 不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异 */63 通常会议是解决冲突最快的方式 参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员 会议应该讨论那些非正式讨论不能解决的问题 通常会议分为三个阶段： 叙述阶段 讨论阶段 决策阶段 */63 需求建模 在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做 目标软件的模型不应涉及软件实现细节 常用的分析方法：