5.2.3.1 需求文件
需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。前者是相关方的需要，后者是指如何实现这些需要。把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求的类别包括：
- 业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
- 相关方需求。相关方或相关方群体的需要。
- 解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
- 功能需求。功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。
- 非功能需求。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
- 过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
- 项目需求。项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
- 质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。
可在本过程更新的项目文件包括（但不限于）：
- 活动清单。见 6.2.3.1 节。为完成项目工作，可以通过增加或修改活动来更新活动清单。
- 假设日志。见 4.1.3.2 节。可以增加新的假设条件和制约因素，也可以更新或关闭已有的假设条件和制约因素。
- 经验教训登记册。见 4.4.3.1 节。任何有助于提高当前或未来项目绩效的经验教训都应得到及时记录。
- 需求文件。见 5.2.3.1 节。在本过程中可以识别新的需求，也可以适时更新需求的实现情况。
- 风险登记册。见 11.2.3.1 节。在本过程中可以识别新的风险，也可以更新现有风险。风险登记册用于在风险管理过程中记录风险。
- 相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。
可用于本过程输入的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。假设日志记录了与技术规范、估算、进度和风险等有关的全部假设条件和制约因素。
- 估算依据。见 6.4.3.2 节和 7.2.3.2 节。估算依据用于根据实际结果来评估持续时间、成本和资源估算，以及成本控制。
- 变更日志。见 4.6.3.3 节。变更日志包含了整个项目或阶段期间的所有变更请求的状态。
- 问题日志。见 4.3.3.3 节。问题日志用于确认没有未决问题。
- 经验教训登记册。见 4.3.3.1 节。在归入经验教训知识库之前，完成对阶段或项目经验教训的总结。
- 里程碑清单。见 6.2.3.3 节。里程碑清单列出了完成项目里程碑的最终日期。
- 项目沟通记录。见 10.2.3.1 节。项目沟通记录包含整个项目期间所有的沟通。
- 质量控制测量结果。见 8.3.3.1 节。质量控制测量结果记录了控制质量活动的结果，证明符合质量要求。
- 质量报告。见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。
- 需求文件。见 5.2.3.1 节。需求文件用于证明符合项目范围。
- 风险登记册。见 11.2.3.1 节。风险登记册提供了有关项目期间发生的风险的信息。
- 风险报告。见 11.2.3.2 节。风险报告提供了有关风险状态的信息，用于确认项目结束时没有未关闭的风险。
见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：
- 商业分析；
- 需求获取；
- 需求分析；
- 需求文件；
- 以往类似项目的项目需求；
- 图解技术；
- 引导；
- 冲突管理。
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。
跟踪需求包括（但不限于）：
- 业务需要、机会、目的和目标；
- 项目目标；
- 项目范围和 WBS 可交付成果；
- 产品设计；
- 产品开发；
- 测试策略和测试场景；
- 高层级需求到详细需求。
应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。图 5-7是需求跟踪矩阵示例，其中列有相关的需求属性。
图 5-7需求跟踪矩阵示例
Programs Portfolios
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。图 5-8 描述本过程的输入、工具与技术和输出。图 5-9 是本过程的数据流向图。
图 5-8定义范围：输入、工具与技术和输出
图 5-9定义范围：数据流向图
由于在收集需求过程中识别出的所有需求未必都包含在项目中，所以定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细的项目范围说明书，对项目成功至关重要。
应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。
此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。
可作为本过程输入的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。假设日志识别了有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。
- 需求文件。见 5.2.3.1 节。需求文件识别了应纳入范围的需求。
- 风险登记册。见 11.2.3.1 节。风险登记册包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。
项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变更请求或额外工作是否超过项目边界提供基准。
项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：
- 产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
- 可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
- 验收标准。可交付成果通过验收前必须满足的一系列条件。
- 项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。
表 5-1项目章程与项目范围说明书的内容
可在本过程更新的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
- 需求文件。见 5.2.3.1 节。可以通过增加或修改需求而更新需求文件。
- 需求跟踪矩阵。见 5.2.3.2 节。应该随同需求文件的更新而更新需求跟踪矩阵。
- 相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。
可作为本过程输入的项目文件包括（但不限于）：
- 项目范围说明书。见 5.3.3.1 节。项目范围说明书描述了需要实施的工作及不包含在项目中的工作。
- 需求文件。见 5.2.3.1 节。需求文件详细描述了各种单一需求如何满足项目的业务需要。
可在本过程更新的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
- 需求文件。见 5.2.3.1 节。可以更新需求文件，以反映在本过程提出并已被批准的变更。
确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。图 5-15 描述本过程的输入、工具与技术和输出。图 5-16 是本过程的数据流向图。
图 5-15确认范围：输入、工具与技术和输出
图 5-16确认范围：数据流向图
由客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。本过程对可交付成果的确认和最终验收，需要依据：从项目范围管理知识领域的各规划过程获得的输出（如需求文件或范围基准），以及从其他知识领域的各执行过程获得的工作绩效数据。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
可作为本过程输入的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
- 质量报告。见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
- 需求文件。见 5.2.3.1 节。将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法。
- 需求文件。见 5.2.3.1 节。记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
- 需求跟踪矩阵。见 5.2.3.2 节。根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
可作为本过程输入的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以改进范围控制。
- 需求文件。见 5.2.3.1 节。需求文件用于发现任何对商定的项目或产品范围的偏离。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。
- 需求文件。见 5.2.3.1 节。可以通过增加或修改需求而更新需求文件。
- 需求跟踪矩阵。见 5.2.3.2 节。应该随同需求文件的更新而更新需求跟踪矩阵。
根据成本基准，确定总资金需求和阶段性（如季度或年度）资金需求。成本基准中既包括预计支出及预计债务。项目资金通常以增量的方式投入，并且可能是非均衡的，呈现出图 7-9 中所示的阶梯状。
如果有管理储备，则总资金需求等于成本基准加管理储备。在资金需求文件中，也可说明资金来源。
可作为本过程输入的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。假设日志记录与质量要求和标准合规性有关的所有假设条件和制约因素。
- 需求文件。见 5.2.3.1 节。需求文件记录项目和产品为满足相关方的期望应达到的要求，它包括（但不限于）针对项目和产品的质量要求。这些需求有助于项目团队规划将如何实施项目质量控制。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求连接到可交付成果，有助于确保需求文件中的各项需求都得到测试。矩阵提供了核实需求时所需测试的概述。
- 风险登记册。见 11.2.3.1 节。风险登记册包含可能影响质量要求的各种威胁和机会的信息。
- 相关方登记册。见 13.1.3.1 节。相关方登记册有助于识别对质量有特别兴趣或影响的相关方，尤其注重客户和项目发起人的需求和期望。
可作为本过程输入的项目文件包括（但不限于）：
- 项目进度计划。见 6.5.3.2 节。项目进度计划提供了所需资源的时间轴。
- 需求文件。见 5.2.3.1 节。需求文件指出了项目所需的资源的类型和数量，并可能影响管理资源的方式。
- 风险登记册。见 11.2.3.1 节。风险登记册包含可能影响资源规划的各种威胁和机会的信息。
- 相关方登记册。见 13.1.3.1 节。相关方登记册有助于识别对项目所需资源有特别兴趣或影响的那些相关方，以及会影响资源使用偏好的相关方。
资源需求识别了各个工作包或工作包中每个活动所需的资源类型和数量，可以汇总这些需求，以估算每个工作包、每个 WBS 分支以及整个项目所需的资源。资源需求描述的细节数量与具体程度因应用领域而异，而资源需求文件也可包含为确定所用资源的类型、可用性和所需数量所做的假设。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。项目中遇到的挑战、本可以规避这些挑战的方法，以及良好的资源获取方式更新在经验教训登记册中。
- 项目进度计划。见 6.5.3.2 节。所需资源的可用性可能会导致项目进度的变更。
- 资源分解结构。见 9.2.3.3 节。在本过程中获取的资源应记录到资源分解结构中。
- 资源需求。见 9.2.3.1 节。可更新资源需求文件，以反映获取的项目资源。
- 风险登记册。见 11.2.3.1 节。本过程中识别的新风险记录在风险登记册中，并通过风险管理过程进行管理。
- 相关方登记册。见 13.1.3.1 节。增加的任何新的相关方，以及在本过程中获得的有关现有相关方的新信息更新在相关方登记册中。
可作为本过程输入的项目文件包括（但不限于）：
- 需求文件。见 5.2.3.1 节。需求文件可能包含项目相关方对沟通的需求。
- 相关方登记册。见 13.1.3.1 节。相关方登记册用于规划与相关方的沟通活动。
项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。项目风险管理的目标在于提高正面风险的概率和（或）影响，降低负面风险的概率和（或）影响，从而提高项目成功的可能性。
项目风险管理的过程是：
11.1 规划风险管理 — 定义如何实施项目风险管理活动的过程。
11.2 识别风险 — 识别单个项目风险，以及整体项目风险的来源，并记录风险特征的过程。
11.3 实施定性风险分析 — 通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。
11.4 实施定量风险分析 — 就已识别的单个项目风险和其他不确定性的来源对整体项目目标的综合影响进行定量分析的过程。
11.5 规划风险应对 — 为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。
11.6 实施风险应对 — 执行商定的风险应对计划的过程。
11.7 监督风险 — 在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。
图 11-1 概括了项目风险管理的各个过程。虽然在本《PMBOK® 指南》中，各项目管理风险过程
以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 11-1项目风险管理概述
项目风险管理的核心概念既然项目是为交付收益而开展的、具有不同复杂程度的独特性工作，那自然就会充满风险。
开展项目，不仅要面对各种制约因素和假设条件，而且还要应对可能相互冲突和不断变化的相关方期望。组织应该有目的地以可控方式去冒项目风险，以便平衡风险和回报，并创造价值。
项目风险管理旨在识别和管理未被其他项目管理过程所管理的风险。如果不妥善管理，这些风险有可能导致项目偏离计划，无法达成既定的项目目标。因此，项目风险管理的有效性直接关乎项目成功与否。
每个项目都在两个层面上存在风险。每个项目都有会影响项目达成目标的单个风险，以及由单个项目风险和不确定性的其他来源联合导致的整体项目风险。考虑整体项目风险，也非常重要。项目风险管理过程同时兼顾这两个层面的风险。它们的定义如下：
- 单个项目风险是一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
- 整体项目风险是不确定性对项目整体的影响，是相关方面临的项目结果正面和负面变异区间。
它源于包括单个风险在内的所有不确定性。
一旦发生，单个项目风险会对项目目标产生正面或负面的影响。项目风险管理旨在利用或强化正面风险（机会），规避或减轻负面风险（威胁）。未妥善管理的威胁可能引发各种问题，如工期延误、成本超支、绩效不佳或声誉受损。把握好机会则能够获得众多好处，如工期缩短、成本节约、绩效改善或声誉提升。
整体项目风险也有正面或负面之分。管理整体项目风险旨在通过削弱负面变异的驱动因素，加强正面变异的驱动因素，以及最大化实现整体项目目标的概率，把项目风险敞口保持在可接受的范围之内。
因为风险会在项目生命周期内持续发生，所以，项目风险管理过程也应不断迭代开展。在项目规划期间，就应该通过调整项目策略对风险做初步处理。接着，应该随着项目进展，监督和管理风险，确保项目处于正轨，并且突发性风险也得到处理。
为有效管理特定项目的风险，项目团队需要知道，相对于要追求的项目目标，可接受的风险敞口究竟是多大。这通常用可测量的风险临界值来定义。风险临界值反映了组织与项目相关方的风险偏好程度，是项目目标的可接受的变异程度。应该明确规定风险临界，并传达给项目团队，同时反映在项目的风险影响级别定义中。
项目风险管理的发展趋势和新兴实践项目风险管理的关注面正在扩大，以便确保考虑所有类型的风险，并在更广泛的背景中理解项目风险。项目风险管理的发展趋势和新兴实践包括（但不限于）：
- 非事件类风险。大多数项目只关注作为可能发生或不发生的不确定性未来事件的风险。例如：
关键卖方可能在项目期间停业，客户可能在设计完成后变更需求，或分包商可能要求对标准化操作流程进行优化。
不过，识别并管理非事件类风险的意识正在不断加强。非事件类风险有两种主要类型：
- 变异性风险。已规划事件、活动或决策的某些关键方面存在不确定性，就导致变异性风险。例如，生产率可能高于或低于目标值，测试发现的错误数量可能多于或少于预期，或施工阶段可能出现反常的天气情况。
- 模糊性风险。对未来可能发生什么，存在不确定性。知识不足可能影响项目达成目标的能力，例如，不太了解需求或技术解决方案的要素、法规框架的未来发展，或项目内在的系统复杂性。
变异性风险可通过蒙特卡洛分析加以处理，即：用概率分布表示变异的可能区间，然后采取行动去缩小可能结果的区间。管理模糊性风险，则需要先定义认知或理解不足之处，进而通过获取外部专家意见或以最佳实践为标杆来填补差距。也可以采用增量开发、原型搭建或模拟等方法来处理模糊性风险。
- 项目韧性。随着对所谓“未知-未知”因素的意识的增强，人们也越来越明确地知道确实存在突发性风险。这种风险只有在发生后才能被发现。可以通过加强项目韧性来应对突发性风险。
这就要求每个项目：
- 除了为已知风险列出具体风险预算，还要为突发性风险预留合理的应急预算和时间；
- 采用灵活的项目过程，包括强有力的变更管理，以便在保持朝项目目标推进的正确方向的同时，应对突发性风险；
- 授权目标明确且值得信赖的项目团队在商定限制范围内完成工作；
- 经常留意早期预警信号，以尽早识别突发性风险；
- 明确征求相关方的意见，以明确为应对突发性风险而可以调整项目范围或策略的领域。
- 整合式风险管理。项目存在于组织背景中，可能是项目集或项目组合的一部分。在项目、项目集、项目组合和组织这些层面上，都存在风险。应该在适当的层面上承担和管理风险。在较高层面识别出的某些风险，将被授权给项目团队去管理；而在较低层面识别出的某些风险，又可能上交给较高层面去管理（如果在项目之外管理最有效）。应该采用协调式企业级风险管理方法，来确保所有层面的风险管理工作的一致性和连贯性。这样就能使项目集和项目组合的结构具有风险效率，有利于在给定的风险敞口水平下创造最大的整体价值。
裁剪时需要考虑的因素因为每个项目都是独特的，所以有必要对项目风险管理过程的应用方式进行裁剪。裁剪时应考虑的因素包括（但不限于）：
- 项目规模。由预算、持续时间、范围或团队人数所体现的项目规模，要求采取更详细的风险管理方法吗？或者项目小到只需要用简化的风险管理过程吗？
- 项目复杂性。由高水平创新、新技术采用、商务安排、界面或外部依赖关系导致的项目复杂性提高，是否要求采用更稳健的风险管理方法？或者项目是否简单到只需要用简化的风险管理过程？
- 项目重要性。项目的战略重要性有多大？项目的风险级别因旨在创造突破性机会、克服组织经营的重大障碍或涉及重大产品创新而提高了吗？
- 开发方法。它是否是瀑布式项目，风险管理过程可以相继或重复开展；或者此项目是否采取敏捷型方法，需在每个重复过程的开始阶段以及执行期间处理风险？
根据上述需考虑的因素来裁剪项目风险管理过程，这是规划风险管理过程的一部分工作。裁剪结果将被记录在风险管理计划中。
在敏捷或适应型环境中需要考虑的因素从本质上讲，越是变化的环境就存在越多的不确定性和风险。要应对快速变化，就需要采用适应型方法管理项目，即：通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理。在选择每个迭代期的工作内容时，应该考虑风险；在每个迭代期间应该识别、分析和管理风险。
此外，应该根据对当前风险敞口的理解的加深，定期更新需求文件，并随项目进展重新排列工作优先级。
可作为本过程输入的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素可能引发单个项目风险，还可能影响整体项目风险的级别。
- 成本估算。见 7.2.3.1 节。成本估算是对项目成本的定量评估，理想情况下用区间表示，区间的大小预示着风险程度。对成本估算文件进行结构化审查，可能显示当前估算不足，从而引发项目风险。
- 持续时间估算。见 6.4.3.1 节。持续时间估算是对项目持续时间的定量评估，理想情况下用区间表示，区间的大小预示着风险程度。对持续时间估算文件进行结构化审查，可能显示当前估算不足，从而引发项目风险。
- 问题日志。见 4.3.3.3 节。问题日志所记录的问题可能引发单个项目风险，还可能影响整体项目风险的级别。
- 经验教训登记册。见 4.4.3.1 节。可以查看与项目早期所识别的风险相关的经验教训，以确定类似风险是否可能在项目的剩余时间再次出现。
- 需求文件。见 5.2.3.1 节。需求文件列明了项目需求，使团队能够确定哪些需求存在风险。
- 资源需求。见 9.2.3.1 节。资源需求是对项目所需资源的定量评估，理想情况下用区间表示，区间的大小预示着风险程度。对资源需求文件进行结构化审查，可能显示当前估算不足，从而引发项目风险。
- 相关方登记册。见 13.1.3.1 节。相关方登记册规定了哪些个人或小组可能参与项目的风险识别工作，还会详细说明哪些个人适合扮演风险责任人角色。
可作为本过程输入的项目文件包括（但不限于）：
- 里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
- 项目团队派工单。见 9.3.3.2 节。项目团队派工单包含关于项目团队技能和能力的信息，以及他们可用于支持采购活动的时间。如果项目团队不具备开展采购活动的能力，则需要外聘人员或对现有人员进行培训，或者二者同时进行。
- 需求文件。见 5.2.3.1 节。需求文件可能包括：
- 卖方需要满足的技术要求；
- 具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
- 资源需求。见 9.2.3.1 节。资源需求包含关于某些特定需求的信息，例如，可能需要采购的团队及实物资源。
- 风险登记册。见 11.2.3.1 节。风险登记册列明风险清单，以及风险分析和风险应对规划的结果。有些风险应通过采购协议转移给第三方。
- 相关方登记册。见 13.1.3.1 节。相关方登记册提供有关项目参与者及其项目利益的详细信息，包括监管机构、合同签署人员和法务人员。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录任何与法规和合规性、数据收集、数据分析和供方选择分析相关的经验教训。
- 里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
- 需求文件。见 5.2.3.1 节。需求文件可能包括：
- 卖方需要满足的技术要求；
- 具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
- 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，任何被选中的卖方都会带来特殊的风险。
- 相关方登记册。见 13.1.3.1 节。更新相关方登记册，记录任何关于相关方的补充信息，尤其是监管机构、合同签署人员，以及法务人员的信息。
可作为本过程输入的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。在项目早期获取的与实施采购有关的经验教训，可用于项目后期阶段，以提高本过程的效率。
- 项目进度计划。见 6.5.3.2 节。项目进度计划确定项目活动的开始和结束日期，包括采购活动。
它还会规定承包商最终的交付日期。
- 需求文件。见 5.2.3.1 节。需求文件可能包括：
- 卖方需要满足的技术要求；
- 具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
- 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，任何被选中的卖方都会带来特殊的风险。
- 相关方登记册。见 13.1.3.1 节。此文件包含与已识别相关方有关的所有详细信息。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录在实施采购期间所遇到的挑战、本可采取的规避方法，以及有效的方法。
- 需求文件。见 5.2.3.1 节。需求文件可能包括：
- 卖方需要满足的技术要求；
- 具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
- 需求跟踪矩阵。见 5.2.3.2 节。随着将卖方纳入项目计划，可能需要根据特定卖方的能力，变更需求登记册及跟踪矩阵。
- 资源日历。见 9.2.1.2 节。可能需要根据卖方的可用性更新与进度计划有关的资源日历。
- 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，每个被选中的卖方都会带来特殊的风险。在合同签署过程中，应该对风险登记册进行变更，以反映每个卖方带来的具体风险。
- 相关方登记册。见 13.1.3.1 节。此文件包含与已识别相关方有关的所有详细信息。 与具体卖方签订协议后，需要更新相关方登记册。
可作为本过程输入的项目文件包括（但不限于）：
- 假设日志。见 4.1.3.2 节。假设日志记录了采购过程中做出的假设。
- 经验教训登记册。见 4.4.3.1 节。在项目早期获取的经验教训可供项目未来使用，以改进承包商绩效和采购过程。
- 里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
- 质量报告。见 8.2.3.1 节。质量报告用于识别不合规的卖方过程、程序或产品。
- 需求文件。见 5.2.3.1 节。需求文件可能包括：
- 卖方需要满足的技术要求；
- 具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
- 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
- 风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，每个被选中的卖方都会带来特殊的风险。
- 相关方登记册。见 13.1.3.1 节。相关方登记册包括关于已识别相关方的信息，例如，合同团队成员、选定的卖方、签署合同的专员，以及参与采购的其他相关方。
并非任何项目文件都将成为首次识别相关方的输入。然而，需要在整个项目期间识别相关方。项目经历启动阶段以后，将会生成更多项目文件，用于后续的项目阶段。可作为本过程输入的项目文件包括（但不限于）：
- 变更日志。见 4.6.3.3 节。变更日志可能引入新的相关方，或改变相关方与项目的现有关系的性质。
- 问题日志。见 4.3.3.3 节。问题日志所记录的问题可能为项目带来新的相关方，或改变现有相关方的参与类型。
- 需求文件。见 5.2.3.1 节。需求文件可以提供关于潜在相关方的信息。
可用作本过程输入的项目文件包括（但不限于）：
- 变更日志；
- 问题日志；
- 需求文件。
可用作本过程输入的项目文件包括（但不限于）：
- 假设日志；
- 需求文件；
- 风险登记册。
可在本过程更新的项目文件包括（但不限于）：
- 假设日志；
- 需求文件；
- 需求跟踪矩阵；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 项目范围说明书；
- 需求文件。
可在本过程更新的项目文件包括（但不限于）：
- 假设日志；
- 需求文件。
可用作本过程输入的项目文件包括（但不限于）：
- 假设日志；
- 需求文件；
- 需求跟踪矩阵；
- 风险登记册；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 项目进度计划；
- 需求文件；
- 风险登记册；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 需求文件；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 假设日志；
- 成本估算；
- 持续时间估算；
- 问题日志；
- 经验教训登记册；
- 需求文件；
- 资源需求；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 里程碑清单；
- 项目团队派工单；
- 需求文件；
- 需求跟踪矩阵；
- 资源需求；
- 风险登记册；
- 相关方登记册。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册；
- 里程碑清单；
- 需求文件；
- 需求跟踪矩阵；
- 风险登记册；
- 相关方登记册。
可在本过程更新的项目文件包括（但不限于）：
- 活动清单；
- 假设日志；
- 经验教训登记册；
- 需求文件；
- 风险登记册；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 经验教训登记册；
- 项目进度计划；
- 需求文件；
- 风险登记册；
- 相关方登记册。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册；
- 需求文件；
- 需求跟踪矩阵；
- 资源日历；
- 风险登记册；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 经验教训登记册；
- 质量报告；
- 需求文件；
- 需求跟踪矩阵。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册；
- 需求文件；
- 需求跟踪矩阵。
可用作本过程输入的项目文件包括（但不限于）：
- 经验教训登记册；
- 需求文件；
- 需求跟踪矩阵。
可在本过程更新的项目文件包括（但不限于）：
- 经验教训登记册；
- 需求文件；
- 需求跟踪矩阵。
可用作本过程输入的项目文件包括（但不限于）：
- 假设日志；
- 经验教训登记册；
- 里程碑清单；
- 质量报告；
- 需求文件；
- 需求跟踪矩阵；
- 风险登记册；
- 相关方登记册。
可用作本过程输入的项目文件包括（但不限于）：
- 假设日志；
- 估算依据；
- 变更日志；
- 问题日志；
- 经验教训登记册；
- 里程碑清单；
- 项目沟通记录；
- 质量控制测量结果；
- 质量报告；
- 需求文件；
- 风险登记册；
- 风险报告。