浅谈软件项目中的需求管理

浅谈软件项目中的需求管理

曾创能－332070063

2013年4月17日

摘要：

需求管理在软件开发项目管理中起着至关重要的作用。本人以曾作为项目经理参与的国内某期货交易所核心结算业务系统（下称“结算系统”）的项目为例，阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。

关键词：

项目管理需求管理软件项目开发

引言：

在如今软件开发领域，尽管各种开发技术越来越先进，可利用的软件开发工具和方法也越来越多，但仍然有相当比例的软件项目失败。究其原因，常常是由于在项目开始阶段没有正确地理解、确定和定义需求，或者是由于在项目进展过程中没有正确地管理需求。

众所周知，项目管理的三要求为TQC（时间、质量、成本）。我个人认为，在软件开发项目中，要使TQC目标最大化，范围管理中的需求管理有着至关重要的作用，这与当今中国软件开发的特征有很大关系。当前中国软件开发的领域集中在应用开发领域，多以开发业务管理系统为主。而中国是新型经济体，在企业管理等领域处于逐步摸索、不断变更，以适应国际化竞争的转型初期。在此转型阶段，各企业的管理模式、业务管理方法等有很大不同，且自身也处于不断否定自己的管理、不断变更自己的管理方法和调整业务模式之中。作为软件项目开发承接方，必须适应中国这一各企业“需求各不相同”、“需求多变”的国情。

本人以曾作为项目经理参与的国内某期货交易所核心结算业务系统（下称“结算系统”）的项目为例，阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。

软件需求管理的流程：

软件需求是软件项目开发工作的一个重要源头。需求管理一般由需求分析师和项目经理共同完成的。需求分析师尽可能准确的理解和获取客户需求及潜在需求，编写《需求规格说明书》，而项目经理则需通过加强需求管理，有效的防范和减少不必要的需求变更。按我多年项目开发管理经验，我个人认为，需求阶段准备把握了各类需求（功能、非功能、潜在需求等）并有效地管理需求，项目也就已经成功了一半。

在我负责结算系统时，按需求工程的方法论，将需求管理的流程可划分为如下几部分：

?制定需求管理计划

需求管理计划往往被软件项目管理人员所忽视，很多项目经理在开发项目时，一上来就是让需求分析师跟客户谈需求去，这样做会导致需求

工作的盲目性甚至可能让需求分析师无所适从。

在本项目启动时，我通过如下步骤制定需求管理计划：

1、确定需求沟通机制；

2、确定需求变更管理办法；

3、确定需求跟踪方法；

4、确定需求管理涉及的干系人，并明确职责；

5、明确需求管理工具；

6、编写需求管理计划。

?需求调研

需求调研是需求分析师一项非常重要的工作。在本项目中，我确定了对期货核心结算业务吃得很透，具有5年以上相关经验的技术人员作为需求分析师负责与客户的需求访谈和调研，并成立需求组，在需求组中还配备了软件设计师和软件测试工程师旁听。我认为，在需求阶段，虽然以需求分析师为主，但软件设计师和软件测试工程师参与非常重要，他们可以了解第一手的需求信息。

?需求分析和定义

针对获取的用户需求进行分析和整理，并规格化，形成需求规格说明书。针对每项功能需求，定义需求的重要性、优先级、实现的难易程度。

?需求确认

针对需求规格说明，和客户业务、技术人员起来，通过讲解的方式，确认需求，并最终让客户方需求接口负责人签字确认。

?管理需求变更

管理需求变更是需求管理中非常重要的一环，也是经验不足的项目经理容易忽视的地方。

在软件项目中，没有不变的需求，不能指望在需求阶段一蹴而就，就此确定下来。随着设计和开发的深入，有些原定的需求本来就可能显得不合理；加之时间的推移会伴随着客户业务的变化和发展，需求变更是不可避免的。管理需求变更，是项目成功的关键因素。

在结算系统项目中，我采用如下方式对需求变更进行管理：

1、需求变更申请需书面提出，并由客户方需求接口人签字认可。当我方收到需求变更申请时，先由项目组经理与客户方需求接口人协商，协商未果，由包括双方领导在内组成的CCB审核，是否接受变更；

2、CCB审核确定接受的需求变更，录入需求管理工具TD，并通知相关方（包括设计组、开发组、测试组），评估影响范围及工作量；

3、针对需求变更，进行相应的设计和开发的调整；

4、验证需求变更是否完成。

?需求跟踪

针对需求列表，定期对需求进展进行跟踪。

需求跟踪是指跟踪一个需求从定义、实现到验证的全过程，包括编制每个需求同系统各类元素之间的联系文档，这些元素包括其他类型的需求、体系结构、其他设计组件或模块、源代码模块、测试用例、帮助文件等。需求跟踪的目的是建立与维护“需求-设计-编码-测试”之间的一致性，确保所有的工作成果符合用户需求。

如果采用手工操作方式，对需求进行跟踪，将是一个非常繁重的体力活。在本项目中，我们应用TD管理工具，该工具把需求定义、设计（每项设计关联一个或多个需求点）、开发（建立开发模块与需求点的关联矩阵）、测试（每个测试用例关联一个或多个需求点）有机的联系在一起。

我负责专人（本项目以系统集成人员兼职）来定期扫描和跟踪需求的进展，可以让我随时了解项目的进展以及离完全符合客户所有需求还有多远的距离。

软件需求管理的心得体会

?要充分识别客户的需求和潜在需求

客户的需求各种各样，纷繁复杂，我们要从中将这些需求进行分类。有些需求是现有的业务规则和功能、有些是对现有工作的抱怨、有些是客户根据自己理解设想的业务规则和功能。针对各类需求，我们要有不同的对待方法，尤其要慎重对待对现有工作抱怨的需求，这类客户他对现实不满，但又没有想法设想一套新的业务规则和功能，这时候需要我们充分理解，抓住客户抱怨的本质，通过自身对客户业务的理解，帮助客户设计一套能解决他的抱怨的新的规则和功能。

在本项目开发中，我们有重点地针对客户抱怨较大或较多的需求，内部召集相关人员充分挖掘客户的需求和潜在需求，并运用快速开发工具AxureRP-Pro搭建系统原型，以直观易懂的界面作为交流工具，充分讨论其是否满足客户的真实需求。

?需求确认非常重要

在以前的项目中，经常在项目验收时存在客户反悔、扯皮的事情，而项目开发时需求文档等各类开发文档却都很齐全。究其原因，跟需求没有正式确认有很大关系。有些项目经理或需求分析人员抱怨项目时间紧，客户需求人员没空，所以免了需求确认这一环节。但我认为这一环节一定不能免。哪怕项目组再忙，客户再忙，一定要想办法让客户书面确认需求并签字。在本项目中，需求分析完成后，我通过给客户逐步讲解需求，同时逐步让客户对需求进行确认。在客户需求变更后，我通过会议纪要、需求变更单等让客户确认签字以保护当前协商的成果。

?需求双方都要务实

需要双方领导层达成共识，需求是无止境的，项目成功才是关键的。在本项目初期，我请求我方领导和客户方领导多次沟通，定下保证实现项目主要需求，一定要保障项目成功的基调，并为此做了一些物质上的一些激励，即我方拿出项目合同额10%的钱，激励由甲、乙双方共同实际参与此项目的项目人员，当然包括客户方的需求人员，如果项目按时上线，实现所有主要的日常业务功能，那么就可以参与分享此项目奖，否则该项目奖池归零。

?设计实现别让需求扩大化

追求完美是技术人员的通病。在校期间，课程设计等计算机实现方面，学生追求算法完美可以认为是一种美德，但项目是受多种因素约束的，我们不可能实现完美无缺的项目。我们的设计人员一定不要把需求放大，放到一个更完美，适应性更强的模型中，这样无形中扩大了项目范围，加大了项目的实现成本，对项目对个人都是有害的。我们在提炼客户需求的时候，可以采用“往前跨半步”的方式，满足客户现在以最近的将来可能需要的需求以满足系统的灵活性，切忌追求更加抽象化，更加完美，盲目扩大需求范围，要知道，简单是美，适用的才是最好的。

?严格规范需求变更控制流程

项目开发中，需求变更是永恒的主题，我们要采取恰当的措施，正视这个问题。以前项目开发过程中，由于客户方相关人单方面跟项目某一个开发人员指出说原理解的需求不正确，需重新拟定，导致后来需求变更泛滥，项目无法收尾的惨剧。

在本项目中，由双方领导层、双方项目经理等组成变更控制委员会CCB，并要求开发人员不得私自答应或接受客户某一个需求提出人员的需求变更，所有变更必须以客户方需求接口人汇总整理后，以书面方式提出向开发方项目经理申请，开发方项目经理可以与客户方需求接口人讨论是否接受和拒绝需求变更，当不能达成一致时，交由CCB，由CCB决定是否变更，确有变更的，录入到变更控制系统TD，并通知各方实施变更。通过这套机制，客户要实现需求变更不是那么随便，有很多人会参与监督这一变更过程，客户也害怕自己的形象受损，有效杜绝了客户需求提出人员对需求的朝令夕改和源源不断提出的可有可无的需求的情况发生。

?别忽视需求跟踪

不要等到UAT时，才发现需求未实现，或实现不全，这样会让验收工作苦笑不得，影响在客户方的形象。在本项目中，我委派系统集成人员兼做定期的需求跟踪，每个月一次，以检查正在进行的设计和开发，其功能点是否符合对应的需求。

?抓住客户方需求接口人

在项目启动初期，一定要要求客户规定唯一一个需求接口人，这个接口人就是项目开发方的教练（coach）。在需求阶段，需求接口人需始终跟需求组一起，跟客户的各个部门一起讨论客户需求，所有部门的需求需经需求接口人同意。这

样做好处很多，客户方需求接口人起着沟通项目甲乙双方桥梁的作用，甚至算半个乙方（项目开发方）的人。在讨论和汇总客户各部门、各人员的需求时，客户方需求接口人可以帮项目组过滤一些无用或很次要的需求，也可以协调客户部门各人员需求的冲突，更可以协调项目甲、乙双方的需求理解偏差和冲突。客户方需求接口人还可以通过全程参与项目需求管理，了解更多以前没有机会了解的业务，提升自身业务能力，这也是他（她）所乐见的。在项目验收时，客户方需求接口人可以根据自身全程参与，更深入地理解系统需求的重点，在验收或试用阶段如果有实际操作人员有反悔的情况，他（她）可以以更深入地对业务和对系统的理解来调停。

苦练内功，适当引导客户需求

有很多时候，项目组开发人员抱怨客户需求太霸道，实现起来很别扭。但究其原因，发现是由于你别客户牵着鼻子走，客户说怎样就怎样，但客户又不是计算机设计专家，导致项目开发人员抱怨不断。我们在项目开发过程中，一定先要虚心听，且要多问几个为什么，然后在自己公司找相关业务专家、行业顾问多咨询，以更简洁、更合理的模型来满足客户需求。如果自己公司缺乏行业经验，一定要聘请业务专家、行业顾问等专业人士，通过行业知识和业务的培训和专业指导等方式，提高项目团队特别是需求分析师对客户需求的把握能力。此外，还可以对客户方业务人员提供免费的计算机和软件开发等基础支持的培训，以便引导客户需求提出人员以更接近技术人员的方式提出合理的需求。

结尾

以上是我在负责国内某期货交易所的结算系统项目中，对需求管理流程的一些认识和心得体会，供广大同行交流，希望能抛砖引玉，为我国信息系统项目管理水平提高做点应有的贡献。

--------------------

参考文献：

《信息系统项目管理师教程（第2版）》

作者简介：

曾创能，35岁，上海某软件公司开发总监，从事银行、证券、期货领域软件项目开发十余年，具有多年的信息系统架构设计和项目管理经验，在项目管理、部门建设方面有许多独到之处，有十余个负责的金融项目曾获得过行业大奖。