项目因需求而生，先有需求才有项目。如果把软件项目建设进程比作一条河流，那么软件项目需求就好比是这条河流的源头。也就是说事关需求的问题都是根源性问题，影响到河水的质量与流速。Frederick Brooks早在他1987年经典文章“No Silver Bullet”就阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。

　　那么如何才能从根本上做好软件项目需求的把握与控制？

　　山东省软件评测中心作为国内最早一批获得国家实验室认可并取得政府授权的中立的第三方机构，凭籍对软件项目的深刻理解与多年的项目经验积累总结出以下四点，仅供探讨：

　　一、项目前期的需求分析

　　1、需求分析谁来做

　　在设定目标之后首先要明确职责，需求分析由谁来做？

　　需求分析目标的实现依赖的是一个组织，这个组织中的每个个体通过相互间的协作都对整个需求分析的过程和结果发挥作用，贡献力量。需求分析师在需求分析中发挥了主导作用。但如果没有组织中其他个体的参与和协作，需求分析的结果可想而知。在实际项目中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括甲方项目负责人和最终用户，乙方的需求分析人员和项目管理者。这部分工作做得到位，能保障做出优秀的软件项目。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁与隐患。

　　2、需求分析的评价标准

　　“正确的需求”对采用任何一种开发模式都至关重要，对项目的成败具有重要意义。

　　那么什么样的需求才是“正确的需求”呢？我们认为正确的需求可以概括为“内涵一致，外延完整”八个字。具体来说可以体现为清晰性、完整性、一致性、可行性、一致性、可管理性以下六点：

　　★ 清晰性：系统的目标是否已定义；是否对关键术语和缩略语进行定义和描述；所使用的术语是否和用户/客户使用的一致；需求的描述是否清晰，无二义；是否有对整套系统进行功能描述；是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）；如果有会影响实施的假设情况，是否已经声明；是否已经对每个业务逻辑进行输入、输出以及过程的详细说明。

　　★ 完整性：是否列出了系统所必须的依赖、假设以及约束；需求说明书是否已包含了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测性（此范围比较广，包括性能指标、需求是否遗漏、重复或不一致的地方等）。

　　★ 一致性：需求说明是否存在直接相互矛盾的条目；本需求说明书是否与相关需求素材一致。

　　★ 可行性：所描述的所有功能是否必要并充分地满足客户/系统目标；需求规格说明书描述的详细程度是否足以满足进行详细设计；已知的限制（局限）是否已经详细说明；是否已确认每个需求的优先级别。

　　★ 依从性：该文档是否遵守了公司规定的文档编写标准。

　　★ 可管理性：是否将需求分别陈述，因此它们是独立的并且是可验证检查的；是否所有需求都可以回溯到相应的需求素材，反之亦然；是否已详细说明需求变更的过程。

　　3、需求分析的成果与呈现方式—项目需求规格说明书

　　需求分析是为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述。由需求模型构件生成精确的形式化的描述，即需求规格说明书，它将作为甲乙双方之间的协议，同时也是评价后续工作的基线。需求分析员按照指定的文档模板撰写《产品需求规格说明书》。根据项目情况有时需要分别撰写《软件需求规格说明书》和《硬件需求规格说明书》。

　　项目经理需邀请同行专家和甲方（包括甲方和最终用户）共同评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。

　　需求评审之后，甲乙双方责任人需对《产品需求规格说明书》作出书面承诺。在需求评审阶段，分析人员要在甲方和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、清晰、准确、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。