3. 需求分析.ppt

第三章 需求分析 需求分析的任务 与用户沟通获取需求的方法 分析建模与规格说明 实体-联系图 状态转换图 其他图形工具：层次方框图、Warnier、IPO 验证软件需求 3.1 需求分析的任务 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划 确定对系统的综合需求 功能需求：指定系统必须提供的服务功能。 性能需求：指定系统必须满足的约束条件，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 可靠性和可用性需求：可靠性需求定量地指定系统的可靠性；可用性量化用户可以使用系统的程度。 出错处理需求：说明系统对环境错误的响应机制。有时指对系统的潜在错误的处理方式。 接口需求：描述目标系统与其应用环境通信的格式。常见的接口需求有：用户接口需求、硬件接口需求、软件接口需求、通信接口需求。 约束：说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。 逆向需求：说明软件系统不应该做什么。逆向需求很多，但是一般仅选取能澄清真实需求且可消除可能发生的误解的逆向需求。 将来可能提出的要求：明确列出那些虽不属于当前系统开发范畴，但是可以分析将来很可能会提出来的要求。为系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。 分析系统的数据要求 原因：任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响。 方法： 建立数据模型：3.4实体-联系图 数据字典：全面准确地定义数据，缺点是不够形象直观。 图形工具：3.7层次方框图、Warnier图，辅助描绘数据结构，以提高可理解性。数据结构表示数据元素之间的逻辑关系。 数据结构规范化：系统经常使用数据库或文件长期保存数据信息。为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，需要使数据结构规范化，如3.5。 导出系统的逻辑模型 综合前面分析的结果导出系统的详细逻辑模型。 通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述系统的逻辑模型。 修正系统的开发计划 根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.2 与用户沟通获取需求的方法 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型 访谈 基本形式： 正式访谈：系统分析员将提出一些事先准备好的具体问题，与用户交谈，同时做好相应的记录。 非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。 有效方式： 发放调查表：回收并分析调查表，在有针对性的访问用户，以解决分析调查表过程中发现的新问题。 情景分析技术：所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。简单的说是在一定程度上演示系统的行为，使用户便于理解，并给予相应的评价，以进一步获得完善的用户需求。 面向数据流的自顶向下求精 图3.1 面向数据流自顶向下求精过程 分析要点： 通常把分析过程中得到的有关数据元素的信息记录在数据字典中；通过分析而补充的数据流、数据存储和处理，添加到数据流图的适当位置上；对算法的简明描述记录在IPO图中。 从输入端开始，分析员借助数据流图、数据字典和IPO图向用户解释输入数据是怎样一步一步地转变成输出数据的。用户听取分析员的报告，并及时纠正和补充分析员的认识。 简易的应用规格说明技术 一种面向团队的需求收集方法：提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。 过程： 初步的访谈：通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案 开发者和用户分别写出“产品需求” 一起开会，讨论产品需求，共同确定系统功能、系统的组成对象及其约束条件和性能标准 起草完整的软件需求规格说明书 优点： 开发者与用户不分彼此，齐心协力，密切合作； 即时讨论并求精； 有能导出规格说明的具体步骤 快速建立软件原型 原则：快速建立演示目标系统主要功能的可运行的程序。实现用户看得见的功能(例如，屏幕显示或打印报表)，省略目标系统的“隐含”功能(例如，修改文件)。 特点： 快速：尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。 容易修改：原型的“修改--试用--反馈”过程可能重复多遍。 方法与工具： 第四代技术：众多数据库查询、应用系统生成器、其他高级的非过程语言，能够快速地生成可执行的代码。 可重用的构件技术：使用一组已有的软件构件(组件)来装配(