（一）復習
需求文檔是產品的說明書
需求文檔包含：修訂記錄、背景、主要流程、詳細功能邏輯、數據上報，發布策略
bug也是需求文檔的一部分
（二）案例講解
案例一：
一個版本里面的4-5個功能點就比較合適
錯誤：
1、沒有標注需求的來源（用戶反饋，調研、數據分析）
2、沒有需求優先級
錯誤：
1、中間的應該是是keep，而不是功能結構圖
2、只有功能結構邏輯，而沒有信息結構邏輯
優點：用顏色的不同區分了功能結構的不同點
錯誤：
1、流程圖有兩個結尾
2、邏輯上不連貫
3、判斷邏輯上用一個判斷，盡量不用多個判斷
4、組隊界面使用一個頁面，這是不合理的
5、跳轉最后結果要說明（不要寫完成）
優點：1、頁面跳轉邏輯有一個流程度
2、結構明確，閱讀性ok
3、接受與不接受應該有一個狀態讓用戶知曉
錯誤：下面兩張圖片中的跳轉繞了一個大的彎子
錯誤：組隊運動會獲得榮譽，但會讓用戶獲得感不強（刺激感不強）
案例二：
錯誤：
1、都到v6.5版本了，之前的版本也要寫上去，功能升級的點
2、需求優先級沒有做劃分
錯誤：
思維導圖最多三級就ok了
錯誤：
1、版本第一個活動做的太復雜了（過度設計）
2、邏輯不符合，用戶可能會直接離開
錯誤
1、豎性目錄結構給觀看的人增加閱讀障礙，（最好使用兩級就行了）
2、沒有放在一張圖里面，不能讓人看見頁面之間的跳轉邏輯
錯誤：
進入頁面較為散亂，沒有突出重點
錯誤：報名界面較小（應該不管按鈕有多小，用戶都能去碰到）用戶可能退出流失
案例三：
錯誤：vip懸浮頁會讓我們的用戶點擊率變少，導致我們的產品收益變少
錯誤：具體流程過多，可能會讓用戶變的麻煩而退出（可以改為第1/3步，或者為進度條的提醒）
錯誤：
1、互聯網產品經理在進行一次產品版本升級的過程中不可能升級11個功能的，選擇4-5個功能點就可以了
2、沒有一個需求的優先級
3、沒有一個修訂記錄
錯誤：
1、頁面左上角一般不會放兩個圖標，用戶可能會誤觸
2、如果增加直播圖標，請把他帶來的收益寫出來
錯誤：
購買界面沒有說明判斷相關的條件
錯誤：長按界面進行快進，設計的過于隱蔽（應給用戶設計一個引導）且沒有控制的按鈕（如何回到原來的速度，且如何回退功能）
案例四：
優點：下拉框式組件，相較于傳統的輸入框，讓用戶更加直觀的理解
缺點：如果是選項進去了用答題的方法給用戶推薦東西我們就要把背后的邏輯給用戶說清楚，要不然就會讓用戶不知所云
總結
（三）個人總結
1、在進行PPR文檔的撰寫中，我們需要對需求文檔需求進行排序，以防我們的開發人員不知道我們此次的開發重點
2、在進行相關的需求時，我們要限定我們的需求數量，原因在于我們是小版本的更新迭代，不需要太多的功能的增肌或者是補全，還有一個原因在于開發周期與目標不能匹配
3、對于產品原型圖的交互邏輯方面、在繪制思維導圖的時候盡量用三級式的結構，多了對于文檔理解人員來說是個負擔（對于邏輯判斷的時候，使用兩個判斷邏輯就行了，判斷邏輯過多理解不來）
4、在繪制思維導圖的時候盡量使用流程化的繪制，且用一個文檔撰寫，以防頁面跳轉邏輯的不清晰
5、修訂記錄要嚴格按照格式來進行書寫，原因在于以防系統版本功能發生問題開發人員找人找不到相關人員，且不要在開發人員哪一欄寫好寫上一個組的，這會讓人產生疑惑
6、在流程圖方面，我們要進行相關的開始和結尾的劃分，以防開發人員找不到入口和結尾
7、在進行語言的描述時候，盡量使用簡潔、干練的語言進行說明，給予開發人員明確的任務需求
8、在業務跳轉邏輯方面，盡量準確簡潔，還需在功能使用完畢的時候給予客戶相關的提示，給予用戶交互感
9、在一些用戶看不到的功能使用方面的介紹，我們需要給用戶一個引導和提示，讓用戶明確功能的作用
10、在界面的相關制作方面，我們需要參考同類競品的相關分析，盡量不要違背用戶的使用習慣
