面向對象的需求獲取概述
9.1.1 對需求獲取的總的看法
需求獲取 將注意力放在系統目標的描述上。開(kāi)發(fā)者、客戶(hù)和用戶(hù)共同標識了一個(gè)問(wèn)題域，定義了解決這一問(wèn)題域的系統。這類(lèi)定義稱(chēng)為 需求規格說(shuō)明 ，這類(lèi)定義可用于開(kāi)發(fā)者和用戶(hù)之間的溝通。
需求獲取包括如下活動(dòng)：
• 標識參與者 。開(kāi)發(fā)者需要標識出未來(lái)系統將支持的不同用戶(hù)類(lèi)型。
• 標識場(chǎng)景 。為了獲得未來(lái)系統將提供的典型功能，開(kāi)發(fā)者對用戶(hù)活動(dòng)進(jìn)行觀(guān)察并開(kāi)發(fā)出一組帶有細節的場(chǎng)景。開(kāi)發(fā)者使用這些場(chǎng)景與用戶(hù)進(jìn)行溝通并加深開(kāi)發(fā)者對應用域的理解。
• 標識用例 。一旦用戶(hù)和開(kāi)發(fā)者確認了一組場(chǎng)景，開(kāi)發(fā)者將從場(chǎng)景中導出一組能夠完全表示未來(lái)系統的用例。當場(chǎng)景所表示的是一種具體實(shí)例時(shí)，將從中抽象出用例，以描述所有可能情況。在描述用例時(shí)，開(kāi)發(fā)者即決定了系統的范圍。
• 求精用例 。通過(guò)細化每一個(gè)用例，以及使用帶有錯誤處理的用例和使用異常條件處理的用例，描述系統的行為。開(kāi)發(fā)者應確保需求規格說(shuō)明是完全的。
• 標識用例之間的關(guān)系 。開(kāi)發(fā)者標識出用例之間的依賴(lài)關(guān)系。通過(guò)提取相同功能，開(kāi)發(fā)者可以鞏固用例模型。這一做法保證了需求規格說(shuō)明是一致性的。
• 標識非功能需求 。開(kāi)發(fā)者、用戶(hù)和客戶(hù)需要對用戶(hù)可見(jiàn)的非功能需求的方方面面進(jìn)行標識。這些內容包括系統性能上的約束、文檔、將要消耗的資源、其安全性和其質(zhì)量等。 在需求獲取期間，開(kāi)發(fā)者將訪(fǎng)問(wèn)不同的信息資源，包括：
• 客戶(hù)所提供的、與應用域相關(guān)的文檔和手冊；
• 將被未來(lái)系統替換的遺留系統的技術(shù)文檔；
• 用戶(hù)和客戶(hù)本人。第三個(gè)方面是最重要的信息資源，因為開(kāi)發(fā)者在需求獲取活動(dòng)期間的最多活動(dòng)是與用戶(hù)和客戶(hù)之間的交流。
在需求工程期間，常常使用一種稱(chēng)為 聯(lián)合應用設計（ Joint Application Design ， JAD ） 的溝通技術(shù)，即用戶(hù)和開(kāi)發(fā)者聯(lián)合開(kāi)發(fā)需求規格說(shuō)明，將注意點(diǎn)放在營(yíng)造開(kāi)發(fā)者、用戶(hù)和客戶(hù)之間容易進(jìn)行溝通的氣氛上。需求工程中的 跟蹤性 將注意點(diǎn)放在記錄、形式化、聯(lián)結、分組和操作需求之間的依賴(lài)關(guān)系，以及需求和其它工作產(chǎn)品之間的依賴(lài)關(guān)系上。
9.1.2 需求獲取概念
在本節中，我們主要描述需求獲取概念，特別描述如下內容：功能需求；非功能需求；需求規格說(shuō)明的確認；需求規格說(shuō)明的屬性；需求規格說(shuō)明的類(lèi)型和描述需求獲取活動(dòng)。
1. 功能需求
功能需求 描述了系統與其獨立于系統實(shí)現的環(huán)境之間的交互。環(huán)境包括用戶(hù)和任何其它與該系統進(jìn)行交互的外部系統。
2. 非功能需求
非功能需求 描述了不直接關(guān)聯(lián)到系統功能行為方面。
可用性 包括用戶(hù)可學(xué)會(huì )的操作、對輸入需要進(jìn)行的準備、對一個(gè)系統可進(jìn)行的解釋以及對輸出狀況的分析等。
可靠性 使得我們對系統提交的服務(wù)具有足夠的信心，它 包括 可靠性 、 健壯性 等。
性能 需求是系統要考慮的定量屬性，例如 響應時(shí)間 、 吞吐量 、 有效性 。
可維護性 需求關(guān)注的是在部署改變后系統所處的狀況，包括 可適配性 、 可維護性 、 國際化 。
3. 需求規格說(shuō)明的確認
確認需求規格說(shuō)明 包括檢查需求規格說(shuō)明是否是完全、一致、無(wú)二義性和正確的。
4. 需求規格說(shuō)明的屬性
需求規格說(shuō)明中最重要的屬性是可現實(shí)性、確認性和可追蹤性。需求規格說(shuō)明是 可 現實(shí)性 的，如果系統在約束下是可實(shí)現的話(huà)。需求規格說(shuō)明是 可 確認 的，如果系統一旦構建起來(lái)后，就能夠使得設計結論能進(jìn)行測試，以說(shuō)明系統實(shí)現了該需求規格說(shuō)明。
如果針對每一個(gè)需求規格說(shuō)明，均可通過(guò)軟件開(kāi)發(fā)過(guò)程，實(shí)現其對應的系統功能，且如果每一個(gè)系統功能可逆向追蹤到其對應的需求規格說(shuō)明集合上的話(huà) , 則我們說(shuō)需求規格說(shuō)明是 可追蹤 的。
5. 需求獲取的類(lèi)型
依據需求的來(lái)源，需求獲取活動(dòng)可分為三類(lèi)：首次工程、再工程和界面工程。
首次工程 是因為沒(méi)有現成系統存在，開(kāi)發(fā)過(guò)程將從打草稿開(kāi)始，因此需要從用戶(hù)和客戶(hù)處獲取需求。首次工程項目由用戶(hù)需求或新的市場(chǎng)需求啟動(dòng)。例如，衛星表可看成是一個(gè)首次工程項目。
再工程 項目是針對一個(gè)現存系統或遺留系統進(jìn)行的再設計和再實(shí)現，其啟動(dòng)原因是可行的技術(shù)或商業(yè)需求。有時(shí)再工程是因為在二次開(kāi)發(fā)活動(dòng)中系統擴展了新功能，而基本系統的目標保持不變。新系統的需求從現存系統或遺留系統中獲取。
界面工程 項目是對一個(gè)現存系統用戶(hù)界面的再設計。除了界面外，現存系統或遺留系統中的功能，將毫無(wú)懸念地被保留下來(lái)，只需對其界面進(jìn)行再設計和再實(shí)現。這類(lèi)項目是再工程項目，在此項目中，如果開(kāi)銷(xiāo)代價(jià)不高的話(huà)，現存系統或遺留系統是不可能丟棄的。
需求獲取活動(dòng)
9.2.1 標識參與者
圖 9.4 衛星表系統中的參與者
需求獲取的第一步是標識參與者。這一步驟定義了系統邊界，并從開(kāi)發(fā)者角度描述了系統中的所有觀(guān)察點(diǎn)。
9.2.2 標識場(chǎng)景
場(chǎng)景中的主要類(lèi)型包括： 當前場(chǎng)景 ； 原型場(chǎng)景 、 評價(jià)場(chǎng)景 和 培訓場(chǎng)景 。
在標識場(chǎng)景的過(guò)程中，開(kāi)發(fā)者可通過(guò)如下問(wèn)題的提出，來(lái)獲取和確認場(chǎng)景：
• 參與者希望系統完成的任務(wù)是什么？
• 參與者要訪(fǎng)問(wèn)的信息是什么？誰(shuí)創(chuàng )建了這些數據？這些數據可以做修改或刪除嗎？由誰(shuí)完成這些工作？
• 參與者需要告知系統，相關(guān)外部交換是什么？怎樣交換？何時(shí)交換？
• 系統需要向參與者詢(xún)問(wèn)的事件是什么？最遲時(shí)期多長(cháng)？
結合火災報警與調度系統實(shí)例，我們可標識出四個(gè)任務(wù)場(chǎng)景： 1 ） 倉庫火災場(chǎng)景； 2 ） 擋泥板被撞場(chǎng)景； 3 ）轎車(chē)撞樹(shù)場(chǎng)景； 4 ）地震場(chǎng)景。
9.2.3 標識用例
場(chǎng)景 是 用例 的實(shí)例，即對一個(gè)給定功能而言，一個(gè)用例可以說(shuō)明所有可能場(chǎng)景，參與者可啟動(dòng)用例。在用例被啟動(dòng)后，該用例也可以與其它參與者進(jìn)行交互。一個(gè)用例標識了貫穿相關(guān)系統事件的全部流程，在這種情況下，用例描述了一系列從初始情況出發(fā)的相關(guān)交互。通過(guò)用例可以定義開(kāi)發(fā)范圍，即通過(guò)泛化場(chǎng)景和標識系統，使得開(kāi)發(fā)者能夠在高層用例層定義系統的開(kāi)發(fā)范圍。具體做法是，在初始時(shí)，開(kāi)發(fā)者對用例進(jìn)行命名，將這些用例與初始參與者關(guān)聯(lián)起來(lái)。用例的名字應該是一個(gè)動(dòng)詞短語(yǔ)，以說(shuō)明參與者將完成什么功能。
9.2.4 求精用例
通過(guò)求精用例，將會(huì )產(chǎn)生大量細節，這些細節涉及未來(lái)系統應提供的特征和與系統相關(guān)聯(lián)的約束。特別要注意在初始時(shí)那些有意或無(wú)意忽略用例的相關(guān)情況，這些內容在用例求精過(guò)程中被細化：
• 細化系統操縱的元素；
• 說(shuō)明參與者和系統之間的低層交互序列；
• 說(shuō)明訪(fǎng)問(wèn)權限（這些權限約束了參與者可引用的那些用例）；
• 標識出遺失的異常情況，說(shuō)明對這些異常情況的處理；
• 分離出用例之間的公共功能。
9.2.5 標識初始的分析對象
為了標識出對象，在此給出其中的一些準則：
• 對于理解用例而言，開(kāi)發(fā)者和用戶(hù)所使用的術(shù)語(yǔ)，其含義必須是清楚的；
• 在用例中出現可重復的名詞（例如，事件）應該引起注意；
• 如果是系統必須跟蹤的現實(shí)世界中的實(shí)體（例如，現場(chǎng)工作人員，資源），則要引起注意；
• 如果是系統必須跟蹤的現實(shí)世界中的處理（例如，危機處理計劃），則要引起注意；
• 如果是用例（例如，報告緊急情況），則應產(chǎn)生一個(gè)對應的對象；
• 如果是數據源和數據匯（例如，打印機），則應認真分析；
• 與用戶(hù)進(jìn)行交互的人工制品（例如，工作站）應引起注意；
• 總是 出現在應用域中的術(shù)語(yǔ)要特別引起注意。
需求獲取管理
9.3.1 客戶(hù)談判規格說(shuō)明：聯(lián)合應用設計
聯(lián)合應用設計 （ JAD ）是由 IBM 公司在 70 年代末提出的一種需求開(kāi)發(fā)方法。
JAD 由五個(gè)活動(dòng)組成（參見(jiàn)圖 9.13 ）。
1. 項目定義
2. 調研
3. 準備
4. 會(huì )議
5. 最終文檔
圖 9.13 JAD 的活動(dòng)
9.3.2 追蹤性維護
追蹤性是對需求進(jìn)行跟蹤的能力。這一能力包括跟蹤需求從哪里來(lái)（例如，誰(shuí)組織需求？該需求要解決哪一個(gè)客戶(hù)的需要？），到系統的哪一部分去，以及對項目的影響（例如，哪一個(gè)構件實(shí)現了該需求，哪一個(gè)測試檢查了其實(shí)現）。追蹤性使得開(kāi)發(fā)者看到的系統是完全的，測試者看到的系統是否與其需求相符合，設計者記錄系統內部的機理，以及維護者評價(jià)變化帶來(lái)的影響。
維持 追蹤性的最簡(jiǎn)單方法是在文檔、模型和代碼制品之間進(jìn)行交叉參考。
面向對象分析
9.4.1 分析的概述
分析 將關(guān)注點(diǎn)放在系統模型的產(chǎn)生上，這一模型稱(chēng)為分析模型，該模型應該是正確的、完全的、一致性的和可確認的。
9.4.2 分析的概念
1. 對象模型和動(dòng)態(tài)模型分析
分析模型表示從用戶(hù)視點(diǎn)出發(fā)，分析將開(kāi)發(fā)的系統。 分析對象模型 是分析模型的一部分，該模型將注意點(diǎn)放在由系統、系統特征和系統關(guān)系操縱的單一概念上。用 UML 類(lèi)圖描述的分析對象模型，包括類(lèi)、屬性和操作。分析對象模型是對用戶(hù)是可見(jiàn)的。
動(dòng)態(tài)模型 將注意點(diǎn)放在系統的行為上。動(dòng)態(tài)模型用順序圖或者用狀態(tài)圖描述。順序圖表示在單一用例期間，一組對象之間的交互。狀態(tài)圖表示了單一對象（或者一組關(guān)聯(lián)緊密的處理對象）的行為。狀態(tài)圖將責任分配給某一類(lèi)，并且在這一過(guò)程中標識出新類(lèi)、關(guān)聯(lián)和屬性，并將之加入分析對象模型中。
2. 實(shí)體、邊界和控制對象
在分析對象模型中，包括了實(shí)體對象、邊界對象和控制對象三種類(lèi)型。 實(shí)體對象 表示系統將跟蹤的持久信息。 邊界對象 表示參與者與系統之間的接口和交互。 控制對象 負責用例實(shí)現。例如，在具有兩個(gè)按鈕的衛星表實(shí)例中，年、月和日是實(shí)體對象；按鈕和液晶顯示器是邊界對象；改變數據控制是控制對象，以表示通過(guò)按下組合按鈕改變日期的活動(dòng)。我們將實(shí)體對象、邊界對象和控制對象所構成的分析對象模型稱(chēng)為 三對象模型 。
3. 泛化和特化
繼承 使得我們能夠將概念組織成層次結構。
泛化 是建模中的活動(dòng)，該活動(dòng)標明了從多個(gè)底層概念中得到的抽象概念。例如，我們可以將交通事故和火災抽象為緊急情況，以描述交通事件和火災的共同（或泛化）特征。 特化 是建模中的活動(dòng)，該活動(dòng)將一個(gè)源于高層的概念特化為多個(gè)實(shí)例。
.5 小結
需求獲取活動(dòng)是高度迭代和增量化的開(kāi)發(fā)活動(dòng)。對用戶(hù)和客戶(hù)而言，大粒度功能被表示成框架和建議的結構?？蛻?hù)增加需求，評價(jià)現存的功能，修改現存的需求。通過(guò)原型法，開(kāi)發(fā)者對非功能需求進(jìn)行調研，并挑戰每一個(gè)需求。在初始的時(shí)候，需求獲取是一次集思廣益的活動(dòng)。隨著(zhù)系統需求的擴大，以及需求變得越來(lái)越具體后，開(kāi)發(fā)者需要用更有序的方式擴展和修改需求分析模型，以管理信息的復雜性。
典型的分析活動(dòng)序列是，在開(kāi)發(fā)初始用例模型時(shí)，用戶(hù)、開(kāi)發(fā)者和客戶(hù)將參與進(jìn)來(lái)，他們一起標識各個(gè)概念，并建立起參與對象的術(shù)語(yǔ)表，定義用例和定義參與對象的活動(dòng)。開(kāi)發(fā)者將參與對象分類(lèi)成實(shí)體對象、邊界對象和控制對象。這些活動(dòng)持續循環(huán)進(jìn)行，直到系統的絕大多數功能均標識成用例為止。隨后開(kāi)發(fā)者構造順序圖，以找出任何未標識的對象。當所有的實(shí)體對象均已命名并進(jìn)行了主要描述后，分析模型在其求精之前進(jìn)入了相對穩定的狀態(tài)。
9-1. 考慮一下帶有圖形用戶(hù)界面的文件系統，如 Macintosh 的 Finder 、 Microsoft 的 Windows Explorer 和 Linux 的 KDE 。從描述怎樣從一個(gè)軟盤(pán)拷貝一個(gè)文件到硬盤(pán)的用例中標識出了如下對象： File 、 Icon 、 TrashCan 、 Folder 、 Disk 和 Pointer 。說(shuō)明哪些對象是實(shí)體對象，哪些對象是邊界對象，哪些對象是控制對象。
9-2. 假設如前所述的同一文件系統，考慮一個(gè)包含了從軟盤(pán)上選擇文件并拖動(dòng)該文件到 Folder 再釋放鼠標的場(chǎng)景。標識和定義至少一個(gè)關(guān)聯(lián)到此場(chǎng)景的控制對象。
9-3. 在順序圖中水平地排列習題 9-1 和習題 9-2 中列出的對象，將邊界對象放在左邊，將你要標識的控制對象放在中間，將實(shí)體對象放在右邊。畫(huà)出將文件拖入文件夾的交互順序。在本題中，忽略異常情況。
9-4. 檢查你在練習 9-3 中畫(huà)出的順序圖，標識出這些對象之間的關(guān)聯(lián)。
9-5. 標識出與場(chǎng)景（將一個(gè)文件從一張軟盤(pán)拷貝硬盤(pán)）相關(guān)的每一個(gè)對象的屬性?？紤]如下異常情況“在該文件夾中存在同一文件名”和“磁盤(pán)中沒(méi)有足夠的空間”。
