第2章信息系统项目管理基础
1、项目的特点：（1）临时性（一次性）（2）独特的产品、服务或成果（3）逐步完善（4）资源约束（5）目的性
2、战略管理包括以下三个过程：①战略制定②战略实施③战略评价
3、PRINCE2提供最佳的项目管理方法论，更加接近项目的实施，更加重视项目的实际收益和回报。是一种基于流程的结构化项目管理方法。
4、PRINCE2包括4个被称为要素的主要部分。这4个要素包括原则、流程、主题以及项目环境
5、PRINCE2方法具有七个原则：（1）持续业务验证（2）吸取经验教训（3）明确定义的角色和职责（4）按阶段管理（5）例外管理（6）关注产品（7）根据项目环境剪裁
6、PRINCE2主题包括：商业论证；组织；质量；计划；风险；变更；进展
7、PRINCE2是一种基于流程的项目管理方法。
8、职能型组织的优点体现在如下方面。
（1）强大的技术支持，便于知识、技能和经验的交流。
（2）清晰的职业生涯晋升路线。
（3）直线沟通、交流简单、责任和权限很清晰。
（4）有利于重复性工作为主的过程管理。
同时，职能型组织也存在着如下缺点：职能利益优先于项目，具有狭隘性；组织横向之间的联系薄弱、部门间沟通、协调难度大；项目经理极少或缺少权利、权威；项目管理发展方向不明，缺少项目基准等。
9、项目型组织的优点体现在如下方面。
（1）结构单一，责权分明，利于统一指挥。
（2）目标明确单一。
（3）沟通简洁、方便。
（4）决策快。
同时，项目型组织也存在着如下缺点：管理成本过高，如项目的工作量不足则资源配置效率低；项目环境比较封闭，不利于沟通、技术知识等共享；员工缺乏事业上的连续型和保障等。
10、矩阵型组织的优点体现在如下方面。
（1）项目经理负责制、有明确的项目目标。
（2）改善了项目经理对整体资源的控制。
（3）及时响应。
（4）获得职能组织更多的支持。
（5）最大限度地利用公司的稀缺资源。
（6）降低了跨职能部门间的协调合作难度。
（7）使质量、成本、时间等制约因素得到更好的平衡。
（8）团队成员有归属感，士气高，问题少。
（9）出现的冲突较少，且易处理解决。
同时，矩阵型组织也存在着如下缺点：管理成本增加；多头领导；难以监测和控制;资源分配与项目优先的问题产生冲突；权利难以保持平衡等。
11、瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段
12、螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期所划分的四阶段：制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。
13、迭代式开发模型分四个阶段：初始、细化、构造、移交，可进一步描述为周期（Cycle ）、阶段（Phase ）、迭代（Iteration ）;核心工作流从技术角度描述迭代模型的静态组成部分，包括：业务建模、需求获取、分析与设计、实现、测试、部署。不同的工作流在不同的时间段内工作量的不同，几乎所有的工作流在所有的时间段内均有工作量，只是大小不同而已。
14、V 模型的特点如下：注意区分
（1）单元测试的主要目的是针对编码过程中可能存在的各种错误；
（2）集成测试的主要目的是针对详细设计中可能存在的问题；
（3）系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行；
（4）验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。
（5）V 模型用于需求明确和需求变更不频繁的情形。
15、原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下。
（1）实际可行（2）具有最终系统的基本特征（3）构造方便、快速，造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。
16、敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。 Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发。
17、如何做好一个项目经理： 真正理解项目经理的角色、重视项目团队的管理，惩罚分明、计划、计划、再计划、真正理解一把手工程，注重用户参与。
18、瀑布模型 适用：需求明确或很少变更的项目，如二次开发或升级型的项目，有利于大型软件开发人员的组织与管理；开发团队比较弱或缺乏经验。
螺旋模型 适用：特别适合于大型复杂的系统，风险大的项目。
喷泉模型适用：是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。 敏捷方法：适用：小型或中型软件开发团队，并且客户的需求模糊或者多变。
统一过程（RUP ）适用：一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同性能水平和不同的项目规模。
19、优秀项目经理应该具备的素质（广博的知识、丰富的经历、良好的协调、职业道德、沟通表达、领导）项目经理必须承担管理者和领导者的双重角色。
第3章 立项管理
1、项目立项一般包括提交项目建议书、项目可行性研究、项目招标与投标等内容。
2、项目建议书应该包括的核心内容如下。（1）项目的必要性。（2）项目的市场预测。（3）产品方案或服务的市场预测。（4）项目建设必需的条件。
3、可行性研究内容一般应包括以下内容（1）投资必要性（2）技术的可行性（3）财务可行性（4）组织可行性（5）经济可行性（6）社会可行性（7）风险因素及对策。
4、为防止投标人在投标后撤标或在中标后拒不签订合同，招标人通常都要求投标人提供一定比例或金额的投标保证金。招标人决定中标人后，未中标的投标人已缴纳的保证金即予退还。
5、如果以邮寄方式送达的，投标人必须留出邮寄时间，保证投标文件能够在截止日期之前送达招标人指定的地点，而不是以“邮戳为准”。在截止时间后送达的投标文件，即已经过了招标有效期的，招标人应当原封退回，不得进入开标阶段。以“邮戳为准”的是合同
6、经济可行性分析，具体包括支出分析、收益分析、投资回报分析以及敏感性分析等。
7、一般地，可行性研究分为初步可行性研究、详细可行性研究、可行性研究报告三个基本的阶段
8、在初步项目可行性研究之前可进行项目机会研究，如果就投资可能性已进行了项目机会研究，那么项目的初步可行性研究阶段往往可以省去。
9、辅助（功能）研究包括项目的一个或几个方面，但不是所有方面。
10、机会研究、初步可行性研究、详细可行性研究、评估与决策是投资前时期的四个阶段。在实际工作中，前三个阶段依项目的规模和繁简程度可把前两个阶段省略或合二为一，但详细可行性研究是不可缺少的。升级改造项目只做初步和详细研究，小项目一般只进行详细可行性研究。
11、详细可行性研究的方法很多，如经济评价法、市场预测法、投资估算法和增量净效益法等。
12、详细可行性研究的内容，信息系统项目详细可行性研究的内容，一般可以归纳如下
（1）概述（2）需求确定（3）现有资源、设施情况分析（4）设计（初步）技术方案（5）项目实施进度计划建议（6）投资估算和资金筹措计划（7）项目组织、人力资源、技术培训计划（8）经济和社会效益分析（效果评价）。（9）合作/协作方式。
13、对于效益的量化及计算方法有函数求解法、相关关系法、模糊数学法、专家意见法（德尔菲法）、成本降低法、利润增加法
14、项目前评价（论证）的作用主要体现在以下几个方面：
（1）项目论证是确定项目是否实施的依据。
（2）项目论证是筹措资金、向银行贷款的依据。
（3）项目论证是编制计划、设计、采购、施工以及机构设备、资源配置的依据。
（4）项目论证是防范风险、提高项目效率的重要保证。
15、项目论证一般分为机会研究、初步可行性研究和详细可行性研究三个阶段。
16、项目论证的一般程序，一般有以下七个主要步骤。注意选择考顺序
（1）明确项目范围和业主目标
（2）收集并分析相关资料。
（3）拟定多种可行的能够相互替代的实施方案。
（4）多方案分析、比较。
（5）选择最优方案进一步详细全面地论证。
（6）编制项目论证报告、环境影响报告书和采购方式审批报告。
（7）编制资金筹措计划和项目实施进度计划。
17、项目评估由第三方进行。是项目投资前期进行决策管理的重要环节，是审查项目可行性研究的可靠性、真实性和客观性，为银行的贷款决策或行政主管部门的审批决策提供科学依据。项目评估的最终成果是项目评估报告。
18、项目评估工作一般可按以下程序进行。注意选择考顺序
（1）成立评估小组，进行分工，制订评估工作计划。
（2）开展调查研究，收集数据资料，并对可行性研究报告和相关资料进行审查和分析。
（3）分析与评估。
（4）编写评估报告。
（5）讨论、修改报告。
（6）专家论证会。
（7）评估报告定稿。
19、建设方项目论证的内容：(1)项目财务评价(2)项目国民经济评价(3)项目环境影响评价(4)项目社会影响评价
20、承建方项目论证的内容：
（1）承建方技术可行性分析
（2）承建方人力及其他资源配置能力可行性分析
（3）项目财务可行性分析
（4）项目风险分析
（5）对可能的其他投标者的相关情况分析
21、项目可行性研究报告的编制内容与项目建议书批复内容有重大变更的，应重新报批项目建议书。项目初步设计方案和投资概算报告的编制内容与项目可行性研究报告批复内容有重大变更或变更投资超出已批复总投资额度10%的，应重新报批可行性研究报告。项目初步设计方案和投资概算报告的编制内容与项目可行性研究报告批复内容有少量调整且其调整内容未超出已批复总投资额度10%的，需在提交项目初步设计方案和投资概算报告时以独立章节对调整部分进行定量补充说明。
22、立项流程：（必须掌握）
甲方：（初步需求）---编写项目申请书----可行性研究----项目论证-----项目评估-----获得批复-------发布招标文件（一般是这样，有的是有能力自己建设）
乙方：看到招标文件----做识别、可行性研究、论证、评估 -----决定投标------中标-----甲乙双方签订合同。
第4章项目整体管理
1、项目章程是正式批准项目的文件。由于项目章程要授权项目经理在项目活动中动用组织的资源，所以，项目经理任何时候都应在规划开始之前被委派，最好是在制定项目章裎之时。
2、项目章程是由项目实施组织外部签发的。千万记住不是项目经理发布的。
3、项目章程应当包括以下内容（直接列入或援引其他文件)。
（1）项目目的或批准项目的原因。
（2）可测量的项目目标和相关的成功标准。
（3）项目的总体要求。
（4）概括性的项目描述。
（5）项目的主要风险。
（6）总体里程碑进度计划。
（7）总体预算。
（8）项目审批要求（用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）。
（9）委派的项目经理及其职责和职权。
（10）发起人或其他批准项目章程的人员的姓名和职权。
4、项目章程的批准，标志着项目的正式启动。在项目中；应尽早确认并任命项目经理，由于项目章程将授权项目经理在项目活动中使用组织资源，项目经理应该参与制定项目章程。
5、项目工作说明书：工作说明书指明如下事项之一：（1）业务需求（2）产品范围说明书（3）战略计划
6、事业环境因素，注意和组织过程资产的区分
7、财务方面的考虑向来是项目选择过程中的重要考虑因素。三个主要的项目财务价值评价方法包括净现值分析、投资收益和投资回收率分析。
（1）净现值分析
（2）投资收益率分析：ROI是将净收入除以投资额的所得值。ROI越大越好。
ROI=（总的折现收益-总的折现成本）/折现成本
（3）投资回收期分析
8、项目目标具有如下特性。（1）项目的目标有不同的优先级（2）项目目标具有层次性注意和项目特点的区别。
9、引导技术可用于指导项目章程的制定。头脑风暴、冲突处理、问题解决和会议管理等，都是引导者可以用来帮助团队和个人完成项目活动的关键技术。
10、项目管理计划记录了计划过程组的各个计划子过程的全部成果，包括：（掌握）
（1）项目管理团队选择的各个项目管理过程。
（2）每一选定过程的实施水平。
（3）对实施这些过程时使用的工具与技术所做的说明。
（4）在管理具体项目中使用选定过程的方式和方法，包括过程之间的依赖关系和相互作用，以及重要的依据和成果。
（5）为了实现项目目标所执行工作的方式、方法。
（6）监控变更的方式、方法。
（7）实施配置管理的方式、方法。
（8）使用实施效果测量基准并使之保持完整的方式、方法。
（9）项目干系人之间的沟通需要与技术。
（10）选定的项目生命期和多阶段项目的项目阶段。
（11）高层管理人员为了加快解决未解决的问题和处理未做出的决策，对内容、范围和时间安排的关键审查。11、分析技术：在项目管理中，根据可能的项目或环境变量的变化，以及它们与其他变量之间的关系，采用分析技术来预测潜在的后果。例如，可用于项目的分析技术包括：回归分析；分组方法；因果分析；根本原因分析；预测方法（如时间序列、情景构建、模拟等）；失效模式与影响分析；故障树分析；储备分析；趋势分析；挣值管理；差异分析。（掌握）
12、项目计划编制工作流程：对论文有帮助的
1）明确目标
2）成立初步的项目团队
3）工作准备与信息收集
4）依据模板、标准编写初步的概要的项目计划。
5）把上述计划纳入项目计划，然后对项目计划进行综合平衡、优化
6）项目经理负责组织编写项目计划
7）评审与批准项目计划
8）获得批准后的项目计划就是项目的基准计划。
13、编制项目计划所遵循的基本原则有：目标的统一管理、方案的统一管理、过程的统一管理、技术工作与管理工作的统一协调、计划的统一管理、人员资源的统一管理、各干系人的参与、逐步精确。
第5章项目范围管理
1、项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。
2、判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，则根据产品是否满足了产品描述来判断。
3、范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，包含如下内容
（1）如何制订项目范围说明书。
（2）如何根据范围说明书创建WBS。
（3）如何维护和批准WBS。
（4）如何确认和正式验收已完成的项目可交付成果。
（5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。
4、项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
5、需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
6、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。主要包括以下内容。
（1）如何规划、跟踪和汇报各种需求活动。
（2）需求管理需要使用的资源。
（3）培训计划
（4）项目干系人参与需求管理的策略
（5）判断项目范围与需求不一致的准则和纠正规程
（6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求
（7）配置管理活动
7、需求的分类（1）业务需求（2）干系人需求（3）过渡需求（4）质量需求，QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。
8、收集需求的工具与技术主要有访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析等。
9、焦点小組：将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人弓I导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。焦点小组是一种群体访谈而非一对--访谈，可以有6〜10个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。
10、引导式研讨会：通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一个好处是，能够比单项会议更快地发现和解决问题。
11、群体创新技木是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
（1）头脑风暴：各抒己见
（2）名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法
（3）德尔菲技术：可以防止个人的观点被不正确的放大
（4）概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
（5）亲和图又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。
（6）多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
12、群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
13、标杆对照将实际或计划的做法与其他类似组织的做法(例如,流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据…标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。
14、系统交互图是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
15、文件分析就是通过分析现有文档,识别与需求相关的信息来挖掘需求。可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等
16、收集需求过程的主要输出有需求文件和需求跟踪矩阵。需求文件描述各种单一的需求将如何满足与项目相关的业务需求。
17、需求文件的内容包括（但不限于）以下几个方面：（1）业务需求（2）干系人需求（3）解决方案需求（4）项目需求（5）过渡需求。（6）与需求有关的假设条件、依赖关系和制约因素。
18、需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。
19、可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。可验证性是需求的最基本特性。
20、每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型。
21、从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。注意区分追溯和回溯。
22、由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
23、第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
24、表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
25、应在需求跟踪矩阵中记录每个需求的相关属性这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。
26、产品分析是一种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
27、项目范围说明书包括如下内容：（1）产品范围描述（2）验收标准（3）可交付成果（4）项目的除外责任（5）制约因素（6）假设条件。
28、里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线。
29、工作包是位于WBS每条分支最底层的可交付成果或项目工作组成部分，工作包的大小需要遵循8/80原则。
30、控制账户是一种管理控制点。是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。
31、规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分。是在控制账户之下、工作包之上的WBS要素，是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
32、WBS词典也称为WBS词汇表，它是描述WBS各组成部分的文件
33、创建WBS过程的工具与技术主要有分解和专家判断，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作。
（2）确定WBS的结构和编排方法。
（3）自上而下逐层细化分解。
（4）为WBS组件制定和分配标识编码。
（5）核实可交付成果分解的程度是恰当的。
34、分解的原则
（1）功能或者技术原则。在创建WBS时，需要考虑将不同人员的工作分开。
（2）组织结构。对于职能型的项目组织而言，WBS也要适应项目的组织结构形式
（3）系统或者子系统。总的系统划分为几个主要的子系统，然后对每个子系统再进行分解
35、在进行WBS分解时，可以有如下三种方式注意，如果说是第一层，
（1）将项目生命周期的各阶段作为分解的第二层
（2）主要可交付成果作为分解的第二层
（3）子项目作为分解的第二层
36、WBS不是某个项目团队成员的责任,应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
37、较常用的WBS表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。
38、树型结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌。用于中小型项目。表格形式的直观性比较差，但能够反映出项目所有的工作要素，用于大型项目。
39、在分解的过程中，应该注意以下8个方面。
（1）WBS必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。
（2）WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动
（3）WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
（4）WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与
（5）WBS的指导。作为指导而不是原则，WBS应控制在4〜6层。当然，大项目可以超过6层。
（6）WBS应包括项目管理工作,也要包括分包出去的工作。
（7）WBS的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
（8）WBS并非是一成不变的…在完成了WBS之后的工作中,仍然有可能需要对WBS进行修改。
40、当一个项目的WBS分解完成后，项目干系人对完成的WBS应该给予确认，并对此达成共识。
41、确认范围的主要工具与技术是检查和群体决策技术。检査也称为审查、评审、审计、走查、巡检、测试等。
42、确认范围应该贯穿项目的始终，一般步骤如下
（1）确定需要进行范围确认的时间。
（2）识别范围确认需要哪些投入。
（3）确定范围正式被接受的标准和要素。
（4）确定范围确认会议的组织步骤。
（5）组织范围确认会议。
43、确认范围与核实产品：核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
44、确认范围与质量控制，确认范围与质量控制的不同之处在于：
（1）确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准)。
（2）质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。
（3）质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。
45、确认范围与项目收尾，确认范围与项目收尾的不同之处在于：
（1）虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
（2）确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
46、需求工程：与需求相关的活动都叫做需求工程，分为2类：一类是需求开发、一类是需求管理。
47、需求开发主要包含：需求获取（捕获用户的需求）、需求分析（将需求信息进行分析、抽象描述、建立概念模型）、需求定义（编制《需求规格说明书》）、需求验证（对需求文档进行评审，确认需求。）在需求开发中，完成需求验证过程后将确定需求基线。
48、需求管理包含：制定需求管理计划（如何进行需求管理的）、求得对需求的理解（确保项目干系人对需求正确理解）、求得对需求的承诺（实现需求所需的活动人员之间达成一致和建立承诺）、管理需求变更（通过变更流程对需求进行管理，防止需求蔓延）、维护对需求的双向跟踪性（需求文档和产品之间的双向跟踪）、识别项目工作与需求之间的不一致性（识别项目计划和工作产品与需求之间的不一致之处）。