需求管理过程域的要点

今天在客户处，看到客户拿了一份从网上下载的对CMMI2级、3级的实践的注释，随手翻了一翻，刚读了第1个PA需求管理的5条特定实践，就发现基本上每条实践都有大大小小的误解，我想该材料很容易对CMMI的实施造成负面的影响。因此，特地根据我的咨询经验与体会，对该过程域的理解与实施要点进行了整理。
在下表中：
（1）没有翻译模型的原文；
（2）包含了模型的要点；
（3）扩展了模型的要求；
（4）列出了客户的某些好的实践。
因此，通过该表应更容易理解模型的要求，更容易与实践结合起来，但是列出的理解与实践要点并非都要做到。

实践	理解与实施要点
SP1.1 理解需求：与需求提供者一起理解需求的含义。	（1）先判断需求提供者是否合适，，即哪些人是合法的需求提供者，建立确认合适的需求提供者的准则, （2）再判断提出的需求是否可接受，建立需求可接受的准则 （3）最后和需求提供者对需求达成一致的理解 （4）上述的准则可以定义在需求开发计划书中，也可以体现为单独的检查单。 （5）该过程域的SP1.1 SP1.2 SP1.4 在过程定义时可以放在需求开发过程中，SP1.3可以单独写一个过程，或者和配置管理的变更流程合并，SP1.5可以定在评审的过程中或问题处理的过程中
SP1.2 取得对需求的承诺：取得项目成员对需求的承诺。	（1）此处的需求承诺是需求实现者对需求可实现的承诺不是客户对需求不变的承诺。 （2）需求的承诺有2类时间点：一是需求刚建立时，二是需求变更时。 （3）在需求承诺前，需要开发人员理解需求，一般sp1.1是本实践的基础。 （4）承诺可以是书面的签字，也可以是电子的。 （5）并非每个人都要对需求做出承诺，可以是项目组的核心成员作为代表。 （6）开发组需要对客户有正式的承诺，该承诺一般体现在合同或项目任务书中。 （7）开发人员的承诺可以是和对计划的承诺合在一起，也可以单独承诺，承诺的时机可能不同。
SP1.3 管理需求变更	（1）需求的变化是永恒的 （2）需求是渐变的，是积少成多的 （3）需求的小的变化也要管理 （4）不同规模的需求变更，控制的严格程度不同 （5）在组织内应该区分不同规模的需求变更，并定义不同的流程 （6）需求变更的重点是变更的波及范围分析，在做变更的影响分析时，要考虑对：其他需求、对设计、对编码、对测试、对进度、对工作量、对人员、对风险的影响。 （7）需求变更时要参考需求跟踪矩阵 （8）需求变更的控制组应该有客户参与 （9）客户方的需求变更流程也应该规范 （10）在商务合同中要对需求变更的流程进行定义，规范双方的接口
SP1.4 维护需求的双向可跟踪性	（1）需求跟踪矩阵的主要作用： 验证需求的可实现性、可测试性； 进行需求变更的影响分析。 维护阶段，管理需求的变更 （2）何时使用需求跟踪矩阵： 需求、设计、测试用例评审时； 需求、设计、测试用例等变更时； 功能审计时。 (3) 需求跟踪矩阵分为： 纵向跟踪关系：客户需求到产品需求；需求到设计、测试用例、代码：需求责任分配 横向跟踪关系：需求与需求之间的关系，该跟踪关系对产品集成过程有影响。 （4）在需求、设计、测试用例评审时跟踪矩阵要一起评审
SP1.5 确认项目工作和需求间的差异	（1）在需求评审时、计划评审时、设计评审时、测试用例评审时要识别是否和需求一致。 （2）在需求变更、设计变更、测试用例变更时，要判断是否和需求一致。 （3）在日常工作中也可能发现和需求的不一致。 （4）识别出的不一致问题要有记录，并跟踪问题的关闭