软件的设计需求分析.ppt

需求分析 福州大学 软件学院 张舒 本章主要内容 软件需求分析的任务和过程 结构化分析方法 原型化方法 动态分析方法 数据及数据库需求 需求（Requirements) 定义:需求是关于系统将要完成什么工作(what)的一段描述语句,是指用户或者客户对要开发的软件系统的要求。 它们必须经过所有相关人员的认可,其目的是彻底解决客户的问题。 需求的内容在“问题定义”中描述（可能是招标文件）。 需求分析 指开发人员为了准确地理解和表达用户要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式功能规约（需求规格说明）的过程。 准确地回答“系统必须做什么？” 软件需求分析的目标 确定系统的综合要求 确定系统功能、性能、运行等方面要求 对将来可能提出的要求做准备 分析系统的数据要求 考虑数据、数据处理 导出系统逻辑模型 通常用数据流图表示 修正系统开发计划 对系统成本、进度有更精确的估算 总之，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。 需求分析的重要性 “构建一个软件系统最困难的部分是确定构建什么。其他部分工作不会像这部分工作一样，在出错之后会如此严重的影响随后实现的系统，并且在以后修补竟会如此的困难。” －－Fred Brooks 问题： 对于任何项目是否一定要严格执行全面的需求分析呢？ 需求分析的过程 (1) 问题识别 确定对目标系统的综合要求，即软件的需求 提出这些需求实现条件，以及需求应达到的标准 软件的需求包括： 功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求 资源使用需求 成本消耗需求 开发进度需求 预先估计以后系统可能达到的目标 问题识别的另一项工作是建立分析所需要的通信途径，以保证能顺利地对问题进行分析。 (2) 分析与综合 基本思想： 从信息流和信息结构出发，逐步细化所有的软件功能， 找出系统各元素之间的联系、接口特性和设计上的约束，分析它们是否满足功能要求，是否合理。 剔除其不合理的部分，增加其需要部分，最终综合成系统的解决方案，给出目标系统的详细逻辑模型。 常用的分析方法 功能分析法 将系统看作若干功能模块的集合，进行子功能分解，最终形成系统雏形。 结构化分析法 面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 (DSSD) 常用的分析方法 信息建模法 借助各种有序模型（功能、信息、数据、控制、决策等），来分析系统。常用工具：E－R图 面向对象的分析方法 (OOA) 识别问题域内对象，及其之间的联系，并建立模型 (3) 编制需求分析阶段的文档 软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 (4) 需求分析评审 系统定义的目标是否与用户的要求一致; 系统需求分析阶段提供的文档资料是否齐全; 文档中的所有描述是否完整、清晰、准确反映用户要求; 与所有其它系统成分的重要接口是否都已经描述; 被开发项目的数据流与数据结构是否足够确定; 所有图表是否清楚，在不补充说明时能否理解; 主要功能是否已包括在规定的软件范围之内，是否都已充分说明; 设计的约束条件或限制条件是否符合实际; 开发的技术风险是什么; 是否考虑过软件需求的其它方案; 是否考虑过将来可能会提出的软件需求; 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认; 需求分析过程的任务 可以概括为7个不同的活动： 起始 导出 精化 协商 规格说明 确认 管理 起始 通常是在确定了商业要求或者发现新市场、新服务时，项目才开始， 相关人员会进行粗略的可行性分析、并确定项目范围后开始。 导出需求 看似简单： 询问客户，系统或者产品的主要目标是什么？ 想要实现什么？ 产品如何满足业务要求，如何用于日常工作？ 实则困难 为何导出需求十分困难？ 范围问题 系统边界不清楚，客户或者用户的说明带有多余的技术细节，可能混淆系统整体目标 理解问题 用户不能完全确定需要什么，在与工程师沟通过程中有问题。需求之间还可能存在冲突。 易变问题 需求随时间变化 可采取的解决办法 发掘需求 克服企业背景对需求工程的影响 克服方法不当对需求工程的影响。 克服受访谈者对需求工程的影响。 克服就项目论项目对需求工程的影响。  限制需求 不能头脑发热 认清真正的需求 定义需求的边界 引导需求 控制需求 精化 是一个分析建模动作，由一系列的建模和求精任务构成。 最终形成一个分析模型，定义了问题的信息域、功能域和行为域。 协商 通过协商来调解需