（1）需求文件的内容包括（但不限于）以下几个方面：业务需求，包括可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则。干系人需求，包括对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求。解决方案需求，包括功能和非功能需求、技术和标准合规性(Complicance)需求、支持和培训的需求、质量需求和报告需求。可用纯文本方式或用模型展示解决方案需求，也可两者同时使用。项目需求，包括服务水平、绩效、安全和合规性等，以及验收标准。过渡需求。与需求有关的假设条件、依赖关系和制约因素。

（2）需求跟踪矩阵在CMMI中，需求管理是已管理级的一个关键过程域，其目标是为产品需求建立一个基线，供软件开发及其管理使用，使计划、产品和活动与需求保持一致。从需求工程的角度来看，需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪基线中需求的状态。可跟踪性包含两个层面的含义，一个是项目执行过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前后关系或主从关系的产品。

例如，某个给定构件的需求和设计的匹配程度；另一个是项目产品中每个元素能够建立其存在理由的程度，例如，产品设计中的每个元素定位它所满足需求的程度。

1、需求跟踪的内容每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型，如图5-1所示。

图5-1中的箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。图5-1左半部分表明，从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。如果以用例(usecase)的形式来描述用户需求，图5-1左半部分就是用例和功能需求之间的跟踪情况。图5-1右半部分表明，由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。第五类联系链是需求文件之问的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。

2、需求跟踪矩阵表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束时都能交付，还可以为管理产品范围变更提供框架。需要跟踪的内容包括以下几个方面。业务需求、机会、目的和目标。项目目标。项目范围(WBS可交付成果)。产品设计。产品开发。测试策略和测试场景。高层级需求到详细需求。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵，它保存了需求与后继工作  成果的对应关系。例如，从用户原始需求到需求文件之间的跟踪，可以采用如表5-3所示的矩阵。

对于从需求文件到下游工作产品之间的跟踪，可以采用如表5-4所示的矩阵。

需求跟踪矩阵中可以定义各种产品元素类型间的一对一、～对多和多对多关系，也就是说，允许在表5-4的一个单元格中填入多个元素来实现这些特征。例如，一个构件对应一个设计元素，多个测试案例验证一个功能点，每个用例导致多个功能点等。应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。另外，为了确保干系人满意，可能需要增加一些补充属性，例如，稳定性、复杂性和验收标准等。

3、定义范围

4、创建WBS其中要求举例写出详细的五层WBS。涉及到的知识点如下：WBS将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，直到整个项目都分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。最普通的WBS如表5-5所示。