条目化的需求，用MS Word难以管理，一般需要存放在数据库中。

但条目化不能解决一个古老的问题，即如何能把需求描述清楚。需求必须要写的清晰明确，完整，确保开发人员不需要为一个模糊的需求做决定，尤其是不要自行发挥。我推荐使用wiki来描述需求的细节，加上UI prototype，形象的描述需求。wiki最大的好处在于协同修改很方便。

另外，一些实践能够帮助需求开发工程师提高需求编写质量：

1、记录每条需求的原因。有研究成果表明，通过记录每条需求的原因（即为什么要实现这个功能），可以删除多达半数的所谓“需求”。虽然在记录工作上投入了一定的工作量，但是有效地避免了为那些不必要的需求所要完成的后续工作，可以显著地降低系统规模、缩短系统开发周期，正所谓“事半功倍”。
2、尽可能考虑采用适当形式化的方法。由于自然语言存在歧义，一个二义性的描述因此可能导致对于同一个需求的不同解释，而采用形式化表示方法编写需求能够更加准确地在用户和开发团队间进行沟通。常用的形式化需求表示方法包括：实体关系图、数据字典、数据流程图、USE CASE等。当然还是 UI prototype最直接，简单，有效。
3、使用专业的工具编写需求，管理需求。这类工具由于没有成熟的理论指导，客户的要求各有不同，市场上相应的工具不多。汉星天公司一直致力于这方面的研究，推出了相应的需求描述，需求变更管理的解决方案；并在中国上百家大企业得到非常好的效果。

用户需求 vs. 软件需求

需求，谁来写呢？我们先看看两个定义需求的名词：

◆用户需求
用户对于其需要解决的问题以及期待的软件能力的描述。通常以用户的语言描述，用作开发团队与用户就系统如何解决问题进行沟通的桥梁。
◆软件需求
建立在用户需求之上，以开发团队所能理解的方式描述系统所应具有的功能，是开发团队进行设计和实现的依据。

我了解的一般的客户，写个word文档，发封email或打个电话，就把需求甩给开发团队了。能写一个结构完整、内容严谨需求的客户很少。在美国，基本上用户会写需求RFP（Request for Proposal）。国内有时候项目经理或做需求分析的工程师会帮助用户整理用户需求。用户需求比较粗。有了用户需求之后，再对其细化，写出软件需求。对于应用系统来说，软件需求写好了，开发的工作就简单多了。

这两种需求分别记录。里程碑一般以用户需求为目标。用户需要关联到多个软件需求上。

项目规划和进度监控

将需求作为项目规划和实施的目标，这是RDPM的核心。一切以需求为中心。

通过小版本发布逐步实现需求

在项目计划和进度控制方面，我们采用迭代的方法。

将项目目标分解为较小的、易于管理的子目标，这对于减少项目失败风险很有帮助。项目目标分解可以从各个角度进行，采用小版本发布分阶段实现项目需求是目前越来越被认同的一种。尤其是现在流行的敏捷开发方法，更是提倡迭代开发。有个普遍的误解就是以为敏捷开发方法只适用于小规模的开发团队，其实对大的团队一样适用。大的开发团队 可以按照实现不同的模块分成很多小的项目小组，给个项目小组其实就是一个小团队。一般5、6个人最为合适，团队合作和沟通成本之间有一个很好的平衡。

小版本发布是针对以前瀑布式开发的缺点而提出的开发方式。在以前的模式中，项目往往经过一个漫长的需求开发、设计、编码和测试阶段后才能够与客户见面，而客户在这个时间段上进入了“盲区”，直到开发团队“隆重推出”开发成果。而恰恰这个时候是项目风险最大的时候，由于在过程中缺乏交流机会，客户往往会发现这个产品与他们想象的很不一样，因此很有可能导致项目拖延或者失败。

小版本发布则不同，它将系统的实现分解为多个连续的版本，每一个都实现一部分的系统功能。当每个小版本结束后，都会邀请客户评估这一版本实现的状况，并且根据用户反馈制定和调整下一个小版本的目标。这样做的好处是显而易见的：客户越早看到产品，就能越早发现与开发团队间就用户需求方面的理解差异，尽早调整需求，从而避免了在项目后期调整需求带来的巨额代价。另一个潜在的好处是，这一部分产品功能经过验收后就有可能投入使用，从而尽早为用户提供价值。 当然，小版本发布会不可避免地面临较多的需求变更请求，因此需要仔细的管理需求变更。

以需求实现为单位规划项目实施

小版本发布需要为每个版本制定实施目标，确定在本次版本中需要实现的功能以及计划修改的以前版本的缺陷。而用户需求是功能的表达方式，因此使用用户需求作为小版本是顺理成章的。当然根据粒度不同，也可以使用软件需求做为小版本发布的内容。

在定下版本计划的目标后，就需要规划实施。不过由于用户需求描述的是客户的业务和对系统的期望，因此直接采用用户需求作为开发任务安排的起点并不合适。从用户需求导出的软件需求则是以开发团队能够理解的语言和结构描述的，很适合作为安排需求实现的基础。需求追踪矩阵可以帮助我们找到版本目标中的那些用户需求相关的软件需求，项目经理则为找到的这些软件需求的实现制定开发任务，从而形成开发任务集的主线，再辅以集成测试和缺陷追踪，就形成了完整的开发计划。这样的分解方式自然而且清晰，易于上手。

项目的进度监控

前文说到用户需求是客户与开发团队间的契约，因此用户需求自然成为客户参与项目时候关心的重点。但是，在实际项目过程中，当客户真正参与项目、试图了解项目进展状况时，却发现除了用户文档外，再也找不到这些需求的影子，取而代之的是一堆花花绿绿的项目任务进展报告、甘特图、统计报告等。这些报表也许准确地反映了现在项目中任务的分布和实现状况，但是与用户关心的需求实现状态没有什么直接联系，因而与缺少了共同的语言。

这个问题来源于传统项目管理过程中以任务为中心的理念和实践。在这种理念下，项目被认为是一个任务的集合，主要的工作就是任务的分解（WBS： Work Breakdown Structure）、分派、实现和审核。在一个项目组内部，这的确是工作的主要内容。但是，现代的软件开发过程都强调用户的参与，项目进展仅仅以任务为视角展现就不是很合适了。对于客户而言，他们所熟悉的问题描述，即用户需求，已经被分解成几十甚至上百个大大小小的任务，再难看出它们之间的联系，客户自然会感到迷茫，更别说从中看出需求实现的状态了。

而RDPM中提供的是需求实现状态图，需求变化趋势，需求数量完成率，需求规模完成率，工时消耗率等指标。这些指标对于客户来说更有意义。

(编辑:aniston)