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

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

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

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

在這個定義中，我們強調了兩件事情：

一、用例是被從現實的場景中抽象出來的，而不是被隨便發明出來的；

二、每個用例（場景）應能提供完整的商業價值。在未來的博文里會介紹這兩條會如何幫助我們避免對用例的誤用。

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

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

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

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。