十年來國內軟體工程方面的進展有目共睹，在軟體需求方面，我們看到在大多數組織中已經建立起了一級或兩級需求體系（業務需求和軟體需求）；在某些組織中，需求分析員已經成為一種專門的職位；甚至在某個大型國有商業銀行已經成立乙個專門的部門來負責需求分析工作。應該來說，這是一些非常可喜的進步。
然而，目前大多數的專案參與者都對需求工程的現狀不滿，這又是為什麼呢？首先，我們必須承認市場快速變化而帶來的需求變化的確對專案帶來了很大的挑戰，為此許多專案應用了迭代化開發來應對這樣的變化。但根據我們對客戶的訪談，更多的需求變化是由於需求溝通不力造成的，也就是說，參與需求溝通的各方並沒有達成真正的共識，這又是什麼原因呢？根據我們的分析，這主要是由於缺少乙個可以被各方真正理解和溝通、並可以被逐步精化的需求體系。
目前，大多數使用者採用的需求體系基本上是沿襲了結構化分析的文件體系（包括資料流圖，資料字典等）。這種文件體系起源於70年代，當時，軟體的主要應用還是科學計算或資訊處理，理解需求的人往往也受過結構化分析的相關教育，然而這些內容對今天的大多說業務人員或終端使用者而言就是很難理解的了。這裡的主要問題是分析代替了需求。為了解決這個問題，有的組織引入了非形式化、非結構化的業務需求，然而卻很難在兩種需求之間建立明確的對應關係，從而出現了業務人員/終端使用者認可業務需求，但開發人員覺得不夠詳細；開發人員認可軟體需求，但業務人員/終端使用者無法給與確認。
那麼，我們如何解決這一軟體需求的困境呢？
首先，讓我們仔細研究一下用例的定義：
乙個用例抽象了目標系統在現實中將執行的一組場景（每個場景由一系列動作組成）；這些場景會產生乙個對某個actor
有價值的
、可觀測的結果;
在這個定義中，我們強調了兩件事情：一、用例是被從現實的場景中抽象出來的，而不是被隨便發明出來的；二、每個用例（場景）應能提供完整的商業價值。在未來的博文裡會介紹這兩條會如何幫助我們避免對用例的誤用。
用例的優勢在於它天生是黑盒的，它用自然語言抽象了使用者和目標系統的互動，避免了混入分析、設計和實現細節，以保證用例可以被不懂具體技術的業務及測試人員所真正理解。同時，需求分析員又可以方便地通過用例分析（use case analysis）（即用分析類來試圖在理想方式下實現用例），將需求體系精華成分析模型。在這一過程中，需求分析員可以更進一步地完善基於用例的需求體系，而不必擔心分析模型會汙染需求，從而實現需求與分析的分離及有效互動。
最後，我們必須指出，基於用例的需求管理體系中不僅僅包含用例，它還應該包括涉眾請求，特性列表，前景文件，補充規約，詞彙表等等。
用例其實是ivar在許多年前發明的老技術了，現在被很多人所採用，而被更多人誤用，下面的文章讓我們看看一些對用例的典型的誤解和誤用
用例是乙個門檻很低的技術，任何人都可以隨便畫幾個小人和幾個橢圓，然後向全世界宣稱我在用用例進行需求建模了，但是好像也沒有真正解決我的問題。在這種情況下，用例技術很可能被誤用了。在對用例不同型別的誤用之中，最嚴重、最普遍的莫過於利用用例來進行功能分解了。
剛在為了偷懶，想找張現成的錯誤使用用例的例子，結果找的了2023年kurt寫的在這方面的文章以及最近一位老兄在csdn上給出的翻譯（已經收藏在我的網摘裡）。kurt對這個問題的闡述已經相當清楚了，我也就不多寫了，大家去看我的網摘或原文吧！
作為總結，可以記住這樣兩句話：
1、login往往不是乙個好的用例；
2、用例是不會互相呼叫的；
英文原文：
中文翻譯：
最近在與使用者的溝通過程中，發現使用者經常會認為用例是一種基於圖形描述或uml的方法，從而質疑用例是否能夠有足夠的描述能力，或者用例是否易於被業務人員理解。其實，這是對用例的另一種典型的誤解。
在用例模型中，的確會用到一些uml的圖符（乙個小人代表actor，乙個橢圓代表use case，等等），但這些圖符是非常容易理解的。而且用例的主要資訊是在需求規約當中，用例模型傳遞的資訊可能只佔所有相關需求資訊的5%。
所以，我建議，大家可以粗略地認為用例與uml基本無關，它主要是一種基於文字的結構化地書寫需求的方式。
用例的粒度問題一直是困擾著需求分析員的常見問題，對於這個問題，抱歉，沒有銀彈，我只能給出一些解決這個問題的基本原則：
1.控制用例的總體數量：一般來說，乙個相當複雜的系統的用例數量可能在
30-50
個之間，如果乙個系統的用例數量大大超過了這一範圍，那就該看看是不是陷入了功能分解的誤區；
2.高內聚、低耦合：用例是一種結構化寫作需求的技術，用例是被從現實的場景中抽象出來的。如果這些場景有緊密的聯絡（高內聚），那用用例技術來組織它們則可以復用這些場景中的步驟描述，從而達到事倍功半的效果；
3.寫寫看:
很多時候在初步規劃用例模型的階段，有時很難判斷乙個用例的粒度是否合適，不要執迷於一次獲得乙個完美的用例模型和用例粒度。不妨先得出乙個初稿，然後寫寫用例，看看是不是符合高內聚、低耦合的原則，實際上在寫用例的過程中，用例模型往往是需要不斷進行調整的；
4.避免功能分解：功能分解是正確使用用例技術的最大敵人，很多用例粒度的討論其實都是功能分解的思想在作怪。
目前大多數使用者的開發都是對現有系統的公升級和改造，在這樣的情況下還能使用用例技術嗎？很幸運答案是肯定的，你可以按照以下步驟進行：
1.確定系統邊界：通過標識actor來定義系統邊界；
2.重構用例模型：簡要地捕獲和描述現有系統的用例模型；
3.擴充套件用例模型補充用例規約：根據系統的公升級和改造要求，增加新的用例或對已有用例進行擴充套件；在對現有用例進行擴充套件之前，則需要補充用例的基本事件流和涉及到的備選流，在以它們為基礎來對描述需要的新行為；
這樣，就可以在對現有系統的改造過程中，逐步地重構整個系統的用例模型和用例描述。
軟體需求與分析 問題賬戶需求分析
案例 某大銀行的一位銀行卡辦公室的收賬經理liz遇到了乙個問題。她每週都收到乙份過期未付款的賬戶名單。這份報告已經從兩年前的250個賬戶增加到現在的1250個賬戶。為了確定那些嚴重拖欠債務的賬戶，liz需要通讀這份報告。嚴重拖欠債務的賬戶由幾個不同的規則確定，每個規則都要求liz檢查客戶的一項或幾項...
中小企業的軟體需求問題
近年來，做為我國經濟發展新興動力的中小企業同時也成為了it行業的熱點市場。it領域的頂級廠商在高階市場日趨飽和的情況下，正逐漸將眼光投向中小企業市場。而大多數it廠商由於自身的資源和規模限制無法涉足高階使用者，中小企業市場為這些廠商提供了廣闊的發展空間。另一方面，中小企業的成長需要隨著經濟環境的發展...
中小企業的軟體需求問題
近年來，做為我國經濟發展新興動力的中小企業同時也成為了it行業的熱點市場。it領域的頂級廠商在高階市場日趨飽和的情況下，正逐漸將眼光投向中小企業市場。而大多數it廠商由於自身的資源和規模限制無法涉足高階使用者，中小企業市場為這些廠商提供了廣闊的發展空間。另一方面，中小企業的成長需要隨著經濟環境的發展...