第三讲需求工程(requirementsengineering).ppt

第三讲 需求工程（Requirements Engineering） 目 标 了解需求工程的主要活动及它们之间的关系； 掌握有关需求的基本知识； 掌握需求导出和分析的一些技术； 了解结构化分析的基础知识和基本方法； 重点掌握基于UML建模的面向对象分析方法 了解需求有效性验证及如何进行需求评审； 了解需求管理的必要性以及它如何支持其它需求工程活动。 内 容 可行性研究 需求分析基础 需求导出与分析 结构化分析基础 UML与面向对象分析方法 需求有效性验证 需求文档 需求管理 恐怖的噩梦 一个棘手的项目终于接近了尾声，作为项目经理的你坐在办公室舒展着紧张了几个月的身躯，头脑中盘算着如何让客户痛快的付清合同款。 这时，客户走进你的办公室，坐下，直视着你的眼睛 说道：“我知道你认为你理解我说的是什么，但你并不理解我所说的并不是我想要的。” 需求工程过程 需求工程过程并不具有唯一的模型，按照不同的应用领域、不同的客户与开发团队，需求工程的过程有很大的差异。 然而，在所有的过程中都会涉及一些共同的活动，它们是： 可行性研究(feasibility study)； 需求导出与分析(elicitation and analysis)； 需求描述(specification)； 需求有效性验证(validation)； 需求管理(management)。 需求工程过程 需求工程 1. 可行性研究 可行性研究要决定被提议的系统是否值得去做。 可行性研究过程较短，焦点集中在以下几个问题： 系统的开发是否符合组织的总体目标？ 系统是否可能在现有的技术和预算限制内完成？ 系统能否与已存在的其它系统相兼容？ 进行可行性研究 进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。 信息的评估与汇总需要分析人员与Stakeholders相沟通，通过提出问题汇总信息，可能提出的问题包括： 如果系统没有实现，机构将如何应对？ 当前处理过程存在哪些问题？新系统将如何处理？ 系统将对业务目标有什么直接的贡献？ 系统需要和哪些系统相集成？ 需要使用新技术吗？使用那些技术？ 2. 需求分析基础 2.1 什么是需求？ 定义不一致 需求具有双重功能：Ian Sommerville 可以作为竞标、签约的基础一种开放的、易于交流的系统功能及约束的高层概要描述； 签约之后，为了完成合同约定，开发者给出的对系统的详尽、准确的描述。 两种描述都叫做需求文档，分别对应于用户需求和系统需求。 2.2 需求的类型 用户需求 从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明。 系统需求 系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及其约束。系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的重要内容，同时作为开发工作的依据。 需求定义与描述 2.3 功能需求与非功能需求 功能需求 对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。某些情况下还要包括系统不应做什么。 非功能需求 对系统提供服务或功能时收到的约束进行描述。如时间约束、开发过程约束和标准等。 领域需求 这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非功能需求。 2.3.1 功能需求 功能需求描述系统所应提供的功能或服务。 取决于待开发软件的类型、未来的用户以及开发的系统类型。 功能性的用户需求只需要对系统应提供的服务进行高层一般描述，对于系统需求，则应该详细的描述系统功能、输入输出及异常。 功能需求描述 例：图书馆系统（ LIBSYS） 该图书馆系统要提供一个界面，使顾客能够访问多个图书馆不同的文献数据库中的资料。允许用户出于个人学习的目的对文献资料进行搜索、下载和打印。 功能需求描述 用户可以从总的数据库中进行查询，也可以从其中一个子集中查询； 系统应提供一个适当的浏览器供用户阅读馆藏资料； 每次借阅应该对应一个唯一标识符 (ORDER_ID) 。通过这个标识，可以允许用户把文献拷贝到常备存储区。 不严密问题 当需求被不严密的表述时，会产生很多问题。 一些不明确、不准确的表述可能会使用户与开发者有不同的理解。 思考上例中的短语“适当的浏览器”，如何理解？ 用户的理解 开发者的理解 需求的全面性和一致性 原则上，功能性需求描述应该具备全面性和一致性。 全面性 包括了所有用户要求的服务。 一致性 在系统服务的描述中没有冲突和矛盾 In practice, it is impossible to produce a complete and consistent requirements document. 2.3.2 非功能性需求 非功能需求不直接和功能