開發人員怎么才能夠快速理解需求？文檔的制作融入了制作者的思想，因此他人理解總是需要一定的時間的。解決問題的思路有兩個：一是提供標準通用的做法；二是簡化文檔，簡單的東西總是要容易理解，但簡單的東西并不等同于制作容易。
維護文檔需要成本。不管如何，維護成本始終是無法避免的，關鍵在于，能否降低這部分的成本呢？維護成本和文檔數量、復雜度成正比，因此文檔的數量要盡可能的少、復雜度要降低。此外，減少維護的次數也是關鍵的因素之一，在討論精益原則的時候我們說盡可能推遲決策就是這個意思。
針對以上的幾點，XP提出了自己的實現思路－用戶故事。用戶故事簡單，每個人都會寫，每個人也都能理解，改變起來也很容易。但用戶故事只是對系統功能的一個簡單的描述，他并不能提供所有的需求內容，因此，在XP中，用戶故事的實踐需要現場客戶的支持。用戶故事之所以簡單，是因為它只是開發人員和客戶之間的一種契約，更詳細的信息需要通過現場客戶來獲得支持。 從XP的觀點來看，用戶故事有這么幾點作用：
客戶自己描述、編寫需求。對于任何一個需求來說，最理想的狀態都是開發人員教授客戶編寫需求。最差的情況是開發人員代替客戶編寫需求。毫無疑問的，XP要求的就是最優秀的做法�？蛻粢軌蜃约洪_發需求，前提條件是編寫需求的技巧應該足夠簡單，能夠很容易掌握，或是經過培訓很容易掌握。用戶故事就是這樣一種簡單的機制。
用戶的觀點。優秀的需求應該是站在用戶的角度來思考問題，是用戶能夠利用系統完成什么，而不是系統自己完成。用戶故事很好的達成了這一原則。因為用戶故事是用戶站在自己立場上編寫，表現了用戶對系統的期望和看法。
重視全局，而不是細節。需求有精度上的差別，軟件開發初期最關鍵的，是建立一個高階的需求概況，而不是立刻深入細節。對于XP來說，最主要的細節需求獲取的方法是經過現場客戶�，F場客戶隨時提供對需求細節的指導。因此，用戶故事的重點在于，盡可能全面的發現需求，以及，維持一個簡單的需求列表。
評估的依據。用戶編寫的需求為軟件的估算提供了依據。雖然這個依據是比較粗的，但隨著項目的發展，開發速度的估算會越來越精確。在需求初期就進行適當的估算，其目的是讓用戶能夠有一個比較直觀的成本概念。這為用戶制定需求實現的先后次序提供了指導。
用戶自己的統籌安排。制定用戶故事就像是上商場購物，雖然每件物品都是有用的，但是最后購買的次序和數量則要取決于錢包的厚度。在每一個用戶故事具有了成本（即上一條中的估算）之后，用戶就能夠權衡實際成本和需要，并排定需求的座次。
迭代計劃的輸入。用戶對用戶故事的選擇直接影響到迭代計劃的制定，在第一個版本中，用戶希望能夠實現哪一些的需求（通過選擇用戶故事），經過估算，這些需求是不是能夠在這個版本中實現，計劃需要多長的時間。這些都是需求對迭代計劃的影響。
故事的弊端
文章來源于領測軟件測試網 http://www.kjueaiud.com/
