6、召開聯(lián)合會(huì)議
最常見的需求獲取方法是召開會(huì)議或者面談，聯(lián)合會(huì)議是范圍廣的、簡(jiǎn)便的討論會(huì)，也是核心隊(duì)伍成員之間一種很好的溝通方法，該會(huì)議通過緊密而集中的討論得以將用戶代表與開發(fā)人員間的合作伙伴關(guān)系付諸于實(shí)踐并能由此擬出需求文檔的底稿。聯(lián)合會(huì)議的第一個(gè)議題就是系統(tǒng)的必要性和合理性，必須所有成員都同意系統(tǒng)是必要的而且合理的。接下來就可以討論使用實(shí)例清單，清單可以打印成大紙掛在墻上、寫在黑板上或做成演示材料。對(duì)每個(gè)清單合并去掉重復(fù)項(xiàng)，加上補(bǔ)充內(nèi)容就可以得到一份總的清單，注意避免采用負(fù)面的"太差""不可行"去否定用戶的想法，這些想法都應(yīng)該保留下來作為被評(píng)議的清單項(xiàng)，這樣保護(hù)了小組成員開放的思維。最后對(duì)清單進(jìn)行討論，會(huì)議成員必須檢查每一個(gè)使用實(shí)例，在把它們納入需求之前決定其是否在項(xiàng)目所定義的范圍內(nèi)，形成最終的需求報(bào)告。
相關(guān)閱讀：職場(chǎng)溝通必備8個(gè)黃金句型 鬼谷子 語言溝通技巧
在進(jìn)行討論時(shí)，也應(yīng)該避免受不成熟的細(xì)節(jié)的影響，在對(duì)系統(tǒng)需求取得共識(shí)之前，用戶能很容易地在一個(gè)報(bào)表或?qū)υ捒蛑辛谐瞿承┚_設(shè)計(jì)，如果這些細(xì)節(jié)都作為需求記錄下來，他們會(huì)給隨后的設(shè)計(jì)過程帶來不必要的限制，應(yīng)確保用戶參與者將注意力集中在與所討論的話題適合的抽象層上，重點(diǎn)就是討論做什么而不是怎么做。這里有一點(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ù)庫字段設(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ì)模式一樣，需求也有自己的模式。
