引言
作為 BU（UML 出現之前）時代面向對象技術的追隨者和支持者，我必須承認當時的業內思想領袖所傳播的各種方法和表示法對我具有某種魔力。在 UML 出現之前的兩到四年中，您可以走進一個擠滿 OO 鼓吹者的房間，并提問以下問題：
我認為這種 OO 技術很有前途，但是告訴我，既然對象共享行為和數據，那么您如何稱呼對象為實現它的行為義務而做的事情呢？
您可能得到如下答案：
- "它是一個職責！"（Wirfs-Brock）
- "它是一項操作"（Booch）
- "它是一項服務"（Coad/Yourdon）
- "它是一個（虛）函數"（Stourstrup）
- "它是一個方法"（其他很多人）
如果這還不足以讓您混淆的話，那么就不要問您如何用圖形表示我們稱之為對象和類的東西了。（它是一個矩形、一片云，等等。）雖然這看上去很愚蠢，但是實際情況是，我們軟件工程領袖的其中一些最顯著的共識（繼承、關系、封裝），由于在術語和表示法上的微小區別而無法得到共享，或者至少變得混亂。換言之，不管是 OO 工程科學還是將要獲得的利益都不能繼續向前發展，因為還沒有發明用來描述該科學的語言。當然，要在這些作者、方法學家 和獨立思想者中達成共識不是一件小事情，但是最終UML面世了，軟件工程科學又向前邁進了一大步。
雖然需求管理方法學可能不像 UML 出現之前的 OO 方法學所形成的巴比塔那樣糟，但是它卻經歷了同樣的一些問題--尤其是對常見詞匯的模糊、不一致和過度使用非常盛行。這些詞匯（包括諸如"用例"、"特性"和"需求"這樣的基本概念）是"每個人都理解"的日常詞匯，但是在給定的上下文中每個人又賦予了它們自己的含義。結果就是溝通不暢。這種情況僅在將達成共識作為成功標準的領域中發生。Booch [Booch 1994]引用了 Stepp 的說法：
科學中普遍存在的一個問題是為觀察到的對象和情形構造有意義的分類。這樣的分類能推動人們對觀察以及后續的科學理論開發的理解。
為了推動需求的"科學理論"，我們不得不面對術語的問題。
本文的目的在于，通過定義并描述用于說明系統軟件需求的一些最常見術語和概念，來初步探討一下軟件工程的原理。為此，我們希望提供一個能讓所有涉眾（用戶、經理、開發人員等）達成共識的基礎。當然如果我們更有效地交流并因此獲得一致看法，那么就可能更快地開發并交付更高質量的系統。
本文重點不在于需求管理的原理--關于這方面筆者在建議讀物中推薦了很多參考書目。本文的目的僅是幫助該領域中的從業者提高他們對系統正確行為的基本認識。
問題域與解決方案域的對比
在開始描述具體的術語之前，我們首先要意識到需要從兩個完全不同的方面定義術語：問題方面和解決方案方面。我們分別稱之為問題域和解決方案域。
問題域
如果我們在問題域上做一次"低空滑翔"，就會發現許多實際生活周圍的事物。比如"滑翔"過人力資源部門時，會看到雇員、負責發工資的職員以及工資支票。"滑翔"過重型設備工廠時，我們會看到焊工、焊接控制器、焊接機器人和電極。"滑翔"過萬維網時，我們會看到路由器和服務器群集，以及具有瀏覽器、電話機和調制解調器的用戶。換句話說，在任何問題域中，我們可以輕易地識別出我們看到和接觸到的事物（實體）。有時候，我們甚至可以看到這些事物之間的關系；比如，web 用戶和瀏覽器之間就是一對一的關系。我們可能還會看到從一個事物傳遞到另一個事物的消息："焊接工似乎正在往焊接機器人的'大腦'中編制工作次序"。
如果我們是敏銳的觀察者，可能會發現亟待解決的問題："焊接工對不能安排正確的工作次序感到氣餒"或者"注意到雇員輸入薪水數據與收到支票之間有令人不愉快的時間延遲！"。有些問題似乎只是在乞求一種解決方案。也許我們可以構建一個系統（更好的可編程控制器、更有效的工資處理）以幫助那些可憐的用戶解決這些問題。
?
基于用戶和涉眾需求
然而在我們構建新系統之前，我們需要確保理解了該問題域內用戶的真正需要。如果沒有，我們可能會發現焊接工只能愁眉苦臉，因為他就好像腳上得了雞眼一樣痛苦，結果就是他和他的經理都不會對購買我們最新的"SmartBot"自動焊接控制單元感興趣。我們還注意到當我們試圖銷售 SmartBot 時，經理是購買決策中的關鍵涉眾。我們不記得在"滑翔"中看見過她。（也許她當時正在吸煙室，而那里正是我們攝像頭的盲區）。換言之，不是所有的涉眾都是用戶，并且如果我們希望有機會賣出SmartBot，則我們必須同時理解兩個社區（涉眾和用戶）的需要。為了簡便起見，我們稱所有這些需要為涉眾需求，但是我們要不斷地提醒自己系統的潛在用戶有時代表了很重要的一種涉眾類型。
我們將涉眾需要定義為：
業務、個人或操作問題（或機會）的一種反映，其中這些問題必須得到解決，以使用戶相信他們考慮、購買或使用新系統的選擇是正確的。
于是涉眾需求就成為與問題域關聯問題的一種表示。這些涉眾需求并未給出解決方案，但是以一個最初的角度，使我們了解需要實現哪些可行的解決方案。比如，如果我們會見重型設備制造廠中管理焊接工的經理，就可能發現焊接大量重復性的焊接件會消耗巨大的制造時間和成本。另外，焊接工似乎不會喜歡這些具體工作，因為他們一直處在被燙傷的危險中。更糟的是，該工作的物理方面（重復、難以琢磨的手工操作位置以及對視力的危害等）帶來了個人安全問題以及長遠的健康隱患。
充分理解了這些事項，我們就可以開始定義其中一些涉眾需求：
- 我們需要一種自動化的方法來制造大量重復的焊接件，而不用讓焊接工手動控制電極。
- 我們很樂意能有一位焊接工，但是我們需要將其移到焊接件以外的安全區域并且遠離那些移動的機器。
- 我們需要能輕松使用"訓練模式"，這樣一般的焊接工也能夠"訓練"機器為他們做大部分工作。
- 我們需要使訓練模式中具有更大的靈活性，并且意識到這可能與用戶友好性需要的某些方面產生沖突。
當理解了系統的這些不同方面后，主觀上我們會將這些發現"堆放"在一個稱之為涉眾需求的小堆中。
解決方案域
幸運的是，對問題域的"滑翔"不會花很長時間，并且（通常）我們在問題域中發現的東西也不是很復雜。當我們完成"滑翔"并開始構建我們觀察到的問題和需要的解決方案時，就開始理解問題。是的，我們已經開始了最難的一部分：構建問題的解決方案。我們考慮活動集（系統定義、設計等）、為了解決問題而發現和構建的"事物"（計算機、機械臂等），以及在解決方案域的處理部分中創建的工件（比如源代碼、用例和測試）。
在解決方案域中，我們必須成功地執行很多步驟和活動，這樣才能定義、構建并最終部署問題的成功解決方案。它們包括：
1） 理解用戶需求
2） 定義系統
3） 管理范圍并管理變更
4） 精化系統定義
5） 構建正確的系統
簡言之，上述步驟定義了需求管理的一個簡化過程。本文不打算詳細介紹這些步驟；關于這些內容我們會為您推薦一些參考讀物，包括課本"Managing Software Requirements"，[Leffingwell, 1999]。本文與該參考書保持一致，這里提供的大部分定義都來自該參考書。
比如，在參考書[Leffingwell, 1999]中，我們會發現需求管理是這樣定義的：
獲取、組織和記錄系統需求的系統化方法，在客戶與項目團隊之間建立并維護對系統需求變更的一致意見的過程。
還是讓我們繼續尋找并定義用于描述待建系統所需的其他更多的需求管理術語吧。
解決方案域中的常見需求術語
產品或系統的特性
當我們開始考慮已識別問題的解決方案時，很自然會匆匆記下系統的特性。特性在系統的開發中占有很有趣的地位。它們看上去介于用戶真正需要的表達與系統實現這些需要的詳細方式描述之間。這樣，它們就為按照抽象的方式描述系統提供了一種方便的構造，或者如果您愿意的話，提供一種"速記方法"。由于需要解決的問題存在很多可能的解決方案，所以在某種意義上特性提供了特定系統解決方案的最初范圍；它們描述了系統打算做什么以及不打算做什么。
我們將特性定義為
系統為實現一個或多個涉眾需要而提供的服務。
我們可以很容易地使用用戶熟悉的術語用自然語言來表示特性。例如：
- 系統使用的是標準的北美電源。
- 樹瀏覽器提供了組織缺陷信息的一種手段。
- 家用照明控制系統具有與標準家用自動化系統的接口。
由于特性是從涉眾需求派生而來的，所以我們將它們安排在金字塔的下一層，即需要的下面。與此同時，我們還從問題域（需要）轉移到了解決方案域的第一層（特性）。
有一點很重要，需要注意，那就是特性不僅僅是涉眾需求的精化（增加了細節）。相反，它們是用戶提供的對問題的直接響應，并且它們為我們提供了問題的頂級解決方案。
通常，我們應該能夠通過定義 25 到 50 種刻畫系統行為的特性來描述系統。如果您發現手頭有超過 50 種的特性，那么可能是因為您沒能抽象出系統的真正特性或者是系統過于龐大而難于理解，您需要考慮將其分為更小的部分。
特性是用自然語言描述的，所以讀到該清單的任何涉眾都能立即獲得對系統行為的基本理解。特性清單會缺乏細粒度的詳細程度。這沒關系。我們只是在試著交流目的，并且由于很多涉眾都是非技術人員，所以過多的細節可能會讓他們混淆甚至干擾理解。通過例子，我們 SmartBot 自動焊接機器人的部分特性清單可能包括：
- 允許焊接工教導機器人焊接哪些路徑的"lead through path"訓練模式
- 支持重復焊接次序的"step-and-repeat"特性。
用例
當我們進一步考慮系統完成用戶任務的方法時，我們可能發現使用用例技術來進一步描述系統行為很有利益。該技術在很多書籍[Jacobson 1992]中已經得到了很好的發展，并且也是行業標準統一建模語言[Booch 1999]的一個組成技術。
從技術上說，用例：
描述了系統執行的、為用戶帶來價值的一系列動作。
換言之，用例描述了有助于用戶實現他們期望的一系列用戶和系統交互。再換一種說法，用例描述了用戶和系統如何共同合作以實現所識別的特性。
用例還引進了參與者這項構造。參與者只是當時使用系統的用戶的一個標簽。在 UML 中，用一個簡單的橢圓來表示用例，而參與者則用一個帶有名稱的線條畫表示。所以可以如下所示用一個簡單的圖來說明這兩者。
用例技術規定了參與者如何實現用例的一個簡單的逐步過程。比如，用于 Step and Repeat 的用例可能如下所示：
步驟1：焊接工按下 step and repeat 按鈕，啟動該序列。
步驟2：焊接系統為驅動電動機供給電源，以便可以人工控制機器臂移動。
步驟3：焊接工握著扳機，將機器臂移動到焊接部位，并按下"weld here"按鈕，焊接每一條需要焊接的線路。
用例技術提供了很多其他有用的構造，比如預描述和后描述（pre and post description）、可選流（alternate flow）等。我們將在后面詳細討論用例時再討論它們。但是現在，我們只需要知道用例提供了一個優秀的方法用來描述如何實現系統特性。
出于計劃的目的，可能需要除用例之外的一些方法來描述如何實現特定的特性。對于每個特性可能只需要幾個用例即可（也許 3 到 10 個）。在描述用例過程中，我們詳細闡述了系統的行為。隨著其他特征的獲得，用例也變得更加詳細。
遠景文檔
在很多開發嘗試中，問題的聲明、關鍵涉眾、用戶需求、系統特性清單，也許還有示例用例都可以在一個被稱為遠景文檔的文檔中找到。它還有其他很多名稱，比如項目章程（Project Charter）、產品需求文檔（Product Requirements Document）、市場需求文檔（Marketing Requirements Document）等。不管名稱如何，遠景文檔強調了正在構建系統的總體意圖和目的，因此，是那些被標明日期的特性和說明性用例的自然容器。換言之，遠景文檔捕獲了系統的完全形態，并使用涉眾需求、特性和用例來交流意圖。
然而，我們不能簡單地把這些特性和初始用例轉交到開發團隊手中，并期望他們很快開發出真正滿足涉眾需要的系統。我們可能需要在系統功能方面更加明確，并且可能涉及了各種新的涉眾，包括開發人員、測試人員等。這是系統定義的下一層（軟件需求）要解決的需要。
軟件需求
軟件需求在軟件定義過程中提供了下一層特異性。在這一層上，我們必須指定足夠的需求和用例，以便開發人員可以編寫代碼，并且測試人員可以測試這些代碼是否滿足需求。從圖形上說，軟件需求提供了我們金字塔的塔基。
什么是軟件需求？盡管在過去的多年中已經有過很多種定義，但是我們發現需求工程創始人 Dorfman 和 Thayer[Dorfmann 1990]提供的定義最合適：
- 用戶解決將實現一個目標的問題所需的軟件功能，或者
- 必須被一個系統或者系統組件滿足或擁有，以滿足合同、標準、規范或其他正式發布文檔的軟件功能。
應用該定義，開發團隊能夠開發出更具體的需求集，以完善或精化前面討論過的特性清單。每個需求都是某種特性，反之亦然。注意這種方法的簡單性。我們有一個特性清單，然后通過編寫一個為這些特性服務的需求集來精化它們。我們不編寫任何其他需求。這避免了只是坐在椅子上、瞪著天花板，并"為該系統捏造一些需求"的誘惑。
該過程簡單明了，但是并不容易。每個特性都需要檢查，然后編寫需求以支持該特性。不可避免地，為某項特性編寫需求會引發您為已經檢查過的特性添加新的需求，或者對其進行修訂。
當然，您知道編寫需求并不容易，并且可能需要指定大量需求。我們發現考慮三種類型或者種類的軟件需求（功能性需求、非功能性需求和設計約束）很有幫助。
我們發現這三種需求在我們考慮需求的方式以及我們期望需求實現的任務方面很有幫助。讓我們看一下這些不同類型的需求，以及您可以如何使用它們來定義期望系統的各個方面。
功能性需求
功能需求表達了系統行為。更具體地說，功能需求描述了輸入和輸出分別是什么、以及特定輸入如何在不同時刻被轉化成特定的輸出。能有效工作的大部分軟件應用程序都具有豐富的功能性需求。在指定這些需求時，要權衡模糊性（"當您按下 On 鈕之后，系統就會打開"）與具體性這二者的關系，這一點很重要。給予設計人員和實現人員以盡可能多的設計和實現選擇也很重要。如果我們過于具體，那么就可能過于限制開發團隊，如果過于寬松，則開發團隊就不知道系統應該實現哪些功能。
指定需求的正確方法不只一種。其中一種技術只簡單采用了聲明性的方法，并寫下系統需要做的每一件詳細的事件。
比如：在"weld here"輸入被激活時，系統通過每 100 毫秒讀取一次光編碼器來數字化電極端的位置。
細化用例
在很多系統中，通過精化以前定義的用例并開發其他用例，則易于組織規范活動來全面細化系統。利用這項技術，您可以將用例步驟精化成更詳細的系統交互。您還需要定義前置條件和后置條件（在用例之前和之后陳述系統假設），以及由于異常條件而需要的備用動作等。
由于用例在語義上是良好結構的，因此它們提供了一種組織和捕獲系統行為的結構。下面是 Smartbot 的代表性用例。
非功能性需求
除了像輸入轉換為輸出這樣的功能性需求，大多數系統還需要定義一組著重指定其他系統"屬性"的非功能性需求，比如性能需求、吞吐量、可用性、可靠性和可支持性。這些需求和面向輸入輸出的功能需求同樣重要。通常，非功能性需求的表達方式是聲明性的，如： "系統的平均故障間隔時間應該為 2000 小時"，"系統的平均修復時間應為 0.5 小時"，以及"Smartbot 最多應該能夠存儲和檢索 100 條焊接路徑"。
設計約束
與定義系統行為不同，第三類需求通常對系統設計或者我們用來構建系統的過程施加了限制。我們將設計約束定義為：
系統設計上的限制，或者系統開發步驟上的限制，它不影響系統的外部行為，但是必須被實現，以滿足技術、業務或合同要求。
典型的設計約束可能是這樣表達的："用 Java 為焊接工控制單元編程"。一般來說，我們將合理的設計約束看作其他需求，盡管符合這些限制的測試可能需要不同的技術。正如功能性和非功能性需求一樣，這些約束在系統的設計和測試中扮演了不可或缺的角色。
分層結構需求
很多項目通過利用分層或父子結構表達這些需求而受益。父子結構需求是利用父需求表達的特異性的一種擴大。父子需求為您提供了一種增強和擴大規范的靈活的方法，同時還可以組織提供的詳細程度。只看父需求，很容易按照易被用戶理解的方法提供頂級規范。同時，實施人員可以快速檢查詳盡的"子需求"規范，以保證他們能夠理解所有的實施細節。
注意，分層結構需求由三種標準類型的需求組成--功能性、非功能性和設計約束。這里只定義了這些需求間的細化關系。
可跟蹤性
除了為描述我們用來說明系統需求的事物而定義的術語之外，我們現在將注意力轉移到關鍵關系，即可跟蹤性，也就是在這些事項之間可能存在的關系。
開發出高質量軟件的一個重要因素就是在規范、構架、設計、實現和測試階段理解或跟蹤需求的能力。歷史數據表明變更的影響通常被遺漏，系統的小小變更可能帶來顯著的可靠性問題。因此，跟蹤關系并在發生變更時關聯這些關系的能力，形成了很多現代軟件質量保證過程的關鍵線程，尤其是在任務關鍵活動比如安全關鍵系統（醫療和運輸產品），和故障的經濟成本很高的系統（在線交易）中，形成了一個關鍵線程。
下面看一下我們如何定義需求可跟蹤性：
可跟蹤性關系是一種依賴關系，其中實體（故障、用例和需求）"traced to"在某種程度上依賴于它"traced from"的實體。
比如，我們已經描述了如何創建一個或更多軟件需求，以支持遠景文檔中給定的特性或用例。因此，我們可以說這些軟件需求與一個或更多特性具有可跟蹤性關系。
影響分析和懷疑
另外，可跟蹤性關系超出了簡單依賴關系的范圍，因為它提供了利用我們稱之為"懷疑"的概念進行影響分析的能力。當變更出現在"traced from"（獨立）需求中時，可跟蹤性關系就開始"懷疑"，因此必須對"traced to "（依賴需求）進行檢查，以保證它與源需求保持一致。
比如，如果我們使用可跟蹤性將需求與特定測試關聯，并且如果諸如"Smartbot 應該能夠存儲和檢索最多 100 條焊接路徑"這樣的需求變為"Smartbot 應該能夠存儲和檢索最多 200 條焊接路徑"，那么從該需求跟蹤而來的測試就值得懷疑，因為為測試第一個需求而設計的測試不太可能適合測試第二個需求。
變更請求和變更管理系統
最后，變更是不可避免的。對于有希望成功的項目，管理變更的過程是必不可少的。不管它們的來源是什么以及來源如何眾多，所有變更包括影響特性和需求的請求需要有序地被引進和管理。任何變更管理系統的關鍵元素都是變更請求本身。
我們將變更請求定義為：
對系統的特性和/或需求作出修訂或添加的正式請求。變更請求需要作為提議變更的結構化和形式化的陳述，以及圍繞該變更的任何細節進入系統。為了管理這些變更，每個變更都要在系統中有自己的身份，這很重要。變更請求的簡化形式可能為：
在大部分項目中，您會發現不缺少變更！實際上，您的問題是按照有序的方式管理、集成和（根據需要）拒絕不必要的變更。換言之，您需要一個管理變更過程。您的變更管理系統應該用于捕獲所有輸入，并將它們提交給變更控制委員會（CCB）來解決。CCB 由不超過 3 到 5 個代表項目關鍵涉眾（客戶、市場和項目管理）的人員組成，它管理和控制系統變更，因而在幫助項目成功方面扮演了關鍵角色。
結束語
剛一開始，我們就指出本文的目的在于幫助該領域的從業者提高他們回答下列基本問題的能力：
"系統究竟應該實施哪些行為？"
作為實現這一目標的第一步，我們定義和描述了分析人員以及負責描述問題域中問題的其他人員所使用的，用于表達將施加在預期解決方案上的需求的一些常見術語（比如涉眾需要、特性、用例、軟件需求等）。在這個過程中，我們還闡述了有效需求管理的一些關鍵概念。通過使用本文提供的術語和方法，您能夠更有效地理解用戶需要，并與開發人員、測試人員以及負責構建滿足客戶和用戶需要的系統的其他技術團隊成員交流提議解決方案的需求。
進一步定義和交流軟件解決方案的其他更多關鍵方面的一項重要技術就是標準建模語言。統一建模語言（UML）是一種用于可視化、指定和文檔化軟件密集系統的工件的語言，并且提供了按照語義上更精確的方式表達這些技術構造的手段。本文的姊妹篇，Modeling the Requirements Artifacts with UML（利用 UML 建模需求工件），建立了更有效執行需求管理任務所必需的 UML 構造和擴展。
建議讀物
[Leffingwell 1999] Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Unified Approach. Reading, MA: Addison Wesley Longman, 1999.
[Weigers 1999] Weigers, Karl. Software Requirements, Redmond Washington: Microsoft Press, 1999.
參考資料
- [Booch 1994] Booch, Grady. Object-Oriented Analysis and Design with Applications, 2nd ed. Redwood City, CA. Benjamin Cummings, 1994.
- [Booch 1999] Booch, Grady, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide. Reading, MA: Addison Wesley Longman,1999.
- [Dorfmann 1990] Dorfmann, Merlin, and Richard H. Thayer. Standards, Guidelines, and Examples of System and Software Requirements Engineering. Los Alamitos, CA: IEEE Computer Society Press, 1990.
- [Jacobson 1992] Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar ?vergaard. Object-Oriented Software Engineering: A Use Case Driven Approach. Harlow, Essex, England: Addison Wesley Longman, 1992.
- [Rumbaugh 1999] Rumbaugh, James, Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Reading, MA: Addison Wesley Longman, 1999.
- 請參加Rational 中國論壇關于本文的討論。
關于作者
在 Rational 軟件公司里，我很榮幸能夠與一些業內資深方法學家（Grady Booch、Ivar Jacobson、Jim Rumbaugh、Philippe Kruchten、Bran Selic 等人）協同工作。盡管這是我的職業生涯中有益的、令我癡迷的一部分，但這不是我可以推薦給每個人的。換言之，請不要在家嘗試這樣做。 |