用户需求 vs. 软件需求
需求，谁来写呢？我们先看看两个定义需求的名词：
用户需求 - 用户对于其需要解决的问题以及期待的软件能力的描述。通常以用户的语言描述，用作开发团队与用户就系统如何解决问题进行沟通的桥梁。
软件需求 - 建立在用户需求之上，以开发团队所能理解的方式描述系统所应具有的功能，是开发团队进行设计和实现的依据。
我了解的一般的客户，写个word文档，发封email，或打个电话，就把需求甩给开发团队了。能写一个结构完整、内容严谨需求的客户很少。在美国，基本上用户会写需求，RFP（Request for Proposal）。国内有时候项目经理或做需求分析的工程师会帮助用户整理用户需求。用户需求比较粗。有了用户需求之后，再对其细化，写出软件需求。对于应用系统来说，软件需求写好了，开发的工作就简单多了。
这两种需求分别记录。里程碑一般以用户需求为目标。用户需要关联到多个软件需求上。
项目规划和进度监控
将需求作为项目规划和实施的目标，这是RDPM的核心。一切以需求为中心。
通过小版本发布逐步实现需求
在项目计划和进度控制方面，我们采用迭代的方法。
将项目目标分解为较小的、易于管理的子目标，这对于减少项目失败风险很有帮助。项目目标分解可以从各个角度进行，采用小版本发布分阶段实现项目需求是目前越来越被认同的一种。尤其是现在流行的敏捷开发方法，更是提倡迭代开发。有个普遍的误解就是以为敏捷开发方法只适用于小规模的开发团队，其实对大的团队一样适用。大的开发团队 可以按照实现不同的模块分成很多小的项目小组，给个项目小组其实就是一个小团队。一般5、6个人最为合适，团队合作和沟通成本之间有一个很好的平衡。
小版本发布是针对以前瀑布式开发的缺点而提出的开发方式。在以前的模式中，项目往往经过一个漫长的需求开发、设计、编码和测试阶段后才能够与客户见面，而客户在这个时间段上进入了“盲区”，直到开发团队“隆重推出”开发成果。而恰恰这个时候是项目风险最大的时候，由于在过程中缺乏交流机会，客户往往会发现这个产品与他们想象的很不一样，因此很有可能导致项目拖延或者失败。
小版本发布则不同，它将系统的实现分解为多个连续的版本，每一个都实现一部分的系统功能。当每个小版本结束后，都会邀请客户评估这一版本实现的状况，并且根据用户反馈制定和调整下一个小版本的目标。这样做的好处是显而易见的：客户越早看到产品，就能越早发现与开发团队间就用户需求方面的理解差异， 尽早调整需求，从而避免了在项目后期调整需求带来的巨额代价。另一个潜在的好处是，这一部分产品功能经过验收后就有可能投入使用，从而尽早为用户提供价值。 当然，小版本发布会不可避免地面临较多的需求变更请求，因此需要仔细的管理需求变更。
文章来源于领测软件测试网 https://www.ltesting.net/
