對於需求，我們可以根據不同的角色、理解拆分成三個過程：
簡單來說就是：
需求分析原始需求、
需求拆分為系統需求、
需求實現為功能需求
**
需求分析
**：
將客戶需求 輸出成 需求描述。
需求經理需要把 用戶需求（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規划的實現思路是什么，調用什么接口，滿足什么邊界值等等
當然，更高級的項目中，原型圖內，還會附帶 整體系統的邏輯跳轉地圖（進入系統長什么樣、點擊這個按鈕彈什么、點擊這個進入哪個頁面），清晰的不要不要的。
————————————————
版權聲明：本文為CSDN博主「minminzhe520」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/minminzhe520/article/details/52164752