過程中并在其中不斷變更、迭代和完善。
敏捷需求分析認為，需求應建立在以用例為中心的需求文檔體系，采取協(xié)作式而非合同式的溝通方式之上。具體可分為五個關鍵點：
用例；
協(xié)作；
迭代，即需求不是一次最終確定，而是先完成主要框架，再通過迭代逐步精化；
整個過程中以分析為支撐，做需求同時也在做分析，分析模型的輸出結(jié)果應跟需求分開；
把用例分解到用戶故事，在整個軟件生命周期過程中來驅(qū)動開發(fā)和測試。
業(yè)務/技術溝通頻現(xiàn)“兩份需求”
同時還要考慮到的是，將兩份需求改為一份文檔，而不必死摳CMMI概念區(qū)分出用戶和軟件需求。首份需求稿將由SA（系統(tǒng)分析師）來牽頭完成，負責各方協(xié)調(diào)和溝通的工作。理想的情況下，整個團隊在項目開始前就應搭建完畢，包括客戶、開發(fā)測試人員都參與的寫作和迭代，而不是以往的由技術人員對用戶進行里程碑式的教輔。通常來說，一個項目里一名SA同時對應5~9名開發(fā)人員是比較合適的。
需求文檔化與敏捷的平衡點
至于用例和用戶故事。按照敏捷大師Martin博客中的說法，兩者都是組織需求的方式，只是目的不同而已，用例的目的是為了把需求描述清楚，而用戶故事的目的是把需求分解成可用于迭代計劃的單元。對應到產(chǎn)品級和項目級文檔，用例是產(chǎn)品級，例如做咖啡機，不管有多少不同版本，有些核心功能是不改變的，這些都是產(chǎn)品級需求。而用戶故事則是項目級，屬于做完就扔的“拋棄型”。
進一步理解的話，用戶故事其實是一個或多個完整的業(yè)務場景，而用例是場景的抽象，一個用例里可以包含成百上千個場景。用戶故事是基于開發(fā)思想的，不光要考慮業(yè)務，還要考慮如何實現(xiàn)包括工作量大小、任務分配、項目風險以及架構(gòu)風險等多重因素。有人認為寫用戶故事是極簡單的事，但在吳穹看來，現(xiàn)在有很多人都還在用功能點套用用戶故事，顯得不倫不類，而沒有理解到用戶故事的精髓。
以ATM取款為例，正常流程是插卡、取錢、把錢拿走。這個看似簡單的場景其實工作量很大，可以在整個流程中做一些必要的簡化。有人認為既然用戶故事是一個場景，那就把它變成一個場景步驟吧，于是就成了功能點。其實他們忽略了一點，用戶故事還是一個簡化了但還保證完整業(yè)務價值的場景。ATM取款建立用戶故事會涉及哪些因素呢？取款是否需要輸入密碼？小額取款時能否取消密碼輸入的步驟？取錢后打印賬單，查詢余額等，在這里面哪些功能是風險級別高的，哪些需要與銀行核心數(shù)據(jù)通信？這不僅涉及（功能）優(yōu)先級的問題，還可以根據(jù)原則簡化用戶故事。例如可以考慮做一個用戶故事，儲戶用不需驗密的卡，限額是一千塊，取幾百塊錢的時候，把去銀行驗證的過程取消掉。這種情形下很多時候都要考慮到賬戶的風險情況，這些都需要多方溝通。類似的用戶故事簡化的情形有很多，但這時一定基于黑盒方式來做簡化。而在簡化的過程中，考慮如何實現(xiàn)如何合理調(diào)整工作量提高效率，這些都是找（用戶）故事的過程，也是一個白盒的過程。
在實現(xiàn)上，除了強調(diào)快速交付或生命周期很短、業(yè)務模式高度可變的互聯(lián)網(wǎng)、網(wǎng)游等項目，可以采用純用例的模式，現(xiàn)階段讓（大型）企業(yè)IT項目全面接納需求完全無文檔化還是不現(xiàn)實的，更實際的解決辦法是在文檔化和敏捷需求分析之間找到一個平衡，一份需求用例加上用戶故事，然后驅(qū)動開發(fā)這種方式，目前看來，這是現(xiàn)階段更適合大型企業(yè)的敏捷需求實踐模式。