記錄這三年，關於專案管理上的一些心得體會 – 需求篇

對於需求，我們可以根據不同的角色、理解拆分成三個過程：

簡單來說就是：

需求分析原始需求、
需求拆分為系統需求、
需求實現為功能需求

**

需求分析

**：
將客戶需求 輸出成 需求描述。
需求經理需要把 使用者需求（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規劃的實現思路是什麼，呼叫什麼介面，滿足什麼邊界值等等

當然，更高階的專案中，原型圖內，還會附帶 整體系統的邏輯跳轉地圖（進入系統長什麼樣、點選這個按鈕彈什麼、點選這個進入哪個頁面），清晰的不要不要的。