浅谈软件项目的需求管理
软件项目区别于其它项目的最显著的特征是其不可见性，它不像硬件购销、建筑工程，都是实实在在可见的东西。而软件项目在系统交付之前很长一段时间，客户是无法感知自己想要的系统究竟是什么样子。因此，需求管理就显得十分重要，据相关统计数据分析，软件项目90%以上失败的原因都在于没有重视需求或者需求管理方面做的不到位导致的。 需求管理作为软件项目管理的一个重要内容，贯穿项目实施的全生命周期。俗话说：万事开头难。需求作为软件开发的第一个环节，其重要性不言而喻。市面上关于需求管理的相关理论和书籍很多，但多数停留在理论层面，实操性不强。本文主要是根据我们以往项目的经验，进行一些需求管理方面的探讨。我们可以简单的将软件项目的需求管理分为需求获取、需求分析与验证、需求变更控制三个核心内容。
(一)需求获取
需求获取是软件项目需求管理的第一个过程，在这个过程中我们需要运用科学的方法以及相关的项目经验库辅助我们进行需求获取。需求获取的核心内容是通过调研掌握软件项目的实际需求，以便于指导整个项目的实施。需求获取的主要方法包括：用户访谈、问卷调查、现场观摩、头脑风暴等方法。在实际的项目操作过程中，相对比较明确的需求，我们可采用比较固定的需求获取方式，比如：问卷调查等。而对于相对比较模糊的需求或者说用户无法清晰表述自己需要的是什么的时候，我们可采用比较灵活的方式，例如：用户访谈、现场观摩等。
需求的类型主要包括：业务需求、用户需求和功能需求。在需求获取的过程中，无论采用哪种方法，我们都需要自顶向下或自下向上去了解用户真实的想法。业务需求的获取对象主要是客户的高层领导，我们都知道，项目的发起、实施、最终的成败很大程度上都取决于高层领导，我们需要对他们进行访谈，了解高层领导的公司战略、发展方向，更为重要的是获取他们对将要开发的软件系统的期望，以及希望该系统在解决现有业务问题，对公司整体战略的支撑方面的期望。帮助我们去更好地理解系统的宏观构想。在掌握了业务需求后，我们需要对中层管理人员进行调研，核心问题是搞清楚在宏观战略目标落地的这层，或者说指标细化并负责实施的中层他们对软件系统的期望以及实际要求，他们或希望此系统能够带来工作便利，或希望此系统能够做到精细化管理，如此等等。但他们都是具体的业务部门负责人，对自身的业务以及系统对业务的促进方面，有比较深刻的体会。最后，我们需要在掌握了业务需求、用户需求的基础之上，通过对IT管理部门、主要操作人员的需求调研或根据我们对需求的理解，细化出系统的功能需求，这个需求是最低层次的需求，也是一个层层落地的过程。
(二)需求分析与验证
在获取到软件项目需求后，接下来的工作就是对需求进行分析与验证，在项目的实际操作过程中，主要包括：需求分析建模、需求规格说明书编写和需求评审三个大的阶段。
需求分析建模主要是对已搜集到的信息进行提炼、分析和仔细审查，为最终用户所看到的系统建立一个概念模型，确保所有干系人都明白其含义，并能找出其中的错误、遗漏或不足。需求分析是软件项目需求管理的最重要一环。
在需求分析与建模过程中，对于用户需求不确定或用户无法清晰表述需求的，为了加快项目进度，我们往往采用原型法进行需求分析与建模，即根据我们的经验以及对用户基本需求的理解，用Axure等原型设计工具搭建一套原型系统。另外，我们还需要采用UML工具进行用例分析、用例描述等，并最终编写形成《软件需求规格说明书》。
需求验证或需求评审是衡量需求阶段产出成果的重要手段，在完成需求分析与建模后，项目相关干系人应组织召开需求评审会，邀请相关专家、外部相关单位等进行需求评审，就需求分析的结果《需求规格说明书》、原型系统等进行评审，并对评审结果进行签字确认，确保需求没有偏离用户要求，又略高于用户要求。
(三)需求变更控制
需求管理贯穿于软件项目开发的全生命周期，在完成需求获取、分析与验证等任务后，项目组将根据形成的相关报告进行系统设计、编码、测试、发布等工作，这些过程其实都会涉及到需求的变更，这就需要我们有一套较好的机制和方法来管理和控制需求变更，以便于项目能够按期保质又在成本范围内完成。
通常的做法是我们为了避免需求变更的无序、频繁、过度，在项目启动时会制定一套章程，会有一个CCB(变更控制委员会)，通过召开项目启动会的方式，给相关干系人确定项目的实施方法、里程碑、沟通计划，并着重强调需求变更的流程。
在实际操作中，首先是通过VSS等版本控制工具对需求文档进行管理，建立需求基线，并通过需求跟踪矩阵对需求项进行详细标注。
其次，是在项目执行过程中对需求进行变更控制，有一套规范的流程，过程虽然繁琐，但能够给项目的风险控制带来很好的效果。用户提出需求变更申请，由项目实施团队进行需求变更的评估，评估包括可能造成的对系统其它功能的影响、实施此次变更需要投入的工作量等，评估完成后由变更控制委员会确定是否同意变更。如果同意，则由项目组进行变更的实施，并对上线后的变更内容以及整个系统进行验证，确保不影响系统运行和操作。如果不同意，则变更不成立，直接驳回用户方。通过这样一种虽然看似繁琐的方法能够很好地进行需求变更的控制，可以有效避免无序、无理、过度的需求变更，确保项目在可控范围内实施。 以上是我们对软件项目需求管理的一点认识，软件需求管理之所以重要，主要是因为绝大多数项目的失败主要由需求的理解不到位、需求的变更没有得到有效控制等原因造成的。因此，这就要求我们在软件项目的需求管理方面，要下更大的力气去做好需求的获取、分析、变更控制，结合项目管理的相关理论，如PMBOOK、CMMI等，在项目实践中，不断总结经验教训，做好需求管理。
第二篇：浅谈软件项目中的需求管理
项目管理人员继续教育论文
浅谈软件项目中的需求管理
曾创能－332070063
20xx年4月17日
摘要：
需求管理在软件开发项目管理中起着至关重要的作用。本人以曾作为项目经理参与的国内某期货交易所核心结算业务系统（下称“结算系统”）的项目为例，阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。
关键词：
项目管理 需求管理 软件项目开发
引言：
在如今软件开发领域，尽管各种开发技术越来越先进，可利用的软件开发工具和方法也越来越多，但仍然有相当比例的软件项目失败。究其原因，常常是由于在项目开始阶段没有正确地理解、确定和定义需求，或者是由于在项目进展过程中没有正确地管理需求。
众所周知，项目管理的三要求为TQC（时间、质量、成本）。我个人认为，在软件开发项目中，要使TQC目标最大化，范围管理中的需求管理有着至关重要的作用，这与当今中国软件开发的特征有很大关系。当前中国软件开发的领域集中在应用开发领域，多以开发业务管理系统为主。而中国是新型经济体，在企业管理等领域处于逐步摸索、不断变更，以适应国际化竞争的转型初期。在此转型阶段，各企业的管理模式、业务管理方法等有很大不同，且自身也处于不断否定自己的管理、不断变更自己的管理方法和调整业务模式之中。作为软件项目开发承接方，必须适应中国这一各企业“需求各不相同”、“需求多变”的国情。
本人以曾作为项目经理参与的国内某期货交易所核心结算业务系统（下称“结算系统”）的项目为例，阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。
第1页 共7页
项目管理人员继续教育论文
软件需求管理的流程：
软件需求是软件项目开发工作的一个重要源头。需求管理一般由需求分析师和项目经理共同完成的。需求分析师尽可能准确的理解和获取客户需求及潜在需求，编写《需求规格说明书》，而项目经理则需通过加强需求管理，有效的防范和减少不必要的需求变更。按我多年项目开发管理经验，我个人认为，需求阶段准备把握了各类需求（功能、非功能、潜在需求等）并有效地管理需求，项目也就已经成功了一半。
在我负责结算系统时，按需求工程的方法论，将需求管理的流程可划分为如下几部分：
? 制定需求管理计划
需求管理计划往往被软件项目管理人员所忽视，很多项目经理在开发项目时，一上来就是让需求分析师跟客户谈需求去，这样做会导致需求工作的盲目性甚至可能让需求分析师无所适从。
在本项目启动时，我通过如下步骤制定需求管理计划：
1、 确定需求沟通机制；
2、 确定需求变更管理办法；
3、 确定需求跟踪方法；
4、 确定需求管理涉及的干系人，并明确职责；
5、 明确需求管理工具；
6、 编写需求管理计划。
? 需求调研
需求调研是需求分析师一项非常重要的工作。在本项目中，我确定了对期货核心结算业务吃得很透，具有5年以上相关经验的技术人员作为需求分析师负责与客户的需求访谈和调研，并成立需求组，在需求组中还配备了软件设计师和软件测试工程师旁听。我认为，在需求阶段，虽然以需求分析师为主，但软件设计师和软件测试工程师参与非常重要，他们可以了解第一手的需求信息。
? 需求分析和定义
针对获取的用户需求进行分析和整理，并规格化，形成需求规格说明书。针对每项功能需求，定义需求的重要性、优先级、实现的难易程度。
第2页 共7页
项目管理人员继续教育论文
? 需求确认
针对需求规格说明，和客户业务、技术人员起来，通过讲解的方式，确认需求，并最终让客户方需求接口负责人签字确认。
? 管理需求变更
管理需求变更是需求管理中非常重要的一环，也是经验不足的项目经理容易忽视的地方。
在软件项目中，没有不变的需求，不能指望在需求阶段一蹴而就，就此确定下来。随着设计和开发的深入，有些原定的需求本来就可能显得不合理；加之时间的推移会伴随着客户业务的变化和发展，需求变更是不可避免的。管理需求变更，是项目成功的关键因素。
在结算系统项目中，我采用如下方式对需求变更进行管理：
1、需求变更申请需书面提出，并由客户方需求接口人签字认可。当我方收到需求变更申请时，先由项目组经理与客户方需求接口人协商，协商未果，由包括双方领导在内组成的CCB审核，是否接受变更；
2、CCB审核确定接受的需求变更，录入需求管理工具TD，并通知相关方（包括设计组、开发组、测试组），评估影响范围及工作量；
3、针对需求变更，进行相应的设计和开发的调整；
4、验证需求变更是否完成。
? 需求跟踪
针对需求列表，定期对需求进展进行跟踪。
需求跟踪是指跟踪一个需求从定义、实现到验证的全过程，包括编制每个需求同系统各类元素之间的联系文档，这些元素包括其他类型的需求、体系结构、其他设计组件或模块、源代码模块、测试用例、帮助文件等。需求跟踪的目的是建立与维护“需求-设计-编码-测试”之间的一致性，确保所有的工作成果符合用户需求。
如果采用手工操作方式，对需求进行跟踪，将是一个非常繁重的体力活。在本项目中，我们应用TD管理工具，该工具把需求定义、设计（每项设计关联一个或多个需求点）、开发（建立开发模块与需求点的关联矩阵）、测试（每个测试用例关联一个或多个需求点）有机的联系在一起。
第3页 共7页
项目管理人员继续教育论文
我负责专人（本项目以系统集成人员兼职）来定期扫描和跟踪需求的进展，可以让我随时了解项目的进展以及离完全符合客户所有需求还有多远的距离。 软件需求管理的心得体会
? 要充分识别客户的需求和潜在需求
客户的需求各种各样，纷繁复杂，我们要从中将这些需求进行分类。有些需求是现有的业务规则和功能、有些是对现有工作的抱怨、有些是客户根据自己理解设想的业务规则和功能。针对各类需求，我们要有不同的对待方法，尤其要慎重对待对现有工作抱怨的需求，这类客户他对现实不满，但又没有想法设想一套新的业务规则和功能，这时候需要我们充分理解，抓住客户抱怨的本质，通过自身对客户业务的理解，帮助客户设计一套能解决他的抱怨的新的规则和功能。
在本项目开发中，我们有重点地针对客户抱怨较大或较多的需求，内部召集相关人员充分挖掘客户的需求和潜在需求，并运用快速开发工具AxureRP-Pro搭建系统原型，以直观易懂的界面作为交流工具，充分讨论其是否满足客户的真实需求。
? 需求确认非常重要
在以前的项目中，经常在项目验收时存在客户反悔、扯皮的事情，而项目开发时需求文档等各类开发文档却都很齐全。究其原因，跟需求没有正式确认有很大关系。有些项目经理或需求分析人员抱怨项目时间紧，客户需求人员没空，所以免了需求确认这一环节。但我认为这一环节一定不能免。哪怕项目组再忙，客户再忙，一定要想办法让客户书面确认需求并签字。在本项目中，需求分析完成后，我通过给客户逐步讲解需求，同时逐步让客户对需求进行确认。在客户需求变更后，我通过会议纪要、需求变更单等让客户确认签字以保护当前协商的成果。
? 需求双方都要务实
需要双方领导层达成共识，需求是无止境的，项目成功才是关键的。在本项目初期，我请求我方领导和客户方领导多次沟通，定下保证实现项目主要需求，一定要保障项目成功的基调，并为此做了一些物质上的一些激励，即我方拿出项目合同额10%的钱，激励由甲、乙双方共同实际参与此项目的项目人员，当然包括客户方的需求人员，如果项目按时上线，实现所有主要的日常业务功能，那么就可以参与分享此项目奖，否则该项目奖池归零。
第4页 共7页
项目管理人员继续教育论文
? 设计实现别让需求扩大化
追求完美是技术人员的通病。在校期间，课程设计等计算机实现方面，学生追求算法完美可以认为是一种美德，但项目是受多种因素约束的，我们不可能实现完美无缺的项目。我们的设计人员一定不要把需求放大，放到一个更完美，适应性更强的模型中，这样无形中扩大了项目范围，加大了项目的实现成本，对项目对个人都是有害的。我们在提炼客户需求的时候，可以采用“往前跨半步”的方式，满足客户现在以最近的将来可能需要的需求以满足系统的灵活性，切忌追求更加抽象化，更加完美，盲目扩大需求范围，要知道，简单是美，适用的才是最好的。
? 严格规范需求变更控制流程
项目开发中，需求变更是永恒的主题，我们要采取恰当的措施，正视这个问题。以
前项目开发过程中，由于客户方相关人单方面跟项目某一个开发人员指出说原理解的需求不正确，需重新拟定，导致后来需求变更泛滥，项目无法收尾的惨剧。
在本项目中，由双方领导层、双方项目经理等组成变更控制委员会CCB，并要求
开发人员不得私自答应或接受客户某一个需求提出人员的需求变更，所有变更必须以客户方需求接口人汇总整理后，以书面方式提出向开发方项目经理申请，开发方项目经理可以与客户方需求接口人讨论是否接受和拒绝需求变更，当不能达成一致时，交由CCB，由CCB决定是否变更，确有变更的，录入到变更控制系统TD，并通知各方实施变更。通过这套机制，客户要实现需求变更不是那么随便，有很多人会参与监督这一变更过程，客户也害怕自己的形象受损，有效杜绝了客户需求提出人员对需求的朝令夕改和源源不断提出的可有可无的需求的情况发生。
? 别忽视需求跟踪
不要等到UAT时，才发现需求未实现，或实现不全，这样会让验收工作苦笑不得，影响在客户方的形象。在本项目中，我委派系统集成人员兼做定期的需求跟踪，每个月一次，以检查正在进行的设计和开发，其功能点是否符合对应的需求。
? 抓住客户方需求接口人
在项目启动初期，一定要要求客户规定唯一一个需求接口人，这个接口人就是项目开发方的教练（coach）。在需求阶段，需求接口人需始终跟需求组一起，跟客户的各个部门一起讨论客户需求，所有部门的需求需经需求接口人同意。这
第5页 共7页
项目管理人员继续教育论文
样做好处很多，客户方需求接口人起着沟通项目甲乙双方桥梁的作用，甚至算半个乙方（项目开发方）的人。在讨论和汇总客户各部门、各人员的需求时，客户方需求接口人可以帮项目组过滤一些无用或很次要的需求，也可以协调客户部门各人员需求的冲突，更可以协调项目甲、乙双方的需求理解偏差和冲突。客户方需求接口人还可以通过全程参与项目需求管理，了解更多以前没有机会了解的业务，提升自身业务能力，这也是他（她）所乐见的。在项目验收时，客户方需求接口人可以根据自身全程参与，更深入地理解系统需求的重点，在验收或试用阶段如果有实际操作人员有反悔的情况，他（她）可以以更深入地对业务和对系统的理解来调停。
? 苦练内功，适当引导客户需求
有很多时候，项目组开发人员抱怨客户需求太霸道，实现起来很别扭。但究其原因，发现是由于你别客户牵着鼻子走，客户说怎样就怎样，但客户又不是计算机设计专家，导致项目开发人员抱怨不断。我们在项目开发过程中，一定先要虚心听，且要多问几个为什么，然后在自己公司找相关业务专家、行业顾问多咨询，以更简洁、更合理的模型来满足客户需求。如果自己公司缺乏行业经验，一定要聘请业务专家、行业顾问等专业人士，通过行业知识和业务的培训和专业指导等方式，提高项目团队特别是需求分析师对客户需求的把握能力。此外，还可以对客户方业务人员提供免费的计算机和软件开发等基础支持的培训，以便引导客户需求提出人员以更接近技术人员的方式提出合理的需求。
结尾
以上是我在负责国内某期货交易所的结算系统项目中，对需求管理流程的一些认识和心得体会，供广大同行交流，希望能抛砖引玉，为我国信息系统项目管理水平提高做点应有的贡献。
--------------------
第6页 共7页
项目管理人员继续教育论文
参考文献：
《信息系统项目管理师教程（第2版）》
作者简介：
曾创能，35岁，上海某软件公司开发总监，从事银行、证券、期货领域软件项目开发十余年，具有多年的信息系统架构设计和项目管理经验，在项目管理、部门建设方面有许多独到之处，有十余个负责的金融项目曾获得过行业大奖。
第7页 共7页