[工学]《软件工程》第三讲-需求分析-2.pptVIP

第3章 需求分析 3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结 目标 列举信息收集技术技巧 设计项目的E-R图 设计项目的状态转换图 了解其他图形工具 第三章 需求分析(I) 需求分析的基本任务是准确地回答“系统必须做什么?”这个问题。 确定系统必须完成哪些工作，对目标系统提出完整、准确、清晰、具体的要求。 在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书（Software Requirement Specification ），以书面形式准确地描述软件需求。 结构化分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。 3.1 需求分析的任务 3.1.1 确定对系统的综合要求 1. 功能需求 这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束，通常包括速度(响应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。 3. 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性。 可用性与可靠性密切相关，它量化了用户可以使用系统的程度。 4. 出错处理需求 这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么? 注意，上述这类错误并不是由该应用系统本身造成的。在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。 5. 接口需求 接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。 6. 约束 设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计(或实现)过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。 7. 逆向需求 逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。 8. 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。 这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？ 3.1.2 分析系统的数据要求 任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息，在很大程度上决定了系统的面貌，对软件设计有深远影响。 因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。 分析系统的数据要求，通常采用建立数据模型的方法(见3.4节)。 复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。 利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。 为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图，在本章第3.7节中将简要地介绍这两种图形工具。 软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化(见3.5节)。 3.1.3 导出系统的逻辑模型 综合上述两项分析的结果 可以导出系统的详细的逻辑模型， 通常用 数据流图、 实体-联系图、 状态转换图、 数据字典和主要的处理算法 描述这个逻辑模型。 3.1.4 修正系统开发计划 最早在什么时候制定过开发计划? 根据在分析过程中，获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。 3.2 与用户沟通获取需求的方法 主要问题 复查现有报表、表格和过程描述 观察并记录商业过程 访谈