一、软件功能设计文档

1、标题和人员

设计文档的标题，作者（项目的参与者），文档的审阅者，以及文档最后更新的日期。

2、概述

可以被公司里任何一个工程师所理解并且根据概要内容决定是否需要阅读文档的其余部分。这部分非常多不超过3个章节。

3、背景

对于问题的描述、为什么要做这个项目、评估项目需要了解哪些内容以及如何融入到技术战略，产品战略或者是团队的季度目标中。

4、目标和非目标

目标应该包括

明确描述哪些问题不在目标范围内也同样重要。确保所有人对于目标的理解是一致的。

5、里程碑

一些可衡量的检核点。你的PM以及你的经理的经理通过浏览就可以了解项目各个部分的推进情况。如果项目超过1个月，我建议你把项目拆分成多个面向用户的里程碑。

使用自然日以便考虑延迟、假期和会议等等。它看起来可能是下面这个样子：

开始时间：2018年6月7日

里程碑1 – 新系统MVP可在夜间模式下运行：2018年6月28日

里程碑2 – 下线旧系统：2018年7月4日

结束日期：新系统增加功能X，Y，Z：2018年7月14日

如果其中一些里程碑的预计结束时间（ETA）发生变化，可在后面增加[更新]部分。这样项目干系人可以很容易了解到最新的计划。

6、现状

除了描述当前的系统实现以外，您还应该通过概要的流程图来描述用户是如何和系统交互以及数据是怎么流转的。用户故事是完成此类工作的很好的方式。但别忘了你的系统会有很多类型的用户，每种用户都有不同的用户用例。

7、建议方案

这是有些人称之为技术架构的部分。首先提供一个大的方向，然后填充大量的细节。尝试通过用户故事来进行细化。这部分可以包含很多内容和图表。想象你写完这部分就跑到一个荒岛上去度假了。团队里其他工程师可以轻松的通过这部分来实现这个方案。

延伸阅读：

二、WIKI是什么

Wiki是一种在网络上开放且可供多人协同创作的超文本，支持面向社群的协作式写作，Wiki站点可以有多人（甚至任何访问者）维护，每个人都可以发表自己的意见，或者对共同的主题进行扩展与探讨。

其内容具有极高的关联性，初始架构不好的话可能会造成内容结构零散，不好阅读；Wiki 语法标准不一样，不同的wiki系统采用的语法不一致，造成作者编辑困难；并且结构和页面展示形式较难调整。使用wiki的时候需要遵循一定的准则，精心的编写维护。