有一种场景大家可能会觉得似曾相识，项目经理（产品狗）口头或者简单记录一下软件产品大致要做的功能，然后就直接让研发团队的人员（程序猿）去狂撸代码，接着他自己就去喝茶撩妹或者回家陪老婆了（当然小编不会告诉你，宝原科技的项目经理简直不要太负责，喝茶撩妹倒没有，沟通到暂时性失声好么......）。
这种撸起袖子就开始的方式，看似简单高效，便于直接沟通，能够快速迭代。殊不知，没有一份正规且实时更新的功能需求设计文档，后期将会付出三四倍的代价去补救......
最终会引发一场产品狗和程序猿之间的“猿狗大战”
WHY——为什么需要功能需求设计说明书
在没有功能设计文档时，主要有下面几个问题：
前期研究团队沟通成本
如何要让团队里面的所有人员对软件产品的功能需求设计达成共识？
研发人员有一个通病：以为自己了解了一小块需求就立即开始埋头狂撸......代码。最终很可能与项目经理和客户真正想要的功能相差甚远。
于是，当研发人员把数据库设计好了，代码也已经写得差不多了，这时产品狗突然通知，说我们的需求要做一点变化。大家都知道，对程序猿来说，那一点变化，可能会害得程序猿的整个世界都不好了！之前设计的数据库、写的代码都不能用了！所以真的没有什么比加班加点写了几个月的代码，最终被产品狗告知需求变了，代码要删除重新写更可怕的事了（如果有，那就是连工资都不涨了~）......
还有一个比较隐讳的事情是，每个程序猿都特么认为自己写的代码很牛逼（其实对于大多数人这只是一个错觉，醒醒吧，你写的代码并不优秀），不太愿意删除之前所写的东西，所以总是想在原有的代码基础上进行修改。让他们删除代码？比杀了他还难！
但是小编公司的就很不一样的了，在项目经理了解到客户的需求后，他每天都会Code Review团队里面所有人的代码，一直要求他们把不用的代码去掉，虽然手头同时有好几个项目在忙，但大家的极力配合实现了事半功倍，在客户规定的时间内高效的完成了任务。
前期任务进度安排和分配
该文档也是任务进度安排和分配的重要依据。在没有功能需求设计文档之前的所有任务进度计划都是瞎扯淡，都不知道具体要做什么东西，哪能拿出合理的任务进度计划。如果你拿出来了，我也不相信那是经过认真分析做的进度计划，我知道那只是用来给领导看的。
中期产品经理需求变更
软件在开发过程中难免会遇到功能的需求变更，此时将程序猿们召集在一起把所有的变更讲一遍？接着走出会议室的时候可能每个人都有自己的理解。于是下一场战争已悄然临近......
后期测试团队产品测试
所以，测试团队在项目Kickoff 之时就应该介入，而不是在产品开发完成之后。
前期测试团队就应该对功能需求设计文档充分了解，且以此来编写具体的测试用例文档。否则，只能是在界面上进行简单的表面测试。而且真正的BUG 并不在表面，这些BUG 会藏得很深，最后等到发现的时候可能已经造成很大的损失。
至此，让甚至都不知道产品有哪些功能的测试团队来收尾，会造成他们想覆盖全部的测试用例都会变得异常艰难！
测试用例应该尽可能详细，尽量保证测试用例走完能确保产品能上线发布。下图为我们在登录注册时用到的一部分用例：
WHERE——文档应该放在何处
功能说明文档一定要保持实时性，任何变更的需求，新增的需求都必须在该文档中体现。
产品狗在编写完文档后，要发给项目经理、研发人员、销售人员、运营推广人员等等，如何保证每个人的文档都是最新的呢？如果通过QQ、邮件等方式，是不是每次更新都要重新通知所有人：“嘿，各位兄弟，文档作了一次修改，我给大家都重新发一份新的”。每个人电脑里面都有好几个版本的文档，时间长了，自己都忘记哪个文档是最新的；产品狗也记不清是否是所有相关的人都发了最新的文档......
研发人员可能会说通过SVN 来作版本管理啊，给每个人分配一个帐号。“天啊，SVN 是啥？”-销售人员、运营推广人员估计一脸懵逼。
更好的办法是通过团队实时协作的云端工具。从而实现分享和实时讨论，告别反复修改版本再发送邮件的麻烦。如果你会FQ，那你可以使用Google Docs、Office Online。否则你可以使用石墨文档、一起写。
WHAT——什么是功能需求设计文档&应该包含哪些内容
功能需求设计文档最重要的是描述产品所要包含的所有功能，越详细越好，可以结合产品的原型设计图来讲解。让项目所有相关人知道产品是什么，包含哪些页面，页面如何跳转等。
该文档是产品经理、项目经理、研发人员、销售人员、运营推广人员沟通的一个桥梁，一份好的功能需求设计文档是软件产品是否能成功的关键。
考虑是该文档的受众，这份文档不应该包含具体的编程技术上的说明。不管你是用C#/.NET、JAVA 还是其它，这应该是另外研发团队内部使用的一份文档。
一般人第一反映就是去网上找一份功能需求设计文档模板，我个人感觉那些模板90% 根本没有存在的必要，太过形式化，没有实际意义和模板化的内容，只会使文档成为一个摆饰，更加浪费大家的时间。
那么一份合格的软件需求设计文档应该包括哪些内容呢？
项目背景
项目产生的实际背景、具体的运用场景、大致要解决什么样的问题、针对的阅读对象、版本修改记录、文档作者以及修改人信息。
详细的功能点描述
写明产品所包含的所有功能点，对功能、界面、接口的描述一定要充分详细，每处可以交互的地方都要给出具体的说明。再次强调，一定要详细描述每一个页面所拥有的功能。
产品不包含的功能点说明
除了写明产品所包含的所有功能点外，还应该写明软件所不包含的功能，这一点也很重要。
使用场景（画面感）
将复杂的业务逻辑融入到具体的使用场景中，更容易让项目经理、研发人员、销售人员、运营推广人员不同背景的人产生共识。
流程图
大家都知道“一图胜千言”，能用图说明的尽量用图来说明，只通过大量枯燥的文字可能效果并不太好。流程图是一种用图形表示逻辑和算法的工具，特别对研发人员撸代码很有帮助。
Windows 用户可以使用Visio，Mac用户可以使用 OmniGraffle，还可以使用免费在线作图,实时协作工具 ProcessOn。
我之前就用ProcessOn 画了一个设置了缓存的网络请求的流程图，这里作个参考：
人员角色“实例化”
跟上面提到的“画面感”相结合，将人员和角色能够实例化。
比如我们的产品要实现如下功能，有两种表达方式：
医生给患者测量血压，并记录到系统中。
上海华山医院肾内科的王主任医生在给32号病区1号病床的患者刘阿姨量血压，将测量到的血压100/70mmHg输入到透析管理系统。
哪种方式更便于理解？特别是对医疗知识不太了解的码农们。当然可能有人觉得第一种方式更简洁。可能是我举的例子不够好，也可能是我的理解能力不够强。（但不要怀疑我的智商！哈哈哈...）
结合产品原型设计图
产品原型设计图可以帮助粗枝大叶地了解产品大致的框架，便于项目经理、研发人员、销售人员、运营推广人员等人在产品未开发之前对产品有一个相对直观的认识。没有一个原型图，就想把这帮人拉到同一个频道沟通一定是不可能的事！（如果你做到了，来来来，我们公司就急缺您这样的人才！）
最后，常用的原型设计工具有墨刀、Mockplus、Axure。
HOW——如何保证文档质量
要保证需求设计文档能够实时更新同步，而不是疲于应付。然后让大家都通过该文档来进行沟通，谁有问题直接去看文档，需求一旦变更首先就更新到文档。
接着研发人员就应该严格按文档上的描述来开发，所以产品的正确打开方式，NO功能需求文档，NO开发!
任何口头、QQ或邮件上的新的功能需求一概不理！
然后另一个比较重要的前提是产品狗要比较给力，否则老板还是会让你狂撸代码...
