施，并安排相关人进行验证。因实施及验证不属于需求变更管理流程，故这里不赘述。
通过上述手段，本项目保证了所有的需求变更都有据可依，同时，也通过该完整的需求管理过程，为后续的需求跟踪及相关的测试提供了信息保障。
三、需求跟踪
在实际项目开展中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户UAT（用户接收测试）时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。
本项目需求双向跟踪，包括从用户原始需求到系统需求、设计、编码、测试用例等之间的双向跟踪。如下图所示：
用户需求 系统需求 概设 详设 源码 测试用例 …… 最终产品
1.1 1.1.1 P3 1.1.1 P4 1.1.1 XX.java TC01 …… 功能点1
双向跟踪包括：
·正向跟踪：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。一旦某个需求需要变更，就可以快速找到所有影响的范围。
·反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。
在本项目里，我们采用RP实现了上述双向跟踪。通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。而且通过RP和CQ集成，在进行需求变更时，我们可快速找到需求关联项。
在我参与的这个项目里，作为需求管理负责人，我的工作主要目的是确保项目所有干系人对需求的一致理解，通过CQ管理和控制需求的变更，采用RP实现从需求到最终产品的双向跟踪。主要的工作流程包括制定需求管理计划，并通过评审得到客户的认可，求得项目所有干系人对需求的理解，求得对需求的确认、通过CQ管理需求变更，维护对需求的双向跟踪，并且通过RP的双向跟踪功能，协助我们识别项目工作与需求之间的不一致等。虽说该项目严格按照CMMI的需求管理过程要求实施，但是在实施过程中，也有我们自己的心得体会及教训，下面各列举一两点：
经验：
1.一定在项目启动时，就要和客户就需求接口人予以明确。经过该项目的实践，发现，这个角色的设置，是相当正确的，避免了客户所有业务人员直接面对开发人员的情况，保证了开发所使用的需求都是有依据和证据的。
2.有效的需求跟踪是避免需求遗漏的有效办法之一。可以避免在类似UAT时才发现需求未实现或者实现不全，减少项目上线压力，同时也减少了客户对公司项目团队的不满。正因为如此，通过该项目的实施经历，客户与我们又签订了后续的合同。通过该项目的成功实施，为我司与该客户后续的长期合作奠定了良好基础。
教训：
由于客户工作较忙，在进行需求分析，并对需求达成一致阶段，客户无法保证时间进行配合，无法逐个需求与我方进行沟通，同时，由于客户对需求的理解也有个过程，所以刚开始，客户提供的需求较泛。针对该情况，我方根据类似项目经验，结合我方对客户提供需求的理解进行开发。在提交第一版本给客户时，客户发现该版本与实际需要有一定偏差。此时客户对我们有很大意见。在碰到该问题情况下，我们及时调整需求分析及需求理解策略。经过双方沟通，客户同意我方就关键需求，先开发原型，并就原型与客户进行实际演示，客户针对原型上细化需求，并说明潜在需求。通过迭代式方式，当原型实现的业务与功能达到客户需求时，我们再针对这部分关键需求进行开发。通过需求开发方式、需求达成一致策略的调整，该项目终于如期上线，并按计划通过验收。