?1 寫出用戶級的需求用例。在現(xiàn)在的需求調(diào)研中，更多的是把客戶提出的需求用流程圖的方式表達(dá)。但是
在給客戶講解的時候效果不是很好，主要存在以下問題：
?? 1）流程圖不適合描述分支很多的流程。分支過多，將導(dǎo)致流程圖十分復(fù)雜，不具有可讀性。
?? 2）流程圖的受眾比較少。在實際的業(yè)務(wù)業(yè)務(wù)調(diào)研中，面對的用戶往往是系統(tǒng)的使用者，而不是作為
技術(shù)人員的維護(hù)和開發(fā)者，由于不具備相關(guān)技術(shù)背景，因此這些人在閱讀流程圖的時候，往往覺的眼花繚亂，更不要說提什么修改建議了。這將會使很多本應(yīng)在需求調(diào)研階段發(fā)現(xiàn)的問題，遺留到了用戶正式使用的時候，由此帶來的損失不可估量。
?? 3）由于流程圖是一個粗線條的流程描述，因此許多客戶提出的細(xì)節(jié)問題，需要以另外的方式進(jìn)行記錄
這可能會導(dǎo)致在設(shè)計階段遺漏掉。如 系統(tǒng)使用這在使用時的心態(tài)，等等
? 2 采用用例和流程的結(jié)合形式來描述客戶的需求，原因如下：
?? 1）由于用例采用自然語言描述，所以任何人可以輕松的進(jìn)行閱讀。
?? 2）在一定格式的輔助下，用例描述不必受流程分支多少的約束。
?? 3）采用自然語言描述，可以詳細(xì)的描述處用戶的使用細(xì)節(jié)，這些細(xì)節(jié)可能會對這個項目的開發(fā)起著
?? 決定作用。
?? 4）加入流程圖，讓具有相關(guān)背景知識的人迅速的了整個流程的全貌。如果分支不是很多流程圖
?? 還是可以畫的十分簡潔易懂的。
?? 5）好的用例對后期的設(shè)計，開發(fā)，測試都是很有幫助的。甚至可以直接作為客戶的培訓(xùn)素材
? 3 如何寫用例
?? 1）寫用例需要結(jié)合用例圖，用例圖可以讓用例的讀者了解整個系統(tǒng)提供的功能，和與其他系統(tǒng)的關(guān)系。?這樣可以使讀者的在閱讀用例時，在一個限定的范圍內(nèi)思考問題。
?? 2）用例的格式大體上可以分為前提條件，主成功用例，擴(kuò)展。當(dāng)然，作者可以豐富用例的格式，這里
?? 僅僅是一個最簡單的框架。
?? 3）由于是在需要階段的用例，因此用例盡量用輕松的語調(diào)來寫用例。你甚至可以把用例當(dāng)作一片散文來寫。這里需要注意的是，在寫用戶級用例的時候需要把系統(tǒng)當(dāng)作一個黑盒，不要去描述系統(tǒng)內(nèi)部是如何工作的
?? 此時作者一定要以一個客戶的角度來考慮問題，來描述系統(tǒng)。
?? 4）用例可以也可以想寫函數(shù)是的寫一些通用性比較強(qiáng)的模塊，以便其他用例可以復(fù)用。如用戶身份驗證模塊。
?? 5）在寫用戶級的用例時候，對用戶使用系統(tǒng)的細(xì)節(jié)需要描述，如使用者的心態(tài)。這可能決定著用戶易用度的設(shè)計。
?? 6）在寫用例的時候一定需要用完整的主謂賓來寫。及誰，在做什么
?4 用例描述僅僅是對用戶需求一個梳理的過程，我們還需分析出其中的主要實體，和他們的關(guān)系，在分析
? 的過程中可能會對產(chǎn)生新的疑惑，可以和客戶及時溝通。當(dāng)然在設(shè)計的過程中，也可以繼續(xù)和客戶溝通
? 但是，客戶方不一定能夠隨時協(xié)調(diào)到合適人員，這將導(dǎo)致項目的推后。因此，在集中討論期間
? 多做一些分析，乃至設(shè)計（原型的設(shè)計），可以大大減少后期的工作了量，提高客戶滿意度。用例，分析，和原型 可以是在需求期間一個小的迭代周期。
?5 在討論需求的時候，最好是以集中會議的形式進(jìn)行，參會者應(yīng)為 相關(guān)領(lǐng)導(dǎo)，系統(tǒng)將來的實際使用者
? ，技術(shù)把關(guān)人員。為什么者樣作，和如何利用其中的微妙關(guān)系，需要大家自己去體會，去琢磨。呵呵