软件项目和传统的工程项目有本质的差别，那是任务的不确定性。“需求变更”是业界公认的项目管理重大挑战。 许多失败的软件项目都是在规划阶段的需求管理上埋下了隐患。

　　需求的描述

　　目前我们所说的软件项目，多数指的是应用类（Application）的软件项目，应用类的软件基本上会用现成的框架，如J2EE， 或Microsoft的平台等等，主要精力放在需求的实现上。目前的应用系统多数是为客户做定制开发的项目，比如各大企业、政府、机构、国防等做的系统，也有一些做产品的，如中小企业的财务系统，通用办公软件等等。

　　需求一次性写好，很难。软件是慢慢成长起来的，一个milestone一个milestone的发展。象小孩子长大一样，中间可能会走弯路、错路，需要我们不短的调整、指引，后他才能成才。你很难一开始给他描绘一个一生的所有的详细场景，让他按照你的蓝图走。

　　我们建议先想好我们会有几个milestone，每个milestone发布哪些功能。然后描述需求，框架性的需求要先确定好， 然后先写近要实现的功能的需求说明。这样产品可以比较快的面世，客户会及时的给出反馈。从而减小项目的风险。

　　以需求驱动的项目管理（RDPM）

　　用户的需求是软件开发的源泉和归宿。需求代表了用户期待解决的问题，而软件项目开发的所有活动都是为此目标服务的。在众多的软件开发实施案例中，项目一旦开始，对于用户而言项目像进入了隧道的列车：他们再难看到自己需求的实现状况，虽然有众多的形形色色的项目进展报表，却很难回答一个很简单的问题：我的那些需求究竟实现的怎样？ RDPM（Requirement Driven Project Management）的核心在于需求，而不是任务。

　　需求的开发首先要需求条目化。条目化之后，我们可以给每个需求设置属性，通过这些属性来决定需求实现的顺序，工期，查看当前的状态等等。包括里程碑的制定，都要针对具体的需求项。同时为了处理变更，我们还要记录需求之间的依赖关系以及追踪需求与后续的开发工件（如计划、任务、测试用例、实现代码等）的关系。这些关系又称之为“需求 追踪矩阵”。一旦需求发生变化，影响面很广，要评估与实施需求变更，首先要确认需求变化带来的冲击面。这个工作要依赖于“需求追踪矩阵”体系。这也是我们为什么要把需求条目化的一个重要原因。

　　需求，谁来写呢？ 用户需求 - 用户对于其需要解决的问题以及期待的软件能力的描述。通常以用户的语言描述，用作开发团队与用户系统如何解决问题进行沟通的桥梁。软件需求 - 建立在用户需求之上，以开发团队所能理解的方式描述系统所应具有的功能，是开发团队进行设计和实现的依据。我了解的一般的客户，写个word文档，发封email，或打个电话，把需求甩给开发团队了。能写一个结构完整、内容严谨需求的客户很少。在美国，基本上用户会写需求，RFP（Request for Proposal）。国内有时候项目经理或做需求分析的工程师会帮助用户整理用户需求。用户需求比较粗。有了用户需求之后，再对其细化，写出软件需求。对于应用系统来说，软件需求写好了，开发的工作简单多了。

　　项目规划和进度监控，将需求作为项目规划和实施的目标，这是RDPM的核心。一切以需求为中心。 通过小版本发布逐步实现需求。在项目计划和进度控制方面，我们采用迭代的方法。将项目目标分解为较小的、易于管理的子目标，这对于减少项目失败风险很有帮助。项目目标分解可以从各个角度进行，采用小版本发布分阶段实现项目需求是目前越来越被认同的一种。尤其是现在流行的敏捷开发方法，更是提倡迭代开发。有个队可以按照实现不同的模块分成很多小的项目小组，给个项目小组其实是一个小团队。一般5、6个人为合适，团队合作和沟通成本之间有一个很好的平衡。小版本发布将系统的实现分解为多个连续的版本，每一个都实现一部分的系统功能。当每个小版本结束后，都会邀请客户评估这一版本实现的状况，并且根据用户反馈制定和调整下一个小版本的目标。这样做的好处是显而易见的：客户越早看到产品，能越早发现与开发团队间用户需求方面的理解差异，尽早调整需求，从而避免了在项目后期调整需求带来的巨额代价。另一个潜在的好处是，这一部分产品功能经过验收后有可能投入使用，从而尽早为用户提供价值。 当然，小版本发布会不可避免地面临较多的需求变更请求，因此需要仔细的管理需求变更。

　　以需求实现为单位规划项目实施 ，小版本发布需要为每个版本制定实施目标，在定下版本计划的目标后，需要规划实施。从用户需求导出的软件需求作为安排需求实现的基础。需求追踪矩阵可以帮助我们找到版本目标中的那些用户需求相关的软件需求，项目经理则为找到的这些软件需求的实现制定开发任务，从而形成开发任务集的主线，再辅以集成测试和缺陷追踪，形成了完整的开发计划。这样的分解方式自然而且清晰，易于上手。

　　项目的进度监控，用户需求自然是客户参与项目时候关心的重点。 RDPM中提供的是需求实现状态图，需求变化趋势，需求数量完成率，需求规模完成率，工时消耗率等指标。

　　需求的变更， “需求变更”是业界公认的项目管理重大挑战，尤其是项目后期产生的需求变更，对项目的影响是非常大的。但是需求的变化又是不可避免的。

　　对于如何应对需求变更，主要的思路有两条：首先是从源头做起，提高需求质量，减少变更的可能性；另一个是建立流程严格控制需求变更，因篇幅所限，在此不做赘述。

　　总结

　　软件项目与传统的工程项目有着很大的不同，这种不同导致描述需求的方式，实现需求，进行项目计划、监控项目进度的方式都有很大的不同。我们提出以需求为中心的软件项目管理。通过提高需求描述的质量、采用小版本发布策略、将用户需求作为小版本的目标来组织和计划项目开发、积极应对需求变更、提供以用户需求为中心的项目进展视图，从而和客户一起来保证项目的成功。