北京理工大学软件工程实践1.pptVIP

北京理工大学软件工程实践 汤铭端 中国航天科工集团公司204所 第四讲 需求分析 内容 需求分析概念 需求分析过程 需求分析方法 需求分析产品 目的 掌握需求分析基本概念 掌握需求分析过程 了解基本需求分析方法（DFD+DD） 了解需求规格说明的内容条目 软件需求的定义 客户定义的“需求”对开发者是一个较高层次的产品概念。 开发者所说的“需求”对用户来说像是详细说明。 软件需求包含多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。 IEEE软件工程术语（1997）的需求定义： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式强制性文件所需具有的条件或能力。 （3）反映上面（1）或（2）所描述的条件或能力的文档说明。 上述定义包括从用户（外部）、从开发者（内部）角度来阐述需求。 需求的层次 业务需求（business requirement）：反映组织机构或客户对系统、产品高层次的目标要求。 用户需求（user requirement）：描述用户使用产品必须要完成的任务。 功能需求（functional requirement）：定义开发人员必须实现的软件功能。 需求规格说明中还包括非功能需求。 软件需求各组成部分之间关系 不成熟的需求分析 无足够用户参与 用户需求的不断增加 摸棱两可的需求 不必要的特征（镀金） 过于精简的规格说明 忽略了用户分类 不准确的计划 高质量需求过程的获益 开发后期和整个维护阶段的重做的工作大大减少 Boehm发现可以节省成本68倍 有研究认为可以节省成本200倍 强调产品开发中的通力合作，面向市场，让用户积极参与，可以建立忠实的客户关系，避免在无用功能上白耗精力，弥补用户期望和开发者实际开发间的期望鸿沟 采用系统方法将需求分配到各子系统可以简化集成 有效的变更控制和影响分析能降低变更的负面影响 清晰、无二义的需求文档有利于测试 需求说明的特征 完整性 正确性 可行性 必要性 划分优先级 无二义性 可验证性 需求规格说明的特点 完整性 先用TBD标明缺项 在开发前必须解决所有TBD 一致性 可修改性 每项需求只在SRS中出现一次 可追踪性 结构、粒度方便设计、实现、测试的追踪 谁是客户 定制软件：合同甲方（提出方） 通用软件：高层管理者和（或）市场部 嵌入式软件：软件所属计算机系统 客户的权利 1 要求分析人员使用符合客户语言习惯的表达 2 要求分析人员了解客户的业务及目标 3 要求分析人员编写软件需求规格说明 4 要求得到需求工作结果的解释说明 5 要求开发人员尊重你的意见 6 要求开发人员对需求及产品实施提供建议 7 描述产品易使用的特性 8 调整需求，允许重用已有的软件组件 9 要求对变更的代价提供真实可信的评估 10 获得满足客户功能和质量要求的系统 客户的义务 1 给分析人员讲解你的业务 2 抽出时间清楚地说明并完善需求 3 准确而详细地说明需求 4 及时地作出决定 5 尊重开发人员的需求可行性及成本评估 6 划分需求优先级别 7 评审需求文档和原型 8 需求出现变更要马上联系 9 应遵守开发机构处理需求变更的过程 10 尊重开发人员采用的需求工程过程 对签定需求协议的认识 签约是客户同意需求的标志行为 客户不应当忽略签约的严肃性 开发方不应当因此拒绝变更 签约应当建立在一个需求协议的基线上 应当理解为：“我同意这份文档表达了目前我们对项目软件需求的了解。进一步的变更可在此基础上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成本、资源和项目时间工期任务等。” 需求开发过程 需求获取 需求分析 编写需求规格说明 需求验证 知识培训 需求管理 项目管理 需求获取的内容 在同用户的交流过程中收集各种用户的信息 认真理解用户的各项要求 澄清模糊 排除不合理 明确约束 分析人员的两个信条 第一：只有在彻底了解和掌握了用户的全部意图之后，才有可能建立起成功的软件系统。 第二：一切从用户的角度着想，在条件允许的情况下，应尽可能地保证用户从所构造的软件系统中获得最大的利益。 容易产生的问题 交流障碍 误解 各方缺乏共同的语言 “完整性”问题 需求永远会变化 用户本身的意见不一致 错误的要求 认识上混淆目标和需求 需求获取的过程 确定需求开发过程 编写项目目标和范围文档 将用户群分类并归纳各自特点 选择各类用户的产品代表 建立起典型用户的核心队伍 让用户代表确定使用实例 召开应用程序开发联系会议 分析用户工作流程 确定质量属性和其它非功能属性 通过检查当前系统的问题报告来进一步完善需求 跨项目重用需求 建立模型的步骤 分析现有系统和过程，建立物理模型 抽取特征，建立旧系统的逻辑模型 根据新的要求，补充和建立新的逻辑模型 需求分析的