迭代需求的整理是敏捷開發的第一步，也是敏捷開發很重要的一步，在這一步中我們需要把客戶的業務需求按照優先順序的順序，整理成為一個個的迭代。然後把一個個的迭代拆成一個個可驗收的故事卡。

       在此需要說說什麼是故事卡，故事卡和業務需求之間的關係。故事卡是一個個獨立的，可驗收的功能，一個業務需求可以拆分為多個故事卡。比如：我們常見的賬號管理需求，需要對賬號進行增、刪，改、查。因為新增、修改、刪除、查詢都是一個個可單獨驗收的場景，我們可以把賬號管理需求拆分為四個故事卡。因此把需求拆分為故事卡的原則是：

    1.故事卡是可以獨立驗收的場景

      2.故事卡包含的點數應該儘量小，一般劃分為1、3、5個點，如果超過了應該重新拆分該故事卡。給故事卡評點的標準是什麼了？我們可以按照一個查詢完成的工作量是1個點，然後衡量該故事卡的工作量而適量的評點。

      3. 注意故事卡完成的工作量中包括自我測試和聯調的時間。而不是單獨的只是開發完成。

       敏捷開發強調成員之間的互動而不強調文件，但這並不意味著不需要文件，需求說明的好壞直接影響著客戶價值的交替，我們先來看看下面的一張圖：

客戶      ： 客戶高興的把具有5個價值點的需求交代給需求人員

需求人員： 需求人員由於理解的不同，只從顧客那裡接受了3個價值點

程式設計師   ： 由於需求人員表述的不清晰，最終程式設計師只理解了1個價值點，並互動給客戶

客戶      ： 當客戶拿到只有1個價值點的產品後，客戶哭了！！

因此作為需求人員，當在向程式設計師解析需求的時候，需要做到以下幾點，防止價值點的丟失。

a.  功能點：需求包含了那些功能點

b.  約束條件： 每個功能點有什麼約束條件

c.  流程圖 ：功能點的業務流程是怎樣的

d. 如果有介面的話，需要有頁面元素圖以及說明。

e. 驗收：驗收不同於測試用例，主要用來模擬使用者的行為以及期望的響應

現在我們就以一個簡單的登入介面，來講講應該怎樣去描敘需求：

功能點：

         1. 使用者可輸入使用者名稱、密碼。可選擇自動自動登入、記住密碼。響應登入按鈕

         2. 當點選登入時： a. 判斷使用者名稱、密碼是否有為null，有則提示使用者。

                                   b. 記錄使用者名稱、密碼以及記住密碼、自動登入的狀態

                                   c.  發起登入請求，並響應登入狀態。成功則調轉到下一個介面，失敗則提示使用者

         3. 啟動登入介面的時候，讀取配置檔案，訪問記住密碼和自動登入狀態。如果記住密碼為true，自動登入為false，則啟動登入介面的時候，使用者名稱和密碼為上次登入退出時的使用者名稱和密碼。如果自動登入為true，則直接執行點選登入的事件。

約束條件：

         1. 使用者名稱必須以字母開頭，並且包含字母、數字，長度不小於6位，當焦點切換到密碼的時候，自動驗證輸入的使用者名稱的合法性

         2. 密碼以*號隱藏

流程圖：

介面（低保真--介面元素草圖）：

驗收

以上對敏捷開發的闡述，摘自網上！