一、軟件功能設計文檔

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的時候需要遵循一定的準則，精心的編寫維護。