需求描述方法論：條件—結果—目標
嘮嗑時光
各位鄉親父老們，歡迎來到村裏！我還是先來自我介紹下，免得各位老鄉對我有些陌生（此處需要些掌聲！）。
背景：在大四實習選擇了產品汪道路的我，有幸在世界500強某公司實習，這讓我在畢業後工作上更有底氣了（邪惡笑）。剛開始實習時，就想着從我的工作點滴中總結出一些產品乾貨，與各位鄉親父老們學習、討論…….（想着有一天能在村裏的廣播站，作為村裏的產品傳播員，分享乾貨）。沒想到現在已經畢業兩年了，才開始輸出我第一篇乾貨，才作為村裏的產品傳播員。
好了，我們還是先進入到正題吧，（不然我這個村裏產品傳播員的位置不保了！）各位鄉親父老們，請準備好筆和紙，今天的入門級乾貨課程馬上開始。今天分享的乾貨，對於剛入門產品的村員們來説，個人覺得非常實用。這也是我在實習的時候，自己總結出來的一些需求描述方法論。
工作場景
上級汪：待會和客户開需求會議後，你把需求描述下，記錄至需求池中。
下級汪信心滿滿地説：好的，沒問題。（不就是把客户的需求記錄下而已，這也太簡單了! 偷笑）
會議結束，下級汪很快就把客户的需求記錄至需求池中，胸有成竹提交至上級汪。
上級汪看了看，這需求怎麼描述地一團糟呢，看起來真費勁！！
在初步入產品工作時，你很有可能需要維護項目的需求池，記錄來自客户、公司各個部門的需求，那我們怎麼去做好需求描述呢？那我們直接進入到真題演練環節吧，讓各位老鄉們實戰感受下。
真題演練
項目背景：此係統用於門店旅行社，用户下載APP登錄後，需綁定旅行社員工（旅遊專家）。綁定後，旅行社員工可為用户提供專業的旅遊服務，如旅遊選品推薦、旅遊訂單確認等。
下級汪描述的需求
1. 需求描述：
用户綁定旅遊專家後，若旅行社員工不在旅行社或休息日時，則無法處理相關業務。
2. 解決方案如下：
（1）當旅行社員工收到訂單需求後無法處理時，自行聯繫同事幫忙處理；
（2）當旅行社員工收到訂單需求不在旅行社時，可通過手機登錄營業端進行處理。
3. 需求評審結果：
軟件開發角度上暫不修改，通過其他方式按照解決方案（1）（2）暫時解決此問題。
上級汪描述的需求
1. 需求描述：
當用户綁定了旅遊專家，且營業端只能在（旅行社的）PC上運行，如果該旅遊專家不在旅行社或PC出故障時，當用户發起相關業務時，該旅遊專家無法處理用户的業務請求，也無法委託其他同事代辦。旅行社要求希望此情況下該旅遊專家要能夠處理用户的業務請求。
2. 解決方案如下：
（1）系統增加旅遊專家委託代辦功能；
（2）系統增加營業端的手機版；
3. 需求評審結果：軟件暫不修改
（1）委託代辦：該旅行社員工把自己的賬號密碼臨時通知同事代為處理，事後變更密碼即可。
（2）營業端的手機版：後續適當時機會安排開發；目前該旅行社員工可以用手機瀏覽器直接登錄營業端，界面雖然沒有針對手機優化，但可以使用。
點評：通過上級汪和下級汪之間的需求描述對比，在不瞭解項目的整體情況下，看到上級汪的需求描述時，我們也能很清楚的知道在描述一個怎麼樣的需求，而下級汪描述的需求，需要對整個項目整體很瞭解，我們才可以看得懂。在實際情況下，需求會議上會有對項目瞭解程度不同的人員參會，所以按照上級汪的描述方式，好處顯而易見。
方法提取
那麼上級汪是如何把需求描述地如此清晰呢，使得對項目瞭解程度不同的人員都能理解？其實在描述需求的時候是有一套方法論，那接下來，我講對上級汪的需求進行拆分，各位鄉親父老們，睜大眼睛看看！
1. 需求描述：
條件：
（1）當用户綁定了旅遊專家，且營業端只能在（旅行社的）PC上運行；
（2）如果該旅遊專家不在旅行社或PC出故障時，當用户發起相關業務時；
結果：
（1）旅遊專家無法處理用户的業務請求，
（2）旅遊專家也無法委託其他同事代辦。
目標：
旅行社要求希望此情況下該旅遊專家要能夠處理用户的業務請求。
2. 解決方案：
（1）系統增加旅遊專家委託代辦功能；
（2）系統增加營業端的手機版；
3. 需求評審結果：軟件暫不修改：
（1）委託代辦：該旅行社員工把自己的賬號密碼臨時通知同事代為處理，事後變更密碼即可。
（2）營業端的手機版：後續適當時機會安排開發；目前該旅行社員工可以用手機瀏覽器直接登錄營業端，界面雖然沒有針對手機優化，但可以使用。
我把上級汪的需求描述拆分後，各位鄉親父老們應該能很清晰地看出其中的套路了吧。
在描述需求的過程中，我們使用以下的套路，會讓你的需求描述看起來：
條件：描述下事情發生在怎麼樣的前提條件下，也可稱為事情發生的前置條件；
結果：時間發生後，產生的結果是什麼；也可稱為事情發生的後置條件；
目標：在產生的結果下，需要解決怎麼樣的問題；
所以我們再描述需求時，我們腦海中應該有這麼一條弦：條件—結果—目標，這樣描述出來的需求更勝一籌！在需求描述完成之後，通過需求會議討論出解決方案及解決方案的評審結果。
大家可以拿起手頭上的需求，趕緊試試，看看是否顯靈！