需求工程系列（二）- 基於用例的需求管理架構

 為瞭解決前文所述的軟體需求困境，我們首先需要找到一種可以被各方真正理解和溝通、並可以被逐步精化的需求體系。我認為，這種體系應該是基於用例（usecase）的。

 

首先，讓我們仔細研究一下用例的定義：

一個用例抽象了目標系統在現實中將執行的一組情境（每個情境由一系列動作組成）；這些情境會產生一個對某個Actor有價值的、可觀測的結果;

 

在這個定義中，我們強調了兩件事情：一、用例是被從現實的情境中抽象出來的，而不是被隨便發明出來的；二、每個用例（情境）應能提供完整的商業價值。在未來的博文裡會介紹這兩條會如何協助我們避免對用例的誤用。

 

用例的優勢在於它天生是黑盒的，它用自然語言抽象了使用者和目標系統的互動，避免了混入分析、設計和實現細節，以保證用例可以被不懂具體技術的業務及測試人員所真正理解。同時，需求分析員又可以方便地通過用例分析（use case analysis）（即用分析類來試圖在理想方式下實現用例），將需求體系精華成分析模型。在這一過程中，需求分析員可以更進一步地完善基於用例的需求體系，而不必擔心分析模型會汙染需求，從而實現需求與分析的分離及有效互動。

 

最後，我們必須指出，基於用例的需求管理體系中不僅僅包含用例，它還應該包括涉眾請求，特性列表，前景文檔，補充規約，詞彙表等等。

 

用例其實是Ivar在許多年前發明的老技術了，現在被很多人所採用，而被更多人誤用，下面的文章讓我們看看一些對用例的典型的誤解和誤用。