论信息系统项目的需求管理

在本项目中我们采用如下需求变更管理流程。

1.首先是客户需求接口人提出需求变更清单(记录需求变更项)，我方需求接口人接收到该需求变更，并在CQ上发起需求变更流程，并分配给技术负责人。

2.项目技术负责人接收到需求变更，对该变更进行技术评估，如果技术上可行，进入下一节点;否则给出相关的技术解答，也同样进入下一节点。

3.项目经理接收到技术分析通过的需求变更，进行资源分析、进度分析等，分析通过的需求变更项，进入CCB审核环节。对于技术负责人分析不通过的需求变更，项目经理经过确认后，结束来流程，处于驳回关闭状态。针对这部分需求变更，需求接口人将给客户予以答复。

4.对于项目经理审核通过的需求变更，CCB安排人员进行复核，复核通过后，该需求变更将由后续的实施人员(如开发修改代码、需求人员修改需求文档等)进行实施，并安排相关人进行验证。因实施及验证不属于需求变更管理流程，故这里不赘述。

通过上述手段，本项目保证了所有的需求变更都有据可依，同时，也通过该完整的需求管理过程，为后续的需求跟踪及相关的测试提供了信息保障。

三、需求跟踪

     在实际项目开展中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户UAT(用户接收测试)时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。

    本项目需求双向跟踪，包括从用户原始需求到系统需求、设计、编码、测试用例等之间的双向跟踪。

用户需求系统需求概设详设源码测试用例……终产品

1.11.1.1P3 1.1.1P4 1.1.1XX.javaTC01……功能点1

　双向跟踪包括：

?正向跟踪：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。一旦某个需求需要变更，可以快速找到所有影响的范围。

?反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。

在本项目里，我们采用RP实现了上述双向跟踪。通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。而且通过RP和CQ集成，在进行需求变更时，我们可快速找到需求关联项。

在我参与的这个项目里，作为需求管理负责人，我的工作主要目的是确保项目所有干系人对需求的一致理解，通过CQ管理和控制需求的变更，采用RP实现从需求到终产品的双向跟踪。主要的工作流程包括制定需求管理计划，并通过评审得到客户的认可，求得项目所有干系人对需求的理解，求得对需求的确认、通过CQ管理需求变更，维护对需求的双向跟踪，并且通过RP的双向跟踪功能，协助我们识别项目工作与需求之间的不一致等。虽说该项目严格按照CMMI的需求管理过程要求实施，但是在实施过程中，也有我们自己的心得体会及教训，下面各列举一两点：

经验：

1.一定在项目启动时，要和客户需求接口人予以明确。经过该项目的实践，发现，这个角色的设置，是相当正确的，避免了客户所有业务人员直接面对开发人员的情况，保证了开发所使用的需求都是有依据和证据的。

2.有效的需求跟踪是避免需求遗漏的有效办法之一。可以避免在类似UAT时才发现需求未实现或者实现不全，减少项目上线压力，同时也减少了客户对公司项目团队的不满。正因为如此，通过该项目的实施经历，客户与我们又签订了后续的合同。通过该项目的成功实施，为我司与该客户后续的长期合作奠定了良好基础。

教训：

由于客户工作较忙，在进行需求分析，并对需求达成一致阶段，客户无法保证时间进行配合，无法逐个需求与我方进行沟通，同时，由于客户对需求的理解也有个过程，所以刚开始，客户提供的需求较泛。针对该情况，我方根据类似项目经验，结合我方对客户提供需求的理解进行开发。在提交第一版本给客户时，客户发现该版本与实际需要有一定偏差。此时客户对我们有很大意见。在碰到该问题情况下，我们及时调整需求分析及需求理解策略。经过双方沟通，客户同意我方关键需求，先开发原型，并原型与客户进行实际演示，客户针对原型上细化需求，并说明潜在需求。通过迭代式方式，当原型实现的业务与功能达到客户需求时，我们再针对这部分关键需求进行开发。通过需求开发方式、需求达成一致策略的调整，该项目终于如期上线，并按计划通过验收。