需求文檔，或許叫解決方案文檔更合適。
百度隨便搜一下『需求文檔』，大約幾十萬個結果。想必我們都看過不少這種文章，下過不少模板。很多時候還是不得要領，一想到寫文檔就頭疼。
這篇文章關注的不是寫成什么樣，然后給大家一個模板了事，也不會講文檔的結構應該怎樣。
思路清晰，做事才能高效。本文關注的是寫作背后的思考過程是怎樣的，現(xiàn)在，把我的一些思考分享出來。
引言
說需求文檔之前，我們先了解一下『需求』這個詞。很多場景下，我們都會用的這個詞。調(diào)一下字體顏色，也被設計師說成是需求，需求這個詞感覺有些被泛化了。
而產(chǎn)品經(jīng)理在作需求分析的時候。這個需求的定義是指：誰在什么情況下想做什么，以達成什么結果？簡單來講，就是某個角色想得到或完成什么？需求是需求方的渴求，只跟需求方自己相關，是不帶解決辦法的，提出解決辦法是產(chǎn)品經(jīng)理的工作。
如果有人說，我想加個按鈕，產(chǎn)品經(jīng)理正確的做法是搞清楚用戶的出發(fā)點是什么？為何要加？有沒有更好的解決辦法？而不是馬上就把按鈕加上。
傳統(tǒng)的軟件需求分析理論中，需求可以分為三個層次：
業(yè)務需求（Business requirement）標志組織或客戶高層次的額目標。業(yè)務需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業(yè)務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。
用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統(tǒng)必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。
功能需求（functional requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務，滿足業(yè)務需求。功能需求有時也被稱作行為需求（behavīoral requirement），因為習慣上總是用“應該”對其進行描述：“系統(tǒng)應該發(fā)送電子郵件來通知用戶已接受其預定”。功能需求描述是開發(fā)人員需要實現(xiàn)什么。
我們在做需求分析，也按照這個思路來進行。
第一步，公司想干什么？
正確定義問題，是成功解決問題的一半。
宏觀上，你需要對組織的優(yōu)勢、劣勢非常了解；需要對用戶構成及特點很熟悉；需要對市場變化趨勢有把握。
在以上的背景條件下，提供一個解決方案，其實就像是在大生態(tài)下面，打造一個微型的生態(tài)。
假設我們在經(jīng)營一片果園，目標就是種出好吃的果子。
先解構這個小生態(tài)，是由哪些要素組成？比如需要有果樹，需要有肥沃的土壤，需要有人去打理等等。
更進一步，生態(tài)里面的哪些要素是變量？有哪些變量是我們可以調(diào)整的？
這過程中遵循的一些本質(zhì)的規(guī)律是什么？比如光合作用，比如溫度變化與甜度的關系等等。
最后，評估這個果園經(jīng)營狀況需要哪些指標？
上面其實有些像是商業(yè)需求分析文檔，站在一個宏觀的角度去看待問題，想辦法建立一個可以良性運轉的生態(tài)。
上面完成之后，我們再把視角放大，把這個小生態(tài)放到整個大生態(tài)里面去審視：對原有整個體系會產(chǎn)生怎樣的影響？還有哪些點沒有想到呢？
第二步，各個角色能做什么？
接下來我們進入用戶需求分析。
簡而言之把自己代入到這個生態(tài)里面的每一個具體角色，思考需要完成哪些事情。注意，這個角色不一定是指人，也可以指一個系統(tǒng)。從進入這個生態(tài)開始，到離開這個生態(tài)，這個角色要完成哪些事情？
這一步梳理完了之后，輸出用例圖及每個用例的詳細描述。
有必要的話，可以按價值取向?qū)τ美M行分類，比如說效率向、利益向。再用KANO模型分析一遍，這樣下來，基本上對需求會有透徹的理解了。
用例，是以使用角色的視角，描述與系統(tǒng)的交互的過程及結果，關注的是用戶可感知的層面。每個用例完成情況的衡量標準是什么？都得想清楚，因為我們是為一群用戶來做設計。
第三步，用戶完成的過程是怎樣的？
明確了能干什么事，那么就下來就把每一件要干的事解構出來。這個階段，輸出流程圖即可。
流程圖是以過程為中心，用全局的視角，關注事情怎樣被完成。一件事情可能有很多角色參與，共同來完成。每一個流程圖都為了獲得一個結果，各個分支都得考慮到，也就是說，必須是一個閉環(huán)。
用例和流程圖梳理完了之后。建議大家把各個用例涉及到的數(shù)據(jù)實體羅列出來。數(shù)據(jù)的狀態(tài)轉換是怎么樣的？這個也非常重要的，通常是輸出狀態(tài)轉換圖。
第四步，用戶的頁面交互是怎樣的？
這里我說一個觀點：用例是對用戶需求的描述，流程圖為用例服務，原型是為流程服務。
寫文檔就是從抽象到具象的過程。原型之前的工作就是抽象的部分，是可以脫離某一種具體實現(xiàn)方式及頁面而存在的。
作圖之前，還得再做一部分抽象的事情。
先把用戶觸點想清楚，你是想自己做個APP呢，還是做公眾號呢？或者小程序呢？如果是已經(jīng)成形的產(chǎn)品，基本上就沒什么可想的了。
然后作一個頁面結構圖，這個相當于文章目錄，梳理完畢之后，各個模塊需要哪些頁面就清楚了。每一個頁面基本上可以與流程圖的節(jié)點對應起來的，大家可以以這種方式去自查。
作一個頁面，也得有大局觀。頁面在整體的流程當中，扮演什么角色？比如說商品詳情，這個頁面要負責銷售轉化。用戶在這一步關注什么信息？他的決策依據(jù)是什么？這些都需要對用戶有很細微的理解，才能在滿足用戶需求的基礎上提升轉化。
每個頁面上的數(shù)據(jù)展示規(guī)則或者交互效果說明的有必要說明的，等直接在頁面上標示說明。比如時間是顯示年月日還是顯示X天前？頁面的顯示相關規(guī)則不要與前面的用戶流程圖混在一起，頁面只關注微觀的呈現(xiàn)。
注意，每個頁面都得與數(shù)據(jù)狀態(tài)轉換圖對應，思考各個元素在各種狀態(tài)下的呈現(xiàn)。
頁面建議用Axure的母板來做，做完了所有頁面，再與相關的用例描述、流程圖對應起來，平鋪在一個頁面，做好交互跳轉指示。
文檔到這一步，基本上就差不多了，實際工作中可能還有其他部分，比如說非功能性需求、性能需求等。
總結
需求文檔是對解決方案的描述，思考過程是從宏觀到微觀，從抽象到具象，類似哲學上還原論的思考方式。
抽象的工作沒有完成之前，先不要去做頁面這些具象的工作。
再次說明：用例是對用戶需求的描述，流程圖為用例服務，原型為流程服務。我的思路就是以用例為中心。
以上希望對大家有用。另外，建議大家去學習一下UML，包括它非常有用的一些圖表，這對理清思路大有裨益。
