以需求驱动的项目管理(RDPM)
针对应用软件的项目，汉星天公司提出与传统的基于任务的项目管理方法不同的，以需求为中心的软件项目管理方法。在管理中，Microsoft Project和Word的使用处于次要地位。
用户的需求是软件开发的源泉和归宿。需求代表了用户期待解决的问题，而软件项目开发的所有活动都是为此目标服务的。在众多的软件开发实施案例中，当项目一 旦开始，对于用户而言项目就像进入了隧道的列车：他们再难看到自己需求的实现状况，虽然有众多的形形色色的项目进展报表，却很难回答一个很简单的问题：我的那些需求究竟实现的怎样？ RDPM(Requirement Driven Project Management)的核心就在于需求，而不是任务。
需求的开发
首先要需求条目化。而不是放在一个大Word文档中。条目化之后，我们就可以给每个需求设置属性，通过这些属性来决定需求实现的顺序，工期，查看当前的状态等等。包括里程碑的制定，都要针对具体的需求项。 同时为了处理变更，我们还要记录需求之间的依赖关系以及追踪需求与后续的开发工件（如计划、任务、测试用例、实现代码等）的关系。这些关系又称之为“需求 追踪矩阵”。 一旦需求发生变化，影响面很广，要评估与实施需求变更，首先要确认需求变化带来的冲击面。这个工作就要依赖于“需求追踪矩阵”体系。这也是我们为什么要把需求条目化的一个重要原因。
条目化的需求，用MS Word难以管理，一般需要存放在数据库中。
但条目化不能解决一个古老的问题，即如何能把需求描述清楚。需求必须要写的清晰明确，完整，确保开发人员不需要为一个模糊的需求做决定，尤其是不要自行发挥。我推荐使用wiki来描述需求的细节，加上UI prototype，形象的描述需求。wiki最大的好处在于协同修改很方便。
另外一些实践能够帮助需求开发工程师提高需求编写质量：
记录每条需求的原因。有研究成果表明，通过记录每条需求的原因（即为什么要实现这个功能），可以删除多达半数的所谓“需求”。虽然在记录工作上投入了一定的工作量，但是有效地避免了为那些不必要的需求所要完成的后续工作，可以显著地降低系统规模、缩短系统开发周期，正所谓“事半功倍”。
尽可能考虑采用适当形式化的方法。由于自然语言存在歧义，一个二义性的描述因此可能导致对于同一个需求的不同解释，而采用形式化表示方法编写需求能够更加准确地在用户和开发团队间进行沟通。常用的形式化需求表示方法包括：实体关系图、数据字典、数据流程图、USE CASE等。当然还是 UI prototype最直接，简单，有效。
使用专业的工具编写需求，管理需求。这类工具由于没有成熟的理论指导，客户的要求各有不同，市场上相应的工具不多。汉星天公司一直致力于这方面的研究，推出了相应的需求描述，需求变更管理的解决方案；并在中国上百家大企业得到非常好的效果。
文章来源于领测软件测试网 https://www.ltesting.net/
