3.1-需求分析的概念和任务.pptVIP

第三章 需求分析 第3章 需求分析 需求分析的目的 《用户需求报告》 1、需求分析的概念和任务 需求的概念 需求分析为什么重要？ 需求获取为什么难？ 需求分析的重点 需求的层次 需求分析的目标 需求分析的任务 需求分析的9项任务 画出系统的组织结构图、列出各部门的岗位角色(机构模型)。 画出系统业务操作流程图。 画出系统的数据流图，掌握业务规则，获得初步数据模型。 列出系统的功能点，即功能模型。 列出系统的性能点，即性能模型。 列出系统的接口，即接口模型。 确定系统的运行环境，即环境模型。 确定系统的界面约定，即界面模型。 对开发工期、费用、开发进度、系统风险等分析与评估。 实现步骤： 需求分析的过程 问题的识别 分析与综合 描述需求的规则 需要能够表达和理解问题的信息域和功能域 要能以层次化的方式对问题进行分解和不断细化 要给出系统的逻辑视图和物理视图 编写需求规格说明书 软件需求规格说明的规则 描述要“做什么”而不是“怎样实现” 要求使用面向处理语言说明（或称系统定义语言） 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许扩充 规格说明必须局部化和松散耦合 《用户需求报告》要点指南 《需求规格说明书》编写要点 需求管理文档 需求验证 需求分析评审的内容 系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述; 被开发项目的数据流与数据结构是否足够，确定; 所有图表是否清楚，在不补充说明时能否理解;主要功能是否已包括在规定的软件范围之内; 约束条件或限制条件是否符合实际; 开发的技术风险是什么; 是否考虑过软件需求的其它方案; 软件需求的扩充能力; 检验标准，对系统定义成功与否进行确认; 思考题1 为什么说需求获取难？ 需求分析的重点是哪些？ 需求分析的9大任务是什么？ 简述需求分析的过程？ * * 需求分析的概念和任务 获取需求的方法 需求分析方法 数据及数据库需求分析* 《需求规格说明书》 做什么? (需求分析) 从开发工作的流程来看，需求分析是软件计划的下一工作步骤，它为软件设计阶段提供一个软件需求规格说明书。 软件计划 需求分析 软件功能 软件作用范围 成本、资源估算 软件规格说明 软件开发工作流程 用户解决问题或达到目标所需的条件或权能(Capability)。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面①或②所描述的条件或权能的文档说明。 IEEE的软件工程标准词汇表对软件需求的定义： 大型系统的失败，最后均归结到需求分析. 《用户需求规格书》是一个里程碑/基线. 需求分析占软件开发工作量的30%左右. 需求获取中的错误，会发散式的传播. 用户需求具有动态性(不稳定性)。 用户需求具有模糊性(不准确性)。 对需求达成一致的艰难性。 管理体制、机构设置处在变革中。 软件书籍没有将需求分析讲清楚。 通过对业务流程和数据流程的分析，在以下四个方面与客户要达成完全一致目标。 业务模型、 功能模型、 性能模型、 接口模型。 需求分析要明确：万一需求有点变化，双方必须履行合同规定的“需求变更管理程序”。 业务需求：反映组织机构或客户对软件高层次的目标要求。这项需求是用户高层领导机构决定的，它确定了系统的目标、规模和范围。 用户需求：用户使用该软件要完成的任务。 功能需求：定义了软件必须实现的功能。 非功能需求：对功能需求的补充。 需求可分解为4个层次： 构造一个完整的、精致 的目标系统逻辑模型； 确定设计约束和定义软件有效性要求。 软件规格说明 借助当前系统的逻辑模型，调查、研究、分析、综合。 通过抽象思维、逻辑推理，导出目标系统的逻辑模型。 准确表达系统“做什么” 。 认清问题、分析资料、 建立分析模型 编写软件需求规格说明书 软件开发项目是要实现目标系统的物理模型，包括确定待开发软件系统的元素，将功能和信息结构分配到系统元素中。 逻辑模型，忽视实现机制与细节，只描述系统要完成的功能和要处理的信息。 需求分析的任务 分析现实世界，充分理解当前系统，并用一个具体模型描述，获得当前系统的物理模型。 在理解当前系统“怎么做”的基础上，抽取“做什么”的本质，抽象出系统的逻辑模型。 分析目标系统与当前系统逻辑上的差别，导出目标系统的逻辑模型。 对目标系统逻辑模型进行补充，以求完整地描述。 当前系统 逻辑模型 物理模型 目标系统 模型化 物理模型 怎么做 具体化 抽象化 逻辑模型 做什