本文是一個“小白版”的需求分析文檔，主要結合“會務管理系統 – 會議報名模塊”的產品案例，對需求文檔的框架展開了詳細説明，與大家分享。
本文的“初期需求分析文檔”不是產品經理工作中輸出的產品需求説明書，是為初期用研後的資料整理後進行輸出的，文檔格式除了通用部分，都有相對的調整，與市面上的文檔區別還是很多的；比如場景圖、及文檔內對業務及流程的落地説明，並非對企業內部協作使用的專業化文檔，本文檔主要用於初期的資料留痕。
如果文章中的文檔進行深度分析，就會專業化，進而演變成需求分析文檔、產品需求説明書、概要設計等。
一、前言
本文從“會務管理系統 – 會議報名模塊”的產品案例，説明初期的需求分析文檔到底如何寫，如何更落地；讓自己及其他閲讀夥伴更清晰的認知產品的場景、業務、流程，一步步形成完整的產品閉環，説用户懂的話，交出一份“小白版”的需求分析文檔~
“文言文”
很多產品人在初期產品調研後，做了信息收集及整理，輸出需求分析文檔，雖然這份文檔輸出是更好的鋪墊接下來的工作，但往往太過於官方，或者過於業務化，對於閲讀文檔的目標用户沒有做到同理心，領導看不懂，協作夥伴看不懂，這樣的文檔，價值何在呢？
產品人輸出任何東西都要儘可能的有價值，而我們是最應該知道什麼是價值的人，這對自己也是一種沉澱性的輸出。
os：閲讀文檔的目標用户，這裏面客户也算其一；在特殊情況下，文檔輸出的第一版是需要與用户核對，敲定很多業務規範及流程中的細節。
“白話文”
在做內容輸出時，謹記説人話，專業性語言少來，儘可能讓閲讀人員能夠“小白化”的讀懂，儘可能場景化，通俗易懂。
2. 明確文檔的用户
不同角色：
產品人：為產品部門內相關設計人員提供需求信息的展示，同時對自己為自查，對項目做留痕。
用户/客户：這裏的客户會與產品人進行輸出文檔的業務準確性做深入碰撞，敲定業務框架。
團隊成員：對接協作夥伴設計、程序；清晰明瞭，無需精細化宣講
3. 明白文檔價值
文檔價值
輸出：把大腦中的構思落地出來，形成文檔，給自己做自查，給夥伴清晰的視野反饋。
留痕：把關鍵性的信息全部囊括在內，有可追溯性，對內對外皆可做到整個項目的管理。
4. 如何讓文檔更落地
讓文檔落地，我們首先要明白，寫文檔的本質是什麼？
首先我們在輸出文檔時，對於我們目標用户必須要明確，而不是太過自我，很多業務細節延伸出來的伴生性功能需要雕琢一下，這些伴生性功能是否符合業務流、是否優化了業務流；
那麼我們需要切換到用户的業務場景視角，去發現這些是否真的是用户需要的，圍繞着業務場景及各個角色進行輸出內容。
三、文檔框架
框架分四部分：通用部分、場景流程、需求集合、其他説明。
os：框架的四個部分是本人泛指，自我定義，大家可以自己調整自己的文檔框架
1. 通用部分
文檔目的：
閲讀者介紹：簡要説明閲讀用户是誰即可，這裏點明產品的使用用户及角色做一個定義。
業務名稱解釋：對於項目中涉及的業務流程中出現的業務名詞做相應解釋。
項目綜述：
項目背景：圍繞整個項目的背景進行説明，着重描述業務場景。
項目範圍：業務場景中所涉及到的主線、支線業務流全面覆蓋；這裏包括伴生性需求。
項目目標：點出產品實現的目的，而不是產品人揣摩設計出來的
so：此部分為需求分析模板的通用部分，不做舉例説明了；切記一點，儘可能讓這部分足夠落地的闡述；用户閲讀文檔的第一部分就如同天書，後面也不會詳細去看。
2. 場景流程
業務流程：
總業務流程
業務流程説明
水務行業協會會務組織人員能在會務系統上編寫和發佈會議通知、酒店信息、房間信息等。
參會人員能從電腦、手機上查看會議通知和報名，報名後可以在網站上繳費、訂房、填寫發票信息、網上籤到，其中這幾個部分的操作沒有任何強關聯和限制，不分先後。
業務流可以有以下幾種情況，例如：
參會人員報名後可以進行繳費，之後預定房間，網上籤到；
參會人員可以不繳費、直接預訂房間，網上籤到；
參會人員可以不繳費、不預定房間，直接網上籤到；
參會人員可以報名後直接去現場簽到；
參會人員可以不提前報名，直接到現場簽到，一同辦理：報名、繳費、訂房、現場簽到多項內容。
其中現場簽到前進行網上籤到是有好處的，簽到後可以查看最新的會議動態。不進行網上籤到的必須現場簽到後才可以查看會議動態；
現場簽到後，就可以按照分配的房間，辦理入住。並且領取資料和查看最新會議動態。最新會議動態可以在網頁上和手機上查看，內容包括：最新議程、酒店信息變更、房間信息更新等。
應用終端：Web、wap、H5；
業務場景：
1）前台：會務管理系統中，前台的用户角色以及對應業務模塊的交互關係；
2）後台：在會務管理後台中，用户可分為五類
會務組領導：會務組的領導一般只需要查詢信息，看會議的報名、繳費、簽到等情況。後續還會增加統計功能。
會務組信息編輯人員：主要是在會前編輯會議通知，會中發佈通知變更，會後查看報名、繳費信息，退款審核等。
會務組現場服務人員：主要負責現場簽到，查看、修改報名及繳費信息，會後負責退款的審核等。
會議組財物人員：主要查看繳費和發票信息，更改繳費狀態，按照退款審核結果完成退款等操作。
信息錄入人員：線下報名過多，會務組人員需要協助錄入時就需要本角色的進入，主要負責錄入報名和繳費的信息。如需要也可錄入簽到信息。
3. 需求合集
根據業務需求而來的模塊，以前台“網上報名”為例，舉例説明。
每一模塊的結構是這樣的：
需求説明
參會人員可以通過手機、電腦瀏覽看到會議通知，點擊報名入口，進入報名流程；報名通道選擇：網站的原始會員可以通過會員通道報名，不是會員的用户可以通過非會員通道報名
1）會員報名：
如果已經是本站的會員，可通過會員登錄的通道進入報名頁面；登錄方式可以支持會員賬號和手機號。
會員登錄後可以根據情況選擇，是要“為自己報名”還是“為他人報名”。
會員登錄後可以為自己報名，填寫相應的報名信息即可完成報名。
報名信息包括：會員賬號、姓名、性別、手機號、單位、職位、省市信息、是否入住、是否接受拼房、是否參觀等信息，以上信息都為必填項。
本次需要優化的內容，主要是針對系統在使用過程中，遇到的一些問題；
具體如下：
有些人報名時填寫的手機號碼是明顯錯誤的，現在填寫的信息有“1”、“11111111”、“ajdiwk”等情況，希望可以提高準確率，比如可以限制位數、數字驗證等方法。
頁面中“姓名”的位置有填寫單位名稱或多人姓名的情況，希望本次優化中可以減少此種情況的發生。由於參會人員中會有少數民族的情況，名字字數比較長，根據以往報名人的名字長度分析，一般都在8個漢字以內。
很多人的性別和拼房信息是錯誤的，因為現在的方式是有一個默認選項，部分人就直接略過不去選擇了，提交後也可報名成功，很容易被忽略。希望去掉現在的默認選項，必須選擇才可以通過。
為了實現報名情況按照省、市統計的功能，報名信息中還需要增加省市的信息，最好用下拉選擇的方式。
會員報名信息中需要帶入本會員已有的相關信息。
報名成功後希望可以收到短信提醒，説明報名的基本情況，內容可包含會議名稱、會議地點、會議時間等內容。
為他人報名
會員登錄後還可以選擇為他人報名，選擇“為他人報名”後，填寫參會人的報名信息即可完成報名。報名完成後還可以繼續為他人報名，直到將所有需要參會的人員都報完為止。
2）非會員報名
如果還不是本網站的會員，可以選擇非會員報名的通道進行報名。
非會員報名要實現不用註冊和登錄，只要通過驗證即可進行報名。
報名人需要填寫的信息包括姓名、單位、手機號碼，需要驗證身份方可通過。比如，可以通過手機號碼進行驗證，此處需要提示填寫正確的手機號碼，以便收取驗證碼等等。
為了讓非會員報名成功後，能夠查詢自己的報名信息並增加網站的會員數量，非會員報名成功後應按照所填寫的手機號碼生成一個新的會員賬號，報名人可以用此賬號登錄本網站，並收到“新賬號”的短信提醒，希望新賬號的初始密碼是簡單的數字。
此時報名人已經成為會員，後續的操作與會員報名基本相同；可以根據情況選擇，是要“為自己報名”還是“為他人報名”。
不一一舉例了……等
4. 其他説明
此部分為“數據説明”。
例如：報名單、回執單、會議小條、發票信息、現場簽到表。
“會議小條”數據項包括序號、繳費金額、房間類型、數量、資料份數、房間號碼；樣式如下：
現場簽到表；樣式如下：
四、總結 一個小白能看的懂的需求分析文檔，要搞定三點
先明白文檔讀者是誰，對症下藥，不盲目揣測、預言；設計經驗固然有用，但請慎用，不要自以為，要用户以為。
文檔呈現的內容一定要夠落地，讓任何一個用户看見之後，能夠清晰知道這個產品是做什麼的，解決什麼問題，存在的價值是什麼。
模板！模板！模板！任何一個文檔模板都是可以自行定義的，你的工作方式不同，文檔輸出內容就一定會存在差異，以上模板只是一個舉例，可以自己雕琢一番。
些許經驗分享
很多產品人都很清楚，在過往經歷中，一定存在這樣的場景，需求到手，沒有形成內容落地，直接進行設計；這裏可能存在各種外在因素導致這一環節遺失，直接從需求過度到功能框架、原型設計；這可以理解，但不要掉以輕心，畢竟這是對原始需求的一種留痕。
在簡單點説，可以把這個“小白版”的需求分析文檔，當做一次會議記錄，用最簡單，最直白的大白話記錄下來，未來翻過來看看，非常清晰的知道，當初的需求是什麼，而不是資料的一層層翻閲。
每日一語
年少的時日從我身邊滑過，而我從來不知道，那已是生活；
珍惜我們每一次的努力，每一次需求的探索，都是對未知的渴望，也是對自己的沉澱。
題圖來自Unsplash，基於CC0協議