软件过程的需求管理教材.ppt

需求变更控制策略 项目启动阶段的变更预防 项目实施阶段的需求变更 需求一定要与投入有联系 小的需求变更也要经过正规的需求管理过程 精确的需求与范围定义并不会阻止需求的变更 注意沟通技巧 项目收尾阶段的总结 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 软件过程与项目管理 软件过程与项目管理 软件过程与项目管理 第四章 软件需求工程 需求的挑战 需求不总是很显而易见； 需求来自各个方面，涉及众多利益相关者，知识背景各不相同，知识和信息沟通困难； 涉及多学科、多领域的交叉； 需求常常不容易用文字清晰地表达； 需求固有的不一致性，主要由客观世界本身固有的矛盾性，以及利益相关者在认识现实世界上的错误所引起； 需求相互之间以及与其他可交付工件之间以多种方式相关联； 需求经常变更； 需求可能对时间敏感； 需求出错的高成本 需求阶段 0.5-1 2.5 5 10 25 100 设计阶段 单元测试阶段 编码阶段 验收测试阶段 维护阶段 The 1-10-100 Rule 软件需求的三个层次 系统需求 涉众需求 Stakeholder Needs 项目前景文档 Vision 软件需求规约 Software Requirement Spec 业务需求/产品需求 原始需求 概要需求 详细需求 软件需求的三个层次 业务需求（business requirement）反映了组织机构或客户对系统、产品的概括的目标要求； 用户需求(user requirement) 文档描述了用户使用系统而完成的任务的集合； 功能需求(functional requirement)定义了开发人员必须实现的软件功能。 软件需求的内容 功能需求（Functional requirement） 指软件产品为满足用户业务需求而必须具有的功能特性。 非功能需求（Non-functional requirement） 指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。 功能性 指与一组功能及其指定的性质有关的一组属性 适合性、准确性、依从性、安全性 软件需求的内容 可靠性 与在规定的一段时间和条件下软件维持其性能水平的能力有关的一组属性 成熟性、容错性、易恢复性 易用性 与一组规定或者潜在的用户为使用其软件所需做的努力和对这样的使用所作的评价有关的一组属性 易理解性、易学习性、易操作性 软件需求的内容 效率 指与在规定的条件下软件的性能水平与所使用资源量有关的一组属性 时间特性、资源特性 维护性 指与进行指定的修改所需的努力有关的一组属性 易分析性、易改变性、稳定性、易测试性 软件需求的内容 可移植性 指与软件可从某一环境转移到另一环境的能力有关的一组属性 适应性、易安装性、遵循性、可替换性 约束条件（Constraint Condition） 描述在设计或实现应用系统时应遵守的限制条件 精度、工具和语言约束、设计约束、硬件平台约束、使用标准约束 软件需求的内容 “FURPS+”模型 FURPS 功能性（Functional）：特性、功能、安全性； 可用性（Usability）：人性化因素、帮助、文档； 可靠性（Reliability）：故障频率、可恢复性、可预测性； 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。 + 实现（Implementation）、接口（Interface）、操作（Operation）、包装（Packaging）、授权（Legal） 不合格需求说明产生的原因 无足够用户参与 用户需求的不断增加 模棱两可的需求 不必要的特性（需求的镀金） 过于精简的规格说明 忽略了用户分类 软件需求工程 需求工程是一种获取、组织、定义、管理需求的系统方法，以使客户与项目团队对不断变更的系统需求达成并保持一致。 软件需求工程 需求开发 需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 获取数据 分析、处理 目标系统模型 需求获取 系统分析员 从数据流和数据结构出发，找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求 需求获取概述 需求获取是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。 需求获取的方法 需求研讨会 头脑风暴 用例模型 访谈 角色扮演 原型法 基于用例的需求获取 执行者的识别 谁使用系统的主要功能？ 谁将提供、使用和删除信息？ 谁负责维护、管理并保持系统正常运行？ 谁会对某一特定需求感兴趣？ 系统的外部资源是什么？ 系统需要和哪些外部系统交互？ 用例的识别 某个执行者要求系统为其提供什么功能？该执行