1970年Winston Royce提出了著名的"瀑布模型"，是大家耳熟耳熟能详的经典开发模型之一，需求分析是瀑布模型的六个基本活动之一。最近几年流行的敏捷开发，user story是项目组成员经常念叨的高频词，系统原型、需求确认表等是项目重要的文档。需求文档不管是在瀑布模型还是敏捷开发中都占用重要的地位。软件需求文档为什么在不同的开发模型中都占据重要的位置呢？从软件需求文档的目的进行分析，具体如下：

 确认。需求文档不管是以软件需求规格说明书的形态体现还是以系统原型的形式呈现，都是为了让客户能够确认需求是否正确反映了他们的需求，检查每一项功能是否都符合客户期望。从晦涩的文字到user story、原型只是期望能够让确认需求的客户更容易理解和确认需求是否反映了了他们的期望。

-需求规格说明书-

-原型-

设计、编码: 软件是通过计算机从键盘等输入终端输入指令，通过计算加工，再到屏幕、打印机等终端设备的输出的一个过程。需求文档描述恰恰是描述系统的输入、输出、系统执行过程中的业务规则及逻辑变化的文档，所以，软件需求文档是系统设计工程师编写概要设计、数据库设计等文档的依据，也是软件开发工程师编码的参照依据。一些项目中，开发人员常因为业务规则描述遗漏或理解偏差而返工的现场。

验证。验证就是检查产品是否满足需求。一方面是项目组测试团队要验证软件是否达到用户期望，需求文档是测试中重要的参考指导文档，另一方面，在系统验证阶段，开发方和用户方进行验证的依据就是需求文档，这要求需求文档具有可验证性。

-bug跟踪矩阵-

追踪: 需求跟踪矩阵等文档对于跟踪、管理需求具有重要的意义。如某一需求不清晰，通过需求跟踪矩阵可以从源头进行沟通，澄清需求。另外，向前追踪，追踪需求的各个功能点是否都已实现，并通过测试、验证。

-需求确认表-

需求管理: 尽管我们期望软件需求在设计、编码前都已经得到了正确、完整的需求，但需求在开发期间总是在变更，需求的增加、调整在所难免。敏捷开发的出现在一定程度了上缓解了需求变更给项目最终交付带来影响。

法庭证据。当项目出现纠纷，最后对簿公堂时。双方确认的需求文档是法庭裁决供应商是否满足合约的重要依据。

 综上所述，需求文档是项目的重要产出物，我们应当认真对待，不应因为项目时间紧而草率的对待。