功能规范和设计文档的

人们经常混淆功能规范和设计文档的各自目的和作用。其实，设计和功能从来都不应该放在同一个文档内。设计和功能都必须在产品开发期间实现文档化，但是，它们各自的文档在目的和读者两个方面是完全不同的。

这篇文章主要讨论功能文档同设计文档之间的差别，以及它们各自受众的需求，此外我们还要讨论功能文档和设计文档开发过程中容易引起混淆的常见误解。

功能规范 功能文档，比如功能规范文档等，都是在完成需求文档之后才创建的。这类文档定义了应用程序“方式方法的含义”。

功能规范保证新产品或服务的开发有一条系统的途径。此类文档对我们有以下帮助：

使完成开发项目所必要的资源和开发时间能得到更准确的估计

给决策者提供了开发的产品所应具有功能的单一描述

不适合长时间手持。他认为这款产品并不缺少翻页按钮 功能规范文档有时依赖于开发团队所选择的开发策略（如果有的话）。功能规范文档中通常包括的产业标准说明内容包括：

业务案例，通过它证明为什么要开发应用程序满足客户的要求。

应用程序特性规范，对应用程序如何开发以满足客户要求进行说明。

应用程序的用户界面的说明。

功能规范的读者 因为功能规范记录了客户实际能利用的产品功能特性，所以功能规范的读者范围最大。这类信息还会影响到机构内保证产品成功运作的其他团队所进行的活动和项目。而在开发团队和质量保证团队以外，这类信息还会牵扯到市场、行销和客户支持等部门。

消息软件开始公司Mobellium的总裁Nancyfaye Autenzio指出：“当我们在和那些准备结盟、联合开发或者同其他应用程序和系统集成的技术伙伴和系统集成商打交道时，能有这类文档（功能规范）实在是太恰当不过了。”

客户和技术支持团队也是功能规范的主要读者；他们用功能规范培训支持人员，让他们了解应用程序的工作原理以便在推出产品之后能对客户提供必要的支持。他们需要知道产品如何影响他们的支持基础结构和他们通过和络支持的客户。客户支持通常也就意味着代表了客户的声音。

设计文档 在有些机构内除了编程开发团队和质量保证团队，其他任何部门和个人都是无权阅读设计文档的。然而，在有的情况下，设计文档同样有助于除开发和质量保证以外的其他用途。

设计文档包括了开发中的应用程序的编程设计信息。这类设计信息用途有限但却是机构所拥有的知识产权的必要记录。设计文档的某些用途还包括了公司开发的知识产权信息，公司就是借这些信息在企业兼并、收购以及且建立战略合作关系期间证实其产品的价值。

这类文档还有助于在各种经济状况下维持企业的技术知识库；如果企业的设计文档组织得当，编排得力，那么它们就不会承受开发人员口述“项目历史”的痛苦。

设计文档的读者 查阅设计文档的读者主要想获取以下的信息：

应用程序体系结构和设计目标的细节

数据检查

代码的文档（高级）

数据流程图

无线应用领域的顾问Kevin Hoisington认为：“设计文档还能成为销售和市场的武器。我就确实看到过设计文档被用来促使产业分析家相信开发中的产品应该受到分析报告中更高的评价而不仅仅是准备为用户安装的一堆产品。”

功能文档和设计文档之间的常见误解 功能文档和设计文档之间产生混淆的根源不仅很多而且还经常与时而变。缺乏有力的产品管理、项目管理乃至技术文档等等都会模糊这类文档的真实目的。此外，那些从“拍脑袋”式的开发环境下跃迁的机构会在其应用程序开发过程中实现过程和度量时把所有的信息一股脑地记录下来。

职业定位错误的无经验职员也是导致功能规范和设计文档之间产生误解的常见问题。功能文档和设计文档都应该具有所有权属，而且还应该在软件开发周期内有自己的一席之地。而无经验的职员却可能会找到很多理由来合并这些文档，比如：“既然没人读这些文档。我就把这些玩意扔了算了。”或者没时间写文档之类的。

无论如何，我们得深知，今天多用点时间编写我们的功能规范和设计文档，将来很多人和部门才会借它们完成自己的工作，所有的付出都会得到回报的。

：炒饭