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