软件项目管理课件：第3章 项目范围与软件需求管理.ppt

第三章 项目范围与软件需求管理 教师： 贾向阳 Email：jxy@whu.edu.cn 目 录 3.1 概 述 3.2 收集需求 3.3 定义范围 3.4 创建工作分解结构 3.5 核实范围 3.6 控制范围 3.7 软件需求管理 3.8 案例分析 3.1 概 述 “范围” 的两种含义： 产品范围——某项产品、服务或成果所具有的特性和功能。 项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。 项目的干系人必须在项目究竟要产生什么样的产品上达成共识，以及在一定程度上还要就如何生产这些产品以提交所有的可交付成果达成共识。 3.1 概 述 项目范围管理的5个过程 收集需求——为实现项目目标而定义并记录干系人的需求的过程。 定义范围——制定项目和产品详细描述的过程。 创建工作分解结构——将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。 核实范围——正式验收项目已完成的可交付成果的过程。 控制范围——监督项目和产品的范围状态、管理范围基准变更的过程。 目 录 3.1 概 述 3.2 收集需求 3.3 定义范围 3.4 创建工作分解结构 3.5 核实范围 3.6 控制范围 3.7 软件需求管理 3.8 案例分析 3.2 “收集需求”过程 需求 需求：指发起人、客户和其他干系人的明确的且记录下来的需要与期望 包括商业需求、项目管理需求、交付需求、技术需求、安全需求、性能需求等。 需求的作用 收集需求旨在定义和管理客户期望。 需求是工作分解结构的基础 成本、进度和质量规划也要在需求的基础上进行。 3.2 “收集需求”过程 系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定： 系统或产品范围的限制性描述 与系统或产品有关的人员及特征列表 系统的技术环境的描述 系统功能的列表及应用于每个需求的领域限制 一组描述不同运行条件下系统或产品使用状况的应用场景 为更好地定义需求而开发的任意原型。 需求获取的工作产品为进行需求分析提供了基础 3.2 “收集需求”过程 收集需求的数据流图 3.2 “收集需求”过程 收集需求：输入、工具与技术和输出 3.2 “收集需求”过程 主要的工具技术 （1）访谈 访谈是一种通过与干系人直接交谈，来获得信息的正式或非正式方法。 访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。 通常采取“一对一”的形式，但也可以有多个被访者和/或多个访问者共同参与。 访谈有经验的项目参与者、干系人和主题专家，有助于识别和定义项目可交付成果的特征和功能。 3.2 “收集需求”过程 在具体的实践中，适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备： 所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化； 不要限制用户对问题的回答，这有可能会引出原先没有注意的问题； 提问和回答在汇总后应能够反映用户需求的全貌。 例子：“赛艇比赛成绩计算系统”的第一次面谈的准备计划 3.2 “收集需求”过程 （2）焦点小组会议 焦点小组会议是把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。 焦点小组会议往往比“一对一”的访谈更热烈。 3.2 “收集需求”过程 （3）引导式研讨会 通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。 是快速定义跨职能需求和协调干系人差异的重要技术。 由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。 能够比单项会议更快地发现和解决问题。 例如，在软件开发行业，就有一种被称为“联合应用开发（或设计）（Joint Application Development，JAD）”的引导式研讨会。这种研讨会注重把用户和开发团队集中在一起，来改进软件开发过程。 3.2 “收集需求”过程 （4）群体创新技术 头脑风暴法。用来产生和收集对项目需求与产品需求的多种创意的一种技术。 名义小组技术。通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用。 德尔菲技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。 概念/思维导图。把从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的关系，从而引导出新的创意。 3.2 “收集需求”过程 亲和图。这种技术可以将大量创意分类，以便审查和分析。 3.2 “收集需求”过程 （5）群体决策技术 群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。