在上一份工作中遇到的挑战力度最强的需求说明文档当属多元化威客平台（桂林某知名刷钻公司2014年新产品）。接下来的内容已尽量规避公司商业机密，我已经重写过了（hehe）。只以文档结构和编写心得进行经验分享，希望大家提出意见。

我写文档度过了一个最痛心疾首的过程：从复杂到简单。简化是很历练一个人的写作水平的，所以你们会发现我在功能部分写的很简短，篇幅少。因为涉及功能的部分都必须假设开发人员都已经具备基本的岗位能力和理解能力，不懂业务可以在初期的会议上多提问，多沟通，更利于项目研发的稳定进行。篇幅最多的还是产品部分，要将产品的工作原理、业务流程、核心特性等情况完整还原给所有产品干系人，这一步叫入门。

这份文档就没按常理出牌，因为压根没那个必要。当你有能力觉得自己能独立完成一份文档的时候，大纲是你定的，不是别人定的。

文档结构简要

首先来看看文档结构。

（文档结构）

由于项目研发的时间非常有限，我在负责产品策划时直接将功能需求文档与产品需求文档融合在了一起，并按照层次关系、阅读人群将内容进行了划分。把产品业务和一些能给业务说明带来详尽解释的术语说明、功能约束、角色说明等放在了文档的头部。功能详细需求放在了文档的中部，尾部是附录。

引言、业务需求这2块由于产品需求不同、产品人员阐述风格不同会有较大出入，但不管怎么写，只要把产品的业务核心写清道明即可，没有什么技术难度。接下来重点讲下功能这块的用例。

功能编写这块

功能说明是FRS的核心，网上已有很多参考模板，我压根就没按那个来。什么“功能性需求”、“非功能性需求”。我得说个实事求是的问题，光这标题还没看到里面的内容能明白吗？现在的项目需求和业务流程越来越复杂，用这2个分类能讲清楚吗？大纲还是得自己定。外人看不懂、内人也看不懂，你这文档写给谁看呢？就算有人看得懂，那也是经过事先培训后的一少部分人，别折腾，认认真真写一份人人都看得懂的FRS才是正事儿。

首先在“功能列表”里将所有功能模块用表格垂直描述，每个模块尽量言简意赅，一行搞定。接着在“功能模块说明”（这名字随便定义，贴切就行，这个文档很大部分我都不按规范写，按公司的实际情况、组织部门的沟通思路编写，你懂哒！）按照功能将模块一个一个展开详尽说明。

PS：写功能说明怎么可能没有原型图？原型图只截了图放在“页面布局”里，响应内容仍然在原型图里。

模块结构

先来一个简单的例子：

前置和后置条件的交互流程已经在Axure原型图中完整演义，在文档中只有简略的说明。

而“检测项”部分的互动效果也在Axure中完整演练了，但还是用最少的文字再在文档里描一便，方便“一次性读者”（有些部门没办法得到原型图文件，又或者迎合一部分懒人，免得被抓小辫子，你懂哒）通用的约束已在“全局功能说明”（见“文档结构”图中标注处）中说明，此处可指明后省略。

Tips：有一些稍微复杂的模块还需要有但不限于流程说明、限制说明、拓展属性、类别驱动、关联事务等：

1. 出现1次：就放在现在的模块说明里以便阅读，像这样：

   

2. 出现2次以上：建立文档关联或关联说明。最好能在主功能里提前说明2者或多者间的关系，以便读者心里有数。也可以像下面说的“特殊属性”这样做。

有一种特殊属性会影响到系统下特定功能的业务流程，则一定要单独出来写。比方下图这样，我是单独写在了一个一级目录里，因为它的重要性很强，需要直观的导向：

里面是酱紫的：

（例一）

（例二）

文档会持续更新，暂时先这样，欢迎大家喷！

——2014.4.11