协商与建模需求规约与验证需求管理-Read课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,制作者,程丽,软件工程,第二章 需求工程,本章介绍以下内容,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,课程的任务、目的和基本要求,掌握可行性分析的方法,掌握需求工程的定义及六个阶段,掌握软件需求内容,掌握需求获取的方法与策略,掌握需求分析原则,掌握需求规约的原则,掌握需求规约的内容,了解需求验证过程,了解需求管理相关概念,接下来介绍,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,可行性研究的任务,可行性研究的具体步骤,系统流程图,成本效益分析,方案的选择和折衷,可行性分析的结论,可行性研究的文档,可行性分析,提出问题,有无解决的办法,是否值得去做,可行性研究的目的,可行性研究的任务,技术可行性,确定技术风险，项目实现的可能性,经济可行性,考虑投入,产出，市场前景，经营策略,社会可行性,考虑合同、责任、侵权、用户组织的管理模式及规范问题,可行性研究的步骤,确定项目规模和目标,研究正在运行的系统系统流程图,建立新系统的高层逻辑模型简单数据流图,导出和评价各种方案,推荐可行的方案,编写可行性研究报告，交使用部门审查,用,图形符号描述项目处理流程、范围和功能,处理 输入,/,输出,连接 换页连接,数据流 文档,联机存储 磁盘,显示 人工输入,人工操作 辅助操作,通信链路,系统流程图,工资处理过程：,每月末,教师,把他们当月实际授课时数登记在,课时表,上，由各系汇总后交给财务科。,职工,把他们当月完成承包任务的情况登记在,任务表,上，汇总后交给财务科。,会计根据这些原始数据计算每名教职工的工资，编制工资表、工资明细表。然后，把记有每名教职工工资总额的,工资表,报送,银行,，由银行把钱打到每名教职工的工资存折上，同时把,工资明细表,发给每名教,职工,。,例子：人工系统计算工资和编制报表,教师,课时表,任务表,职工,工资支付系统,工资表,工资明细表,银行,教师,职工,成本效益分析,效益表现,有形效益：,无形效益：,货币的时间价值、投资回收期、纯收入,从性质上、心理上进行衡量,货币的时间价值,F=P*(1+n*i) (,不计复利,),P=F/(1+n*i),i-,利率,P-,现在值（元）,n-,年数,F-,将来值（元）,成本效益分析,成本效益分析,投资回收期,使累计的经济效益等于最初投资费用所需的时间,投资回收期越短，就越快获得利润,纯收入,整个生存周期之内的累计经济效益（折合成现在值）与投资之差,一个系统可以有多个可行的实现方案，每个方案对成本、时间、人员、技术、设备都有不同的要求，不同方案开发出来的系统在功能、性能方面也会有所不同。因此要在多个可行的实现方案中作出选择。,由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约。,如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。因此，在必要时应进行折衷。,方案的选择和折衷,可行性分析的结论,可以立即开始进行,需要推迟到某些条件（例如资金、人力、设备等）落实之后才能开始进行,需要对开发目标进行某些修改之后才能开始进行,因为某种原因（如，技术不成熟、经济上不合算等）不能进行,可行性研究的文档,在可行性研究后提交的文档，包括,引言,可行性研究前提,对现有系统的分析,所建议的系统,可选择的其它系统方案,投资及效益分析,社会因素方面的可行性分析,结论,接下来介绍,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,软件需求工程细分为,需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理,需求工程,需求获取,系统分析人员与用户交流，对现有系统观察，对任务进行分析，确定系统或产品的范围，与系统或产品有关的人员及特征，系统的技术环境，系统功能，应用于每个需求的领域限制，一组描述不同运行条件下系统或产品使用状况的应用场景。,需求分析与协商,需求获取结束后，分析活动对需求进行分类组织，分析每个需求与其它需求的关系，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。,在需求获取阶段，经常出现以下问题：,用户提出的要求超出软件系统可以实现的范围或实现能力；,不同的用户提出了相互冲突的需求,系统建模,建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。,常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。,需求规约,软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。,需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。,需求验证,作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。,在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。,需求管理,需求工程包括获取、分析、规定、验证和管理软件需求，而,“,软件需求管理,”,则是对所有相关活动的规划和控制。,换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。,接下来介绍,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,软件需求包括,功能需求,性能需求,用户或人的因素,环境需求,界面需求,文档需求,数据需求,资源使用需求,安全保密要求,可靠性需求,软件成本消耗与开发进度需求,其他非功能性要求,需求获取方法与策略,建立顺畅的通信途径,访谈与调查,观察用户操作流程,组成联合小组,用况,（,Use Case,）,建立顺畅的通信途径,建立分析所需要的通信途径，以保证能顺利地对问题进行分析。,访谈与调查,在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：,所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；,不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；,提问和回答在汇总后应能够反映用户需求的全貌。,例：,“,赛艇比赛成绩计算系统,”,的第一次面谈的准备计划,初次与,Dartchurch,航行俱乐部的航行秘书（,DR,）接触，面谈有关事宜。,(,在电话交谈时，了解到他们希望得到的是一个“价廉”的，基于,PC,的系统，以用于计算赛艇比赛成绩,),时间：,2005-6-5,地点：对方场地,主要问题,确定基本问题。,确定,DR,的角色,还涉及其它人员吗？,调查财物方面事宜。,系统（大致上）是如何运作的？,当前存在的问题是什么？,他们都希望做些什么？,观察用户操作流程,到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。,组成联合小组,便利的应用规约技术,(Facilitated Application Specification Techniques , FAST),：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调,FAST,基本原则,在中立的地点举行由开发者和用户出席的会议；,建立准备和参与会议的规则；,建议一个足够正式的议程以便可以进行自由的交流；,一个,“,协调者,”,(,他可以是用户、开发者或其他外人,),来控制会议；,使用一种,“,定义机制,”,(,它可以是工作表、图表、墙上胶黏纸或墙板,),；,目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。,FAST,会议 步骤,1),当举行了开发者和用户之间的初步访谈后，确定一个,FAST,会议的时间地点，并在会议日之前将产品请求发布给所有的与会者。,2),要求每个,FAST,出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表,(,如，成本、规模大小、权重,),和性能标准列表,(,如，速度、精度,),。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。,3),进行,FAST,会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品。,FAST,会议 步骤,(,续,),4),一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的,FAST,出席者讨论，进行添加、删除或进一步的精化等工作。（在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。）,5),在小规约完成后，每个,FAST,的出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。,用况,（,Use Case,）,当需求作为非正式会议、,Fast,的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。,创建用况模型的主要步骤如下：,确定谁会直接使用该系统，即参与者（,Actor,）,选取其中一个参与者,定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况,对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程,描述该用况的基本过程,接下来介绍,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,需求分析原则,1,必须能够表示和理解问题的信息域,2,必须能够定义软件将完成的功能,3,必须能够表示软件的行为,(,作为外部事件的结果,),4,必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节,5,分析过程应该从要素信息移向细节信息,为什么要引入信息域？,所有的软件应用程序均可被称为数据处理。如：工资系统的批处理软件，开发控制汽车发动机油流的实时嵌入式软件。,将数据从一种形式变换为另一种形式,对事件的处理也不例外。例如，压力传感器检测压力是否超过安全值，并发送警报到监控软件，警报信号是一个事件，该事件控制系统的行为。,因此，数据,(,数值、字符、图象、声音等,),和控制,(,事件,),二者均驻留于问题的信息域内。,信息域,信息域：包括信息内容、信息流、以及信息结构。,信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。,例如，数据对象,“,工资,”,是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等,信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息,(,数据和,/,或控制,),，然后进一步被变换为输出,信息结构表示了各种数据和控制项的内部组织,数据或控制项将被组织为,n,维表还是树形结构？,在结构的语境内，什么信息是和其他信息相关的？,信息包含在单个结构中，还是使用不同的结构？,在某信息结构中的信息如何和在另一个结构中的信息相关？,信息域,抽象、分解与多视点分析,问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的,一般,-,特殊关系,首先关注一般问题的解决途径，进而指导特殊问题的解决方法。,问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。,较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析,分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分,例如,横向分解,纵向分解,需求协商,协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案,协商不是简单的逻辑或技术上的争论,要注意组织和行政方面的因素,不一致的目标,责任的丧失或转移,组织文化,组织管理态度和士气,部门差异,通常会议是解决冲突最快的方式,参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员,会议应该讨论那些非正式讨论不能解决的问题,通常会议分为三个阶段：,叙述阶段,讨论阶段,决策阶段,需求建模,在软件需求分析阶段，所创建的模型，要着重于描述系统要,做什么,，而不是,如何去做,目标软件的模型不应涉及软件实现细节,常用的分析方法：,面向数据流的结构化分析方法,(SA),面向数据结构的分析方法,面向对象的分析方法,(OOA),接下来介绍,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,需求规约的原则,1,从现实中分离功能，即描述要,“,做什么,”,而不是,“,怎样实现,”,。,2,要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到,“,做什么,”,的规约。,3,如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。,4,规约必须包括系统运行环境。,需求规约的原则,(,续,),5,规约必须是一个认识模型，而不是设计或实现的模型。,6,规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。,7,规约必须允许不完备性并允许扩充。,8,规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。,需求规约,.,引言,A.,系统参考文献,B.,整体描述,C.,软件项目约束,.,信息描述,A.,信息内容表示,B.,信息流表示：,数据流,控制流,.,功能描述,A.,功能划分,B.,功能描述：,处理说明,限制局限,性能需求,设计约束,支撑图,C.,控制描述,控制规约,设计约束,.,行为描述,A.,系统状态,B.,事件和响应,.,检验标准,A.,性能范围,B.,测试种类,C.,期望的软件响应,D.,特殊的考虑,.,参考书目,.,附录,引言,陈述软件目标，在基于计算机的系统语境内进行描述。,信息描述,给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。,功能描述,描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。,需求规约,行为描述,描述作为外部事件和内部产生的控制特征的软件操作。,检验标准,描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是,“,确认测试,”,的基础。,参考书目,包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。,附录,包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。,需求规约,需求描述,我们的研究表明，家庭安全系统的市场正以每年,40,的比率增长，我们希望能进入该市场，并试图建造基于微处理器的家庭安全系统，该系统将保护和,/,或识别一系列出人意料之外的“情况”，如非法进入、火警、水灾或其他。该产品，暂时称为,SafeHome,，产品将使用合适的传感器来检测各种情况，具体使用时房主可按需要编程，并且当系统检测到情况时，会自动地给监控机构拨打电话。,提出话题列表,为,SafeHome,描述的对象可能包括：,若干烟雾检测器,若干窗口和门传感器,若干运动检测器,一个警报器,一个事件,(,启动某传感器,),一个控制模板,一个显示器,一串电话号码,一次电话拨号等等。,提出话题列表,服务的列表可能包括：,设置警报器,设置监控传感器,电话拨号,控制面板编程,读显示器,(,注意，服务作用于对象,),系统的制造成本必须低于,200,万美元，界面必须是友好的，以及必须是和标准电话线接口,),性能标准,应该在一秒钟之内识别传感器事件,应该实现事件优先级模式。,产生小规约,SafeHome,中的对象“控制面板”的小规约可能是：,安装在墙纸上。,大小大约为,95,英寸。,包含标准的,12,键键盘和特殊键。,包含,LCD,显示，操作如草图所示,(,未在此给出,),。,所有的客户交互通过键盘发生，键盘被用于启动或关闭系统。,连接提供交互指南、回显等的软件到所有的传感器。,撰写完整规约,在小规约完成后，每个,FAST,的出席者提出一个针对产品,/,系统的确切标准列表,将该列表提交给团队,创建一个意见一致的确定标准列表,一个或多个参与者,(,或外来者,),被赋予撰写完整的规约草案的任务,(,用来自,FAST,会议的结果为输入,),。,需求工程的指导性原则,在开始建立分析模型前先理解问题。,开发原型，使得用户能够了解将如何发生人机交互。,记录每个需求的起源及原因。,使用多个需求视图。,给需求赋予优先级。,努力删除含糊性。,需求验证,需求验证目的是要检验需求是否能够反映用户的意愿,需求验证,评审人员评审时往往需要检查以下内容：,系统定义的目标是否与用户的要求一致；,系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；,被开发项目的数据流与数据结构是否确定且充足；,主要功能是否已包括在规定的软件范围之内，是否都已充分说明；,设计的约束条件或限制条件是否符合实际；,开发的技术风险是什么；,是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。,接下来介绍,可行性分析,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,需求管理,需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动,需求跟踪有两种方式，正向跟踪与逆向跟踪,正向跟踪：以用户需求为切入点，检查,需求规约,中的每个需求是否都能在后继工作产品中找到对应点,逆向跟踪：检查设计文档、代码、测试用况等工作产品是否都能在,需求规约,中找到出处,作业,教材,45,页，第,3,题,教材,61,页：,2,、,8,、,9,（第一问）,Thank You !,