03 软件需求工程

1需求工程软件工程（SoftwareEngineering）2通过对问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。软件需求作为软件生命周期的一个阶段，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域——需求工程。90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE），1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。3内容摘要1.什么是需求工程？2.什么是软件需求工程？3.软件需求的重要性4.软件需求的困难5.软件需求内容6.需求工程的活动41)需求的基本概念–宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。–软件需求——是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。2)需求工程(RE)的概念–是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。–需求分析专家AlanDavis把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”–RE通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。1什么是需求工程52.什么是软件需求工程？•需求工程RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。•软件需求工程——是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。6软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。需求的重要性–FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：•开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。–需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。–国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。3.软件需求的重要性73.软件需求的重要性美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。完成并实施完成未实施未完成分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。未完成完成未实施完成84.软件需求的困难软件需求是软件工程中最复杂的过程之一：•应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。•非功能性需求建模技术的缺乏及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。•沟通上的困难，由于系统需求分析各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。–客户说不清楚需求；–需求自身经常变动；–分析人员或客户理解有误。9真正的软件需求获取如此困难（漫画）10需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需求和软件能力之间的桥梁。需求工程系统目标系统服务软件约束运行环境5.软件需求内容11软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出软件需求的内容5.软件需求内容12功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。领域需求是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。13非功能需求产品需求机构需求外部需求互操作需求道德需求立法需求性能需求空间需求交付需求实现需求标准需求隐私需求安全性需求可用性需求效率需求可靠性需求可移植性需求非功能需求14因此系统应该具备以下功能：⑴基本数据维护功能⑵基本业务功能⑶数据库管理功能⑷信息查询功能例1：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。151.功能需求⑴基本数据维护功能：提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。⑵基本业务功能：读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，可以进行书籍的编目、入库、更新等操作。16⑶数据库管理功能：对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。⑷信息查询功能：提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。172.非功能需求①系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。②对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。③对系统查询速度的需求：要求系统在20S之内响应查询服务请求。④对系统可靠性的需求：要求系统失败发生率小于1%。183.领域需求例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：⑴图书编目要求按照《中国图书馆分类法》进行；⑵由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。19HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。……6.需求工程的活动20需求工程中的活动可分为两大类:一、需求开发二、需求管理6.需求工程的活动21一、需求开发需求开发的任务是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用《需求规格说明书》规范的形式准确地表达用户的需求。需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。（1）需求获取的目的是深入实际，通过各种途径,在充分理解用户需求的基础上，获取用户的需求信息。（2）需求分析、协商与建模的目的是对各种需求信息进行分析，消除错误，刻画细节等。（3）需求规格说明目的是根据需求获取和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。（4）需求验证是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。确保需求说明准确、完整地表达系统的主要特性。22需求获取是需求工程的主体,非常困难，主要原因有：●缺乏领域知识,应用领域的问题常常是模糊的、不精确的；●存在默认的知识,如难以描述的常识问题；●存在多个知识源,且多知识源之间可能有冲突；●客户可能的偏见，如不能提供或不想告知你所需要了解的事情。(一)、需求获取(requirementelicitation)23需求获取技术1.面谈法重要而直接，简单的需求获取技术。2.问卷法调查法是对面谈法的补充。3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法还有知识工程方法等如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；2）面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。24需求获取技术1.面谈法重要而直接，简单的需求获取技术。2.问卷法调查法是对面谈法的补充。3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法是从多个用户中收集需求信息的有效方式，一般问卷设计形式：1）多项选择问题；2）评分问题；3）排序问题。25需求获取技术1.面谈法重要而直接，简单的需求获取技术。2.问卷法调查法是对面谈法的补充。3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法由开发方和用户方共同召开,操作步骤：①开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；②会后开发方整理出《需求调研记录》提交给用户方确认；③如果此主题还有未明确的问题则再次沟通,否则开始下一主题；④所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。26需求分析阶段主要对收集到的需求进行提炼、分析和认真审查，进行需求建模、对模型或原型进行分析。确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立完整的分析模型。(二)、需求分析、协商与建模271、确定系统的综合要求系统功能要求—这是最主要的需求，确定系统必须完成的所有功能。系统性能要求—应就具体系统而定，例如可靠性、联机系统的响应时间、存储容量、安全性能等。系统运行要求—主要是对系统运行时的环境要求，如系统软件、数据库管理系统、外存和数据通信接口等。将来可能提出的要求—对将来可能提出的扩充及修改作预准备。2、分析系统的数据要求软件系统本质上是信息处理系统，因此，必须考虑：数据（需要哪些数据、数据间联系、数据性质、结构）数据处理（处理的类型、处理的逻辑功能）3、导出系统的逻辑模型。4、修正系统的开发计划—通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。需求分析、协商与建模的具体任务28当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化抽象化具体化实例化怎么做做什么当前系统目标系统需求定义需求分析的一般步骤291．必须能够表示和理解问题的信息域2．必须能够定义软件将完成的功能3．必须能够表示软件的行为(作为外部事件的结果)4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5．分析过程应该从要素信息移向细节信息需求分析操作原则30信息域•信息域：包括信息内容、信息流、以及信息结构。–信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。•例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等–信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出–信息结构表示了各种数据和控制项的内部组织•数据或控制项将被组织为n维表还是树形结构？•在结构的语境内，什么信息是和其他信息相关的？•信息包含在单个结构中，还是使用不同的结构？•在某信息结构中的信息如何和在另一个结构中的信息相关？31需求工程的指导性原则•除了上面提到的操作性分析原则，Davis提出了一组针对需求工程的指导性原则：•在开始建立分析模型前，先充分理解问题。•开发原型，使得用户能够了解如何进行人机交互。•记录每