面向?qū)ο蟮男枨螳@取

與需求分析

需求獲取是獲得系統(tǒng)必要的特征，或者獲得客戶能接受的、系統(tǒng)必須滿足的約束。需求工程的目標(biāo)是定義構(gòu)造系統(tǒng)的需求。需求工程主要包括兩個(gè)活動(dòng)：（1）需求獲取，即導(dǎo)出用戶可理解的系統(tǒng)規(guī)格說明；（2）需求分析，其結(jié)論是給開發(fā)者無二義性解釋的分析模型。在這兩個(gè)活動(dòng)中，需求獲取更具有挑戰(zhàn)性，因?yàn)樾枨螳@取需要在多個(gè)具有不同背景的參與者團(tuán)隊(duì)之間進(jìn)行協(xié)作。采用場(chǎng)景和用例的溝通技術(shù)是彌補(bǔ)上述代溝的有力工具。場(chǎng)景表達(dá)了用戶和系統(tǒng)之間的一系列交互，描述了一個(gè)系統(tǒng)實(shí)例。用例是對(duì)一類場(chǎng)景所進(jìn)行的抽象。場(chǎng)景和用例兩者均用自然語言描述，這一形式對(duì)用戶而言是易于理解的。9.1面向?qū)ο蟮男枨螳@取概述需求獲取是關(guān)于開發(fā)者、客戶和用戶之間為了定義新系統(tǒng)而進(jìn)行的溝通。在需求獲取過程中，如果無法及時(shí)發(fā)現(xiàn)所犯錯(cuò)誤，將使得整個(gè)系統(tǒng)交付延遲。這里所提到的錯(cuò)誤包括：丟失了系統(tǒng)必須支持的功能、不正確的功能描述、引起誤導(dǎo)或不可用的用戶界面，以及無用功能等。需求獲取方法的目標(biāo)，就是為了提高開發(fā)者、客戶和用戶之間的溝通。9.1.1對(duì)需求獲取的總的看法需求獲取將注意力放在系統(tǒng)目標(biāo)的描述上。開發(fā)者、客戶和用戶共同標(biāo)識(shí)了一個(gè)問題域，定義了解決這一問題域的系統(tǒng)。這類定義稱為需求規(guī)格說明，這類定義可用于開發(fā)者和用戶之間的溝通。在分析過程，形式化需求規(guī)格說明，以產(chǎn)生分析模型。需求規(guī)格說明和分析模型之間的區(qū)別，僅僅在于其所用語言和記號(hào)的不同；需求規(guī)格說明通常用自然語言來書寫，而分析模型通常用形式化或半形式化方式表示出來。需求規(guī)格說明支持客戶和用戶之間的溝通。分析模型支持開發(fā)者之間的溝通。需求獲取和分析應(yīng)該將注意點(diǎn)放在用戶對(duì)系統(tǒng)的看法上。需求獲取包括如下活動(dòng)：（1）標(biāo)識(shí)參與者。（2）標(biāo)識(shí)場(chǎng)景。（3）標(biāo)識(shí)用例。（4）求精用例。（5）標(biāo)識(shí)用例之間的關(guān)系。（6）標(biāo)識(shí)非功能需求。在需求獲取期間，開發(fā)者將訪問不同的信息資源，包括：客戶所提供的、與應(yīng)用域相關(guān)的文檔和手冊(cè)將被未來系統(tǒng)替換的遺留系統(tǒng)的技術(shù)文檔；用戶和客戶本人。第三個(gè)方面是最重要的信息資源，因?yàn)殚_發(fā)者在需求獲取活動(dòng)期間的最多活動(dòng)是與用戶和客戶之間的交流。在需求工程期間，常常使用一種稱為聯(lián)合應(yīng)用設(shè)計(jì)（JointApplicationDesign，JAD）的溝通技術(shù)，即用戶和開發(fā)者聯(lián)合開發(fā)需求規(guī)格說明，將注意點(diǎn)放在營(yíng)造開發(fā)者、用戶和客戶之間容易進(jìn)行溝通的氣氛上。需求工程中的跟蹤性將注意點(diǎn)放在記錄、形式化、聯(lián)結(jié)、分組和操作需求之間的依賴關(guān)系，以及需求和其它工作產(chǎn)品之間的依賴關(guān)系上。9.1.2需求獲取概念1.功能需求功能需求描述了系統(tǒng)與其獨(dú)立于系統(tǒng)實(shí)現(xiàn)的環(huán)境之間的交互。環(huán)境包括用戶和任何其它與該系統(tǒng)進(jìn)行交互的外部系統(tǒng)。對(duì)衛(wèi)星表的功能需求描述衛(wèi)星表是一種利用全球定位系統(tǒng)（GlobalPositioningSystem，GPS）顯示使用者所在地時(shí)間的手表，該手表具有確定位置和時(shí)區(qū)轉(zhuǎn)換功能。衛(wèi)星表通過衛(wèi)星將位置信息存儲(chǔ)到手表中，使得手表擁有者無需留心對(duì)時(shí)間的調(diào)整。當(dāng)手表擁有者跨越時(shí)區(qū)時(shí)，或跨越執(zhí)行夏令時(shí)的行政邊界時(shí)，衛(wèi)星表會(huì)自動(dòng)調(diào)整時(shí)間和日期。衛(wèi)星表的顯示面板有兩行，上面一行顯示時(shí)間（時(shí)、分、秒、時(shí)區(qū)），下面一行顯示日期（星期、日、月、年）。衛(wèi)星表通過購(gòu)買手表時(shí)配送的串行設(shè)備進(jìn)行升級(jí)。2.非功能需求非功能需求描述了不直接關(guān)聯(lián)到系統(tǒng)功能行為方面。根據(jù)Jacobson等人提出的FURPS+模型，我們將非功能需求分4類，即可用性、依賴性、性能和可維護(hù)性。FURPS為如下英文單詞首字母的縮寫：Functional，Usability，Reliability，Performance和Supportability，即功能、可用性、可靠性、性能和可維護(hù)性的縮寫?？捎眯园ㄓ脩艨蓪W(xué)會(huì)的操作、對(duì)輸入需要進(jìn)行的準(zhǔn)備、對(duì)一個(gè)系統(tǒng)可進(jìn)行的解釋以及對(duì)輸出狀況的分析等。可靠性使得我們對(duì)系統(tǒng)提交的服務(wù)具有足夠的信心。它包括可靠性，即系統(tǒng)或構(gòu)件在指定條件下和給定時(shí)間內(nèi)完成其所要求功能的能力；健壯性，即在不正確輸入或者壓力環(huán)境下，系統(tǒng)或構(gòu)件能正確完成功能的程度；安全性，即當(dāng)缺乏對(duì)災(zāi)難后果的考慮時(shí)，系統(tǒng)所能夠承受的打擊能力的程度等。性能需求是系統(tǒng)要考慮的定量屬性。響應(yīng)時(shí)間，即對(duì)用戶輸入而言，系統(tǒng)響應(yīng)的快慢程度；吞吐量，即在一個(gè)指定的時(shí)間量?jī)?nèi)，系統(tǒng)能完成的工作量；有效性，即當(dāng)提出使用要求時(shí)，系統(tǒng)或構(gòu)件的可操作性和可訪問性程度和準(zhǔn)確性?？删S護(hù)性需求關(guān)注的是在部署改變后系統(tǒng)所處的狀況，包括可適配性，即改變系統(tǒng)以適應(yīng)外部應(yīng)用域的能力；可維護(hù)性，即改變系統(tǒng)以適應(yīng)新技術(shù)或找出錯(cuò)誤的能力；國(guó)際化，即改變系統(tǒng)以適應(yīng)國(guó)際習(xí)慣的能力。依據(jù)FURPS＋模型所得到的非功能需求，還有其它分類：實(shí)現(xiàn)需求是對(duì)系統(tǒng)實(shí)現(xiàn)進(jìn)行的約束，包括使用特定工具、程序設(shè)計(jì)語言和硬件平臺(tái)；界面需求是外部系統(tǒng)強(qiáng)制性的約束，如交互格式等；操作需求是管理員和系統(tǒng)設(shè)定的操作方面的約束；提交需求是實(shí)際系統(tǒng)提交方面的約束；合法需求涉及使用許可證、規(guī)則和認(rèn)證等方面的問題。非功能需求也稱為系統(tǒng)的質(zhì)量需求。非功能需求被分為實(shí)現(xiàn)、界面、操作和提交。上例中的衛(wèi)星表非功能需求描述如下。衛(wèi)星表的非功能需求

衛(wèi)星表的質(zhì)量需求

[可用性需求]要求任何用戶，在無用戶手冊(cè)時(shí)，也能夠使用衛(wèi)星表。

[可靠性需求]如果衛(wèi)星表不設(shè)置按鈕，則不應(yīng)該有請(qǐng)求手表復(fù)位的軟件故障發(fā)生。

[性能需求]衛(wèi)星表能夠在全球定位系統(tǒng)向手表發(fā)送信息中斷結(jié)束后的5分鐘之內(nèi)顯示出正確的時(shí)間區(qū)域。

[性能需求]衛(wèi)星表在5年之內(nèi)的時(shí)間誤差應(yīng)控制在1/100秒的范圍內(nèi)。

[性能需求]衛(wèi)星表在所有的24個(gè)時(shí)域內(nèi)均應(yīng)該能夠正確顯示時(shí)間。

[支撐性需求]衛(wèi)星表可以通過隨車攜帶的串行接口升級(jí)。衛(wèi)星表的約束

[實(shí)現(xiàn)需求]與衛(wèi)星表關(guān)聯(lián)的所有相關(guān)軟件，包括車載軟件，將使用Java編寫出來。

[接口需求]衛(wèi)星表遵守由物理的、電氣標(biāo)準(zhǔn)的串行設(shè)備接口。3.需求規(guī)格說明的確認(rèn)確認(rèn)需求規(guī)格說明包括檢查需求規(guī)格說明是否是完全、一致、無二義性和正確的。如果該需求規(guī)格說明涉及系統(tǒng)的所有可能場(chǎng)景均已描述的話，則該需求規(guī)格說明是完全的。如果需求規(guī)格說明與其本身無矛盾的話，則該需求規(guī)格說明是一致性的。如果根據(jù)需求規(guī)格說明恰好能夠定義出一個(gè)系統(tǒng)來，而不存在有兩種或多種解釋的話，則該需求規(guī)格說明是無二義性的。如果該需求規(guī)格說明精確地表示了客戶需要的系統(tǒng)以及開發(fā)者傾向構(gòu)建的系統(tǒng)的話，則該需求規(guī)格說明是正確的。具有高風(fēng)險(xiǎn)的系統(tǒng)各個(gè)部分必要時(shí)可通過原型化進(jìn)行模擬，以說明該部分的可行性。建立原型的目的就是從用戶處獲取反饋意見。4.需求規(guī)格說明的屬性需求規(guī)格說明中最重要的屬性是可現(xiàn)實(shí)性、確認(rèn)性和可追蹤性。如果系統(tǒng)在約束下是可實(shí)現(xiàn)的，則需求規(guī)格說明是可現(xiàn)實(shí)性的。需求規(guī)格說明是可確認(rèn)的，如果系統(tǒng)一旦構(gòu)建起來后，就能夠使得設(shè)計(jì)結(jié)論能進(jìn)行測(cè)試，以說明系統(tǒng)實(shí)現(xiàn)了該需求規(guī)格說明。如果針對(duì)每一個(gè)需求規(guī)格說明，均可通過軟件開發(fā)過程，實(shí)現(xiàn)其對(duì)應(yīng)的系統(tǒng)功能，且如果每一個(gè)系統(tǒng)功能可逆向追蹤到其對(duì)應(yīng)的需求規(guī)格說明集合上的話,則我們說需求規(guī)格說明是可追蹤的。可追蹤性也包括追蹤需求、設(shè)計(jì)系統(tǒng)和設(shè)計(jì)中間產(chǎn)品的能力，在此中間產(chǎn)品包括系統(tǒng)構(gòu)件、類、方法和對(duì)象屬性。5.需求獲取的類型依據(jù)需求的來源，需求獲取活動(dòng)可分為三類：首次工程、再工程和界面工程。首次工程是因?yàn)闆]有現(xiàn)成系統(tǒng)存在，開發(fā)過程將從打草稿開始，因此需要從用戶和客戶處獲取需求。首次工程項(xiàng)目由用戶需求或新的市場(chǎng)需求啟動(dòng)。再工程項(xiàng)目是針對(duì)一個(gè)現(xiàn)存系統(tǒng)或遺留系統(tǒng)進(jìn)行的再設(shè)計(jì)和再實(shí)現(xiàn)，其啟動(dòng)原因是可行的技術(shù)或商業(yè)需求。界面工程項(xiàng)目是對(duì)一個(gè)現(xiàn)存系統(tǒng)用戶界面的再設(shè)計(jì)。在首次工程和再工程過程中，開發(fā)者需要采集盡可能多的應(yīng)用域信息。這類信息通常在過程手冊(cè)、新職員的文件、系統(tǒng)的手冊(cè)、術(shù)語表、由用戶開發(fā)的日志以及與客戶和用戶會(huì)面的過程記錄中是找不到的。9.2需求獲取活動(dòng)描述需求獲取活動(dòng)，可將一個(gè)問題陳述語句映射成一條需求規(guī)格說明。在使用UML為建模工具的前提下，這一需求規(guī)格說明可用一組參與者、場(chǎng)景和用例等記號(hào)來表示。需求獲取的主要步驟應(yīng)該包括：標(biāo)識(shí)參與者；標(biāo)識(shí)場(chǎng)景；標(biāo)識(shí)用例；求精用例；標(biāo)識(shí)參與者和用例之間的關(guān)系；標(biāo)識(shí)初始的分析對(duì)象和標(biāo)識(shí)非功能需求。例：火災(zāi)報(bào)警與調(diào)度系統(tǒng)是一個(gè)基于事件進(jìn)行管理的分布式信息系統(tǒng)?；馂?zāi)報(bào)警與調(diào)度系統(tǒng)包括多個(gè)參與者：現(xiàn)場(chǎng)工作人員，比如警察和消防員；調(diào)度者，是負(fù)責(zé)回答報(bào)警呼叫并對(duì)事故現(xiàn)場(chǎng)資源進(jìn)行調(diào)度的警官。火災(zāi)報(bào)警與調(diào)度系統(tǒng)通過對(duì)意外事件追蹤、資源調(diào)度和任務(wù)計(jì)劃等，支持這兩類參與者?；馂?zāi)報(bào)警與調(diào)度系統(tǒng)也可以訪問多個(gè)數(shù)據(jù)庫，如會(huì)合地點(diǎn)數(shù)據(jù)庫和緊急操作過程數(shù)據(jù)庫?，F(xiàn)場(chǎng)工作人員和調(diào)度者通過不同接口進(jìn)行交互，現(xiàn)場(chǎng)工作人員通過移動(dòng)個(gè)人助理訪問火災(zāi)報(bào)警與調(diào)度系統(tǒng)，調(diào)度者通過調(diào)度室里面的工作站訪問火災(zāi)報(bào)警與調(diào)度系統(tǒng)。9.2.1標(biāo)識(shí)參與者通過標(biāo)識(shí)參與者，可找出與系統(tǒng)產(chǎn)生交互的外部實(shí)體。參與者可以是人，也可以是一個(gè)外部系統(tǒng)。在衛(wèi)星表實(shí)例中，手表的擁有者、全球定位系統(tǒng)和手表驅(qū)動(dòng)軟件均是參與者。圍繞著衛(wèi)星表，這些參與者之間交換信息?，F(xiàn)舉例說明如下：手表的擁有者帶著表，以便隨時(shí)看表，通過手表知道時(shí)間；手表本身監(jiān)視著來自衛(wèi)星的信號(hào)，通過與全球定位系統(tǒng)GPS進(jìn)行交互，計(jì)算其位置；下載新數(shù)據(jù)到該手表上。從上述例子中可以看出，參與者定義了不同功能類別。需求獲取的第一步是標(biāo)識(shí)參與者。這一步驟定義了系統(tǒng)邊界，并從開發(fā)者角度描述了系統(tǒng)中的所有觀察點(diǎn)。要注意的是：大多數(shù)參與者在系統(tǒng)開發(fā)之前就已經(jīng)存在；在標(biāo)識(shí)參與者的初始階段中，很難區(qū)分參與者和對(duì)象。參與者是在系統(tǒng)邊界之外的，即它們是來自外部的；子系統(tǒng)和對(duì)象在系統(tǒng)邊界之內(nèi)，它們是內(nèi)部的。因此，任何要使用未來系統(tǒng)的外部軟件系統(tǒng)就是一個(gè)參與者。在標(biāo)識(shí)參與者的過程中，開發(fā)者可通過如下問題的提出獲取和確認(rèn)參與者：系統(tǒng)完成工作后，哪一個(gè)用戶組受益？系統(tǒng)的主功能由哪一個(gè)用戶組完成？次要功能由哪一個(gè)用戶組完成？與該系統(tǒng)進(jìn)行交互的外部硬件和軟件系統(tǒng)是誰？在火災(zāi)報(bào)警與調(diào)度系統(tǒng)中，通過這些問題可導(dǎo)出一個(gè)潛在的參與者清單，包括：消防員、警官、調(diào)度者、調(diào)查員、市長(zhǎng)、政府官員、會(huì)合地點(diǎn)數(shù)據(jù)庫、系統(tǒng)管理員等等。一旦參與者標(biāo)識(shí)出來后，需求獲取的下一步活動(dòng)是決定每一個(gè)參與者將訪問的功能。這一信息通過場(chǎng)景使用和形式化用例來獲取。9.2.2標(biāo)識(shí)場(chǎng)景場(chǎng)景是一種說明人們將做什么的陳述性描述，以及人們?cè)噲D利用計(jì)算機(jī)系統(tǒng)和應(yīng)用程序經(jīng)驗(yàn)的陳述性描述。一個(gè)場(chǎng)景是系統(tǒng)單一特征的非形式化描述。場(chǎng)景不能代替用例，因?yàn)閳?chǎng)景將重點(diǎn)放在特定實(shí)例和具體事件上，這一點(diǎn)與通用性描述相對(duì)。報(bào)告緊急情況用例中的倉(cāng)庫火災(zāi)場(chǎng)景

場(chǎng)景名稱

倉(cāng)庫著火參與者實(shí)例

甲，乙：現(xiàn)場(chǎng)工作人員丙：調(diào)度員事件流1.甲正駕駛著巡邏車在主要街道上巡邏，突然發(fā)現(xiàn)一個(gè)倉(cāng)庫冒出了黑煙。乙是甲的同事，馬上從自己的膝上電腦上激活火災(zāi)報(bào)警與調(diào)度系統(tǒng)的“緊急事件報(bào)告”功能。2.乙輸入了出事建筑物所在的地址，簡(jiǎn)要描述了現(xiàn)場(chǎng)情況和災(zāi)情的緊急程度。同時(shí)，考慮到這一地區(qū)相對(duì)比較熱鬧，除了請(qǐng)求消防隊(duì)外，乙還請(qǐng)求了幾個(gè)醫(yī)療隊(duì)前來。乙確定輸入后，等待回答。事件流

3.丙是3.調(diào)度員，他通過工作站上發(fā)出來的嘟嘟聲音，發(fā)覺了該緊急事件。丙查閱了乙的郵件信息，并對(duì)其報(bào)告進(jìn)行了回復(fù)。丙指派了一個(gè)消防隊(duì)和兩個(gè)醫(yī)療隊(duì)趕往出事地點(diǎn)，接著他將相關(guān)隊(duì)伍的到達(dá)時(shí)間通報(bào)給了乙。

4.乙收到了回復(fù)和相關(guān)隊(duì)伍預(yù)計(jì)到達(dá)的時(shí)間。在火災(zāi)報(bào)警與調(diào)度系統(tǒng)場(chǎng)景中，現(xiàn)場(chǎng)工作人員報(bào)告了一次火災(zāi)，而調(diào)度者對(duì)這一事件進(jìn)行了響應(yīng)。注意，這一場(chǎng)景描述了單一的實(shí)例。場(chǎng)景不會(huì)試圖去描述所有可能的火災(zāi)報(bào)告情況。在實(shí)際應(yīng)用中，場(chǎng)景不會(huì)包括對(duì)決策描述。如果要表達(dá)決策，則需要用兩個(gè)場(chǎng)景描速，一個(gè)場(chǎng)景對(duì)應(yīng)了“為真”情況，另一個(gè)場(chǎng)景對(duì)應(yīng)了“為假”情況。場(chǎng)景中的主要類型包括：當(dāng)前場(chǎng)景；原型場(chǎng)景、評(píng)價(jià)場(chǎng)景和培訓(xùn)場(chǎng)景。當(dāng)前場(chǎng)景描述了當(dāng)前情況。原型場(chǎng)景描述了未來的系統(tǒng)。原型場(chǎng)景用于兩個(gè)方面，其一是在建模時(shí)開發(fā)者用于完成對(duì)未來系統(tǒng)的構(gòu)思，其二是作為來自用戶需求的溝通介質(zhì)。評(píng)價(jià)場(chǎng)景描述了用戶任務(wù)，據(jù)此評(píng)價(jià)系統(tǒng)功能。培訓(xùn)場(chǎng)景是向新用戶介紹系統(tǒng)功能的教程。這些教程通過一步步的指導(dǎo)，以實(shí)現(xiàn)手把手地教會(huì)用戶操作該系統(tǒng)的目的。在需求獲取中，開發(fā)者和用戶需撰寫并求精了一系列場(chǎng)景，以達(dá)成系統(tǒng)應(yīng)該做什么的共同理解。在標(biāo)識(shí)場(chǎng)景的過程中，開發(fā)者可通過如下問題的提出，來獲取和確認(rèn)場(chǎng)景：參與者希望系統(tǒng)完成的任務(wù)是什么？參與者要訪問的信息是什么？誰創(chuàng)建了這些數(shù)據(jù)？這些數(shù)據(jù)可以做修改或刪除嗎？由誰完成這些工作？參與者需要告知系統(tǒng)，相關(guān)外部交換是什么？怎樣交換？何時(shí)交換？系統(tǒng)需要向參與者詢問的事件是什么？最遲時(shí)期多長(zhǎng)？開發(fā)者使用系統(tǒng)的用戶手冊(cè)、過程手冊(cè)、公司標(biāo)準(zhǔn)、用戶日志和計(jì)劃表，以及與用戶和客戶交談的記錄等來回答這些問題。開發(fā)者應(yīng)該使用應(yīng)用域中的詞匯而非自己專業(yè)領(lǐng)域的詞匯寫出場(chǎng)景。當(dāng)開發(fā)者更加深入地了解了應(yīng)用域且決定了要采用的可能技術(shù)后，可采用迭代和增量方式求精場(chǎng)景。在標(biāo)識(shí)參與者和標(biāo)識(shí)場(chǎng)景期間，開發(fā)者要做的最重要工作是理解這些應(yīng)用領(lǐng)域。結(jié)合火災(zāi)報(bào)警與調(diào)度系統(tǒng)實(shí)例，我們可標(biāo)識(shí)出四個(gè)任務(wù)場(chǎng)景：1）倉(cāng)庫火災(zāi)場(chǎng)景，即描述在倉(cāng)庫中檢測(cè)到火災(zāi)時(shí)；兩個(gè)現(xiàn)場(chǎng)工作人員到達(dá)現(xiàn)場(chǎng)并請(qǐng)求支援；2）擋泥板被撞場(chǎng)景，即描述一場(chǎng)在高速公路上所發(fā)生的、但未引起傷亡的車禍。警官記錄了事件并在毀壞的車輛被拖走期間管理高速公路上交通；3）轎車撞樹場(chǎng)景，即一輛轎車撞到了一棵樹上。救火車被呼叫來并找到這輛轎車。因?yàn)檫@一事件是低優(yōu)先級(jí)的，救火車花費(fèi)了一些時(shí)間才到達(dá)現(xiàn)場(chǎng)。在等待的同時(shí)，不耐煩的車主爬上了一顆樹并隨后從樹上掉了下來，摔傷了腿，這時(shí)還要請(qǐng)求一輛救護(hù)車；4）地震場(chǎng)景，即一場(chǎng)空前的地震破壞了建筑和公路，造成了多起交通事故，為此啟動(dòng)了全國(guó)范圍內(nèi)的緊急處理預(yù)案。政府官員得到了通知：公路的損壞妨礙了交通事故的處理。9.2.3標(biāo)識(shí)用例

場(chǎng)景是用例的實(shí)例，即對(duì)一個(gè)給定功能而言，一個(gè)用例可以說明所有可能場(chǎng)景，參與者可啟動(dòng)用例。用例描述了一系列從初始情況出發(fā)的相關(guān)交互。通過關(guān)注誰啟動(dòng)了某一個(gè)用例，開發(fā)者可標(biāo)識(shí)出前面未注意到的新參與者。用例名稱報(bào)告緊急情況參與者由現(xiàn)場(chǎng)工作人員啟動(dòng)與調(diào)度員調(diào)度者聯(lián)絡(luò)事件流1.現(xiàn)場(chǎng)工作人員激活其終端上“報(bào)告緊急情況”的功能。

2.火災(zāi)報(bào)警與調(diào)度系統(tǒng)對(duì)上述請(qǐng)求做出反應(yīng)：向現(xiàn)場(chǎng)工作人員提交一份要填寫的表格。

3.現(xiàn)場(chǎng)工作人員填好表格上的相關(guān)內(nèi)容，如選擇緊急級(jí)別、類型、位置和簡(jiǎn)單情況描述等?，F(xiàn)場(chǎng)工作人員還需要描述緊急情況可能出現(xiàn)的后果。一旦填寫完畢，現(xiàn)場(chǎng)工作人員提交表格，以通知調(diào)度者。4.火災(zāi)報(bào)警與調(diào)度系統(tǒng)接收到表格后，就通知調(diào)度者。事件流5.調(diào)度者檢查所收到的提交信息，并通過調(diào)用用例在數(shù)據(jù)庫中創(chuàng)建一個(gè)事件。調(diào)度者選擇響應(yīng)并確認(rèn)收到該緊急報(bào)告。入口條件現(xiàn)場(chǎng)工作人員登陸進(jìn)入火災(zāi)報(bào)警與調(diào)度系統(tǒng)。出口條件

現(xiàn)場(chǎng)工作人員收到確認(rèn)信息并選擇對(duì)調(diào)度者的響應(yīng)；

或者，現(xiàn)場(chǎng)工作人員收到一條解釋信息，以說明為何該事務(wù)不必處理。質(zhì)量需求

現(xiàn)場(chǎng)工作人員的報(bào)告要在30秒鐘內(nèi)答復(fù)。

選擇響應(yīng)要在調(diào)度者發(fā)送后30秒鐘內(nèi)到達(dá)。我們可以從四個(gè)方面描述一個(gè)用例。第一個(gè)方面是描述用例的入口條件和出口條件，使得開發(fā)者能夠在用例被引用時(shí)，以及用例對(duì)系統(tǒng)和環(huán)境狀態(tài)的影響之下，理解這些條件。第二個(gè)方面是通過對(duì)入口條件和出口條件的檢查，開發(fā)者可判定是否丟失了用例。第三個(gè)方面是描述用例的事件流，使得開發(fā)者和客戶可討論參與者和系統(tǒng)之間的交互。最后一個(gè)方面應(yīng)該關(guān)注與用例相關(guān)聯(lián)的需求質(zhì)量，使得開發(fā)者在指定的功能環(huán)境下，獲取非功能需求。注意這四個(gè)方面所描述的是用例的最本質(zhì)方面。在實(shí)際描述中，通過加入額外內(nèi)容，以描述事件、規(guī)則和在事件流執(zhí)行中必須遵守的相關(guān)情況。簡(jiǎn)單用例寫作指南

用例應(yīng)該使用動(dòng)詞短語命名。用例名字應(yīng)該說明用戶要努力完成什么。

使用名詞短語對(duì)參與者進(jìn)行命名。

系統(tǒng)的邊界是清晰的。由參與者完成的步驟和由系統(tǒng)完成的步驟是可以進(jìn)行區(qū)分的。

事件流中的用例步驟表達(dá)成主動(dòng)語態(tài)。這將直接說明是誰完成了這一步驟。

前后步驟之間的因果關(guān)系是清晰的。

用例描述了完整的用戶事務(wù)。

異常情況應(yīng)該另外描述。

用例描述不涉及系統(tǒng)的用戶接口。

從長(zhǎng)度上講，一個(gè)用例最多不超過三段文字。否則，可使用UML中的包含關(guān)系和擴(kuò)展關(guān)系將一段較長(zhǎng)的文字分解成較小的用例。9.2.4求精用例在上述的實(shí)例基礎(chǔ)上，通過擴(kuò)充報(bào)告緊急情況用例，我們可以在火災(zāi)報(bào)警與調(diào)度系統(tǒng)中增加識(shí)別事件類型的細(xì)節(jié)，同時(shí)可說明調(diào)度者怎樣對(duì)現(xiàn)場(chǎng)工作人員進(jìn)行應(yīng)答的交互細(xì)節(jié)，這樣做，我們就求精了報(bào)告緊急情況用例。如圖9.8所示，注意所增加的內(nèi)容在正文中用斜體表示。用例名稱報(bào)告緊急情況參與者由現(xiàn)場(chǎng)工作人員啟動(dòng)與調(diào)度員調(diào)度者聯(lián)絡(luò)事件流1.現(xiàn)場(chǎng)工作人員激活其終端上“報(bào)告緊急情況”的功能。2.火災(zāi)報(bào)警與調(diào)度系統(tǒng)對(duì)上述請(qǐng)求做出反應(yīng)：向現(xiàn)場(chǎng)工作人員提交一份要填寫的表格。表格包括緊急類型菜單（一般緊急情況、火災(zāi)和交通事故）和事故位置、事件描述、資源請(qǐng)求，以及危險(xiǎn)的資源領(lǐng)域。

3.現(xiàn)場(chǎng)工作人員通過最小化操作說明緊急情況類型和描述域的內(nèi)容填好表格?，F(xiàn)場(chǎng)工作人員還需要描述緊急情況可能出現(xiàn)的后果以及所申請(qǐng)的資源。一旦現(xiàn)場(chǎng)工作人員填寫完畢，就提交表格，以通知調(diào)度者。事件流4.火災(zāi)報(bào)警與調(diào)度系統(tǒng)接收到表格后，就通過彈出一個(gè)對(duì)話框通知調(diào)度者。5.調(diào)度者檢查所收到的提交信息，并通過調(diào)用用例在數(shù)據(jù)庫中創(chuàng)建一個(gè)事件。包含在現(xiàn)場(chǎng)工作人員表格中的所有信息自動(dòng)地包含在事件中。調(diào)度者通過分配資源給事件（使用分配資源用例）以及確認(rèn)緊急報(bào)告選擇一種響應(yīng)。6.火災(zāi)報(bào)警與調(diào)度系統(tǒng)顯示確認(rèn)信息并選擇對(duì)現(xiàn)場(chǎng)工作人員的響應(yīng)。入口條件

…（同圖4－8，略）。使用場(chǎng)景以及定義系統(tǒng)功能用例，其目標(biāo)在于創(chuàng)建被用戶在早期開發(fā)中確認(rèn)的需求。在更改和確認(rèn)需求期間，將有很多用例多次重寫，一些用例充分求精，另一些用例則完全放棄。為了節(jié)約時(shí)間，很多探索性的工作可通過使用場(chǎng)景和實(shí)驗(yàn)性的用戶界面來完成。隨后進(jìn)行求精用例，這將會(huì)產(chǎn)生大量細(xì)節(jié)，這些細(xì)節(jié)涉及未來系統(tǒng)應(yīng)提供的特征和與系統(tǒng)相關(guān)聯(lián)的約束。特別要注意在初始時(shí)那些有意或無意忽略用例的相關(guān)情況，這些內(nèi)容在用例求精過程中被細(xì)化：細(xì)化系統(tǒng)操縱的元素；說明參與者和系統(tǒng)之間的低層交互序列；說明訪問權(quán)限（這些權(quán)限約束了參與者可引用的那些用例）；標(biāo)識(shí)出遺失的異常情況，說明對(duì)這些異常情況的處理；分離出用例之間的公共功能。9.2.5標(biāo)識(shí)參與者和用例之間的關(guān)系通過參與者和用例之間關(guān)系的分析，開發(fā)者和用戶能減少模型的復(fù)雜性，增加模型的可理解性。1.參與者和用例之間的通信關(guān)系參與者和用例之間的關(guān)聯(lián)表示了用例執(zhí)行期間的信息流。2.用例之間的擴(kuò)展關(guān)系如果一個(gè)用例在某種條件下可包括擴(kuò)展者的行為，則該用例就擴(kuò)展出另一個(gè)用例。在火災(zāi)報(bào)警與調(diào)度系統(tǒng)實(shí)例中，當(dāng)現(xiàn)場(chǎng)工作人員正填充表格時(shí)，如果現(xiàn)場(chǎng)工作人員的車輛駛?cè)胨淼?，則現(xiàn)場(chǎng)工作人員的工作站和調(diào)度者的工作站之間的連接就會(huì)被斷開?，F(xiàn)場(chǎng)工作人員的工作站需要通知現(xiàn)場(chǎng)工作人員：其表格沒有交付，同時(shí)通知現(xiàn)場(chǎng)工作人員將采取的進(jìn)一步措施。連接斷開用例被作為報(bào)告緊急情況（參見圖9.10）的擴(kuò)展進(jìn)行建模。在連接斷開用例啟動(dòng)的前提下，該用例的條件被描述成與報(bào)告緊急情況相反的情況。通常情況下，我們將異常事件流和選擇性事件流從基礎(chǔ)性用例中排除，這一做法有兩個(gè)優(yōu)點(diǎn)1）使得基本用例變短，從而更容易理解；2）將公共用例從異常用例中分離出來，可減少冗余，使得開發(fā)者用不同方法處理每一類別異常用例的功能。此外，這兩個(gè)用例中的任何一個(gè)用例必須具有入口條件和出口條件，以方便用戶整體理解。3.用例之間的包含關(guān)系使用包含關(guān)系可以將用例之間的冗余內(nèi)容分離出來。例如，在選擇訪問一個(gè)事件（火災(zāi)中哪個(gè)城區(qū)是危險(xiǎn)的）和分配資源（找出哪一個(gè)資源距離該事件最近）時(shí)，調(diào)度者需要考慮市區(qū)地圖。在這一情況下，在查看市區(qū)地圖時(shí)，可查看該用例描述的所需事件流（圖9.11），包括使用打開事件用例與分配資源用例。4.對(duì)包含關(guān)系的擴(kuò)展這兩個(gè)結(jié)構(gòu)之間的主要差別是這些關(guān)系的用途不同。對(duì)包含關(guān)系而言，觸發(fā)目標(biāo)（即被包含）事件用例使用源用例的事件流描述，必須說明每一個(gè)包含用例。對(duì)擴(kuò)展關(guān)系而言，觸發(fā)源（如將擴(kuò)展）事件用例用源用例作為前置條件，在擴(kuò)展用例時(shí)說明哪一個(gè)用例被擴(kuò)展。因此，當(dāng)系統(tǒng)行為強(qiáng)烈地依賴一個(gè)事件并出現(xiàn)了相對(duì)較少用例時(shí)，系統(tǒng)行為應(yīng)該使用包含關(guān)系表示。這些系統(tǒng)行為的類型通?？勺鰹楹芏喙蚕到y(tǒng)功能。反之，隨時(shí)都可以發(fā)生的系統(tǒng)行為或者系統(tǒng)行為的發(fā)生可以用更簡(jiǎn)捷的方式說明成一個(gè)入口條件時(shí)，應(yīng)該表示成擴(kuò)展關(guān)系。系統(tǒng)行為還應(yīng)該包含異常情況。圖9.12表示的連接斷開用例，分別用了包含關(guān)系（左欄）和擴(kuò)展關(guān)系（右欄）進(jìn)行描述。報(bào)告緊急情況（包含關(guān)系）1.……報(bào)告緊急情況（擴(kuò)展關(guān)系）1.……2.……3.現(xiàn)場(chǎng)工作人員填好表：選擇緊急情況等級(jí)、類型、位置和簡(jiǎn)單情況描述，現(xiàn)場(chǎng)工作人員還需要描述緊急事件的可能后果。一旦填寫完成，則可提交表格，并通知調(diào)度員調(diào)度者。如果連接被斷開，則應(yīng)用連接中斷用例。2.……3.現(xiàn)場(chǎng)工作人員填好表：選擇緊急情況等級(jí)、類型、位置和簡(jiǎn)單情況描述，現(xiàn)場(chǎng)工作人員還需要描述緊急事件的可能后果。一旦填寫完成，則可提交表格，并通知調(diào)度者。

4.如果連接依然保持，調(diào)度者查看所提交的信息并通過調(diào)用打開事件用例在數(shù)據(jù)庫中創(chuàng)建一個(gè)事件。調(diào)度者選擇一個(gè)響應(yīng)并說明收到報(bào)告緊急情況。如果連接被斷開，則應(yīng)用連接中斷用例。5.……

4.調(diào)度者查看提交的信息并通過調(diào)用打開事件用例，在數(shù)據(jù)庫中創(chuàng)建一個(gè)事件。調(diào)度者選擇一個(gè)響應(yīng)并表明收到報(bào)告緊急情況。

5.……

連接中斷（包含關(guān)系）1.現(xiàn)場(chǎng)工作人員和調(diào)度者收到連接中斷的通知，他們將被告知連接中斷的可能原因（例如，“是否有現(xiàn)場(chǎng)工作人員在隧道中工作？”）。連接中斷（擴(kuò)展關(guān)系）現(xiàn)場(chǎng)工作人員和調(diào)度者之間的連接中斷時(shí)，連接中斷用例擴(kuò)展報(bào)告緊急情況用例。2.將相關(guān)情況記錄到系統(tǒng)中，并在重新連接建立時(shí)進(jìn)行恢復(fù)。3.現(xiàn)場(chǎng)工作人員和調(diào)度者通過其它方式進(jìn)行聯(lián)系，且調(diào)度者在調(diào)度中心啟動(dòng)緊急情況。1.現(xiàn)場(chǎng)工作人員和調(diào)度者收到連接中斷的通知，他們將被告知連接中斷的可能原因（例如，“是否有現(xiàn)場(chǎng)工作人員在隧道中工作？”）。2.將相關(guān)情況記錄到系統(tǒng)中，并在重新連接建立時(shí)進(jìn)行恢復(fù)。3.現(xiàn)場(chǎng)工作人員和調(diào)度者通過其它方式進(jìn)行聯(lián)系，且調(diào)度員調(diào)度者在調(diào)度中心啟動(dòng)緊急情況。9.2.6標(biāo)識(shí)初始的分析對(duì)象在開發(fā)者和用戶彼此協(xié)作開始進(jìn)行工作時(shí)，首先遇到的阻礙之一是各自使用了不同的術(shù)語。為了建立清晰的術(shù)語，開發(fā)者為每一個(gè)用例標(biāo)識(shí)了參與對(duì)象。開發(fā)者應(yīng)該無二義性地標(biāo)識(shí)和描述這些用例名，并將這些用例名收集起來放入術(shù)語表中。標(biāo)識(shí)參與對(duì)象將導(dǎo)出初始分析對(duì)象模型。為了標(biāo)識(shí)出對(duì)象，在此給出其中的一些準(zhǔn)則：對(duì)于理解用例而言，開發(fā)者和用戶所使用的術(shù)語，其含義必須是清楚的；在用例中出現(xiàn)可重復(fù)的名詞（例如，事件）應(yīng)該引起注意；如果是系統(tǒng)必須跟蹤的現(xiàn)實(shí)世界中的實(shí)體（例如，現(xiàn)場(chǎng)工作人員，資源），則要引起注意；如果是系統(tǒng)必須跟蹤的現(xiàn)實(shí)世界中的處理（例如，危機(jī)處理計(jì)劃），則要引起注意；如果是用例（例如，報(bào)告緊急情況），則應(yīng)產(chǎn)生一個(gè)對(duì)應(yīng)的對(duì)象；如果是數(shù)據(jù)源和數(shù)據(jù)匯（例如，打印機(jī)），則應(yīng)認(rèn)真分析；與用戶進(jìn)行交互的人工制品（例如，工作站）應(yīng)引起注意；總是出現(xiàn)在應(yīng)用域中的術(shù)語要特別引起注意。在需求獲取過程中，將為每一個(gè)用例生成參與對(duì)象。例如，從報(bào)告緊急情況用例中，我們標(biāo)識(shí)出的初始參與者有調(diào)度者、緊急情況報(bào)告、現(xiàn)場(chǎng)工作人員和事件。一旦初始對(duì)象標(biāo)識(shí)出來并確定下來后，開發(fā)者可將它們放在一份清單中，以確保所標(biāo)識(shí)出的一組用例是完全。相關(guān)的交叉用例檢查參與對(duì)象的啟發(fā)式規(guī)則如下：哪一個(gè)用例創(chuàng)建了這一對(duì)象？哪一個(gè)參與者可以訪問這一信息？哪一個(gè)用例可以修改和撤銷這一對(duì)象？哪一個(gè)參與者可以啟動(dòng)這些對(duì)象？這一對(duì)象是必須的嗎？9.2.7標(biāo)識(shí)非功能需求非功能需求描述了系統(tǒng)中的與系統(tǒng)行為無直接關(guān)系的方面。非功能需求涉及到了很多問題，包括用戶界面外觀和響應(yīng)時(shí)間等內(nèi)容。非功能需求應(yīng)與功能需求同時(shí)定義，因?yàn)樗鼈儗?duì)系統(tǒng)開發(fā)和系統(tǒng)維護(hù)的代價(jià)影響更大。例如，用于飛機(jī)跟蹤的空中交通控制程序的拼圖顯示系統(tǒng)。一個(gè)拼圖顯示系統(tǒng)將雷達(dá)和數(shù)據(jù)庫中的數(shù)據(jù)解釋成標(biāo)識(shí)某一空域中所有航空器的抽象顯示，顯示內(nèi)容包括航空器的標(biāo)志、速度和高度。這類系統(tǒng)的航空器數(shù)目可以顯示出該空中交通控制軟件的約束性能和系統(tǒng)代價(jià)。如果系統(tǒng)僅可以同時(shí)處理少數(shù)航空器的話，則該軟件就不適用于繁忙的機(jī)場(chǎng)使用。與此相反，能夠處理大批量航空器數(shù)目的系統(tǒng)更有價(jià)值，但這一系統(tǒng)在建造和測(cè)試上將更復(fù)雜。單一拼圖顯示必須能處理的航空器數(shù)量，必須能夠處理顯示航空器的光標(biāo)規(guī)模、標(biāo)識(shí)航空器的特征和它們的性質(zhì)。典型的非功能需求集合可能會(huì)包括沖突的需求。例如，在衛(wèi)星表實(shí)例中，有兩個(gè)非功能需求沖突存在，即手表的代價(jià)會(huì)隨著其計(jì)時(shí)精度的提高而上漲。為了處理這一沖突，客戶和開發(fā)者應(yīng)該區(qū)分這兩類非功能需求的優(yōu)先次序，使得在該系統(tǒng)實(shí)現(xiàn)過程中，這些有沖突的非功能需求可一致性地得到解決。獲取非功能需求的問題實(shí)例

分類

實(shí)例問題

可用性

用戶所需的專門技術(shù)層次是什么？

用戶界面標(biāo)準(zhǔn)對(duì)用戶而言是否熟悉？

應(yīng)該提供給用戶的文檔是什么？可靠性

（包括健壯性、安全性和保密性）

系統(tǒng)應(yīng)該具有的可靠性、可用性和健壯性應(yīng)該是什么？

在出錯(cuò)事件中的系統(tǒng)重啟動(dòng)是否是可以接受的？

有多少數(shù)據(jù)系統(tǒng)可以釋放？

系統(tǒng)怎樣處理異常？

系統(tǒng)的安全需求是什么？

系統(tǒng)的保密要求是什么？性能

系統(tǒng)應(yīng)該怎樣進(jìn)行響應(yīng)？

有無用戶任務(wù)要求時(shí)間至上？

系統(tǒng)應(yīng)該支持用戶有多少？

對(duì)于一個(gè)可比較的系統(tǒng)而言，典型的數(shù)據(jù)存儲(chǔ)有多大？

用戶所能夠接受的最壞延遲是多大？支持性

（包括維護(hù)性和可移植性）

系統(tǒng)可預(yù)見的擴(kuò)充是什么？

誰維護(hù)該系統(tǒng)？

是否有考慮系統(tǒng)支持不同軟硬件環(huán)境的計(jì)劃？實(shí)現(xiàn)

硬件平臺(tái)的約束是什么？

管理團(tuán)隊(duì)制定的約束是什么？

測(cè)試團(tuán)隊(duì)制定的約束是什么？接口

該系統(tǒng)是否存在任何與現(xiàn)存系統(tǒng)的交互？

數(shù)據(jù)是怎樣移入和移出系統(tǒng)的？

系統(tǒng)應(yīng)該支持用戶使用的標(biāo)準(zhǔn)是什么？操作

誰來管理運(yùn)行中的系統(tǒng)？打包

誰來安裝該系統(tǒng)？

所預(yù)見的安裝工作量有多少？

安裝上有時(shí)間約束嗎？合法性

系統(tǒng)是怎樣授權(quán)的？

是否存在任何致使系統(tǒng)失敗而引發(fā)的債務(wù)問題？

在通過使用算法或者構(gòu)件說明時(shí)，是否存在任何權(quán)利或者授權(quán)付費(fèi)發(fā)生？9.3需求獲取管理9.3.1客戶談判規(guī)格說明：聯(lián)合應(yīng)用設(shè)計(jì)聯(lián)合應(yīng)用設(shè)計(jì)（JAD）是由IBM公司在70年代末提出的一種需求開發(fā)方法。在一次由所有風(fēng)險(xiǎn)承擔(dān)者參與的會(huì)議上，使用這一方法可有效獲取用戶需求。客戶、用戶、開發(fā)者和訓(xùn)練有素的會(huì)議主持人在會(huì)議室中坐在一起，他們提出自己的觀點(diǎn)，相互傾聽其他人意見，相互諧調(diào)，最后理智地接受解決方案。最后形成了JAD文檔，這是一份包括數(shù)據(jù)元素、工作流和界面形式的需求規(guī)格說明的完全文檔。因?yàn)樽罱K形式的文檔是由相關(guān)風(fēng)險(xiǎn)承擔(dān)者（即參與者不僅關(guān)心這一項(xiàng)目的成功，而且參與了該項(xiàng)目實(shí)質(zhì)性的決策）聯(lián)合開發(fā)的，因此在后繼開發(fā)過程中，這些需求發(fā)生變化的可能性是最小的。JAD由五個(gè)活動(dòng)組成。1.項(xiàng)目定義JAD提倡者與項(xiàng)目管理者和客戶進(jìn)行會(huì)面，以決定該項(xiàng)目的目標(biāo)與范圍。2.調(diào)研這一活動(dòng)的結(jié)論是在會(huì)議議程和基本的規(guī)格說明中列出工作流和系統(tǒng)信息。3.準(zhǔn)備JAD提倡者準(zhǔn)備會(huì)議。JAD提倡者建立工作文檔，選擇由客戶、項(xiàng)目經(jīng)理、部分用戶和開發(fā)者組成團(tuán)隊(duì)。4.會(huì)議一次JAD會(huì)議至少要3至5天時(shí)間。該團(tuán)隊(duì)對(duì)場(chǎng)景、用例和實(shí)驗(yàn)用的界面進(jìn)行定義并取得一致性的意見。5.最終文檔最終文檔代表了被贊同系統(tǒng)的完整規(guī)格說明。通過促進(jìn)參與者之間的溝通并加速輿論宣傳，JAD使得各個(gè)團(tuán)隊(duì)之間達(dá)到動(dòng)態(tài)平衡。JAD會(huì)議是否成功，通常依賴JAD提倡者的素質(zhì)。9.3.2追蹤性維護(hù)追蹤性是對(duì)需求進(jìn)行跟蹤的能力。這一能力包括跟蹤需求從哪里來，到系統(tǒng)的哪一部分去，以及對(duì)項(xiàng)目的影響。追蹤性使得開發(fā)者看到的系統(tǒng)是完全的，測(cè)試者看到的系統(tǒng)是否與其需求相符合，設(shè)計(jì)者記錄系統(tǒng)內(nèi)部的機(jī)理，以及維護(hù)者評(píng)價(jià)變化帶來的影響。考慮我們?cè)谝婚_始引入的衛(wèi)星表系統(tǒng)。當(dāng)前的規(guī)格說明中提倡雙行顯示形式，以顯示出時(shí)間和日期。當(dāng)客戶認(rèn)為數(shù)字太小以至于影響到了閱讀的舒適程度時(shí)，開發(fā)者將顯示需求改變成為能夠在時(shí)間和日期之間進(jìn)行切換的單行顯示形式。追蹤性將能夠使得我們回答如下問題：是誰提出雙行顯示需求？有無任何隱式約束委托給該需求？因?yàn)樵黾恿税粹o和顯示的緣故，哪一個(gè)構(gòu)件必須改變？哪一個(gè)測(cè)試用例必須改變？維持追蹤性的最簡(jiǎn)單方法是在文檔、模型和代碼制品之間進(jìn)行交叉參考。維持追蹤性的支撐工具可以是速記法和字處理器。對(duì)大型項(xiàng)目而言，應(yīng)使用特定數(shù)據(jù)庫工具，使得捕捉、編輯工作自動(dòng)化，并能追蹤到更細(xì)的層次。9.3.3需求獲取的書面說明需求獲取結(jié)論和分析活動(dòng)用需求分析文檔（RequirementsAnalysisDocument，RAD）形式進(jìn)行書面說明。這一文檔根據(jù)功能和非功能需求完全描述了系統(tǒng)，這一描述可作為客戶和開發(fā)者之間的合約。RAD的讀者包括客戶、用戶、項(xiàng)目經(jīng)理、系統(tǒng)分析員和系統(tǒng)設(shè)計(jì)師。用例和非功能屬性構(gòu)成了文檔的第一部分，將在需求獲取期間撰寫。

需求分析文檔（RAD）模板1．導(dǎo)論

1．1系統(tǒng)目標(biāo)

1．2系統(tǒng)范圍

1．3項(xiàng)目目標(biāo)和成功標(biāo)準(zhǔn)

1．4定義、首字母縮寫詞和縮寫詞

1．5參考書目

1．6總結(jié)2．當(dāng)前系統(tǒng)3．建議的系統(tǒng)

3．1概述

3．2功能需求

3．3非功能需求

3．3．1可用性

3．3．2可靠性

3．3．3性能

3．3．4可支持性

3．3．5實(shí)現(xiàn)性

3．3．6接口3．3．7打包

3．3．8合法性

3．4系統(tǒng)模型

3．4．1場(chǎng)景

3．4．2用例模型

3．4．3對(duì)象模型

3．4．4動(dòng)態(tài)模型

3．4．5用戶接口－搜索路徑和屏幕實(shí)驗(yàn)原型4．術(shù)語表RAD的第一部分是導(dǎo)言。導(dǎo)言的目的是提供系統(tǒng)功能的概要，及其提供這些功能開發(fā)的理由、范圍和對(duì)開發(fā)環(huán)境的參考。引言還包括目標(biāo)和項(xiàng)目終止的準(zhǔn)則。在第二部分當(dāng)前系統(tǒng)中描述當(dāng)前事務(wù)情況。如果用新系統(tǒng)代替現(xiàn)有系統(tǒng)，本節(jié)將描述現(xiàn)存系統(tǒng)的功能和范圍。否則，本節(jié)通過描述怎樣現(xiàn)實(shí)新系統(tǒng)以支持實(shí)現(xiàn)任務(wù)。例如，在衛(wèi)星表實(shí)例中，每當(dāng)穿越時(shí)區(qū)的時(shí)候，用戶復(fù)位其手表。由于這一操作的人工影響，用戶偶然可能會(huì)設(shè)置錯(cuò)誤的時(shí)間，或偶然會(huì)遺忘了復(fù)位操作。與此形成對(duì)比的是，在其生命周期中，衛(wèi)星表需要持續(xù)地確保精確時(shí)間。在第三部分中，建議的系統(tǒng)，對(duì)需求獲取書面說明并分析新系統(tǒng)的模型。這一節(jié)將包括四個(gè)內(nèi)容：1）回顧整個(gè)系統(tǒng)提出的功能；2）非功能需求描述了系統(tǒng)的高層功能；3）非功能需求描述了與系統(tǒng)功能無直接關(guān)系的用戶需要；4）系統(tǒng)模型描述了系統(tǒng)的場(chǎng)景、用例、對(duì)象模型和動(dòng)態(tài)模型。RAD應(yīng)該在用例模型穩(wěn)定后開始撰寫。RAD的修訂歷史將提供變化的歷史，包括每次變化時(shí)作者的責(zé)任、改變?nèi)掌诤妥兓闹饕枋觥?.4面向?qū)ο蠓治?/p>

需求規(guī)格說明中可能存在著二義性，這是由于自然語言的內(nèi)在不確定性引起的。形式化方法有助于標(biāo)識(shí)出規(guī)格說明中的二義性和不一致性，以及在需求規(guī)格說明中忽略了的領(lǐng)域。需求獲取和分析之間是迭代和遞增的活動(dòng)，這些活動(dòng)的發(fā)生通常是并發(fā)的。

9.4.1分析的概述

分析將關(guān)注點(diǎn)放在系統(tǒng)模型的產(chǎn)生上，這一模型稱為分析模型，該模型應(yīng)該是正確的、完全的、一致性的和可確認(rèn)的。在分析活動(dòng)中，開發(fā)者將關(guān)注點(diǎn)放在對(duì)來自用戶處抽取的需求的形式化上（如圖9.15）。形式化將導(dǎo)致新的洞察和發(fā)現(xiàn)需求錯(cuò)誤。用戶和開發(fā)者通常會(huì)盡量延遲不同決策的時(shí)間。當(dāng)開發(fā)者將需求規(guī)格說明翻譯成形式化或者半形式化的模型時(shí)，會(huì)迫使開發(fā)者在開發(fā)早期標(biāo)識(shí)和解決困難的問題。

分析模型由三個(gè)獨(dú)立模型構(gòu)成：(1)由用例和場(chǎng)景表示的功能模型；(2)用類和對(duì)象圖表示的分析對(duì)象模型；(3）用狀態(tài)圖和順序圖表示的動(dòng)態(tài)模型等。

9.4.2分析的概念

1.對(duì)象模型和動(dòng)態(tài)模型分析

分析對(duì)象模型將注意點(diǎn)放在由系統(tǒng)、系統(tǒng)特征和系統(tǒng)關(guān)系操縱的單一概念上。用UML類圖描述的分析對(duì)象模型，包括類、屬性和操作。分析對(duì)象模型是對(duì)用戶是可見的。動(dòng)態(tài)模型將注意點(diǎn)放在系統(tǒng)的行為上。動(dòng)態(tài)模型用順序圖或者用狀態(tài)圖描述。順序圖表示在單一用例期間，一組對(duì)象之間的交互。狀態(tài)圖表示了單一對(duì)象（或者一組關(guān)聯(lián)緊密的處理對(duì)象）的行為。注意，當(dāng)與其它分析模型一起工作時(shí)，或者與動(dòng)態(tài)模型一起工作時(shí)，這些模型所代表的是來自用戶層的概念而非實(shí)際軟件類或?qū)嶋H構(gòu)件。如數(shù)據(jù)庫、子系統(tǒng)、會(huì)話管理器、網(wǎng)絡(luò)之類的類，不應(yīng)該出現(xiàn)在分析模型中，因?yàn)檫@些概念與用戶完全無關(guān)。與分析中的類相比，軟件類將包括很多屬性和關(guān)聯(lián)。因此，分析類可被看作是高層抽象，這一高層抽象將出現(xiàn)在后面的階段中，通過使用更細(xì)的細(xì)節(jié)實(shí)現(xiàn)。2.實(shí)體、邊界和控制對(duì)象

在分析對(duì)象模型中，包括了實(shí)體對(duì)象、邊界對(duì)象和控制對(duì)象三種類型。實(shí)體對(duì)象表示系統(tǒng)將跟蹤的持久信息。邊界對(duì)象表示參與者與系統(tǒng)之間的接口和交互?？刂茖?duì)象負(fù)責(zé)用例實(shí)現(xiàn)。我們將實(shí)體對(duì)象、邊界對(duì)象和控制對(duì)象所構(gòu)成的分析對(duì)象模型稱為三對(duì)象模型。

對(duì)系統(tǒng)進(jìn)行建模時(shí)，常常需要向開發(fā)者提供簡(jiǎn)單的啟發(fā)式規(guī)則。例如，手表所跟蹤的時(shí)間概念，與作為顯示用的時(shí)間概念既有區(qū)別又有聯(lián)系。邊界對(duì)象與實(shí)體對(duì)象之間的差別主要是：作為實(shí)體對(duì)象的時(shí)間是可以通過時(shí)間對(duì)象對(duì)應(yīng)的類來跟蹤。作為邊界對(duì)象的顯示可以通過液晶顯示器來表示。為了區(qū)分不同類型的對(duì)象，我們可以使用UML提供的版類機(jī)制建立模型元素。在圖9.18中，我們將<<control>>版類機(jī)制依附在改變數(shù)據(jù)控制的對(duì)象上。除了使用版類之外，我們還可以在語法層次上利用命名來澄清和區(qū)分這三種不同類型的對(duì)象：控制對(duì)象可在名字前面增加具有表示控制意義的前綴；邊界對(duì)象可以在命名時(shí)清楚地標(biāo)識(shí)接口特征（例如可包括如下前綴形式：From,Button,Display,Boundary）；實(shí)體對(duì)象命名時(shí)通常不使用任何前綴。

3.泛化和特化

繼承使得我們能夠?qū)⒏拍罱M織成層次結(jié)構(gòu)。在概念層次的頂層是泛化的概念，在這一概念層次的底層是一些最特化的概念。在這兩個(gè)層次之間存在著很多中間層次，涉及到或多或少的通用概念。泛化是建模中的活動(dòng)，該活動(dòng)標(biāo)明了從多個(gè)底層概念中得到的抽象概念。特化是建模中的活動(dòng)，該活動(dòng)將一個(gè)源于高層的概念特化為多個(gè)實(shí)例。

9.4.3分析活動(dòng)：從用例導(dǎo)出對(duì)象

分析活動(dòng)包括：

標(biāo)識(shí)實(shí)體對(duì)象；標(biāo)識(shí)邊界對(duì)象；標(biāo)識(shí)控制對(duì)象；使用順序圖將用例映射成對(duì)象；使用CRC卡建模對(duì)象之間的交互；標(biāo)識(shí)關(guān)聯(lián)；標(biāo)識(shí)聚集；標(biāo)識(shí)屬性；建模單一對(duì)象的狀態(tài)相關(guān)的行為；建模對(duì)象之間的繼承關(guān)系；分析模型評(píng)審。

1.標(biāo)識(shí)實(shí)體對(duì)象

從基本的分析模型中劃分對(duì)象。通過檢查每一個(gè)用例和標(biāo)識(shí)候選對(duì)象，我們可以發(fā)現(xiàn)要找出的對(duì)象。為了從需求規(guī)格說明中標(biāo)識(shí)對(duì)象、屬性和關(guān)聯(lián)，我們使用自然語言分析方法，可以通過直覺的候選實(shí)體得到對(duì)象集合。我們將使用Abbott提出的啟發(fā)式準(zhǔn)則，該準(zhǔn)則將語言成分（名詞、進(jìn)行時(shí)、be動(dòng)詞和副詞）映射成模型的成分（對(duì)象、操作、繼承關(guān)系和類）。Abbott啟發(fā)式準(zhǔn)則，以完成將聲音部分映射成模型構(gòu)件

語言成分

模型構(gòu)件實(shí)例

專有名詞實(shí)例人員乙

普通名詞類現(xiàn)場(chǎng)工作人員

Doing動(dòng)詞操作創(chuàng)建、提交、選擇

Being動(dòng)詞繼承是…一種,是其中的一個(gè)

Having動(dòng)詞聚集有,由…組成,包括

情態(tài)動(dòng)詞約束必須是形容詞屬性事件描述

報(bào)告緊急情況用例實(shí)例的一個(gè)例子

用例名報(bào)告緊急情況入口條件

1.現(xiàn)場(chǎng)工作人員激活火災(zāi)報(bào)警與調(diào)度系統(tǒng)終端上的“緊急情況報(bào)告”功能。事件流

2.火災(zāi)報(bào)警與調(diào)度系統(tǒng)通過提交一個(gè)表格給該官員以做出反應(yīng)。該表格包括一個(gè)意外類型菜單（如普通意外，火災(zāi)和交通事故），事件發(fā)生的位置，事件描述，救援申請(qǐng)和危險(xiǎn)材料所在地。3.現(xiàn)場(chǎng)工作人員至少要填寫意外類型和描述域以完成表格?，F(xiàn)場(chǎng)工作人員也可以描述對(duì)意外情況和特定救援申請(qǐng)的可能響應(yīng)。一旦該表格完成，現(xiàn)場(chǎng)工作人員通過按下“發(fā)送報(bào)告”按鈕提交該表格，在這一刻，調(diào)度者得到通報(bào)。事件流4.調(diào)度者評(píng)價(jià)由現(xiàn)場(chǎng)工作人員提交的信息，并通過調(diào)用打開事件用例，在數(shù)據(jù)庫中創(chuàng)建一個(gè)事件。將現(xiàn)場(chǎng)工作人員表格中的所有組成信息自動(dòng)地包含在該事件中。通過分配救援給該事件（使用分配資源用例），調(diào)度者選擇一個(gè)響應(yīng)，并通過發(fā)送信息給現(xiàn)場(chǎng)工作人員，以確認(rèn)意外報(bào)告。出口條件

5.現(xiàn)場(chǎng)工作人員收到確認(rèn)消息并做出響應(yīng)。

自然語言分析方法主要關(guān)注用戶術(shù)語。但這一方法有很多限制。第一，對(duì)象模型的質(zhì)量高度地依賴于分析員的書寫風(fēng)格。第二，與得到的有關(guān)類名詞相比，這一方法可能會(huì)出現(xiàn)很多無關(guān)名詞。這些名詞中，有很多是表示屬性的名詞，或者是同義詞。我們將如下啟發(fā)式準(zhǔn)則與Abbott準(zhǔn)則進(jìn)行結(jié)合：為了理解用例，開發(fā)者或用戶需要澄清的描述項(xiàng)；用例中的連續(xù)名詞（如事件）；系統(tǒng)需要跟蹤的現(xiàn)實(shí)世界中的實(shí)體（如現(xiàn)出工作人員，調(diào)度者等）；系統(tǒng)需要跟蹤的現(xiàn)實(shí)世界中的活動(dòng)（如緊急情況操作預(yù)案）；數(shù)據(jù)源或數(shù)據(jù)匯（如打印機(jī)）。

2.標(biāo)識(shí)邊界對(duì)象

邊界對(duì)象表示了系統(tǒng)與參與者之間的接口。邊界對(duì)象從參與者處收集信息，將之轉(zhuǎn)換成一種可用于實(shí)體對(duì)象和控制對(duì)象的表示形式。

邊界對(duì)象在一個(gè)很粗略的層面上對(duì)用戶界面進(jìn)行建模。該模型不描述用戶界面可視方面的細(xì)節(jié)，如像“菜單項(xiàng)”或“滾動(dòng)條”之類的邊界對(duì)象就顯得太細(xì)了。標(biāo)識(shí)邊界對(duì)象的啟發(fā)式準(zhǔn)則如下：

標(biāo)識(shí)用戶需要的初始用例的用戶界面控制；標(biāo)識(shí)用戶需要鍵入系統(tǒng)的數(shù)據(jù)表格；標(biāo)識(shí)通知和系統(tǒng)用于對(duì)用戶進(jìn)行響應(yīng)的消息；當(dāng)多個(gè)參與者被包含到一個(gè)用例中時(shí)，根據(jù)需要考慮的用戶界面來標(biāo)識(shí)參與者的終止；不要使用邊界對(duì)象對(duì)接口的可視方面進(jìn)行建模，而應(yīng)該使用用戶原型建模可視用戶界面；為了描述界面，總是使用最終用戶的術(shù)語；不要使用來自解答域和實(shí)現(xiàn)域的術(shù)語?，F(xiàn)在通過實(shí)例來說明邊界對(duì)象的標(biāo)識(shí)。通過檢查上面已經(jīng)提到的報(bào)告緊急情況用例，我們找出了如下邊界對(duì)象：確認(rèn)通知、調(diào)度站、報(bào)告緊急情況按鈕、現(xiàn)場(chǎng)工作站和事件表單。

3.標(biāo)識(shí)控制對(duì)象

控制對(duì)象負(fù)責(zé)協(xié)調(diào)邊界對(duì)象和實(shí)體對(duì)象。在現(xiàn)實(shí)世界中，控制對(duì)象通常沒有具體的對(duì)應(yīng)物。通常，在用例和控制對(duì)象之間存在一個(gè)封閉關(guān)系；控制對(duì)象通常在一個(gè)實(shí)體開始時(shí)創(chuàng)建，并在該實(shí)體退出時(shí)終止。從邊界對(duì)象處收集信息，并將這些信息分配給實(shí)體。例如火災(zāi)報(bào)警與調(diào)度系統(tǒng)，在初始時(shí)，對(duì)每一個(gè)參與者，我們使用一個(gè)控制對(duì)象對(duì)報(bào)告緊急情況用例的控制流，建立如下模型：報(bào)告緊急情況控制對(duì)應(yīng)著現(xiàn)場(chǎng)工作人員，而管理意外事件控制則對(duì)應(yīng)著調(diào)度者。

要從現(xiàn)場(chǎng)工作人員群體和調(diào)度者群體中出發(fā)，決策是否使用兩個(gè)控制對(duì)象管理緊急情況用例，這一決策可以推遲到系統(tǒng)設(shè)計(jì)活動(dòng)開始時(shí)才做出。在此基礎(chǔ)上，應(yīng)該在分析模型中使得這些概念可見，允許開發(fā)者將注意點(diǎn)放在這兩個(gè)群體之間因缺乏溝通而產(chǎn)生的異常行為上。4.使用順序圖將用例映射成對(duì)象

順序圖將用例與對(duì)象聯(lián)系在一起。該圖表達(dá)了用例（場(chǎng)景）行為在其參與對(duì)象之間是怎樣分布的。因?yàn)轫樞驁D需要涉及記號(hào)系統(tǒng)方面的更多背景知識(shí)，因此在與用戶的溝通方面不像用例那樣通俗。順序圖代表了從另一個(gè)觀察視角出發(fā)，使得開發(fā)人員能夠發(fā)現(xiàn)規(guī)格說明中遺漏的對(duì)象或界限不明的領(lǐng)域。

順序圖的欄目表示了參與到用例中的對(duì)象。最左一欄是初始化用例的參與者。穿越各欄的水平箭頭表示從一個(gè)對(duì)象發(fā)給另一個(gè)對(duì)象的消息或激勵(lì)。

打叉記號(hào)表示對(duì)象在退出時(shí)消亡，在具有打叉的交互中說明了實(shí)例的消亡。在表示對(duì)象的矩形與打叉記號(hào)之間，用虛線表示該對(duì)象可以接收消息的時(shí)間跨度。對(duì)象不可以接收打叉記號(hào)之下的消息。

順序圖中的第二欄表示與該對(duì)象交互的參與者初始化該用例的邊界對(duì)象。第三欄是管理其余用例的控制對(duì)象。1定義報(bào)告緊急情況用例,這一求精用斜體表示出來用例名報(bào)告緊急情況入口條件

現(xiàn)場(chǎng)工作人員激活火災(zāi)報(bào)警與調(diào)度系統(tǒng)終端上的“緊急情況報(bào)告”功能。事件流

1.火災(zāi)報(bào)警與調(diào)度系統(tǒng)做出響應(yīng)，提交一份報(bào)告給現(xiàn)場(chǎng)工作人員。該表格包括一個(gè)緊急情況類型菜單（普通災(zāi)害、火災(zāi)和交通事故）、事件發(fā)生的位置、事件描述、救援請(qǐng)求、危險(xiǎn)原料所處場(chǎng)所。

2.現(xiàn)場(chǎng)工作人員填寫表格，至少填寫緊急情況類型和描述?，F(xiàn)場(chǎng)工作人員也可能描述緊急情況的可能響應(yīng)要求和特殊救援要求。一旦填寫完表格，現(xiàn)場(chǎng)工作人員就按下“發(fā)送報(bào)告”按鈕，提交表格，這時(shí)就將通知到調(diào)度者。事件流3.調(diào)度者通過彈出的對(duì)話框注意到這一新的事件報(bào)告。調(diào)度者查看提交的信息，通過調(diào)用打開事件用例，在數(shù)據(jù)庫中創(chuàng)建一個(gè)事件。事件里面自動(dòng)包括了現(xiàn)場(chǎng)工作人員提交表格中的所有信息。調(diào)度者選擇響應(yīng)后，將分配救援資源給事件（用分配資源用例），通過發(fā)送短消息給現(xiàn)場(chǎng)工作人員以確認(rèn)收到了報(bào)告。該確認(rèn)告知現(xiàn)場(chǎng)工作人員，緊急情況報(bào)告已經(jīng)收到，創(chuàng)建了一個(gè)事件，并將資源分配給了該事件。該確認(rèn)包括了資源（例如，一輛消防車），以及這些資源將預(yù)期到達(dá)的時(shí)間。

出口條件

現(xiàn)場(chǎng)工作人員收到確認(rèn)消息并做出響應(yīng)。報(bào)告緊急情況用例的對(duì)象

確認(rèn)調(diào)度者對(duì)現(xiàn)場(chǎng)工作人員的緊急情況報(bào)告進(jìn)行響應(yīng)。通過發(fā)送一個(gè)確認(rèn)，調(diào)度者與現(xiàn)場(chǎng)工作人員進(jìn)行交流，報(bào)告已經(jīng)收到的緊急情況報(bào)告，創(chuàng)建一個(gè)事件，并給該資源分配了資源。該確認(rèn)包含了分配的資源，以及其估計(jì)的到達(dá)時(shí)間。通過構(gòu)造順序圖，我們不僅建模了對(duì)象之間的交互順序，同時(shí)我們也將功能分配給該用例。注意到穿過兩個(gè)或多個(gè)用例且被共享的一個(gè)對(duì)象定義，應(yīng)該被標(biāo)識(shí)出來；即如果一個(gè)操作出現(xiàn)在不止一個(gè)順序圖中時(shí)，其行為應(yīng)該是相同的。在分析中，順序圖可幫助開發(fā)者標(biāo)識(shí)出新的參與對(duì)象和丟失行為。因?yàn)轫樞驁D將關(guān)注點(diǎn)放在高層行為上，諸如性能之類的實(shí)現(xiàn)問題不應(yīng)該在這一層面上考慮和解決。畫出順序圖的啟發(fā)式準(zhǔn)則順序圖的第一欄對(duì)應(yīng)初始化該用例的參與者；順序圖的第二欄是邊界對(duì)象（即該參與者用于初始化該用例）；順序圖的第三欄是管理其余用例的控制對(duì)象；通過邊界對(duì)象初始化用例，以創(chuàng)建控制對(duì)象；通過控制對(duì)象創(chuàng)建邊界對(duì)象；實(shí)體對(duì)象可由控制對(duì)象和邊界對(duì)象進(jìn)行訪問；實(shí)體對(duì)象永遠(yuǎn)不會(huì)訪問邊界對(duì)象和控制對(duì)象；這使得通過用例共享實(shí)體對(duì)象變得容易。5.使用CRC卡建模對(duì)象之間的交互

標(biāo)識(shí)對(duì)象之間交互的一種選擇，是由Beck和Cunningham等人于1989年提出的CRC卡。CRC是類、責(zé)任和協(xié)作的縮寫。每一個(gè)類使用一個(gè)CRC卡表示。類的名字在CRC卡的頂端表示，其責(zé)任在左欄表示；為了完成其責(zé)任，所需要的類名字在右欄中表示。圖9.25表示了兩張報(bào)告意外事件控制類和事件類的CRC卡。CRC卡在團(tuán)隊(duì)建模過程中使用。CRC卡與順序圖的比較：對(duì)一個(gè)單獨(dú)的建模者而言，或