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

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

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

文档结构简要

首先来看看文档结构。

（文档结构）

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

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

功能编写这块

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

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

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