本文阐述了信息系统项目管理师的需求管理，需求管理在信息系统中的目的是确保项目各方对需求的一致理解，管理和控制需求的变更，实现从需求到最终产品的双向跟踪。在本项目中，我重点关注以下几个方面的需求管理工作。
一、需求管理计划
需求管理计划对于需求管理工作的成功实施，起着重要的作用，我通过如下步骤，完成制定需求管理计划：
首先，明确需求管理涉及的干系人、角色和职责。为避免需求缺乏一个统一的入口及出口。在本项目中，我们要求客户方安排一名的需求接口人，我方也安排一名需求接口人。所有的客户需求均由客户接口人收集并整理后发给我方需求接口人。对于需求的反馈意见，也由该接口人统一对外传递。通过该约定，避免了因客户直接面对开发人员，导致需求零散且随意变化的情况发生；
明确需求管理采用的平台，如需求管理工具等。在本项目中，我们采用IBMRationalRequisitePro(以下简称RP)作为该项目的需求管理工具，主要实现需求双向跟踪管理等。采用IBMRationalClearQuest(以下简称CQ)作为需求变更管理工具。这两个工具的组合，很好的帮我们团队实现了需求跟踪管理及变更管理。所有达成一致的需求我均会将其导入RP中进行管理；
制定需求变更控制管理流程，并指定变更控制委员会成员组成，从人员安排到流程制度做好管理规划，为后续的项目变更做好基础工作，以便于需求管理人员按计划开展需求管理工作。
编写需求管理计划，在本项目中，采用公司CMMI体系的需求管理计划模板，进行计划的编写，重点描述了上述内容。完成了需求管理计划编写后，由项目经理、架构师、产品经理、各小组TL、QA、客户等共同对需求管理计划进行评审，评审通过后需客户签字确认认可；
二、需求变更
随着软件技术的复杂化，架构的多样化，业务的灵活化，以及随着客户对所需系统目标及需求的清晰化，变更是不可避免的，管理变更是目前项目成功的关键因素。因此，需求变更管理在整个项目的需求管理工作中显得尤其重要。
在本项目中我们采用如下需求变更管理流程。
首先是客户需求接口人提出需求变更清单(记录需求变更项)，我方需求接口人接收到该需求变更，并在CQ上发起需求变更流程，并分配给技术负责人；
项目技术负责人接收到需求变更，对该变更进行技术评估，如果技术上可行，进入下一节点;否则给出相关的技术解答，也同样进入下一节点；
项目经理接收到技术分析通过的需求变更，进行资源分析、进度分析等，分析通过的需求变更项，进入CCB审核环节。对于技术负责人分析不通过的需求变更，项目经理经过确认后，结束来流程，处于驳回关闭状态。针对这部分需求变更，需求接口人将给客户予以答复；
对于项目经理审核通过的需求变更，CCB安排人员进行复核，复核通过后，该需求变更将由后续的实施人员(如开发修改代码、需求人员修改需求文档等)进行实施，并安排相关人进行验证。因实施及验证不属于需求变更管理流程，故这里不赘述；
通过上述手段，本项目保证了所有的需求变更都有据可依，同时，也通过完整的需求管理过程，为后续的需求跟踪及相关的测试提供了信息保障。
三、需求跟踪
在实际项目开展过程中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户接收测试时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。本项目采用需求双向跟踪，包括从用户原始需求到系统需求、设计、编码、测试用例等之间的双向跟踪。
双向跟踪包括：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。一旦某个需求需要变更，就可以快速找到所有影响的范围。
·反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。
在本项目里，我们采用RP实现了上述双向跟踪。通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。而且通过RP和CQ集成，在进行需求变更时，我们可快速找到需求关联项。
经过上述过程的努力，项目的外包采购管理过程得到了有效的保障。经过团队的共同努力，该系统顺利在2011年11月份正式上线，半年后通过初验。回顾项目的整体需求管理工作过程，虽然基本上满足要求，但仍然存在许多小问题，包括对客户安全性需求把握不够、用户交互类产品用户体验不足等。发现这些问题后，我们及时的采取应急措施进行补救，总体上没有对项目进展造成大的影响。
综上所述，严谨的需求管理计划、严格的需求变更控制、需求双向跟踪管理，是我项目中需求管理中的几个主要实践，为项目的成功奠定了基础。在以后的项目整体管理工作中，我要加强关注各相关方利益的权衡，继续深化各方沟通，努力提高项目管理水平，更好地完成项目实施管理。
网友评论