第4讲-需求分析(1)

,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,第四讲,需求分析,1,提纲,需求工程概述,需求获取,需求分析、协商与建模,需求规约与验证,需求管理,2,需求工程概述,什么是软件需求？,用户对目标系统在功能、行为、性能等方面的要求,软件需求的本质是什么？,明确软件到底“,做什么,”，以及应具备的性能,什么是需求分析？,对软件需求的理解、分析与表达,3,功能需求与非功能需求,功能需求应明确软件的行为,非功能需求主要是约定软件的质量标准,用户需求与领域需求,用户需求：只针对某个特定用户,领域需求：针对某个行业的普遍规律,什么是需求工程？,教材,P47,运用相关技术与方法进行需求分析的过程。细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理,6,个阶段。,4,需求工程的六个阶段,5,需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理,I.,需求获取,通过与用户的交流，了解业务现状以及对待开发系统的期望,需求获取收集的,“,原始材料,”,为进行需求分析提供了基础,II.,需求分析与协商,对需求进行分类组织，分析需求之间的关系,检查需求的一致性、重叠和遗漏的情况,根据用户的需要对需求进行排序。,在需求获取阶段，经常出现以下问题：,提出的要求超出软件系统可以实现的范围或实现能力,不同的用户提出了相互冲突的需求,6,教材,P47,48,III.,系统建模,借助建模技术对获取的需求信息进行分析和表达，排除错误和弥补不足，确保需求文档正确反映用户真实意图,常用的分析和建模方法,IV.,需求规约,(Specification)(,编写文档,),通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求,软件需求规约,是分析任务的最终产物,需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用,7,V.,需求验证,(,评审,),需求开发阶段工作的复查手段,对功能的正确性、完整性和清晰性，以及其它需求给予评价,为保证软件需求定义的质量，评审应以专门指定的人员负责,(,应该是需求分析人员之外的其他人员,),，并按规程严格进行,VI.,需求管理,(,维护一致性,),一种获取、组织并记录系统需求的系统化方案：对所有需求工程相关活动的规划和总体控制,需求变更管理：一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程,(,变更的记录、分析、变更过程管理、追踪等,),8,需求确认与需求分析,都需要对系统需求中的遗漏和冲突进行识别和分析,区别,需求分析处理的是未整理的原始需求，此时发现的问题是客户的问题,需求确认的对象是经分析后形成的需求规格说明，此时发现的问题是需求分析人员的问题，此外还需要考虑需求文档是否满足相应的质量标准,9,在实际的开发中，这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是,交叉的,、,递增的,和,反复的,。,10,需求获取,具体的每一种需求,需求获取方法,11,具体每一种需求,功能需求：,功能,（,1,）系统将做什么？,（,2,）系统什么时候做？,（,3,）有多种操作模式吗？,（,4,）必须执行什么种类的计算或数据转换？,（,5,）对可能发生的激励事件的反应是什么？,数据,（,1,）输入、输出数据的格式应该是什么？,（,2,）在任何时间都必须保留任何数据吗？,12,过程约束,资源,（,1,）构造系统需要哪些材料、人员或其他资源？,（,2,）开发人员应该具有怎样的技能？,文档,（,1,）需要多少文档？,（,2,）文档是联机的，还是印刷的，还是两种都要？,（,3,）每种文档针对哪些读者？,标准,国家标准、军用标准,13,设计约束,物理环境,（,1,）设备安放在哪里？,（,2,）在一个地方还是多个地方？,（,3,）是否有任何环境的限制，例如温度、湿度或者电磁干扰？,（,4,）是否对系统的规模有所限制？,（,5,）是否在电源、供热或空调上有所限制？,（,6,）是否会因为现有的软件构件而对编程语言所有限制？,14,接口,（,1,）输入是来自一个还是多个其他系统？,（,2,）输出是否传送到一个或多个其他系统？,（,3,）输入,/,输出数据的格式是否是预先规定的？,（,4,）数据是否必须使用规定的介质？,用户,（,1,）谁将使用系统？,（,2,）将会有几种类型的用户？,（,3,）每类用户的技术水平如何？,15,质量需求,性能,（,1,）有没有执行速度、响应时间或吞吐量的约束？,（,2,）使用什么效率测量方法测量资源使用和响应时间？,（,3,）多少数据将流经系统？,（,4,）数据接收和发送的时间间隔是多少？,可用性和人的因素,（,1,）每类用户需要什么类型的培训？,（,2,）用户理解并使用系统的难易程度如何？,（,3,）就一个系统而言，在多大程度上防止用户误用系统？,16,安全性,（,1,）必须控制对系统或信息的访问吗？,（,2,）应该将每个用户的数据和其他用户的数据隔离吗？,（,3,）应该将用户的程序和其他程序以及操作系统隔离开吗？,（,4,）要采取预防措施以防止盗窃或蓄意破坏吗？,可靠性和可用性,（,1,）系统需要检测并隔离故障吗？,（,2,）规定的平均失效间隔时间是多少？,（,3,）失效后重新启动系统允许的最大时间是多少？,（,4,）系统多久备份一次？,17,获取需求的方法,与用户建立畅通的工作机制,按照业务流程获取与分析用户需求,观察、倾听、提问,对同类型软件与同类型单位进行调研,对所获取的需求进行分析，并与用户协商,与用户组成联合小组，通过“用例”进行分析,18,开发人员眼里的用户,用户不知道他们想要什么,用户不能清楚的表明他们想要什么,用户不能够提供可用的需求陈述,用户提出含有太多政治动因的需求,用户立刻就想要一切,用户不能保持进度,用户不能对需求划分优先级,用户不愿意妥协,用户拒绝为系统负责任,用户未对开发项目全力以赴,19,用户眼里的开发人员,开发人员并不理解操作需求,开发人员不能将清晰陈述的需求转变为成功的系统,开发人员对需求定义设置不现实的标准,开发人员过于强调技术,开发人员总是迟到,开发人员不能对合法变化的需求做出及时响应,开发人员总是超出预算,开发人员总是说“不”,开发人员试图告诉我们如何做我们的本职工作,开发人员要求用户付出时间和工作量，甚至损害到用户的主要职责,20,建立顺畅的通信途径,建立分析所需要的通信途径，以保证能顺利地对问题进行分析。,21,访谈与调查,在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：,所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；,不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；,提问和回答在汇总后应能够反映用户需求的全貌,22,访谈和会议 场景,23,观察用户操作流程,到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。,24,组成联合小组,25,打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调,Facilitated Application Specification Techniques,FAST,基本原则,在中立的地点举行由开发者和用户出席的会议；,建立准备和参与会议的规则；,建议一个足够正式的议程以便可以进行自由的交流；,一个“协调者”,(,他可以是用户、开发者或其他外人,),来控制会议；,使用一种“定义机制”,(,它可以是工作表、图表、墙上胶黏纸或墙板,),；,目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。,26,需求分析原则,（,1,）必须理解和表示问题的信息域（采用数据模型）,（,2,）必须定义软件将完成的功能（采用功能模型）,（,3,）必须表示软件的行为、服务、操作（采用行为模型）,（,4,）划分子系统（分而治之）,（,5,）逐步求精,27,28,软件需求建模,关于软件建模,（,1,）软件建模与需求建模,软件模型包括：需求模型、设计模型,使用,OO,方法，上述,2,种模型可“自然延伸”,需求模型定义,以简单、准确、结构清晰的方式，描述软件需求。,模型一般使用图形方式，并要求符合相应的规范。,29,软件建模的作用？,较好的体现系统的全局，以及系统内部各种“元素”之间的联系。,能够以规范的方式进行描述。,“思考”与交流的工具。,30,几点说明,知道有哪几种模型,软件建模要明确到底使用什么方法,方法主要是结构化方法与面向对象方法，前者在需求分析阶段所使用的是“数据流方法”,采用不同的方法，应使用不同的模型需求,无论采用哪种方法，都要求描述系统的数据、功能与行为。,31,各种模型,词汇,说明,数据对象、属性与关系,一般较少使用，不同于面向对象方法的“对象”与“类”，留意教材的论述,E-R,图,结构化方法，一般在软件设计阶段使用,功能模型,采用数据流图，属于结构化方法，同时具有描述数据的作用,行为模型,教材主要介绍状态图，此外，使用流程图、伪代码、判定树等方法描述数据流图的“数据加工”，也具有描述“行为”的作用,数据字典,与数据流图配合使用，属于数据模型，对数据加工的说明也具有描述“行为”的作用,面向对象模型,UML,面向对象分析与设计课程,业务流程图,对于业务流程复杂的软件，流程图是相对直观、便于双方交流的描述工具，有助于准确理解用户需求，但是，从软件需求分析的角度，需要进一步抽象到更高层次的模型,32,注意：,数据模型、功能模型、行为模型需要配合使用，不能简单的截然分开。,33,需求规格说明,什么是需求规格说明？,对软件需求的书面描述，是需求分析阶段的最终产物。,需求规格说明书的用途,用户,：确认所描述的是否是“自己要开发的软件”,软件开发人员,：做为软件设计与测试的依据,双方,：将来验收所开发软件的依据。,34,需求规格说明的内容,教材模型 提供的模板,需求规格说明的核心内容是什么？,最基本内容是什么？,（,1,）通过模型描述软件的功能、数据与行为,（,2,）软件的运行环境,（,3,）与其它软件系统的接口,（,4,）必要的非功能约定,35,对需求规格说明的评审,评审指标：,（,1,）正确性。需求规格说明的功能、行为、性能描述等，必须与用户对目标软件产品的期望相稳合。,（,2,）无歧义性。对于用户、分析人员、设计人员和测试人员，对需求规格说明书中的任何语法单位只能有唯一的解释。,（,3,）完备性。需求规格说明书不能遗漏任何用户需求。,（,4,）可验证性。对于需求规格说明中的任意需求，均存在技术和经济可行的手段进行验证和确认。,36,（,5,）一致性。需求规格说明的各部分之间不能相互矛盾。,（,6,）可理解性。软件需求规格说明对于用户、设计人员和测试人员等是否容易理解。,（,7,）可修改性。需求规格说明的格式和组织方式应该容易修改，能比较容易的接纳后续的增加、删除和修改，并使修改后能够较好地保持其他各项属性。,（,8,）可追踪性。需求规格说明必须将分析后获得的每一项需求与用户的原始需求联系起来。,37,具体评审内容：,（,1,）系统定义的目标是否与用户的要求一致？,（,2,）系统需求分析提供的文档资料是否齐全？,（,3,）文档中的所有描述是否完整、清晰、准确反映了用户要求？,（,4,）与所有其他系统成分的重要接口是否都已经描述？,（,5,）所开发项目的数据流与数据结构是否足够，是否确定？,38,（,6,）所有图表是否清楚，在没有补充说明时是否易于理解？,（,7,）主要功能是否已包括在规定的软件范围之内，是否都已充分说明？,（,8,）设计的约束条件或限制条件是否符合实际？,（,9,）开发的技术风险是什么？,（,10,）是否考虑过软件需求的其