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