一、 关键过程域中的特殊实践都有哪些？
SP1.1 了解需求：与需求的提供者对需求的含义达成一致。
SP1.2 获得需求承诺：获得项目组成员对需求的承诺。
SP1.3 管理需求变更：在项目进行中，管理需求的变更。
SP1.4 维护需求双向追溯性：维护需求和工作产品之间的双向可跟踪性。
SP1.5 界定项目工作与需求的差异：识别项目计划、工作产品和需求之间的不一致。
二、 具体该怎么做？
SP1.1 了解需求：可以编写到需求获取的流程中，当需求获取完成后，由客户确认需求理解的一致性。
子实践：
1.建立区别适当需求提供者的准则清单。
2.建立客观的需求评估及接受准则。
3.分析需求，以确保其符合已建立的准则的要求。
4.与需求提供者达成需求共识，使项目成员可对需求承诺。
SP1.2 获得需求承诺：可以编写到需求评审的流程中，当需求评审完成后，由开发人员确认需求的可实现性。
子实践：
1.评估需求对现有承诺的影响。需求变更或新需求发生时，评估其对项目成员的影响。
2.协商并记录承诺。在项目成员对需求或需求改变承诺之前，对现有承诺的改变，应先协商。
SP1.3 管理需求变更：需要编写一个需求变更的流程，该流程可以合并到配置管理的变更管理流程中。
子实践：
1.记录所有的需求和需求变更，不论是项目本身产生的或外界的要求。
2.维护需求变更纪录，以及每次变更的理由。维护变更的历史纪录，有助于追踪需求变更的状态
3.从相关干系人的观点，评估需求变更的影响。
4.确保项目人员能取得需求和变更的资料。
SP1.4 维护需求双向追溯性：可以在需求开发过程中建立客户需求到产品需求，产品需求到产品需求的跟踪矩阵，可以在设计过程中建立设计到产品需求的跟踪矩阵，在测试过程中建立测试用例到产品需求的跟踪矩阵，以此类推。
子实践：
1.维护需求追溯性，确保已记录低阶(或衍生)需求的来源。
2.维护需求追溯性，从需求到衍生需求，以及需求分配到功能、接口、对象、人员、过程及工作产品。
3.制作需求追溯表。
SP1.5 界定项目工作与需求的差异：可以在需求评审、设计评审、代码评审、测试用例评审、测试、用户手册评审、需求变更、设计变更等流程中体现识别不一致的活动。
子实践：
1.审查项目计划、活动及工作产品，是否与需求及需求变更相符。
2．界定差异来源及其理由。
3.当需求基线有变动时，界定有关计划及工作产品所需的变更。
4.启动矫正措施。
三、 与CMM中对应过程域的实践活动的区别与联系？
区别：CMMI模型中比CMM进一步强化了对需求的重视。
在CMM中，关于需求只有需求管理这一个关键过程域，也就是说，强调对有质量的需求进行管理，而如何获取需求则没有提出明确的要求。
在CMMI的阶段模型中，2级需求管理过程域中，增加了双向追溯性，强调界定项目工作与需求的差异。CMMI模型对工程活动进行了一定的强化。
联系：CMMI以CMM为基础演化而来。
CMMI继承了CMM收集需求、文档化需求等关键过程域活动。