答案是 - 如前所述 - 这取决于。我相信很多人都会回答敏捷方法论（这是一个更加可移动的盛宴），所以为了完整性，我会选择你所拥有的相当标准的瀑布式方法：
- 范围文档 - 非常高级别概述了什么是更重要的是什么不在项目的范围内以及正在做出什么样的假设。本文档的主要目的是设定对最终交付内容的期望 - 您不是说事情将如何运作，而是您试图回答诸如报告之类的问题？它会将数据传递给其他系统吗？您是否必须编写自己的用户管理功能或从AD中提取？如果你无法得到这些东西的明确答案，那么请包括假设部分并列出你假设的情况，以便人们可以纠正你，如果你错了。它还应该包括目标实施日期之类的东西（不是作为承诺，而是让人们知道预期的内容并相应地管理期望）。
- 功能规范 - 应用程序应在业务级别执行的操作。这可以分为业务需求（业务流程自动化和工作方式）和功能需求（系统执行什么以及如何执行 - 屏幕导航，如何进行计算等），但更常见的是它们是除了最大的系统外。它还应包括“非功能”要求，如性能，负载，安全性等。
- 技术规范 - 最容易被遗漏的。详细的技术设计，包括对象模型，架构图和有关如何解决详细技术问题的信息。
- 测试计划和测试脚本 - 如何使用详细的测试用例，数据和预期结果测试应用程序，涵盖系统的所有元素。
- 用户指南和发行说明 - 如何安装，配置和使用该应用程序。
我要添加的是支持文档 - 应用程序执行的简短（少于10页）速成课程及其操作方式。开发人员通常不会阅读完整的规范（因为他们没有时间或不想），所以这份文档应该足以让他们了解它的作用，工作原理，应用领域最有可能出现问题，等等。它将在建立和实施该系统的团队上线几周后编写。
当然，根据您的方法，您可能没有这些文件，但如果您在旧学校以瀑布方式运行标准项目，这将是非常正常的。
我将使用典型的咨询答案......'它取决于'。
首先，方法论对文档工件产生了极大的影响（更不用说项目成功了），我将瀑布式项目管理放在同一级别，允许我的医生用水蛭盖住我治疗断腿
话虽如此 - 我见过人们使用Microsoft解决方案框架，这里有一个链接，你可以抓住他们的模板：
http://www.microsoft.com/downloads/details.aspx?FamilyID=9D2016AD-6F8A-47F5-84FA-BEC389DB18C1&displaylang=en&displaylang=en
实际上，我强烈建议任何项目使用敏捷方法和工程实践（至少，如果你希望它比瀑布项目有更高的成功机会）。
http://www.agilealliance.com/有一些很好的阅读，维基百科也是http://en.wikipedia.org/wiki/Agile_software_development
祝你好运！
在典型的生产场景中，开发不在客户端进行，通常遵循SDLC的瀑布模型，并准备与WFM的各个阶段相关的文档：
-
需求收集 - 详细说明完整要求的业务需求规范。这本质上是功能性的。这伴随着用户提供的测试用例场景，其中用户提到他们将对所需功能执行的测试和测试用例。这可以作为开发团队的指南，也可以构建功能和验证的范围。
-
需求分析 - 在此阶段，与项目相关的BA进行了影响分析和可行性分析。如果需求，约束，假设中存在任何限制，则与业务用户共享并签字以避免任何进一步的意外。
- 开发方法 - 在此阶段，开发团队负责人或系统分析员准备一个方法文档，定义流程，屏幕设计，将放置在屏幕上的控件，验证，属性，数据库图表等。然后与BA签字。如果开发团队预见到会影响所需功能的任何技术限制，则会再次与业务团队共享并签字。
- 测试 - 当用户对发布进行测试时，他们会根据之前提供的测试用例和测试方案验证发布。发现的缺陷记录在案并发回给开发团队。这些缺陷首先由BA进行验证，以确定在理解缺陷，功能要求失效或技术缺陷时是否报告缺陷。因此提供了解决方案。在此阶段，需要注意所有测试用例都已成功完成并且所有错误都已解决。如果要为下次运行停放任何测试用例或错误，那么根据它对功能的影响，开发团队和业务用户就所涉及的风险进行联合调用。最后，业务用户准备测试签名文档，他们提到每个资源用于测试，观察和流程改进建议的时间。
- 生产部署 - 这包括部署团队，服务器和数据库管理员进行部署的部署说明。
随时提供您的建议。