一步步教你如何写需求分析.ppt

第三章 需求分析 第三章 需求分析 3.1 需求分析的任务及需求分析的过程 3.2 与用户沟通获取需求的方法 3.3 数据流图 3.4 实体-联系图 3.5 状态转换图 3.6 其他图形工具 3.7 验证软件需求 为了开发出真正满足用户需求的软件产品，首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提和关键，不论我们把设计和编码工作做得如何出色，不能真正满足用户需求的程序只会给用户带来失望，给开发者带来烦恼。 需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。 在需求分析的过程中，分析员和用户都起着关键的、必不可少的作用。 要建立分析所需要的通信途径，以保证能顺利地对问题进行分析。 用于需求分析的结构话分析方法必须遵守的准则： 理解并描述问题的信息域，建立数据模型 定义软件必须完成的功能，建立功能模型 描述作为外部事件结果的软件行为，建立行为模型 对三个模型进行分解，用层次的方法展示细节 3.1 需求分析的任务： 确定对系统的综合要求： 1.功能需求：必须完成的所有功能。 2. 性能需求：必须满足的定时约束或容量约束，通常包括速度(响应时间)、磁盘容量、安全性等方面的需求。 3. 可靠性和可用性需求：量化了用户可以使用系统的程度。 4. 出错处理需求：这类需求说明系统对环境错误应该怎样响应。 确定对系统的综合要求： 5. 接口需求：接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。 6. 约束：说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。 7. 逆向需求：逆向需求说明软件系统不应该做什么。 8. 将来可能提出的要求：列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。 分析系统的数据要求 软件系统本质上都是信息处理系统，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法：实体——联系图（ E-R图）。 复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典全面的定义数据。利用图形工具辅助描绘数据结构。 从数据流和数据结构出发，逐步细化软件功能，找出各元素之间的联系，接口特性和设计上的限制，给出目标系统的详细逻辑模型。 导出系统的逻辑模型： 数据流图 实体-联系图 状态转换图 数据字典 加工处理说明书等 修正系统开发计划 开发原型系统：使用户对目标系统有一个更直接、更具体的概念，从而能更准确提出用户需求。（关键的困难在于成本） 编制需求分析文档：《需求规格说明书》 任务概述：系统目标，运行环境，条件与限制 数据描述： 概念模型：E-R图 逻辑模型：数据流图 数据定义：数据字典，加工说明 数据库描述：名称和类型 功能描述：软件功能要求 性能描述：软件性能要求（处理速度、响应时间、安全限制等）。 编制需求分析文档：《需求规格说明书》（续） 运行描述：用户界面、硬件接口、软件接口、故障处理等。 质量保证：阐明软件在交付使用前需要进行的功能测试和性能测试，并且规定源程序和文档遵守的各种标准。 技术审查和管理复审 管理复审：在软件生命周期的每个重要的里程碑（一般是每个阶段计划、需求分析、设计、编码、维护）对工程项目的成本、实际花费、投资回报的前景等从管理的角度进行审查。 技术审查：在软件生命周期的每个阶段进行正式而严格的技术审查，尽量发现隐藏的错误。正式技术评审是软件工程实践者实施的一项软件质量保证活动。 评审的主要内容 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求； 与所有其它系统成分的重要接口是否都已经描述； 被开发项目的数据流与数据结构是否足够，确定； 所有图表是否清楚，在不补充说明时能否理解； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的约束条件或限制条件是否符合实际； 是否考虑了开发的技术风险； 是否考虑过软件需求的其它方案； 是否考虑过将来可能会提出的软件需求； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 有没有遗漏，重复或不一致的地方； 用户是否审查了初步的用户手册或原型； 软件开发计划中的估算是否受到了影响。 需求分析的原则 必须能够表达和理解问题的数据域和