記錄這三年，關於項目管理上的一些心得體會 – 需求篇
對於需求，我們可以根據不同的角色、理解拆分成三個過程：
簡單來說就是：
需求分析原始需求、
需求拆分爲系統需求、
需求實現爲功能需求
**
需求分析
**：
將客戶需求 輸出成 需求描述。
需求經理需要把 用戶需求（User Story） 轉換成 客戶能夠接受的 初始需求 IR（Initial Requirement）
對於用戶來說，我只管提 我的原始需求是什麼
需求經理要記錄 用戶的IR 並在輸出件中標記明確 這幾個點是 用戶原始需求
需求拆分
有了初始需求(IR) 後，SE 就需要將 初始需求，結合自身對系統整體架構的理解，拆分成 SR（System Requirement）
意思就是說：爲了滿足 客戶的原始需求 （IR），SE 需要把 IR 進行拆分，結合自身對系統整體架構的理解，拆分爲系統所需要支持的幾個大的功能點，逐一諾列
需求實現
有了 SR後，需求經理SE，根據客戶需求，再結合自身系統特點，對SR 進行進一步拆分和細化，此時，對 SE就提出了較高的要求：SE需要根據 IR 和 SR ，場景化考慮每一個情況，並做詳盡的 AR （Allocation Requirement）輸出
此時輸出的內容就是：
要麼充分結合系統已有功能 明確指出哪里哪里 哪個功能的什麼場景下，後端接口做擴充、前端功能做擴展
要麼充分考慮用戶所需內容需求，結合自己系統功能，指出，什麼什麼場景下，調用什麼什麼接口，然後成功的時候幹嘛幹嘛 失敗的時候幹嘛幹嘛
上述三個步驟，大概輸出件長成這樣（華爲內部資料，無法附件形式分享，見諒）
當然，上述這一套是華爲的輸出件和流程、我們也可以根據項目的特性不同，單獨輸出《需求功能點》、《需求規格說明書》、《原型圖》，這些總結留到後面再單獨總結闡述
需求變更的管理與執行
當需求存在變更的情況下，正常情況下，華爲的執行順序是這樣的（華爲內部稱之爲 CR(Change Requirement) ）：
1、交付經理 和 售前，根據客戶需求，初擬《需求變更確認表》
2、然後和客戶確認，表中內容是否就是客戶想變更的內容
3、確認後，將表內容發回，由SE 評定工作量（其實就是白花花的銀子）
4、評定完成後，將 工作量更新進入《需求變更確認表》內，和客戶進行確認 和 簽字
5、當客戶側的 CR完成後，SE將 最新變更內容 更新進入 需求表，進入迭代
（內部附件，無法分享出來）
需求細節點輸出件
我們都知道，需求的最後澄清，不能光靠 上述的《UserStory 列表》，很多項目最後的需求澄清，是靠 傳統的 SRS文檔（Software Requirements Specification）。
它起到的作用是：申明清楚，有哪些硬件、哪些功能、性能要求是什麼、輸入輸出、接口需求、警示信息、保密安全、數據與數據庫、文檔和法規的要求等等
而在和華爲打交道的這段期間， 我接觸到的新的東西：FRS（Function Requirements Specification）
它其實就是 我們傳統意義上的 ：《詳細設計文檔》
更多的更加細緻的邊界限制、描述原始需求、展示對應UI圖或原型圖、實現邏輯，是靠FRS 來限制的，而研發除了在項目啓項之初，充分吸收 User Story以外，更多的是通過 FRS 來查看 整體SE規劃的實現思路是什麼，調用什麼接口，滿足什麼邊界值等等
當然，更高級的項目中，原型圖內，還會附帶 整體系統的邏輯跳轉地圖（進入系統長什麼樣、點擊這個按鈕彈什麼、點擊這個進入哪個頁面），清晰的不要不要的。