在很多軟體公司，特別是一些創業型的團隊中，對於這樣的情景可能大家都很熟悉：專案經理或者產品經理（產品狗）口頭或者簡單記錄一下軟體產品的大致要做的功能，直接就讓研發團隊的兄弟（程式猿）去狂擼程式碼。然後他就去喝茶撩妹或者回家陪老婆了…
這種擼起袖子就開乾的方式，看似簡單高效，便於直接溝通，能夠快速迭代。卻不知，發現沒有一份正規且實時更新的功能需求設計文件，會付出三四倍的代價來彌補。
最終會引發一場產品狗和程式猿之間的“猿狗大戰”…
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。
扯了這麼多，來個例子吧。
本軟體是給北京某醫院集團腎內科透析患者所使用的軟體，包括院內管理系統、院外大資料平臺、醫護端APP、患者端APP…
| 版本 | 作者 | 修訂時間 | 稽核人 |
|---|---|---|---|
| v1.0.0 | Charlie Chu | 2017-2-12 | Vivian Wong |
使用場景一：
腎內科的醫生王醫生給31號病床劉阿姨進行透析上機操作，王醫生在院內透析管理系統上點選上機操作，資訊會傳遞到院外的大資料平臺以及醫護端APP、患者端APP上…
劉阿姨患者的家屬登入到患者端APP後，可以實時檢視劉阿姨透析過程中的所有資訊，還可以檢視血壓、血糖、體重等歷史資料…
當劉阿姨在家中通過藍芽血壓計測量血壓時，自動同步到醫院內部，如果劉阿姨的血壓超過預先設定的值，院內的王醫生則會在自己的手機上檢視到劉阿姨的血壓異常報警資訊，王醫生可以立即跟劉阿姨的家屬進行實時溝通…
…<此處省略N字>…
本軟體(v1.0.1版本)不包括的功能需求如下：
- 醫生與患者的實時IM
- 醫生排班設定
- 修改密碼
- 患者積分
功能模組詳細描述：
一、APP登入頁面
由於本產品不存在患者自己註冊的場景，所有的患者錄入都發生在院外透析系統中，患者及家屬在院外只需要輸入相應的手機號，即可登入系統。
登入頁面只有兩個輸入框，一個手機號，一個密碼。
當使用者要輸入手機號時，手機應該彈出純數字鍵盤，最多隻能輸入手機號固定的11位。密碼最多輸入10位。
當使用者點選登入時，APP與後臺伺服器進行互動：
- 不輸入手機號和密碼，直接點選登入按鈕，應該提示使用者輸入手機號和密碼。
- 輸入手機號但不輸入密碼，點選登入，提示“請輸入密碼”。
- 輸入不正確的手機號，點選登入，應該提示“不存在該使用者”。
- 輸入小於11位的手機號，應該提示“請輸入正確的手機號”。
二、登入後首頁
下圖是左側是一個首頁，右側是一個點選透析預警的詳細頁面:
首頁包括功能點：
- 資訊資訊輪播 首頁頂部資訊資訊輪播功能，點選可以跳轉到新的頁面可以檢視資訊詳情。
- 病情諮詢 點選“病情諮詢”模組，患者檢視向指定的醫生了解自己的病情。
- 透析記錄 點選透析記錄，患者可以隨時隨地檢視自己的過往透析記錄。
- 食物速查 點選食物速查，可以檢視所有類別的食物成份含量。
- 透析上下機實時資訊列表 當患者在醫院內進行透析上下機等操作時，會記錄患者的透析上機時間 、下機時間等資訊。點選其中的一條記錄，跳轉到透析詳情頁面，如上圖右側所示。
HOW – 如何保證文件質量
要保證文件能夠實時更新同步，而不是疲於應付。那就是讓大家都通過該文件來進行溝通，誰有問題直接去看文件，需求一旦變更首先就更新到文件。
研發人員嚴格按文件上的描述來開發，在沒有文件之前，對不起，拒絕開發！任何口頭、QQ或郵件上的新的功能需求一概不理！提前是產品狗要比較給力，否則老闆還是會讓你狂擼程式碼…