第3章需求分析.ppt

软件工程 第三章 需求分析 获取需求 1.需求获取原则 2.需求获取技术 3.需求调研方法 4.需求获取步骤 5.需求表达与整理 6.需求确认 需求分析 1.需求分析目标 2.需求分析任务 3.需求分析方法 4.需求分析过程 3.1 需求获取 1.需求获取原则 2.需求获取技术 3.需求调研方法 4.需求获取步骤 5.需求表达与整理 6.需求确认 3.1.1 需求定义 需求定义就是识别用户的要求 系统分析过程的第一步就是识别用户要求。 分析员必须考虑以下问题： 3.1.2. 需求获取的基本原则 深入浅出 需求获取要尽可能全面、细致。获取的需求是个全集，系统真正实现的是个子集。 细致地调研并不表明在分析时将调研内容都纳入到新系统中, 但有利于以后的扩充。 以流程为主线 在与用户交流的过程中，应该用流程将所有的内容串起来。如信息、组织结构、处理规则等。这样便于交流沟通。 流程的描述既要有宏观，又要有微观。即要强调总体的业务流程、全生存期的业务流程，又要对流程细化，有分支的业务流程。 需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在： 需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化； 需求的不准确性：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。 需求获取只有通过有效的客户/开发者的合作才能成功。 3.1.3 需求获取技术 需求获取是在问题及其最终解决方案之间架设桥梁的第一步。 获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析人员、开发人员和客户就能探索出描述这些需求的多种解决方案。 需求获取技术包括两方面的工作： 建立获取用户要求的方法的框架； 支持和监控需求获取的过程的机制。 1. 弄清软件需求的层次 业务需求 反映了组织或客户开展相关业务的工作流和业务规则，是对系统、产品高层次的目标要求，与该组织或客户的业务领域有关。 用户需求 描述用户使用软件需要完成哪些任务，可通过用例 (use case) 图或场景说明加以阐明。 功能―非功能需求 定义了开发人员必须实现的软件功能，而非功能需求如表所示: 3.1.4. 需求调研的方法 调研用户的组织结构、岗位设置、职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。 调研每个子系统的工作流程、功能与处理规则，收集原始信息资料，用数据流来表示物流、资金流、信息流三者的关系。 对调研内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层、决策层的需求既联系又区分开来，形成一个需求的层次。 对与用户沟通的情况及时总结归纳，整理调研结果，初步构成需求基线。若基线符合要求，则需求获取完成。 需求调研的主要手段： 发调查表； 召开调查会； 向用户领域的专家个别咨询； 实地考察， 跟踪现场业务流程； 查阅与待开发系统有关的资料； 使用各种调查工具等。 3.1.5 需求获取的步骤 由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。 下面列出9个步骤，用以指导需求获取活动。 定义项目的视图和范围 包括组织结构图、各部门的岗位/角色列表。 确定用户类 包括人员/责任矩阵。 确定目标系统的业务工作流 包括物流、资金流、信息流，建立业务工作流模型。 运用需求获取技术开发用例（或数据流图）并设置优先级 用以掌握主要业务规则。 收集来自用户的质量特性信息和其他非功能需求 将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。 分类在用例（或数据流图）中涉及的数据 包括数据的组成和数据之间的关系。 详细拟订用例（或数据流图） 建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。 开发并评估界面原型 设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。 从功能描述中开发概念测试用例 用测试用例来验证用例（或数据流图）、功能需求和原型。 3.1.6. 需求整理与表达的方法 采用穷举方法可以避免遗漏。 采用归纳方法，通过对各种情况进行综合分类可以使问题条理化。 采用抽象方法，可以发现问题的实质，抓住问题的主要矛盾，忽略其次要矛盾。 需求整理可以多种手段共用，如组织结构图、业务流程图、多叉树、关系矩阵、文字叙述、表格、图形等。需求描述包括组织结构与岗位定义、业务流程、处理规则、数据项、功能以及上述5个方面的关系。 3.1.7. 需求确认 将整理好的用户需求说明书让用户确认