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