在收到國外匯款時，業務人員需要記錄匯款的相關信息，如果匯款指定的收款人帳戶為本行帳戶，進行入帳處理，如果收款人帳戶屬于同城同業（本地的其他銀行），則通過同城同業轉匯給收款人（后續如何處理？），如果收款人帳戶屬于異地同業（異地的其他銀行），則通過銀行的帳戶行將匯款轉匯至異地，并支付帳戶行轉匯的費用（后續如何處理？）。
以上是一個銀行的國際結算業務中款業務的例子。簡短的敘述和非正式的形式體現了XP強調的簡單原則。故事幫助開發人員和用戶理順流程的關系。在上述例子中，我們看到開發雙方對流程仍然存在一定的疑慮（即括號中有問號的部分），但是這并不影響到用戶故事的創作，因為這個版本的用戶故事還會變化多次。但從這個簡單的例子上來看，我們發現故事的形式仍然存在著一些不足： 故事的形式更容易被人接受，但是也有不規則的缺點。任意描述需求雖然節約了培訓的成本，但是卻造成了不一致性。不同的人對故事有著不同的理解，對需求也就有了不同的理解。需求故事雖然看起來很簡單，但是要講好一個需求故事絕對不是一件容易的事情。需求規約過于形式化和正式化，導致了需求規約難以使用，但是完全不要形式也不是一個好的做法。在形式和可用性之間保持平衡，是講好需求故事的關鍵。 需求故事雖然容易閱讀，但是卻很難寫得好。如何控制需求的描寫精度，如何分解需求，如何組織，如何確定邊界。但是XP并不關心這個問題，只要能夠起到溝通的效果，怎么做都行。這種態度是否正確我們暫不去評價。但在實踐中，由于缺乏系統的指導，一個新手往往需要花費很長的時間才能夠學會故事的寫法。
對于XP來說，需求的開發只有先后次序之分。而先后次序的制定由客戶來負責。但是在實踐中，識別出先后次序并不僅僅是客戶的責任，開發人員同樣需要提供需求優先級和風險的建議。這里有幾點需求優先級的建議：
需求中包含了主要的設計，或是包含了大量的業務實體和典型的業務規則。對于這樣具有系統代表性的需求，應該賦予較高的優先級。
需求中存在重大的技術風險，例如需求中包括了OCR開發包，而開發團隊原先并沒有相關的經驗。
需求中包含了重要的業務流程，代表了本軟件的主要設計思路。
需求具有代表性，并且難以估算，急需對需求進行試驗性的評估，以獲得較為精確的速度值。
需求的時間緊迫。
采用用例技術
文章來源于領測軟件測試網 http://www.kjueaiud.com/
