问题，即如何能把需求描述清楚。需求必须要写的清晰明确，完整，确保开发人员不需要为一个模糊的需求做决定，尤其是不要自行发挥。我推荐使用wiki来描述需求的细节，加上UI prototype，形象的描述需求。wiki最大的好处在于协同修改很方便。
另外一些实践能够帮助需求开发工程师提高需求编写质量：
１、记录每条需求的原因。有研究成果表明，通过记录每条需求的原因（即为什么要实现这个功能），可以删除多达半数的所谓“需求”。虽然在记录工作上投入了一定的工作量，但是有效地避免了为那些不必要的需求所要完成的后续工作，可以显著地降低系统规模、缩短系统开发周期，正所谓“事半功倍”。
２、尽可能考虑采用适当形式化的方法。由于自然语言存在歧义，一个二义性的描述因此可能导致对于同一个需求的不同解释，而采用形式化表示方法编写需求能够更加准确地在用户和开发团队间进行沟通。常用的形式化需求表示方法包括：实体关系图、数据字典、数据流程图、USE CASE等。当然还是 UI prototype最直接，简单，有效。
３、使用专业的工具编写需求，管理需求。这类工具由于没有成熟的理论指导，客户的要求各有不同，市场上相应的工具不多。汉星天公司一直致力于这方面的研究，推出了相应的需求描述，需求变更管理的解决方案；并在中国上百家大企业得到非常好的效果。
用户需求 vs软件需求
需求，谁来写呢？我们先看看两个定义需求的名词：
用户需求 - 用户对于其需要解决的问题以及期待的软件能力的描述。通常以用户的语言描述，用作开发团队与用户就系统如何解决问题进行沟通的桥梁。
软件需求 - 建立在用户需求之上，以开发团队所能理解的方式描述系统所应具有的功能，是开发团队进行设计和实现的依据。
我了解的一般的客户，写个word文档，发封email，或打个电话，就把需求甩给开发团队了。能写一个结构完整、内容严谨需求的客户很少。在美国，基本上用户会写需求，RFP（Request for Proposal）。国内有时候项目经理或做需求分析的工程师会帮助用户整理用户需求。用户需求比较粗。有了用户需求之后，再对其细化，写出软件需求。对于应用系统来说，软件需求写好了，开发的工作就简单多了。
这两种需求分别记录。里程碑一般以用户需求为目标。用户需要关联到多个软件需求上。
项目规划和进度监控
将需求作为项目规划和实施的目标，这是RDPM的核心。一切以需求为中心。
通过小版本发布逐步实现需求
在项目计划和进度控制方面，我们采用迭代的方法。
将项目目标分解为较小的、易于管理的子目标，这对于减少项目失败风险很有帮助。项目目标分解可以从各个角度进行，采用小版本发布分阶段实现项目需求是目前越来越被认同的一种。尤其是现在流行的敏捷开发方法，更是提倡迭代开发。有个普遍的误解就是以为敏捷开发方法只适用于小规模的开发团队，其实对大的团队一样适用。大的开发团队 可以按照实现不同的模块分成很多小的项目小组，给个项目小组其实就是一个小团队。一般5、6个人最为合适，团队合作和沟通成本之间有一个很好的平衡。
小版本发布是针对以前瀑布式开发的缺点而提出的开发方式。在以前的模式中，项目往往经过一个漫长的需求开发、设计、编码和测试阶段后才能够与客户见面，而客户在这个时间段上进入了“盲区”，直到开发团队“隆重推出”开发成果。而恰恰这个时候是项目风险最大的时候，由于在过程中缺乏交流机会，客户往往会发现这个产品与他们想象的很不一样，因此很有可能导致项目拖延或者失败。
小版本发布则不同，它将系统的实现分解为多个连续的版本，每一个都实现一部分的