軟體需求是乙個軟體專案成功的關鍵因素，許多軟體專案失敗都是因為軟體需求的「不完整、不準確、不一致」。而軟體需求是從業務需求經使用者需求最終得到系統需求的，所以業務需求是軟體需求的源頭，而業務需求又是從客戶業務中來的，客戶有問題且需要解決的業務才是業務需求。所以準確、完整的根據使用者的描述獲取使用者的業務需求至關重要。從軟體開發的角度入手，使用使用者故事，從使用者角度描述功能，讓我們可以從使用者角度出發思考問題，避免程式設計師的自以為是，使得業務需求更加的準確、完整。
使用者故事描述了對使用者、系統、或軟體購買者有價值的功能；包括三個方面的內容：乙份書面故事描述（用來做計畫和作為提示）；有關故事的對話（用於具體化故事細節）；測試（用於表達和編檔故事細節且可用於確定故事何時完成）。而使用使用者故事時，多個小故事要勝於乙個龐大的故事；故事卡上需要帶有適當的注釋，來規定對於每個功能的使用者期望是什麼，對下面的測試有著很大的作用。對於故事驅動的專案需要客戶和使用者在專案過程中全程參與。
編寫使用者故事時最好根據使用者類別來編寫，每個使用者故事都由商業語言來編寫而不是技術術語；由客戶團隊（包括確保軟體滿足使用者需求的所有人，可以安排開發人員的工作優先順序）而不是開發人員來編寫。客戶團隊與開發人員一起選擇迭代長度，在每個迭代結束時，開發人員需要交付完全可用的應用程式子集，客戶團隊則要確保專案能夠達成交付所需產品的目標。
驗收測試時即用來驗證實現的使用者故事是否符合客戶團隊的期望。測試應該盡早的在迭代中進行編寫，方便客戶團隊與開發人員進行進度的溝通。
編寫的故事卡主要起提醒作用，提醒客戶團隊和開發人員在以後要進行關於需求的對話，並不是需求本身，具體的細節需要客戶團隊與開發人員討論。編寫的每個故事必須對使用者有價值。有區分軟體使用者和軟體購買者。針對不同的使用者故事卡上的需求側重點也不同。對於編寫的故事卡所需的編碼量需要能夠估計出來，這樣對於規劃每個迭代階段進行的內容有很大的幫助。每個故事都可測試的，測試開發人員是否正確的完成了故事。
總起來說，為了更好的進行軟體需求可以採用使用者故事的方式。一張好的故事卡需要大小適中，由客戶團隊用商業語言進編寫，可以進行測試。寫好使用者故事，並根據功能的優先順序將各個故事安排在相應的迭代階段，然後進行實現，對於整個軟體專案的進行以及完成的軟體與使用者的需求的一致也具有很大的促進作用。
《使用者故事與敏捷方法》閱讀筆記01
使用者故事與敏捷方法第一章是對使用者故事的概覽。首先第乙個問題使用者故事是什麼？使用者故事描述了對使用者 系統或軟體購買者有價值的功能。使用者故事由三個方面組成，包括1 乙份書面的故事描述，用來做計畫和作為提示。2.有關故事的對話，用於具體化故事細節。3.測試，用於表達和編檔故事細節且可用於確定故事...
使用者故事與敏捷開發方法筆記06
使用者故事得到這麼多人的肯定，是因為它自身的優勢有很多 1 使用者故事強調口頭溝通，因為傳統的通過各種文件進行表達，每個人對於文字的含義的理解都不同，所以在閱讀文件的過程中可能會因為理解的不同對專案的完成造成影響 2 人人都可以理解使用者故事，並且使用者故事可以增強人們對各種事件的記憶 3 使用者故...
使用者故事與敏捷開發方法筆記05
每一輪迭代完成之後需要開迭代計畫會議為下一輪的迭代計畫。迭代計畫會議包括 1 討論故事 2 從故事中分解出任務 3 開發人員承擔每個任務的職責 4 以上3項完成之後每個開發人員對其任務量估計，盡量保證自己領取的任務在下輪迭代結束時可以完成。討論故事 開發人員充分理解故事，在其中分解出任務 需要理清故...