第章需求分析.ppt

第3章 需求分析 需求分析 需求分析是软件定义时期的最后一个阶段 回答“系统必须做什么？”的问题 软件需求规格说明，以书面形式准确地描述软件需求 需求分析 需求分析方法所遵守的准则： 建立数据模型 建立功能模型 建立行为模型 对模型进行分解，用层次的方式展示细节 需求分析的重要性 需求分析的重要性 5点事实 软件生命周期中，一个错误发现得越晚，修复错误的费用越高 需求分析的重要性 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 DeMarco在一份研究报告中指出，被检查出来的错误的56％产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。 在需求阶段，代表性的错误为疏忽、不一致和二义性 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A—7E—它机上的”宅行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A—7E项目中77％的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是： 49％不正确的事实，31％疏忽，l 3％不一致，5％二义性 需求分析的重要性 需求错误是可以被检查出来的 需求分析的重要性 在需求过程中会产生很多错误。 许多错误并没有在早期被发现。 这样的错误是能够在产生的初期被检查出来的。 如果没有及时检查出来这些错误，软件费用会直线上升 需求工程 需求是什么?需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合。 需求工程一般指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述出待开发系统及其行为特征和相关约束；通常是一些过程的集合：需求获取(需求引出)、需求分析和编写软件规格说明书(SRS)及验证(包括鉴定和证实)。 需求工程涉及人员 软件需求 需求分析与程序分析的不同 需求分析现状 误解 交流障碍 缺乏共同语言 “完整性”问题 需求永远不会稳定 用户意见不统一 错误要求 认识混淆 需求分析的任务 准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 需求规格说明书 规范的形式准确地表达用户的需求。 仍然回答“What”，而不是“How”，但更细致、精确（合同的拟定） 需求分析的任务 1、确定要求 ⑴ 功能要求(functional requirements):系统必须做什么？ ⑵ 性能要求(performance requirements)：做得怎样？ 例：response time , memory , back-up memory , security , …… ⑶ 运行要求(operational requirements) ：可靠性、可用性、出错处理、接口、约束、逆向需求等。 ⑷ 未来可能的扩充要求(possible evolution)：如3维虚拟现实的效果等等。 需求分析的任务 需求获取 目的：清楚地理解所要解决的问题；完整地获取用户需求。 面临的挑战： 问题的复杂性和对问题空间理解的不完备性与 不一致性 交流障碍 需求易变性 常用方法： 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 访谈 提问 调查表 情景分析技术 对用户将来使用目标系统解决某个具体问题的方法和结果进行分析（举例）。 某出版社系统调查表1 某出版社系统调查表2 面向数据流自顶向下求精 软件系统本质上是信息处理系统，任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息 数据是分析的出发点，在可行性分析阶段许多实际的数据元素被忽略了，需求分析阶段将定义这些数据元素 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法 面向数据流自顶向下求精 面向数据流自顶向下求精 2、用户复查 数据字典准确完整吗？ 算法正确吗？ 有没有遗漏必要的处理或数据元素？ 某些数据元素是从哪里来的？…… ——构成一个循环，认识螺旋式上升 面向数据流自顶向下求精 3、细化DFD： ? 加细前后的I\O须相同。 ? 分解到须考虑具体实现的代码时即可停止 面向数据流自顶向下求精 简易的应用规格说明技术 初步的访谈 开发者和用户分别写出“产品需求” 召开会议 确定是否需要该产品 共同创建一张组合列表 分成小组，制定小型规格说明。 起草完整的软件需求规格说明书 快速建立软件原型 开发原型系统(Prototyping) 原型化方法 在开发初期，要想得到一个完整准确的规格说明不是一件容易的事。特别是对一些大型的软件项目。 用户往往对系统只有一个模糊的想法