lestone一个milestone的发展。象小孩子长大一样，中间可能会走弯路、错路，需要我们不短的调整、指引，最后他/她才能成才。你很难一开始就给他/她描绘一个一生的所有的详细场景，让他/她按照你的蓝图走（工程项目才能做到这样）。
我们建议先想好我们会有几个milestone，每个milestone发布哪些功能。然后描述需求，最框架性的需求要最先确定好, 然后先写最近要实现的功能的需求说明。后面的需求 和开发就可以并行了。这样我们的产品可以比较快的面世，客户会及时的给出反馈。从而减小项目的风险。这里建议写需求的时候，用UI Prototype，User Scenario方法，让用户越早看到实际使用界面和使用方法越好。
目前我们很多项目的需求是用Microsoft Word写的，动辄几十页，上百页。这样的大文档，除了上面讲到的项目管理方法上的问题，还存在下面的问题：
１、规模巨大，不方便查阅。一个中小型应用系统的需求文档可多达数百页甚至更多。即使使用分卷也不方便查阅.
２、不利于更新。需求文档是一个活的文档，不断的增长，更新是难免的。在Word中做了更新，即使用修订模式，也不容易看出更改的部分。这样导致开发和功能设计两个环节沟通不畅。通常就变成需求只有第一个版本，以后的变更就发个邮件或口头说一下了。
３、不利于多人同时、协同修改。
４、需求没有条目化，Word文档中通常只是描述功能，但实际上我们还要把需求分成一项一项，设置每个需求的优先级，难易程度，功能点（function point），在哪个发布中应该做完，需求来源等等。这种类似数据库的特性，在Word难以体现。
５、不利于建立需求与其它开发控制元素的关系。这可能对写需求的业务人员体会不到，但对于项目经理，实现这些需求的人员来说是非常重要的。在开发过程中用户需求与软件需求的关系、软件需求与开发任务的关系、测试用例与需求之间的关系等，对于需求变更控制、质量控制都是非常重要的参考信息。一体化的需求文档（如MS Word）很难做到这一点。
以需求驱动的项目管理(RDPM)
针对应用软件的项目，汉星天公司提出与传统的基于任务的项目管理方法不同的，以需求为中心的软件项目管理方法。在管理中，Microsoft Project和Word的使用处于次要地位。
用户的需求是软件开发的源泉和归宿。需求代表了用户期待解决的问题，而软件项目开发的所有活动都是为此目标服务的。在众多的软件开发实施案例中，当项目一 旦开始，对于用户而言项目就像进入了隧道的列车：他们再难看到自己需求的实现状况，虽然有众多的形形色色的项目进展报表，却很难回答一个很简单的问题：我的那些需求究竟实现的怎样？ RDPM(Requirement Driven Project Management)的核心就在于需求，而不是任务。
需求的开发
首先要需求条目化。而不是放在一个大Word文档中。条目化之后，我们就可以给每个需求设置属性，通过这些属性来决定需求实现的顺序，工期，查看当前的状态等等。包括里程碑的制定，都要针对具体的需求项。 同时为了处理变更，我们还要记录需求之间的依赖关系以及追踪需求与后续的开发工件（如计划、任务、测试用例、实现代码等）的关系。这些关系又称之为“需求 追踪矩阵”。 一旦需求发生变化，影响面很广，要评估与实施需求变更，首先要确认需求变化带来的冲击面。这个工作就要依赖于“需求追踪矩阵”体系。这也是我们为什么要把需求条目化的一个重要原因。
条目化的需求，用MS Word难以管理，一般需要存放在数据库中。
但条目化不能解决一个古老的