拓展阅读：编写需求建议书的一般原则

　　需求建议书应该由用户编写，但各种客观因素的限制，实际上很难做[到。所以，很多时候都是由用户与项目小组共同编写。编写项目需求说明的J过程也是项目小组带领客户进入项目需求启发的过程。编写优秀的项目需求[建议书没有公式化的方法，需要大量的实践经验。以下是编写需求建议书需要把握的几个原则：

　　(1)需求应该是正确的。每个需求必须精确描述要交付的功能。确定需求内容是否正确，需要用户的代表来参与确认，由他们检查、决定用户需[求的正确性。没有用户的需求检查就会导致很多项目实施中的问题出现。例如用户会说：“这不是我们要的东西”;“你没明白我们的意思”，等等。

　　(2)需求应该是可行的。项目的需求应该在有限的资源(已知的能力、有限的系统及其环境)下是可实现的。为了避免需求的不可行性，在需求分析阶段应该有核心技术人员参与，检查在技术上什么能做、什么不能做，哪些需要额外的付出等。

　　(3)需求内容应该是必要的。需求建议书中的每个需求都应该有相应[的出处，即说明什么是客户确实需要的，什么要顺应于外部的需求、接口或标准。如果不能标识出处，则可能这个需求不是真正需要的。

　　(4)需求内容应该有优先权。优先权是由客户或其代理及项目小组共同商讨后建立的。如果所有的需求都被视为同等重要，那么在开发中遇到预t算削减、计划超时或组员的离开而导致新的需求时，项目经理将无所适从。一般优先权有以下三个级别。

　　1)高优先权，表明需求必须体现在本阶段项目的成果中或这个产品的版本中。

　　2)中优先权，表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中。

　　3)低优先权，表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

　　(5)需求内容应该是明确的。需求不该有歧义，要避免使用一些对于拟订项目需求建议书的人很清楚，但对于其他人模糊不清的词汇。如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁、直观地采用用户熟知的语言，而不要采用计算机术语。