傳統需求分析

敏捷需求分析

需求分析時機

更多地集中在專案早期

近乎均勻地貫穿於專案的整個生命週期

需求劃分單位

基於功能分解，劃分模組或子系統，一個模組或子系統的顆粒度通常較大

基於能否獨立業務價值，切割成一個個使用者故事，一個故事有時會跨越傳統的模組或子系統邊界；故事的顆粒度較小

需求細化過程

一步到位，可供開發人員設計開發

逐步細化，僅就下一個迭代需要實現的部分進行詳細分析

需求文件要求

正式文件，往往有明確的格式要求。既作為設計開發人員必須嚴格遵守的規約，也作為向客戶提交的必備產出物之一。難維護，難驗證（跟蹤）

非正式文件。僅僅是輔助開發團隊與客戶溝通，不作為規約，也不作為必備產出物。更多強調通過自動化功能測試用例來跟蹤系統需求

應對需求變更

有嚴格的控制流程，視變更為風險

視變更為必然或預期中的事情

需求易變

需求穩定

客戶或業務人員隨時可找到並與之溝通

客戶或業務人員較難接觸到

客戶更在意產品投入市場或系統投入運營所需的時間

客戶更在意產品或系統是否覆蓋了制定的需求或功能範圍

團隊（包括交付團隊和客戶團隊）成員分佈在同一地域

團隊成員分佈在不同地域

交付團隊擁有更多的開發過程自動化技能及工作環境，諸如自動化測試、持續整合等

交付團隊擁有較少的開發過程自動化技能及工作環境