一. 制定需求管理计划
需求管理计划对于需求管理工作的成功实施，起着重要作用。因此在项目启动后，我通过如下步骤，完成制定需求管理计划工作。
1. 与相关人沟通，梳理并明确需求管理工作内容。包括如何组织项目组人员获取用户需求的方式、需求变更控制流程、需求跟踪频度及触发时机等。
2. 明确需求管理涉及的干系人、角色及职责。因需求管理涉及到干系人较多，为避免需求缺乏一个统一的入口及出口。在本项目中，在需求基线建立后,我们要求客户方安排一名的需求接口人，我方也安排一名需求接口人。后期的客户需求均由客户接口人收集并整理后发给我方需求接口人.
3. 明确需求管理采用的平台，如需求管理工具等。在本项目中，我们在用需求跟踪矩阵表实现需求双向跟踪管理。采用svn作为需求变更管理工具。理
4. 编写需求管理计划。在本项目里，采用公司CMMI体系的需求管理计划模板，进行计划的编写。重点描述了上述内容。完成了需求管理计划编写后，由项目经理、各小组组长、QA共同对该需求管理计划进行评审.
在本项目中对需求获取的活动过程做以下描述:我与2010年3月下旬组建了需求调研分析小组，包括我在内共8人，其中客户方业务人员3人，本项目组5人，我起草了访谈人员列表计划，需求调研问卷。通过早组内谈论将客户方的用户类型分为主管业务的领导，业务精通的用户、以及普通用户三类。对业务领导我们采取个别约谈的方式，调研重点是调研项目的总体要求和非功能性要求，对重点核心的业务需求也进行了调研。对业务精通的重点用户采取了座谈会的形式，以讨论的形式诱导用户提出需求。对普通用户采取调研问卷的形式进行调研。对收集到的用户需求记录进行汇总。将汇总资料通过svn版本控制软件分发给需求分析组的组员，让组员做进一步的分析和整理。根据用户的原始需求和公司指定的SRS模板编写了需求规格说明书的初稿，经过反复的与客户方的用户进行需求调研，整理分析，对需求规格说明书内容做必要的修改和增加。与2010年4月底形成了正式的需求规格说明书。2010年5月初我组织了分析人员，设计人员、和测试人员、客户方参与的用户评审和同行需求评审。评审通过后，最后应ppt文件的形式和客户进行需求确认并签字。通过配置管理员发布需求基线。
二.需求变更管理
随着软件技术的复杂化，架构的多样化，业务的灵活化，以及随着客户对所需系统目标及需求的清晰化，变更时不可避免的。会对项目的质量，成本、进度等产生影响,因此需求变更管理在整个项目的需求管理工作中显得尤其重要.一旦项目的需求基线建立，对需求版本控制管理及极为重要。
在本项目中我们采用如下需求变更管理流程。
1. 首先是客户需求接口人提出需求变更申请清单（记录需求变更项），我方需求接口人接收到该需求变更，并将需求变更申请单转发给项目技术负责人
2. 项目技术负责人接收到需求变更，对该变更进行技术评估，如果技术上可行，进入下一节点；否则给出相关的技术解答，也同样进入下一节点。
3. 项目经理接收到技术分析通过的需求变更，进行资源分析、进度分析等，分析通过的需求变更项，进入CCB审核环节。对于技术负责人分析不通过的需求变更，项目经理经过确认后，结束来流程，处于驳回关闭状态。针对这部分需求变更，需求接口人将给客户予以答复。
4. 对于项目经理审核通过的需求变更，CCB安排人员进行复核，复核通过后，该需求变更将由后续的实施人员（如开发修改代码、需求人员修改需求文档等）进行实施，并安排相关人进行验证。因实施及验证不属于需求变更管理流程，故这里不赘述。
通过上述手段，本项目保证了所有的需求变更都有据可依，同时，也通过该完整的需求管理过程，为后续的需求跟踪及相关的测试提供了信息保障。
三.需求跟踪
在实际项目开展中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户UAT（用户接收测试）时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。
本项目需求双向跟踪，包括从用户原始需求到系统需求、设计、编码、测试用例等之间的双向跟踪。如下图所示：
| 用户需求 | 系统需求 | 概设 | 详设 | 源码 | 测试用例 | …… | 最终产品 |
| 1.1 | 1.1.1 | P3 1.1.1 | P4 1.1.1 | XX.java | TC01 | …… | 功能点1 |
双向跟踪包括：
l 正向跟踪：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。一旦某个需求需要变更，就可以快速找到所有影响的范围。
l 反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。