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