5、確定使用實例
從用戶代表處收集他們將使用系統(tǒng)完成所需任務(wù)的描述，討論用戶與系統(tǒng)間的交互方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務(wù)的許多邏輯相關(guān)任務(wù)和交互順序。使用實例方法給需求獲取帶來的好處來自于該方法是用以任務(wù)為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發(fā)者為中心的方法，使用實例方法可以使用戶更清楚地理解和認(rèn)識到新系統(tǒng)允許他們做什么和怎么做。描寫使用實例的時候要注意使用簡潔直白的表述，盡量使用主動語態(tài)，"系統(tǒng)"或者"用戶"作為主語，比如"用戶提交用戶密碼，系統(tǒng)驗證用戶密碼是否正確"，還有一點在描述中不要設(shè)計界面細(xì)節(jié)，比如"用戶從下拉框中選擇產(chǎn)品類型"。使用實例為以后寫用例場景描述中的基本路徑和擴(kuò)展路徑提供了素材。
6、召開聯(lián)合會議
最常見的需求獲取方法是召開會議或者面談，聯(lián)合會議是范圍廣的、簡便的討論會，也是核心隊伍成員之間一種很好的溝通方法，該會議通過緊密而集中的討論得以將用戶代表與開發(fā)人員間的合作伙伴關(guān)系付諸于實踐并能由此擬出需求文檔的底稿。聯(lián)合會議的第一個議題就是系統(tǒng)的必要性和合理性，必須所有成員都同意系統(tǒng)是必要的而且合理的。接下來就可以討論使用實例清單，清單可以打印成大紙掛在墻上、寫在黑板上或做成演示材料。對每個清單合并去掉重復(fù)項，加上補(bǔ)充內(nèi)容就可以得到一份總的清單，注意避免采用負(fù)面的"太差""不可行"去否定用戶的想法，這些想法都應(yīng)該保留下來作為被評議的清單項，這樣保護(hù)了小組成員開放的思維。最后對清單進(jìn)行討論，會議成員必須檢查每一個使用實例，在把它們納入需求之前決定其是否在項目所定義的范圍內(nèi)，形成最終的需求報告。
在進(jìn)行討論時，也應(yīng)該避免受不成熟的細(xì)節(jié)的影響，在對系統(tǒng)需求取得共識之前，用戶能很容易地在一個報表或?qū)υ捒蛑辛谐瞿承┚_設(shè)計，如果這些細(xì)節(jié)都作為需求記錄下來，他們會給隨后的設(shè)計過程帶來不必要的限制，應(yīng)確保用戶參與者將注意力集中在與所討論的話題適合的抽象層上，重點就是討論做什么而不是怎么做。這里有一點很重要就是要讓用戶理解對于某些功能的討論并不意味著即將在系統(tǒng)中實現(xiàn)它，更不要做暗示或者承諾什么時候完成需求。在討論之后，記下所討論的條目，并請參與討論的用戶評論并更正，因為只有提供需求的人才能確定是否真正獲取需求。當(dāng)最后拿到了一份詳細(xì)準(zhǔn)確的需求報告書的時候，會議就算成功完成了。但是要清楚需求過程本身就是一個迭代的過程，在以后的過程活動中不可避免的將要修改和完善這份報告。
7、分析用戶工作流程
分析用戶工作流程觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過程，通過分析使用實例得到系統(tǒng)的用例圖。編制用例圖文檔將有助于明確系統(tǒng)的使用實例和功能需求，統(tǒng)一建模語言的使用有助于與用戶進(jìn)一步交流。每個用例的描述應(yīng)包括：編號,為每個用例分配一個唯一的編號，為需求的追溯提供了方便；參與者，與這個用例交互的actor；前置條件，開始用例前所必須具備的系統(tǒng)狀態(tài)；后置條件，用例完成后系統(tǒng)達(dá)到的狀態(tài)；基本路徑，用例完成的關(guān)鍵路徑，也是用戶期望的路徑；擴(kuò)展點，基本路徑的分枝，表示意外情況；字段說明，路徑中名稱的進(jìn)一步分解說明，對以后類屬性的定義和數(shù)據(jù)庫字段設(shè)計起作用；設(shè)計約束，實現(xiàn)用例的非功能約束。寫基本路徑時應(yīng)該使用主動語句；句子以actor或者系統(tǒng)作為主語；一句表示一個actor動作，一句表示系統(tǒng)動作，交叉表現(xiàn)交互；不要涉及界面細(xì)節(jié)，比如"用戶在文本框輸入名稱，下拉框選擇類型"。
