项目管理-识别并验证需求.pptVIP

Ldentifying and validating Reqyirements*识别并验证需求 第5单元 目 标 我们将向您讲授如何--- 描述如何识别和验证项目需求 定义绩效度量基线 说明基线的价值 描述定义需求过程中的陷阱 绩效度量基线 在项目计划和绩效度量基线之间应该有一个清晰的区别? 绩效度量基线将较少变更,而且通常仅在工作范围或交付件经过批准的变更发生时才变更 项目有3个基本的绩效度量基线 要求/需求 进度 预算 通常也称为基准线(baseline) 需求基线和排除定义 需要(Need):需要是有用的、要求的或期望的活动、服务、产品和交付件 需求(Requirement):对项目发起人的那些要由项目来实现的需要的正式的文档化的描述 排除情况(Exclusions):对现有项目中”不包括”的陈述 特定(Specifications):对将要实施的特征的一种具体描述 基线(Baseline):计划或控制项目活动的执行时的参照依据,它由协议和项目计划组成.一旦制订了基线,就是受变更控制的 交付件(Deliverables):按照协议必须交付的工作产品 Needs Requirements Speclifications Exclusions Baseline Deliverables 何时识别和验证需求? 当准备一个建议书时 当开始一个项目时 当接手一个已经开始的项目(再验证) 当重新评价一个项目的需求时(项目中) 定义需求(Requirement)的过程 定义需求的过程包括以下步骤 收集客户和干系人的需要 将这些需要分类,归入需求类或排除类 验证(确认)需求 使用难证后的需求作为项目的需求基准线 收集需要(Needs) 收集需要的过程包括以下步骤 阅读所有项目文件,例如合同、DOU、SOW(工作说明书)以及其它可能包含需求的文件) 与项目发起人面谈 把项目发起人对你的问题的答案进行按优先级化和量化,这种分析应该帮助你确定项目的真实需求 识别客户需求 识别需求时,您可能询问的问题包括: 您为什么认为我们应该做这个项目? 您在业务和项目中的角色是什么? 这个项目将对您的角色产生怎么的影响? 您需要什么功能和交付件? 谁是您的干系人? 这个项目将对您的组织有什么财务影响? 现有的基础架构支持你的需求吗? 需要什么外部支持? 将如何定义成功? 它将持续多久? 是否有类似的产品已经开发或动作中? 您的完成标准是什么? 需求收集过程的下一步就是将需要归入需求类或排除类。 把需要归入需求和排除 收集到客户的需要之后,你把这些要求分类归入需求或排除,结果,你将在以下选择中做出决定: 把所有需要当作需求去实施,因为没有新的需求被识别,所有的需要都在原有 的项目定义中 在现有项目中实施一些需要,将其余的留给后续的项目,这种方式令你有一个 优雅的手段,在不危及原始项目的前提下以一个有序的方式去实施所有的需要 不实施任何需要,这种方式在需要没有技术可行性的时候或者在客户不愿意为 此需要付款的时候,是正确的 把需要转换为需求和排除 检查每一个识别出的需要,然后决定这个需要是否应该包括在你的项目里,在做出决定前,先问以下这些问题: 这个需要是项目初始意图的一部分吗? 这个需要是一个新的功能或特征,未被包括在项目的初始意图? 满足此需要的成本是否已经包括在原始的成本估算里了? 每个需要不是需求就是一个排除,把排除都写入文档,以便项目发起人和其他干系人知道你和你的团队在项目中将不提供这些排除。 验证需求以建立需求基准线 验证复查将帮助你理解写下的东西是否是真实地描述了每个人的需要 需求过程的关键是各方均认可需求 验证让你知道每个人都同意此需求,你可以在项目中处理此需求 你使用验证需求的办法来建立需求基准线 一定要把归档的需求与项目发起人、干系人和项目团队进行验证。 *建立需求基准线 需求基准线是被项目发起人、干系人和项目关键成员批准了的需求文档。 基准线定义了项目发起人想要什么,项目组同意提供什么。 除非发起人、干系人和你项目经理批准变更,否则基准线不会更改。 建立项目基准线是你控制项目范围避免范围蔓延的一个手段。 范围蔓延发生在项目需求不断变更时,但范围蔓延失控时,你将永远无法 完成一个项目;进度不停拖延,成本不断增加。 作为一个项目经理,强制建立需求基准线是你的重要的任务之一。 验证需求指南 使用项目定义文档(PDD) 在检查需求时,以现实的眼光对待 明确陈述需求 运用非文字表示(图形/模型)来澄清需求 把需求排入特定的排除 获得关于问题的具体描