2014PM02-软件项目需求管理解读.ppt

第2章 软件项目需求管理 2.1 需求工程 2.2 需求开发 2.3 需求管理 2.1 需求工程 2.1.1 软件需求概念 2.1.2 软件需求层次 2.1.3 软件需求质量评价 2.1.4 需求工程发展历程 2.1.5 需求工程研究内容 2.1.1 软件需求 IEEE软件工程标准词汇表(1997年)中将需求定义为： 1用户解决问题或达到目标所需的条件或能力； 2系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力； 一种反映上面(1)或(2)所描述的条件或能力的文档说明。 通过定义以下五项内容来确定一组完整的软件需求：输入、输出、功能、属性、系统环境的属性 2.1.2 软件需求层次 原始问题描述是对要解决的问题的叙述，它是软件需求的基础。 用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束。 系统需求用详细的术语给出系统要提供的服务及受到的约束。系统需求文档应该是精确的，可以为系统的实现提供依据，因而系统需求文档也称为功能描述，可能成为用户和软件开发组织之间合同的重要内容。 软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述。 原始问题描述和用户需求能够帮助供需双方在较高的抽象层次上进行交流，便于用户和开发人员之间的理解与沟通。 系统需求和软件设计描述是具体的，可以根据它们来进行编码实现，并且二者应该是足够明确和可测试的，即应该能够对系统进行测试以确认它是否实现了需求。 软件需求各组成部分关系 业务需求（business requirement） 用户需求（user requirement） 功能需求（functional requirement） 非功能需求、软件需求规格说明（software requirements specification，SRS）等。 用户需求 通过自然语言、图表、图形等工具描述系统的外部行为，尽量避免涉及系统内部的设计特性，以便没有专业技术背景的用户能看懂 用自然语言描述用户需求可能出现的问题：描述困难、需求混乱 编写用户需求应遵守的几个原则：标准的格式、使用一致的语言、使用特殊文本、尽量避免专业术语 系统需求 系统需求主要包括功能需求；功能需求描述系统所应该提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。 系统做什么？ 系统何时做什么？ 系统何时及如何修改或升级？系统需求还包括系统不应该做的事情。 非功能需求 领域需求 来源不是系统的用户， 系统应用的领域，反映了领域的特点 几个值得重视的问题 用户或人的因素:用户类型 文档需求:读者 资源需求 软件需求类型 UP（统一过程）中，需求根据FURPS+分类 Functional（功能性） Usability（可用性） Reliability（可靠性） Performance（性能） Supportability（可支持性） “+”是指一些辅助性的和次要的因素： Implementation（实现） 2.1.3软件需求质量评价 正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性 可跟踪性 可理解性 2.1.4 需求工程发展历程 需求工程是将用户非形式化需求转化为形式化需求规格说明书的过程 对应用问题及其环境进行理解与分析 为问题涉及的信息和功能建立模型 将用户需求精确化和标准化 编写需求规格说明书 … 具体需求模型【45】探讨 需求工程发展特点 对象化【需求获取，需求对象化】 形式化【提高精度】 自动化 2.1.5需求工程研究内容 是用已经证实有效的技术、方法、确定客户需求，进行需求分析，帮助分析人员理解问题并定义目标系统所有外部特征的一门科学 需求获取、需求分析、规格说明、需求验证【46】 需求管理 定义需求基线（迅速制定需求文档的主体）。 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 以一种可控制的方式将需求变更融入到项目中。 使当前的项目计划与需求一致。 基于估计变更需求所产生影响的基础上，协商新的承诺（约定）。 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 在整个项目过程中跟踪需求状态及其变更情况 需求工程——也叫做需求过程 主要责任人：项目技术经理、项目系统组负责人或系统设计师。 项目经理的责任是关注这个阶段的过程和结果。 需求开发和管理的界限 2.2 需求开发 2.2.1 需求开发活动 2.2.2 需求获取 2.2.3 需求分析 2.2.4 编写需求文档 2.2.5 需求验证 2.2.1需求开发活动 确定产品所期望的用户类。 获取每个用户类的需求。 了解实际用户任