只從一個角度寫使用者故事，往往容易忽略一些需求，因為有些故事針對的並不是系統的一般使用者，因此需要採用一些初始步驟來更好的編寫故事。

使用者角色建模

1 通過頭腦風暴，列出初始的使用者角色集合

每個人儘量想出多的角色，並把它們寫在卡片上；不需要對角色進行討論和評估；直至很難再想到新的角色為止。

2 整理最初的角色集合

分析角色的相似，重疊之處

3 整合角色

整合和弄色角色，將重疊較大的角色，整合為一個角色；重疊較小或有必要分開的角色保留。

4 提煉角色

根據整合好的角色進行討論，通過給每個角色定義一些特徵來建立角色模型。角色特徵是關於同屬於這一類使用者的事實或資訊。任何可以區分這個角色的資訊都可以用作該角色的特徵。

適用於任何角色建模的角色特徵包括：

• 使用者使用軟體的頻率
• 使用者在相關領域的知識水平
• 使用者使用計算機和軟體的總體水平
• 使用者對當前正在開發的軟體的熟悉程度
• 使用者使用該軟體的總體目標

此外，還可以使用虛構人物和極端人物來對角色進行補充。

蒐集故事

拖網（Trawling）式需求收集

1 用不同大小的網用來捕獲不同大小的需求。可以先捕獲大的需求，以便形成對軟體的整體感覺；然後捕獲中等大小的需求，暫時不理會小需求。大小可以是需求的商業價值高低或必要性程度。

2 拖網捕獲可能會漏掉需求，因為這個需求目前對系統來說並不重要。而隨著每輪迭代的反饋，有些需求可能會越來越重要，而有些曾經重要的需求，重要性可能會降低甚至變得不需要。

3 我們不可能一次捕獲所有的需求，可有可能會捕獲到不必要的需求，他們會使需求膨脹。

4 需求收集技能也是發現需求的一個要素。

需求捕獲方式

1 辨別傳功規範過程和敏捷過程最簡單的方法之一，是看他們蒐集需求的方式。傳統規範過程的特徵是過分強調在專案早期正確的獲取並寫出所有需求。敏捷專案承認沒有一種理想的方法，可以在一個單一階段獲取所有的使用者故事。敏捷過程也承認使用者故事有一個時間維度：隨著時間的推移以及先前迭代中加入產品的故事，一個故事的相關性會有所變化。

2 即使承認無法為一個專案編寫所有的故事，我們還是應該在早期嘗試編寫我們可以編寫的故事，即使許多故事還只能停留在十分籠統的階段。使用故事的好處之一是我們可以用不同的詳盡程度來編寫，我們可以展望一個釋出的時間，故事的釋出時間越往後，故事可以約粗略。 

建立故事的方法

• 使用者訪談 -- 儘量使用開放性問題
• 問卷調查 -- 適用獲取具體問題的回答
• 觀察 -- 有助於獲取真正的需求
• 故事編寫工坊 -- 由開發人員，使用者，客戶等共同參與的會議；只編寫儘可能多的故事，不進行優先順序排序；從角色和主頁面開始，推薦使用深度優先的方法，收集完整個操作流程中的所有故事，然後換下一個角色。故事編寫工坊的目的是在短時間內寫出更多的故事。