么做。這里有一點(diǎn)很重要就是要讓用戶理解對(duì)于某些功能的討論并不意味著即將在系統(tǒng)中實(shí)現(xiàn)它，更不要做暗示或者承諾什么時(shí)候完成需求。在討論之后，記下所討論的條目，并請(qǐng)參與討論的用戶評(píng)論并更正，因?yàn)橹挥刑峁┬枨蟮娜瞬拍艽_定是否真正獲取需求。當(dāng)最后拿到了一份詳細(xì)準(zhǔn)確的需求報(bào)告書的時(shí)候，會(huì)議就算成功完成了。但是要清楚需求過程本身就是一個(gè)迭代的過程，在以后的過程活動(dòng)中不可避免的將要修改和完善這份報(bào)告。
7、分析用戶工作流程
分析用戶工作流程觀察用戶執(zhí)行業(yè)務(wù)任務(wù)的過程，通過分析使用實(shí)例得到系統(tǒng)的用例圖。編制用例圖文檔將有助于明確系統(tǒng)的使用實(shí)例和功能需求，統(tǒng)一建模語言的使用有助于與用戶進(jìn)一步交流。每個(gè)用例的描述應(yīng)包括：編號(hào),為每個(gè)用例分配一個(gè)唯一的編號(hào)，為需求的追溯提供了方便；參與者，與這個(gè)用例交互的actor；前置條件，開始用例前所必須具備的系統(tǒng)狀態(tài)；后置條件，用例完成后系統(tǒng)達(dá)到的狀態(tài)；基本路徑，用例完成的關(guān)鍵路徑，也是用戶期望的路徑；擴(kuò)展點(diǎn)，基本路徑的分枝，表示意外情況；字段說明，路徑中名稱的進(jìn)一步分解說明，對(duì)以后類屬性的定義和數(shù)據(jù)庫(kù)字段設(shè)計(jì)起作用；設(shè)計(jì)約束，實(shí)現(xiàn)用例的非功能約束。寫基本路徑時(shí)應(yīng)該使用主動(dòng)語句；句子以actor或者系統(tǒng)作為主語；一句表示一個(gè)actor動(dòng)作，一句表示系統(tǒng)動(dòng)作，交叉表現(xiàn)交互；不要涉及界面細(xì)節(jié)，比如用戶在文本框輸入名稱，下拉框選擇類型。
用例：用戶注冊(cè)，用戶注冊(cè)成為系統(tǒng)會(huì)員
編號(hào)
UC1
參與者 用戶
前置條件
用戶訪問系統(tǒng)，系統(tǒng)運(yùn)行正常
后置條件
系統(tǒng)記錄用戶注冊(cè)信息
基本路徑
1. 用戶請(qǐng)求注冊(cè)。
2. 系統(tǒng)顯示注冊(cè)界面。
3. 用戶提交注冊(cè)信息。
4. 系統(tǒng)驗(yàn)證注冊(cè)信息是否正確。
5. 系統(tǒng)生成用戶名和密碼，保存注冊(cè)信息。
6. 系統(tǒng)顯示注冊(cè)成功信息，進(jìn)入會(huì)員頁面。
擴(kuò)展點(diǎn)
4a. 用戶提供的信息不正確：
4a1. 系統(tǒng)提示輸入正確信息
4a2. 返回3
補(bǔ)充說明
注冊(cè)信息包括＝用戶實(shí)名＋電話＋傳真＋Email＋聯(lián)系地址聯(lián)系地址＝省份＋城市＋街道＋郵編
設(shè)計(jì)約束
注冊(cè)反應(yīng)時(shí)間不能超過3秒
8、確定質(zhì)量屬性
在功能需求之外再考慮一下非功能的質(zhì)量特點(diǎn)，以及確定由于特殊的商業(yè)應(yīng)用環(huán)境對(duì)系統(tǒng)提出的功能或性能上的約束，這會(huì)使你的產(chǎn)品達(dá)到并超過客戶的期望。對(duì)系統(tǒng)如何能很好地執(zhí)行某些行為或讓用戶采取某一措施的陳述就是質(zhì)量屬性，這是一種非功能需求。聽取那些描述合理特性的意見：快捷、簡(jiǎn)易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。你將要和用戶一起商討精確定義他們模糊的和主觀言辭的真正含義，并且要將質(zhì)量屬性分配到每個(gè)用例的設(shè)計(jì)約束中去。
9、檢查問題報(bào)告
通過檢查當(dāng)前已經(jīng)運(yùn)行系統(tǒng)的問題報(bào)告來進(jìn)一步完善需求客戶的問題報(bào)告及補(bǔ)充需求為新系統(tǒng)或新版本提供了大量豐富的改進(jìn)及增加特性的想法，負(fù)責(zé)提供用戶支持及幫助的人能為收集需求過程提供極有價(jià)值的信息。
10、需求重用
如果客戶要求的功能與已有的系統(tǒng)很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。業(yè)務(wù)建模和領(lǐng)域建模式需求重用的最好方法，像分析模式和設(shè)計(jì)模式一樣，需求也有自己的模式。