ch4需求分析分析.ppt

第四章 需求分析 要点： 需求分析的任务与步骤 需求获取的常用方法 分析建模 软件需求说明 两种分析技术 结构化分析技术 面向对象分析技术 需求分析 需求分析是软件定义时期的最后一个阶段 回答“系统必须做什么？”的问题 需求分析的重要性 5点事实 1.软件生命周期中，一个错误发现得越晚，修复错误的费用越高 需求分析的重要性 2. 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 3. 在需求过程中会产生很多错误 DeMarco在一份研究报告中指出，被检查出来的错误的56％产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。 4. 在需求阶段，代表性的错误为疏忽、不一致和二义性 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A—7E—它机上的”宅行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A—7E项目中77％的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是： 49％不正确的事实，31％疏忽，l 3％不一致，5％二义性 需求分析的重要性 5. 需求错误是可以被检查出来的 需求管理的困难性 需求工程涉及人员 软件需求内容梗概 需求分析与程序分析的不同 需求分析现状 误解,交流障碍 缺乏共同语言 需求永远不会稳定 用户意见不统一 错误要求 认识混淆 需求分析的任务和过程 需求分析的任务 建立分析模型 编写需求说明 需求分析的过程 需求获取 需求提炼：分析建模 需求描述：编写SRS 需求验证 需求分析的任务 可行性分析阶段已经粗略了解了用户的需求，甚至已经提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的方案。因此许多细节被忽略。 在系统开发前，还需要进一步确定 需求分析的任务 仍然回答“What”，而不是“How”， 但更细致、精确（合同的拟定） 需求分析的任务 需求分析的任务 1、确定要求 ⑴ 功能要求(functional requirements):系统必须做什么？ ⑵ 性能要求(performance requirements)：做得怎样？ 例：response time , memory , back-up memory , security , …… ⑶ 运行要求(operational requirements) ：运行环境、软硬件配置等。 ⑷ 未来可能的扩充要求(possible evolution)：如3维虚拟现实的效果等等。 需求分析的任务 需求分析的任务 5、开发原型系统(Prototyping) 需求分析的过程 需求获取的常用方法 联合分析小组 用户代表、领域专家和系统分析员 客户访谈 充分准备，寻找共同语言 循序渐进、逐步逼近 问题分析与确认 多个来回 快速原型法的应用 成本考虑 利用高级开发工具或构件组装 原型化方法 在开发初期，要想得到一个完整准确的规格说明不是一件容易的事。特别是对一些大型的软件项目。 用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求。软件开发者对于所要解决的应用问题认识更是模糊不清 随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也能随之变化；开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难，需要以改变需求来解脱困境。 因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。 为了解决这些问题，逐渐形成了软件系统的快速原型的概念。 软件原型的分类 在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。 实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。 进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。 建立快速原型好处 增进软件者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化。 使用原型化方法，可以容易地确定系统的性能，确认系统设计的可行性。 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。 可执行规格说明 基于脚本(scenario)的设计 自动程序设计 专用语言 可复用(reusable)的软件 简化假设 需求分析建模 需求分析建模 结构化分析模型 面向对象分析模型 分析模型描述工具 DFD、DD和PSPEC CFD、CSPEC和STD E-