03 软件需求工程

需求工程软件工程（SoftwareEngineering）1通过对问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格 说明 关于失联党员情况说明岗位说明总经理岗位说明书会计岗位说明书行政主管岗位说明书 ，这一系列的活动即构成软件开发生命周期的需求分析阶段。软件需求作为软件生命周期的一个阶段，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域——需求工程。90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE），1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。2内容摘要1.什么是需求工程？2.什么是软件需求工程？3.软件需求的重要性4.软件需求的困难5.软件需求内容6.需求工程的活动31)需求的基本概念宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。软件需求——是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。2)需求工程(RE)的概念是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。需求分析专家AlanDavis把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”RE通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。1什么是需求工程42.什么是软件需求工程？需求工程RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。软件需求工程——是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。5软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。需求的重要性FrederickBrooks在他1987年经典文章“NoSilverBullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。3.软件需求的重要性63.软件需求的重要性美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。未完成完成未实施完成74.软件需求的困难软件需求是软件工程中最复杂的过程之一：应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。非功能性需求建模技术的缺乏及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。沟通上的困难，由于系统需求分析各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。客户说不清楚需求；需求自身经常变动；分析人员或客户理解有误。8真正的软件需求获取如此困难（漫画）9需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需求和软件能力之间的桥梁。需求工程系统目标系统服务软件约束运行环境5.软件需求内容10软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出软件需求的内容5.软件需求内容11功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。领域需求是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。12非功能需求产品需求机构需求外部需求互操作需求道德需求立法需求性能需求空间需求交付需求实现需求 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 需求隐私需求安全性需求可用性需求效率需求可靠性需求可移植性需求非功能需求13因此系统应该具备以下功能：⑴基本数据维护功能⑵基本业务功能⑶数据库管理功能⑷信息查询功能例1：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。141.功能需求⑴基本数据维护功能：提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。⑵基本业务功能：读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，可以进行书籍的编目、入库、更新等操作。15⑶数据库管理功能：对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。⑷信息查询功能：提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。162.非功能需求①系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。②对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。③对系统查询速度的需求：要求系统在20S之内响应查询服务请求。④对系统可靠性的需求：要求系统失败发生率小于1%。173.领域需求例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：⑴图书编目要求按照《中国图书馆分类法》进行；⑵由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。18HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。……6.需求工程的活动19需求工程中的活动可分为两大类:一、需求开发二、需求管理6.需求工程的活动20一、需求开发需求开发的任务是准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用《需求规格说明书》规范的形式准确地表达用户的需求。需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。（1）需求获取的目的是深入实际，通过各种途径,在充分理解用户需求的基础上，获取用户的需求信息。（2）需求分析、协商与建模的目的是对各种需求信息进行分析，消除错误，刻画细节等。（3）需求规格说明目的是根据需求获取和需求分析的结果，进一步定义准确无误的产品需求，产生《需求规格说明书》。系统设计人员将依据《需求规格说明书》开展系统设计工作。（4）需求验证是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 效果。确保需求说明准确、完整地表达系统的主要特性。21需求获取是需求工程的主体,非常困难，主要原因有：●缺乏领域知识,应用领域的问题常常是模糊的、不精确的；●存在默认的知识,如难以描述的常识问题；●存在多个知识源,且多知识源之间可能有冲突；●客户可能的偏见，如不能提供或不想告知你所需要了解的事情。(一)、需求获取(requirementelicitation)22需求获取技术1.面谈法重要而直接，简单的需求获取技术。2.问卷法调查法是对面谈法的补充。3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法还有知识工程方法等如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；2）面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。23需求获取技术1.面谈法重要而直接，简单的需求获取技术。2.问卷法调查法是对面谈法的补充。3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法是从多个用户中收集需求信息的有效方式，一般问卷设计形式：1）多项选择问题；2）评分问题；3）排序问题。24需求获取技术1.面谈法重要而直接，简单的需求获取技术。2.问卷法调查法是对面谈法的补充。3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法由开发方和用户方共同召开,操作步骤：①开发方根据双方制定的《需求调研 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 》召开相关需求主题沟通会；②会后开发方整理出《需求调研记录》提交给用户方确认；③如果此主题还有未明确的问题则再次沟通,否则开始下一主题；④所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。25需求分析阶段主要对收集到的需求进行提炼、分析和认真审查，进行需求建模、对模型或原型进行分析。确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立完整的分析模型。(二)、需求分析、协商与建模261、确定系统的综合要求系统功能要求—这是最主要的需求，确定系统必须完成的所有功能。系统性能要求—应就具体系统而定，例如可靠性、联机系统的响应时间、存储容量、安全性能等。系统运行要求—主要是对系统运行时的环境要求，如系统软件、数据库管理系统、外存和数据通信接口等。将来可能提出的要求—对将来可能提出的扩充及修改作预准备。2、分析系统的数据要求软件系统本质上是信息处理系统，因此，必须考虑：数据（需要哪些数据、数据间联系、数据性质、结构）数据处理（处理的类型、处理的逻辑功能）3、导出系统的逻辑模型。4、修正系统的开发计划—通过需求对系统的成本及进度有了更精确的估算，可进一步修改开发计划。需求分析、协商与建模的具体任务27当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化抽象化具体化实例化怎么做做什么当前系统目标系统需求定义需求分析的一般步骤281．必须能够表示和理解问题的信息域2．必须能够定义软件将完成的功能3．必须能够表示软件的行为(作为外部事件的结果)4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5．分析过程应该从要素信息移向细节信息需求分析操作原则29信息域信息域：包括信息内容、信息流、以及信息结构。信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出信息结构表示了各种数据和控制项的内部组织数据或控制项将被组织为n维表还是树形结构？在结构的语境内，什么信息是和其他信息相关的？信息包含在单个结构中，还是使用不同的结构？在某信息结构中的信息如何和在另一个结构中的信息相关？30需求工程的指导性原则除了上面提到的操作性分析原则，Davis提出了一组针对需求工程的指导性原则：在开始建立分析模型前，先充分理解问题。开发原型，使得用户能够了解如何进行人机交互。记录每个需求的起源及原因。使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图。给需求赋予优先级。努力删除歧义性。31常用的需求分析方法：功能分解方法面向数据流的结构化分析方法(SA)面向数据结构的分析方法信息建模法面向对象的分析方法(OOA)32功能分解方法将系统看作若干功能模块的集合，每个功能又可以分解为子功能,子功能还可继续分解,分解的结果即是系统的雏形。存在问题1.需要人工完成2.无法对描述的准确度进行验证。3.难以适应需求的变化。问题空间功能子功能映射331．客房预定系统2．前台接待系统3．前台收银系统4．帐务系统5．管家系统6．电话系统7．客历系统8．合约系统9．经理系统10．总经理系统11．密码管理系统12．报表系统13．帐务报表酒店管理系统例：按照功能分解为以下子系统：34盘存/销售系统1.0.0销售处理1.1.0盘存处理1.2.0例：盘存/销售系统，用户提出,系统应具有以下功能:①计算买主订单②准备销售报表③建立买主文件和应收帐发票④运行更新的盘存文件⑤产生托运单和包装单⑥保证库存及时订货计算销售记录1.1.1产生销售报表1.1.2核对买主贷方金额1.1.3验证库存量级1.2.1产生货运订单1.2.2执行买主汇票1.2.3产生盘存报表1.2.435结构化分析方法　结构化分析方法是面向数据流的需求分析方法，是20世纪70年代末由Yourdon,Constaintine及DeMarco等人提出和发展，并得到广泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理系统。　　SA法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。36面向对象的分析方法面向对象的分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型。信息建模法是从数据的角度对现实世界建立系统的信息模型,基本工具是ER图。是由实体、属性和关系组成的网络图。E-实体，是一个或一组对象；R-关系，实体之间联系或交互作用。37需求协商协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素①不一致的目标②责任的丧失或转移③组织文化④组织管理态度和士气⑤部门差异38通常会议是解决冲突最快的方式参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题通常会议分为三个阶段：叙述阶段讨论阶段决策阶段39需求建模在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做目标软件的模型不应涉及软件实现细节典型分析建模方法结构化分析(传统建模方法)面向对象分析40计算机世界现实世界结构化开发方法结构化分析结构化设计结构化编程OOAOODOOP面向对象开发方法模型的作用41面向对象分析模型的组成结构对象-关系模型类/对象模型对象-行为模型使用实例(UseCase)操作、属性、协作者42数据流图(DFD)E-R图状态变迁图(STD图)加工说明控制说明数据对象说明数据字典（DD）结构化分析模型的组成结构43结构化分析模型的元素数据字典(DD)：模型核心(中心库)数据流图(DFD)指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能;DFD中每个功能的描述包含在加工规约(小说明)。E-R图(ERD)状态变迁图(STD)指明作为外部事件的结果,系统将如何动作。44(三)需求规格说明(需求规约)采用原始模板，在你的组织中要为编写软件需求文档定义一种标准模板指明需求的来源为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号记录业务规范45需求规约的原则1．从现实中分离功能，即描述要“做什么”而不是“怎样实现”。2．要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。3．如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。4．规约必须包括系统运行环境。46需求规约的原则(续)5．规约必须是一个认识模型，而不是设计或实现的模型。6．规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。7．规约必须允许不完备性并允许扩充。8．规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。47需求规约IEEE/ANSI830-1993简化大纲Ⅰ.引言A.系统参考文献B.整体描述C.软件项目约束Ⅱ.信息描述A.信息内容表示B.信息流表示：ⅰ数据流ⅱ控制流Ⅲ.功能描述A.功能划分B.功能描述：ⅰ处理说明ⅱ限制∕局限ⅲ性能需求ⅳ设计约束ⅴ支撑图C.控制描述ⅰ控制规约ⅱ设计约束Ⅳ.行为描述A.系统状态B.事件和响应Ⅴ.检验标准A.性能范围B.测试种类C.期望的软件响应D.特殊的考虑Ⅵ.参考书目Ⅶ.附录48引言：陈述软件目标，在基于计算机的系统语境内进行描述。信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。行为描述：描述作为外部事件和内部产生的控制特征的软件操作。检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。49(四)、需求的有效性验证需求验证目的是要检验需求是否能够反映用户的意愿一)需求验证的重要性　１.由于需求分析是软件开发的第一阶段，直接影响后面各阶段的开发。　２.需求的可变性必须进行验证。二)需求验证的内容　1.有效性检查—指功能需求是否符合用户所提出的需求。　2.一致性检查—系统功能描述及约束是否一致。　3.完备性检查—是否包含所有系统用户的需求和约束。　4.可检验性检查—是否能设计出一组验证方法。50需求开发过程可行性研究需求获取和分析需求描述需求有效性验证可行性报告系统模型用户需求和系统需求需求文挡51二、需求管理需求管理是一组用于帮助项目组在项目进展中的任何时候去 标识 采样口标识规范化 下载危险废物标识 下载医疗器械外包装标识图下载科目一标识图大全免费下载产品包装标识下载 、控制和跟踪需求的活动需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理贯穿需求分析全过程，包括:需求管理变更控制建议变更分析影响交流合并测量需求的稳定性版本控制定义需求文档版本确定单个需求文档版本需求跟踪建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求状态跟踪定义需求状态跟踪所有需求状态52需求管理的所有活动中，最重要的是需求变更管理，包括:问题分析和变更描述变更分析和成本计算变更实现修正后的需求识别出的问题需求管理过程需要CASE(ComputerAidedSoftwareEngineering)工具支持。二、需求管理53系统分析员的主要能力在整个系统分析活动中，系统分析员起着关键的作用，其本人应该具备以下能力：熟悉计算机技术；了解用户业务领域的相关知识；能在用户和开发人员之间借助于数据概念进行交流。同时从个人素质上，分析师应善于从原始材料中抽象出逻辑概念，将其重新整理之后成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法，并善于用模型说话；能从冲突或者混淆中吸取恰当事实的能力；能弄清用户环境的能力；能为用户系统恰当配置软硬件的能力能较好地用书面和口头形式进行沟通的能力有“从树木见森林”的能力。54需求工程小结软件需求工程,是软件开发人员与用户密切配合，充分交换意见，获得对需求一致意见的过程。在开发者一方，参与工作的主要角色是系统分析员和系统工程师等，负责沟通用户和开发人员的认识和见解，起着桥梁作用。需求工程阶段的最终任务是要完成目标系统的需求规格说明，确定系统的功能、非功能需求和性能，为后阶段的开发打下基础。本阶段常用的有SA法，OOA法等。55演讲完毕，谢谢观看！