第四章 软件需求工程1012.ppt

第四章 软件需求工程 软件工程课件 第四章 软件需求工程 4.1 软件需求工程基础 4.2 软件需求获取 4.3 传统的需求分析方法 4.4 面向对象的需求分析 4.5 快速原型化方法 4.6 软件需求规格说明 4.7 软件需求评审 4.8 软件需求管理 4.1 软件需求工程基础 软件需求工程的基本任务是准确地回答“软件系统必须做什么？”这个问题。它在系统工程和软件设计之间起到桥梁的作用。 软件需求工程是软件生存周期中重要的一步，也是决定性的一步。只有通过软件需求工程的活动才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。 软件需求的定义和层次 1997年IEEE在《软件工程标准词汇表》对需求（requirement）所作出的定义为： 用户为解决某一问题或为达到某个目标所需要的条件或能力。（需方） 系统或系统部件为满足合同、标准、规格说明或其他正式的强制性文档所必须具有的条件或能力。（供方） 对在a) 和b) 中所描述的条件或能力的文档化说明。 GB／T 11457―2006《信息技术 软件工程术语》等同采用了这个定义。它从两个方面阐述了需求的含义： 从用户角度要求系统应具有的外部行为 从开发者角度要求系统应具有的内部特性 最后强调了需求一定要文档化。 软件需求包括 3 个不同的层次：业务需求、用户需求、功能需求和非功能需求。 不同层次是从不同角度与不同程度反映着细节问题。 业务需求（Business Requirement） 用户需求（user Requirement） 用户需求描述了要求系统必须完成的任务，即用户对系统的目标要求。 用户需求通常只涉及系统的外部可见行为，不涉及系统的内部特性。 用户需要是用户真正需要的东西，用户需求是用户对其需要的一种陈述，但这种陈述可能与它们的需要不一致。 用户需求一般采用自然语言和直观图形相结合的方式描述，例如采用用例（Use Case）文档或场景（Scenario）等方式说明。 功能需求和非功能需求 功能需求定义了开发者应提供的软件功能或服务，但不涉及这些功能或服务的实现。 非功能需求则是对功能需求的补充，包括了对系统的各种限制和用户对系统的质量要求。 特性是指逻辑上相关的功能需求的集合以满足业务需求。 功能需求记录在软件需求规格说明（SRS）中。 非功能需求的描述如下： 系统需求 系统需求来自于系统分析和结构设计。 例如，有一个电信计费系统，它包括许多业务规则，这些业务规则与企业方针、政府条例、会计准则、计算方法有关，它们本身并非软件需求，因为它们不属于任何特定的软件系统的范围，它们属于系统需求。 各种需求的关系 所有的用户需求必须与业务需求一致。 功能需求必须从用户需求中提取，以满足用户对产品的要求从而完成其任务。 开发人员应根据功能需求来设计软件以实现必须的功能。功能需求从外部（用户角度）描述了软件系统所应具有的行为。 对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集。 非功能需求作为功能需求的补充，包括 产品必须遵从的标准、规范和合约； 外部接口的具体细节； 性能要求； 设计或实现的约束条件及质量属性。 约束是指在软件产品设计和构造上的限制。 质量属性是通过多种角度对产品的特点进行描述。 多角度描述产品对用户和开发者都极为重要。 软件需求工程过程 软件需求工程阶段研究的对象是软件项目的用户需要。需要注意的是， 必须全面地理解用户的各种需求 分析和澄清模糊的用户需求 准确地表达被接受的用户需求 只有经过确切描述的软件需求才能成为软件设计的基础。 软件需求工程需要执行的活动包括： 1) 确定目标系统将要面对的各类用户； 2) 从各类用户的代表那里收集需求； 3) 了解用户的任务和目标，以及这些任务要实现的业务目标； 4) 分析从用户那里得到的信息，将用户的任务和目标与软件的功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来； 5) 将顶层的需求分配到软件系统构架内定义好的软件成分中； 6) 了解各个质量属性的相对重要性； 8) 协商需求的实现优先级； 9) 将收集的用户需求表述为书面的需求规格说明和模型； 10) 审阅需求文档，以确保在认识上与用户需求相一致。应在开发组接受需求之前解决所有分岐。 软件开发的目标是实现目标系统的物理模型，即确定待开发系统的各种软件成分，并将功能和信息结构分配到这些软件成分中。但是目标系统的具体物理模型是由当前系统的具体物理模型经过一系列的转换得到的。 软件需求工程的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统 “做什么” 的问题。 Abran和Moore的软件需求工程过程模型（未包括需求管理） 需求获取（获取哪些内容？） 1) 定义需