第 章 项目范围管理
- 格式:docx
- 大小:24.59 KB
- 文档页数:9
5.1 范围管理主要管理什么?项目范围管理包括确保项目做且只做所需的全部工作,以成功完成项目的各个过程。
管理项目范围主要在于定义和控制哪些工作应该包括在项目内,哪些不应该包括在项目内。
什么是产品范围产品范围。
某项产品、服务或成果所具有的特征和功能。
什么是项目范围?为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
两者的联系:项目范围有时也包括产品范围。
商业分析师和项目经理在需求范围管理中有什么不同侧重?应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。
如果项目已配备商业分析师,那么,与需求管理相关的活动便是该角色的职责。
而项目经理则负责确保这些活动在项目管理计划有所安排,并且在预算内按时完成,同时能够创造价值。
项目管理范围概述5.2 焦点小组会议与引导式研讨会有什么区别?焦点小组是召集预定的相关方和主题专家,了解他们对所讨论的产品、服务或成果的期望和态度。
由一位受过训练的主持人引导大家进行互动式讨论。
引导与主题研讨会结合使用,把主要相关方召集在一起定义产品需求。
研讨会可用于快速定义跨职能需求并协调相关方的需求差异。
应用于场景包括(但不限于):联合应用设计或开发(JAD)、质量功能展开(QFD)、用户故事。
原型法适用于什么情况?原型法支持渐进明细的理念,需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。
如何进行头脑风暴?头脑风暴,用于在短时间内获得大量创意,适用于团队环境,需要引导者进行引导。
头脑风暴由两个部分构成:创意产生和创意分析。
制定项目章程时可通过头脑风暴向相关方、主题专家和团队成员收集数据、解决方案或创意。
5.3 需求文件有什么作用,包括什么内容?需求文件描述各种单一需求将如何满足与项目相关的业务需求。
一开始可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。
只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。
目录第一章绪论第二章项目管理的基本原理第三章项目组织与管理第四章项目范围管理第五章项目进度管理第六章项目成本管理第七章项目质量管理第八章项目沟通管理第九章项目风险管理第十章项目采购管理第十一章项目人力资源管理第十二章项目信息管理第十三章项目综合管理第十四章国际工程项目管理第十五章项目管理信息化第十六章项目管理案例第一章绪论1.1 项目管理的定义与特点1.2 项目管理的发展历程1.3 项目管理的重要性1.4 工程项目管理的任务与目标1.5 工程项目管理的方法与工具第二章项目管理的基本原理2.1 项目管理的理论基础2.2 项目管理的生命周期2.3 项目管理的五大过程组2.4 项目管理的九大知识领域2.5 项目管理的关键成功因素第三章项目组织与管理3.1 项目组织的类型与结构3.2 项目组织的设计与优化3.3 项目管理团队的建设与管理3.4 项目经理的角色与职责3.5 项目组织的沟通与协作第四章项目范围管理4.1 项目范围的定义与内容4.2 项目范围规划4.3 项目范围确认4.4 项目范围变更控制4.5 范围管理工具与技术第五章项目进度管理5.1 项目进度计划5.2 项目进度控制5.3 进度管理工具与技术5.4 进度偏差分析5.5 项目进度风险管理第六章项目成本管理6.1 项目成本构成6.2 项目成本估算6.3 项目成本预算6.4 项目成本控制6.5 成本管理工具与技术第七章项目质量管理7.1 项目质量的概念与特性7.2 项目质量管理体系7.3 项目质量控制7.4 项目质量保证7.5 质量管理工具与技术第八章项目沟通管理8.1 项目沟通的必要性8.2 项目沟通的渠道与方式8.3 项目沟通计划8.4 项目沟通控制8.5 沟通管理工具与技术第九章项目风险管理9.1 项目风险的概念与分类9.2 项目风险评估9.3 项目风险应对9.4 风险管理计划9.5 风险管理工具与技术第十章项目采购管理10.1 项目采购概述10.2 采购计划10.3 供应商选择与评估10.4 合同管理10.5 采购合同执行与监控第十一章项目人力资源管理11.1 项目人力资源规划11.2 项目团队建设11.3 项目人员配置与培训11.4 项目团队激励与绩效管理11.5 项目人力资源管理与沟通第十二章项目信息管理12.1 项目信息管理的概念与内容12.2 项目信息系统的构建与维护12.3 项目信息收集与处理12.4 项目信息共享与沟通12.5 项目信息管理工具与技术第十三章项目综合管理13.1 项目综合管理的概念与内容13.2 项目综合管理的方法与工具13.3 项目综合管理在项目管理中的应用13.4 项目综合管理案例第十四章国际工程项目管理14.1 国际工程项目概述14.2 国际工程项目管理特点14.3 国际工程项目风险管理14.4 国际工程项目合同管理14.5 国际工程项目协调与沟通第十五章项目管理信息化15.1 项目管理信息化概述15.2 项目管理信息系统15.3 项目管理信息化工具与技术15.4 项目管理信息化在项目管理中的应用15.5 项目管理信息化发展趋势第十六章项目管理案例16.1 案例一:某住宅楼工程项目管理16.2 案例二:某高速公路工程项目管理16.3 案例三:某国际工程项目管理16.4 案例分析与总结第一章绪论1.1 项目管理的定义与特点项目管理是指运用科学的方法、技术和工具,对项目的整个生命周期进行规划、组织、协调、控制和监督,以实现项目目标的过程。
戚安邦《项⽬管理学》完整版第五章项⽬的范围管理第五章项⽬的范围管理【本章导读】本章将全⾯讨论有关项⽬范围管理的概念、内容、理论和⽅法。
本章着重讨论了项⽬范围管理的意义、概念和特性;项⽬范围管理的作⽤和程序;项⽬范围计划的编制⽅法和项⽬范围变更的控制⽅法等⽅⾯的内容。
本章通过对于项⽬的起始⼯作、项⽬范围的界定和确认、项⽬范围计划制定与实施和项⽬范围变更的控制等⽅⾯管理⼯作的讨论,给出了有关项⽬范围管理原理与⽅法的全⾯描述。
第⼀节项⽬范围管理的概述项⽬的范围管理就是对⼀个项⽬从⽴项到完结的全过程中所涉及的项⽬⼯作的范围所进⾏的管理和控制活动。
这⾥的“项⽬范围”包括,⽽且只包括完成该项⽬、实现项⽬⽬标、获得项⽬产出物所“必需”的全部⼯作。
项⽬的⼯作范围既不应超出⽣成既定项⽬产出物和实现既定项⽬⽬标的需要,也不能少于这种需要。
本章将全⾯介绍项⽬范围管理的理论、⼯具、技术、⽅法和程序。
⼀、项⽬范围及其管理的概念项⽬范围是指项⽬的“产品范围”(即项⽬业主/客户所要的项⽬产出物)和项⽬的“⼯作范围”(即项⽬组织为提交项⽬最终产品所必需完成的各项⼯作)的总和。
项⽬范围管理是指对于项⽬“产品范围”和“⼯作范围”的全⾯管理,其中最为主要的是对于项⽬“⼯作范围”的管理。
⼀个项⽬的“产品范围”既包括项⽬产品或服务的主体部分,也包括项⽬产品或服务的辅助部分。
这些产品或服务的主体与辅助部分之间有着彼此独⽴却⼜相互依赖的关系,所以在项⽬范围管理中,它们必需作为⼀个整体去管理。
项⽬的⼯作范围既包括完成项⽬产出物主体的⼯作,也包括完成项⽬产出物的辅助部分的⼯作,所以项⽬范围管理的内容既包括对于项⽬主体部分⼯作范围的管理,也包括对于项⽬辅助部分的⼯作范围管理。
例如,⼀个信息系统项⽬通常会包括四个部分——硬件、软件、⼈员和软硬件的辅助部分,这四个部分既是彼此独⽴,⼜是相互依存的,所以这四个部分都是项⽬范围管理的对象。
任何⼀个项⽬都需要对项⽬范围进⾏严格的管理,都需要将项⽬产出物范围和项⽬⼯作范围很好地结合在⼀起进⾏认真的管理,从⽽确保项⽬组织能够提供项⽬业主/客户满意的项⽬⼯作成果。
第一章、项目范围管理概述:知识点1.项目范围包括:项目的最终产品或服务,以及实现该产品或服务所需要的各项具体工作。
项目范围的确定就是为成功实现项目的目标,规定或控制哪些方面是项目应该做的,哪些是不该做的,也就是定义项目的范畴。
范围有多种含义:产品范围、项目范围、产品规范。
知识点2.产品范围:即确定产品或服务中应包含有哪些功能和特征,(就是对产品的度量)。
项目范围:项目要做些什么,如何做,才能实现项目的目标,(也是产生项目计划的基础)。
也就是为了交付具有一定特征和功能的产品或服务所应做的工作。
产品规范:即项目产品或服务所包含的具体特征和功能。
知识点3.项目范围的定义要以其组成的所有产品或服务的范围界定为基础,这是一个由一般到具体、层层深入的过程。
产品范围的定义就是对产品要求的度量,项目范围的定义在一定程度上是产生项目计划的基础;产品范围的完成是对照产品要求来进行度量的,而项目范围的完成是对照项目计划来进行度量的。
知识点4.项目范围说明书规定了项目的范围也主定义了项目的工作边界,明确了项目的目标和主要的项目可交付成果。
项目范围说明书应该包括以下3个方面的内容:1、项目的合理性说明书:(说明解释了为什么要进行这一项目);2、项目目标:(确定了项目成功所必须满足的某些数量标准。
至少应包括费用、时间进度和技术性能或质量标准)。
3、项目可交付成果:(是一份主要的、具有归纳性层次的产品清单;这些产品完全、满意的交付标志着项目的完成)。
知识点5.项目范围管理,就是对项目应该包括什么和不应该包括什么做出相应的定义和控制。
知识点6.项目范围管理所包括的内容:1) 、确定项目的需求;2) 、定义和规划项目的范围;3)、范围管理的实施;4)、范围的变更控制管理;5)、范围核实。
知识点7.项目范围管理的作用:1、提高费用、时间和资源估算的准确性;2、确定了进度测量和控制的基准;3、有助于清楚的分配任务。
知识点8.项目范围管理的合理性。
第3章项目范围管理案例案例1:面对项目范围管理上出现的混乱局面,刘工应该如何处理?某软件公司承担了A公司的一个ERP系统开发项目,在项目的实施过程中,系统需求似乎永远无法确定,用户说不清楚自己的需求,怎么做他们都不满意,功能不断增加,用户上周说要这个功能,今天说要这个功能,李部长认为这个功能该这样做,而王经理认为这样不行,结果让软件开发人员无所适从。
该项目已经进行了两年多,项目何时结束还是处于不明确的状态,因为用户不断有新的需求提出来,项目组也就要根据用户的新需求不断去开发新的功能。
大家对这样的项目完全丧失了信心。
公司针对目前出现的局面,派出项目管理专家刘工负责ERP项目组的管理工作。
刘工通过对项目文档分析和A公司相关人员的沟通认识到,这个项目一开始就没有明确界定整个项目的范围,在范围没有明确的情况下,又没有一套完善的变更控制管理流程,任由用户怎么说就怎么做,也就是说,一开始游戏规则就没有定好,从而导致整个项目成了一个烂摊子。
面对项目在范围管理上出现的混乱局面,刘工应该如何处理呢?案例2:如何控制项目的范围?某公司与某省厅签定了该省十几个县的应用软件与相关系统集成的的合同。
合同规定以招标技术说明书的最佳方案验收。
而招标技术说明书是从另一公司的模式抄写的,详细到实现某些功能的方式。
该公司系统能实现其绝大部分功能,但部分方法与技术说明书有区别。
该公司投标书基本照抄招标技术说明书。
且某些功能合同设备清单中没有实现该功能的设备。
假如该公司请你做该项目的项目经理,你将用什么方法控制项目的范围才能成功实施该项目呢?案例3:公司A是拥有较好政府背景的股份制企业,机制比较灵活,该公司运作的项目是政府机关的一个MIS系统。
现在整个开发全部完成,系统已经试运行2个月左右,运行情况比较顺利,但是,目前有几个比较大的问题如下:1. 客户同该公司关系特别密切(毕竟客户是机关),不能完全按照合同进展。
2. 政府的工作节奏比较慢,在项目实施进程中,严重单方面拖延实施进度,造成项目延期。
第一章项目范围管理概述1、项目范围定义:答:在项目环境中,一般项目的范围包括项目的产品(产出物)和工作范围。
产品范围--某项产品、服务或成果所具有的特性和功能。
工作范围--为交付具有特定功能的产品、服务或成果而必须完成的工作。
2、项目范围管理定义:答:项目范围管理实质上是一种功能管理,它是对项目产品范围和工作范围进行全面识别、定义、确认和控制的管理过程与活动。
3、项目范围管理的作用:答:(1)为组织选择和启动项目提供决策;(2)为项目实施提供范围的框架;(3)提高资金、时间、人力和其它资源估算的准确性;(4)确定进度、成本测量和控制的基准,便于对项目的实施提供有效的控制;(5)有助于清楚地分派任务。
4、项目范围管理的意义;答:(1)项目范围管理是所有项目管理工作的平台和基础;(2)项目范围管理是连接项目工作和前期设计过程的枢纽;(3)项目范围管理是连接项目及其外部环境的桥梁。
5、项目范围管理的基本原则:答:(1)明确责任;(2)注重结果;(3)把握平衡;(4)保持简单。
6、项目范围管理的主要工作及其内容:答:(1)项目选择决策。
主要内容:战略分析、需求识别、项目构思、项目选择。
(2)项目启动。
主要内容:项目目标确定、项目发起、项目章程制定。
(3)项目范围规划。
主要内容:项目范围管理规划编制、范围说明书制定。
(4)项目范围定义。
即细分,主要内容:工作分解。
(5)项目范围控制。
指项目利益相关者确认和接受了项目范围,在项目实施过程中,对由于项目实施偏差所造成的项目范围变更或由于项目利益相关者主观要求所造成的项目范围变更所做的度量、评估和处理等各种控制工作。
贯穿于项目全过程,主要内容:范围变更控制。
(6)项目范围验收。
又称范围确认,是指项目利益相关者对已完成的项目的整体范围或项目阶段范围和相应的可交付成果进行正式验收的过程。
主要内容:工作确认、可交付成果审查。
第二章组织战略与项目管理1、战略的定义:答:组织为了实现其使命或长期目标,在与环境的互动中所展开的决策行为、采用的行动模式或遵循的基本概念。
第5章项目范围管理项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的各过程。
管理项目范围主要在于定义和控制哪些工作应包括在项目内,哪些不应包括在项目内。
图5-1 概述了项目范围管理的各个过程,包括:收集需求——为实现项目目标而定义并记录干系人的需求的过程。
定义范围——制定项目和产品详细描述的过程。
创建工作分解结构——将项目可交付成果和项目工作分解为较小的、更易于管理的组成部分的过程。
核实范围——正式验收项目已完成的可交付成果的过程。
控制范围——监督项目和产品的范围状态、管理范围基准变更的过程。
上述过程不仅彼此相互作用,而且还与其他知识领域中的过程相互作用。
基于项目的具体需要,每个过程都可能需要一人或多人的努力。
每个过程在每个项目中至少进行一次,并可在项目的一个或多个阶段(如果项目被划分为多个阶段)中进行。
虽然在本章中,各过程以界限线分明、相互独立的形式出现,但在实践中它们可能以本章未详述的方式相互交叠、相互作用。
第3 章“项目管理过程”已对过程间的相互作用做了详细讨论。
在项目的环境中,“范围”这一术语有两种含义:产品范围——某项产品、服务或成果所具有的特性和功能。
项目范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
管理项目范围所需的各个过程及其工具与技术,因应用领域而异,并通常作为项目生命周期的一部分加以确定。
经批准的详细项目范围说明书以及相应的工作分解结构、工作分解结构词典,构成项目的范围基准。
然后,在整个项目生命周期中,对这个基准范围进行监督、核实和控制。
在进行项目范围管理的5 个过程之前,项目管理团队应先进行规划工作,尽管本章未把该规划工作单独列为一个过程。
该规划工作是制定项目管理计划过程(见节)的一部分,会产生一份范围管理计划,用来指导项目范围的定义、记录、核实、管理和控制。
基于项目的需要,范围管理计划可以是正式或非正式的、非常详细或高度概括的。
根据项目管理计划(见节)来衡量项目范围是否完成,根据产品需求(见节)来衡量产品范围是否完成。
项目范围管理各过程需要与其他知识领域中的过程整合起来,以确保项目工作能实现规定的产品范围。
收集需求收集需求是为实现项目目标而定义并记录干系人的需求的过程。
仔细掌握和管理项目需求与产品需求,对促进项目成功有重要作用。
需求是指发起人、客户和其他干系人的已量化且记录下来的需要与期望。
项目一旦开始,就应该足够详细地探明、分析和记录这些需求,以便日后进行测量。
收集需求旨在定义和管理客户期望。
需求是工作分解结构的基础。
成本、进度和质量规划也都要在这些需求的基础上进行。
需求开发始于对项目章程(见节)和干系人登记册(见节)中相关信息的分析。
许多组织把需求分为项目需求和产品需求。
项目需求包括商业需求、项目管理需求、交付需求等。
产品需求则包括技术需求、安全需求、性能需求等。
图 5-2 显示了收集需求过程的输入、工具与技术和输出,图5-3 概述了本过程的基本数据流向。
收集需求:输入1.项目章程可从项目章程中了解总体项目需求以及关于项目产品的总体描述,并据此制定详细的产品需求。
项目章程已在节讨论。
2.干系人登记册干系人登记册可用来识别那些能提供详细的项目和产品需求信息的干系人。
干系人登记册将在节讨论。
收集需求:工具与技术1.访谈访谈是一种通过与干系人直接交谈,来获得信息的正式或非正式方法。
访谈的典型做法是向被访者提出预设和即兴的问题,并记录他们的回答。
通常采取“一对一”的形式,但也可以有多个被访者和/或多个访问者共同参与。
访谈有经验的项目参与者、干系人和主题专家,有助于识别和定义项目可交付成果的特征和功能。
2.焦点小组会议焦点小组会议是把预先选定的干系人和主题专家集中在一起,了解他们对所提议产品、服务或成果的期望和态度。
由一位受过训练的主持人引导大家进行互动式讨论。
焦点小组会议往往比“一对一”的访谈更热烈。
3.引导式研讨会通过邀请主要的跨职能干系人一起参加会议,引导式研讨会对产品需求进行集中讨论与定义。
研讨会是快速定义跨职能需求和协调干系人差异的重要技术。
由于群体互动的特点,被有效引导的研讨会有助于建立信任、促进关系、改善沟通,从而有利于参加者达成一致意见。
该技术的另一好处是,能够比单项会议更快地发现和解决问题。
例如,在软件开发行业,就有一种被称为“联合应用开发(或设计)(Joint Application Development,JAD)”的引导式研讨会。
这种研讨会注重把用户和开发团队集中在一起,来改进软件开发过程。
在制造行业,则使用“质量功能展开(Quality Function Deployment,QFD)”这种引导式研讨会,来帮助确定新产品的关键特征。
QFD 从收集客户需求(又称“顾客声音”)开始,然后客观地对这些需求进行分类和排序,并为实现这些需求而设置目标。
4.群体创新技术可以组织一些群体活动来识别项目和产品需求。
下面是一些常用的群体创新技术:头脑风暴法。
用来产生和收集对项目需求与产品需求的多种创意的一种技术。
名义小组技术。
通过投票来排列最有用的创意,以便进行进一步的头脑风暴或优先排序。
名义小组技术是头脑风暴法的深化应用。
德尔菲技术。
由一组选定的专家回答问卷,并对每一轮需求收集的结果再给出反馈。
专家的答复只能交给主持人,以保持匿名状态。
概念/思维导图。
把从头脑风暴中获得的创意,用一张简单的图联系起来,以反映这些创意之间的共性与差异,从而引导出新的创意。
亲和图。
这种技术可以将大量创意分类,以便审查和分析。
5.群体决策技术群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。
群体决策技术可用来开发产品需求,以及对产品需求进行归类和优先排序。
达成群体决策的方法很多,例如:一致同意。
每个人都同意某个行动方案。
大多数原则。
获得群体中50%以上的人的支持。
相对多数原则。
根据群体中相对多数者的意见做出决定,即便未能获得一部分人的支持。
独裁。
某一个人为群体做出决策。
在需求收集过程中,几乎可采用上述任何一种决策方法进行群体决策。
6.问卷调查问卷调查是指通过设计书面问题,向为数众多的受访者快速收集信息。
如果受众众多、需要快速完成调查,并想要使用统计分析法,就适宜采用问卷和/或调查方法。
7.观察观察是指直接观察个人在各自的环境中如何开展工作和实施流程。
当产品使用者难以或不愿说明他们的需求时,就特别需要通过观察来了解细节。
观察,也称为“工作跟踪”,通常由观察者从外部来观察使用者的工作。
观察也可以由“参与观察者(Participant observer)”进行。
“参与观察者”需要实际执行一个流程或程序,体验该流程或程序是如何实施的,以便挖掘出隐藏的要求。
8.原型法原型法是指在实际制造产品之前,先造出该产品的实用模型,并据此征求对需求的反馈意见。
原型是有形的实物,它使干系人有机会体验最终产品的模型,而不是只讨论抽象的需求陈述。
原型法符合渐进明细的理念,因为原型需要重复经过制作、试用、反馈、修改等过程。
在经过足够的重复之后,就可以从原型中获得足够完整的需求,并进而进入设计或制造阶段。
收集需求:输出1.需求文件需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
一开始,可能只有概括性的需求,然后随着信息的增加而逐步细化。
只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求,才能作为基准。
需求文件的格式多种多样,既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。
需求文件的组成部分包括(但不限于):业务需求或需抓住的机遇,描述当前局面的不足以及启动项目的原因;可跟踪的业务目标和项目目标;功能要求,描述业务流程、信息以及与产品的内在联系。
可采用适当的方式,如写成文本式需求清单或制作出模型,也可以同时采用这两种方法;非功能性要求,如服务水平、绩效、安全、防护、合规性、保障能力、保留/清除等;质量要求;验收标准;体现组织指导原则的业务规则;对组织其他领域的影响,如呼叫中心、销售队伍、技术团队;对执行组织内部或外部团体的影响;对支持和培训的需求;与需求有关的假设条件和制约因素。
2.需求管理计划需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。
生命周期各阶段间的关系(见节)对如何管理需求有很大影响。
项目经理必须为项目选择最有效的阶段间关系,并记录在需求管理计划中。
需求管理计划的许多内容都是基于该种关系的。
需求管理计划的内容包括(但不限于):如何规划、跟踪和汇报各种需求活动;配置管理活动,例如,如何启动产品、服务或成果的变更,如何分析其影响,如何进行跟踪和汇报,以及谁有权批准变更;需求排序过程;产品测量指标及使用这些指标的理由;需求跟踪结构,即:哪些需求属性将列入跟踪矩阵,并可在其他哪些项目文件中追踪到这些需求。
3.需求跟踪矩阵需求跟踪矩阵是一张连接需求与需求源的表格,以便在整个项目生命周期中对需求进行跟踪。
需求跟踪矩阵把每一个需求与业务目标或项目目标联系起来,有助于确保每一个需求都具有商业价值。
它为人们在整个项目生命周期中跟踪需求提供了一种方法,有助于确保需求文件所批准的每一项需求在项目结束时都得到实现。
最后,需求跟踪矩阵为管理产品范围变更提供了框架。
跟踪需求的过程包括(但不限于):从需求到业务需要、机会、目的和目标;从需求到项目目标;从需求到项目范围/WBS 中的可交付成果;从需求到产品设计;从需求到产品开发;从需求到测试策略和测试脚本;从宏观需求到详细需求。
应在需求跟踪矩阵中记录各项需求的相关属性。
这些属性有助于明确各项需求的关键信息。
需求跟踪矩阵中的典型属性包括:独特的识别标志、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、现状(如活跃中、已取消、已推迟、新增加、已批准)和实现日期。
为确保干系人满意,可能需增加的补充属性包括:稳定性、复杂程度和验收标准。
定义范围定义范围是制定项目和产品详细描述的过程。
详细项目范围说明书的编制,对项目成功至关重要。
应该根据项目启动过程中记载的主要可交付成果、假设条件和制约因素,来编制项目范围说明书。
在规划过程中,由于对项目有了更多的了解,所以应该更具体地定义与描述项目范围。
应该分析现有风险、假设条件和制约因素的完整性,并在必要时补充其他的风险、假设条件和制约因素。
图5-4 显示了定义范围过程的输入、工具与技术和输出,图5-5 概述了本过程的基本数据流向。
定义范围:输入1.项目章程项目章程中包含对项目和产品特征的概括性描述,以及项目审批要求。
项目章程已在节中讨论。
如果执行组织不使用项目章程,则应取得或编制类似的信息,并用做制定详细范围说明书的基础。
2.需求文件见节。