一、軟件功能設計文檔

1、標題和人員

設計文檔的標題，作者（項目的參與者），文檔的審閱者，以及文檔最后更新的日期。

2、概述

可以被公司里任何一個工程師所理解并且根據(jù)概要內(nèi)容決定是否需要閱讀文檔的其余部分。這部分非常多不超過3個章節(jié)。

3、背景

對于問題的描述、為什么要做這個項目、評估項目需要了解哪些內(nèi)容以及如何融入到技術戰(zhàn)略，產(chǎn)品戰(zhàn)略或者是團隊的季度目標中。

4、目標和非目標

目標應該包括

明確描述哪些問題不在目標范圍內(nèi)也同樣重要。確保所有人對于目標的理解是一致的。

5、里程碑

一些可衡量的檢核點。你的PM以及你的經(jīng)理的經(jīng)理通過瀏覽就可以了解項目各個部分的推進情況。如果項目超過1個月，我建議你把項目拆分成多個面向用戶的里程碑。

使用自然日以便考慮延遲、假期和會議等等。它看起來可能是下面這個樣子：

開始時間：2018年6月7日

里程碑1 – 新系統(tǒng)MVP可在夜間模式下運行：2018年6月28日

里程碑2 – 下線舊系統(tǒng)：2018年7月4日

結(jié)束日期：新系統(tǒng)增加功能X，Y，Z：2018年7月14日

如果其中一些里程碑的預計結(jié)束時間（ETA）發(fā)生變化，可在后面增加[更新]部分。這樣項目干系人可以很容易了解到最新的計劃。

6、現(xiàn)狀

除了描述當前的系統(tǒng)實現(xiàn)以外，您還應該通過概要的流程圖來描述用戶是如何和系統(tǒng)交互以及數(shù)據(jù)是怎么流轉(zhuǎn)的。用戶故事是完成此類工作的很好的方式。但別忘了你的系統(tǒng)會有很多類型的用戶，每種用戶都有不同的用戶用例。

7、建議方案

這是有些人稱之為技術架構(gòu)的部分。首先提供一個大的方向，然后填充大量的細節(jié)。嘗試通過用戶故事來進行細化。這部分可以包含很多內(nèi)容和圖表。想象你寫完這部分就跑到一個荒島上去度假了。團隊里其他工程師可以輕松的通過這部分來實現(xiàn)這個方案。

延伸閱讀：

二、WIKI是什么

Wiki是一種在網(wǎng)絡上開放且可供多人協(xié)同創(chuàng)作的超文本，支持面向社群的協(xié)作式寫作，Wiki站點可以有多人（甚至任何訪問者）維護，每個人都可以發(fā)表自己的意見，或者對共同的主題進行擴展與探討。

其內(nèi)容具有極高的關聯(lián)性，初始架構(gòu)不好的話可能會造成內(nèi)容結(jié)構(gòu)零散，不好閱讀；Wiki 語法標準不一樣，不同的wiki系統(tǒng)采用的語法不一致，造成作者編輯困難；并且結(jié)構(gòu)和頁面展示形式較難調(diào)整。使用wiki的時候需要遵循一定的準則，精心的編寫維護。