第4章需求獲取

第四章需求獲取

4.1軟件需求的初始表示

4.2需求獲取的過程模型

4.3定義軟件問題4.4創(chuàng)建框架用例4.5精化用例4.6評(píng)審用例模型

2023/2/41第四章需求獲取目標(biāo)完整地收集、整理利益相關(guān)方對(duì)目標(biāo)軟件系統(tǒng)的需求，并以其容易理解的業(yè)務(wù)語言闡述這些需求，形成文檔意義需求獲取是需求工程中后續(xù)活動(dòng)的基礎(chǔ)，需求工程又是后續(xù)軟件開發(fā)活動(dòng)的基礎(chǔ)需求獲取對(duì)于軟件項(xiàng)目的成敗具有決定性影響主要完成者是來自軟件開發(fā)方的需求工程師其他參與者來自委托方或投資方的客戶來自使用方的用戶項(xiàng)目軟件經(jīng)理和質(zhì)量保證工程師2023/2/42需求獲取需求獲取活動(dòng)的輸入制品包括：有關(guān)項(xiàng)目目標(biāo)、范圍及價(jià)值的概述性文檔項(xiàng)目合同或任務(wù)書經(jīng)評(píng)審?fù)ㄟ^的本次需求工程迭代的工作計(jì)劃。其輸出制品：描述軟件需求的初步的需求模型。該模型經(jīng)過需求分析后將進(jìn)化為正式的需求模型并成為需求規(guī)約的主要組成部分。2023/2/434.1軟件需求的初始表示本節(jié)介紹軟件需求的用例和用例的初始表示。

在需求獲取過程中用到的UML圖形機(jī)制主要是用例圖、類圖與活動(dòng)圖。2023/2/444.1.1用例（一）用例的概念從外部用戶的視角看是參與者(actor)與目標(biāo)軟件系統(tǒng)之間一次典型的交互作用，其效果就是參與者在軟件系統(tǒng)的幫助下完成了某項(xiàng)業(yè)務(wù)功能，或達(dá)成了某項(xiàng)業(yè)務(wù)目標(biāo)。從軟件系統(tǒng)內(nèi)部的視角看用例代表著系統(tǒng)執(zhí)行的一系列動(dòng)作，動(dòng)作執(zhí)行的結(jié)果能夠被外部的參與者所察覺。2023/2/45用例如果多個(gè)用戶在使用目標(biāo)軟件系統(tǒng)時(shí)扮演同一角色，這些用戶用單一參與者表示。如果一個(gè)用戶扮演多種角色，則需要用多個(gè)參與者來表示同一用戶。參與者可以是一類用戶，也可以是其他軟件系統(tǒng)或物理設(shè)備。2023/2/46參與者也叫執(zhí)行者（教材所用術(shù)語）、外部參與者是指外部用戶或外部實(shí)體交互過程中扮演的角色，它與軟件系統(tǒng)交換信息（并使用本系統(tǒng)的功能）用例例如，在課程注冊(cè)管理系統(tǒng)中，主要的參與者有：“Registrar”（教務(wù)管理員）“Student”（學(xué)生）、“Teacher”（任課教師）“BillingSystem”（收費(fèi)系統(tǒng)）在實(shí)際應(yīng)用中，有些用例不由任何物理實(shí)體觸發(fā)，而是由時(shí)間或外部事件來觸發(fā)，此時(shí)可設(shè)置定時(shí)器（Timer）或事件發(fā)送者作為參與者。例如，如果要求在每學(xué)期第一周的星期日自動(dòng)觸發(fā)“匯總選課計(jì)劃”用例，那么該用例的參與者應(yīng)為定時(shí)器。2023/2/47用例相對(duì)獨(dú)立性和完整性是用例必備的兩項(xiàng)特征即，用例表示參與者為達(dá)成一項(xiàng)相對(duì)獨(dú)立、完整的業(yè)務(wù)目標(biāo)而與目標(biāo)軟件系統(tǒng)協(xié)同完成的功能。為了清晰地描述這種外部可見功能，用例往往進(jìn)一步表示為參與者與軟件系統(tǒng)之間的交互動(dòng)作序列。對(duì)于參與者而言，這些交互的目的或者效果在于達(dá)成其業(yè)務(wù)目標(biāo)；對(duì)于待開發(fā)的軟件系統(tǒng)而言，交互的過程即是該項(xiàng)外部可見功能的使用過程。例如，課程注冊(cè)管理系統(tǒng)中的用例有：供教務(wù)管理員使用的“制訂課表”用例、供教務(wù)管理員、學(xué)生和教師使用的“查詢課表及課程信息”用例，供學(xué)生使用的“制訂選課計(jì)劃”用例，供教師使用的“查詢選課學(xué)生信息”用例等。2023/2/48用例（二）用例與軟件需求之間的關(guān)系根據(jù)用例的定義易知，用例是功能性軟件需求的主體部分。在用例驅(qū)動(dòng)的需求工程中，用例描述將占據(jù)需求獲取結(jié)果文檔的大部分篇幅。全局性的業(yè)務(wù)規(guī)則、大部分非功能性的軟件需求并不適于在用例中描述。某些僅作用于單個(gè)或少數(shù)用例的業(yè)務(wù)規(guī)則可以直接在用例描述中出現(xiàn)。僅約束單個(gè)或少數(shù)用例的非功能性需求也可以在用例描述中闡明。2023/2/49用例（三）框架用例框架用例是指宏觀功能已基本明確但內(nèi)容尚不完整的用例。引入框架用例的概念是為了滿足需求獲取過程中記錄、表示細(xì)節(jié)尚未完全確定的用例的需要。2023/2/4104.1.2用例圖UML的用例模型由一到多幅用例圖構(gòu)成，它們表示從軟件系統(tǒng)的外部使用者的角度看到的各項(xiàng)系統(tǒng)功能，并清晰地說明軟件系統(tǒng)的邊界，即，用例圖中的所有用例的集合構(gòu)成目標(biāo)軟件系統(tǒng)應(yīng)該提供的功能，除此之外軟件系統(tǒng)不再承諾其他功能。2023/2/411圖4.1課程注冊(cè)管理系統(tǒng)的用例圖2023/2/412（一）參與者與用例之間的關(guān)系參與者與用例之間的關(guān)系在用例圖中表示為它們之間的連接邊，其意義為：參與者觸發(fā)用例的執(zhí)行，向用例提供信息或者從用例獲取信息。觸發(fā)用例執(zhí)行的參與者稱為主動(dòng)參與者，僅從用例獲取信息的參與者稱為被動(dòng)參與者。參與者與用例之間的連接邊通常為無向邊。僅在以下兩種情形下才考慮采用有向邊：當(dāng)有多個(gè)參與者與用例相連時(shí)，有時(shí)為了強(qiáng)調(diào)其中某個(gè)參與者是該用例的主要參與者（primaryactor），則從該參與者到用例之間連一條有向邊。在這種有向邊之上，信息傳遞仍可能是雙向的。參與者需要提供初始信息以啟動(dòng)用例，用例的執(zhí)行結(jié)果也可反饋至參與者。為了強(qiáng)調(diào)被動(dòng)參與者僅從用例獲取信息，而不向用例提供信息，可以從用例到被動(dòng)參與者之間連一條有向邊。2023/2/413（二）用例之間的關(guān)系用例之間的關(guān)系主要有三種：包含（include）、擴(kuò)展（extend）和繼承

。包含關(guān)系：如果B是A的某項(xiàng)子功能，并且建模者確切地知道在A所對(duì)應(yīng)的動(dòng)作序列中何時(shí)將調(diào)用B，則稱用例A包含用例B。包含關(guān)系經(jīng)常被用來將多個(gè)用例中公共的子功能項(xiàng)提取出來，以避免重復(fù)和冗余。例如，在課程注冊(cè)管理系統(tǒng)中，除“匯總選課計(jì)劃”外的其他用例均要求驗(yàn)證用戶的身份，可將此子功能表示為“用戶身份驗(yàn)證”用例，并在原用例與此用例之間建立包含關(guān)系，見圖4.1。2023/2/414擴(kuò)展關(guān)系如果A與B相似，但A的功能較B多，A的動(dòng)作序列是通過在B的動(dòng)作序列中的某些執(zhí)行點(diǎn)上插入附加的動(dòng)作序列而構(gòu)成的，則稱用例A擴(kuò)展用例B。在擴(kuò)展用例的情形下，允許建模者不確定何時(shí)會(huì)出現(xiàn)導(dǎo)致附加動(dòng)作序列必須執(zhí)行的情況，甚至不確定這些情況是否會(huì)發(fā)生。A的附加動(dòng)作在B的動(dòng)作序列中的插入點(diǎn)稱為A對(duì)B的擴(kuò)展點(diǎn)。擴(kuò)展關(guān)系經(jīng)常用來區(qū)隔

正常的業(yè)務(wù)處理功能和帶有例外處理的功能，這樣可避免例外處理邏輯攪亂或湮滅

正常處理邏輯。例如，假定在課程注冊(cè)管理系統(tǒng)中每門課程設(shè)置所容納的學(xué)生數(shù)量有限制，一旦超出限制需經(jīng)任課教師同意?？稍O(shè)置“制訂選課計(jì)劃[考慮學(xué)生數(shù)量限制]”用例，并將其作為“制訂選課計(jì)劃”的擴(kuò)展用例，見圖4.1。2023/2/415繼承關(guān)系如果A與B相似，但A的動(dòng)作序列是通過改寫B(tài)的部分動(dòng)作或者擴(kuò)展B的部分動(dòng)作而獲得的，則稱用例A繼承用例B。用例之間的繼承關(guān)系同樣須符合針對(duì)類間繼承關(guān)系的可替代性原則：任何特化用例都可應(yīng)用于其泛化用例能夠應(yīng)用的場(chǎng)合。繼承關(guān)系與擴(kuò)展關(guān)系非常類似，在面對(duì)實(shí)際問題時(shí)，可按以下規(guī)則來決定二者的取舍：如果能夠指出明確的擴(kuò)展點(diǎn)，則采用擴(kuò)展關(guān)系；如果希望區(qū)隔正常的業(yè)務(wù)處理功能和帶有例外處理的功能，應(yīng)采用擴(kuò)展關(guān)系；如果不僅要插入新動(dòng)作，而且要修改原動(dòng)作，則采用繼承關(guān)系。如，假定在課程注冊(cè)管理系統(tǒng)中，要求每名學(xué)生選修的課程的總學(xué)時(shí)數(shù)不得超出指定的限額，但對(duì)優(yōu)異生（ExcellentStudent），此限額可以放寬，那么可設(shè)置“制訂優(yōu)異生選課計(jì)劃”用例，并讓其繼承“制訂選課計(jì)劃[考慮學(xué)生數(shù)量限制]”用例，見圖4.12023/2/416用例之間的關(guān)系為避免語義上的復(fù)雜性，用例之間的關(guān)系不應(yīng)超過兩層。例如，如果用例A、B、C、D之間依次兩兩之間都有包含關(guān)系，則表明建模者采用了功能分解方法，這與用例建模所處的需求工程階段不協(xié)調(diào)，也不符合面向?qū)ο蟮乃季S方式。在用例圖中，每個(gè)參與者必須至少與一個(gè)用例相關(guān)聯(lián)；反之，除被包含、被擴(kuò)展的用例外，每個(gè)用例必經(jīng)至少與一個(gè)參與者相關(guān)聯(lián)。如果一個(gè)參與者未與任何用例相關(guān)聯(lián)，那么它就沒有必要在用例圖中出現(xiàn)。如果被繼承的用例未與任何參與者相關(guān)聯(lián)，那么應(yīng)該將它與其（用例繼承意義上的）特化用例合并。2023/2/417用例之間的關(guān)系（三）參與者之間的關(guān)系繼承關(guān)系其意義與面向?qū)ο笾谢镜睦^承關(guān)系相似，但它主要強(qiáng)調(diào)子類參與者對(duì)父類參與者與用例之間的交互行為的繼承。如果參與者B繼承參與者A，A觸發(fā)執(zhí)行用例UC，那么B與UC之間的觸發(fā)執(zhí)行關(guān)系即不必顯式表示。例如，在圖4.1中，參與者“ExcellentStudent”隱含地觸發(fā)執(zhí)行“查詢課表及課程信息”用例，但是，它與“制訂選課計(jì)劃”用例及其擴(kuò)展用例“制訂選課計(jì)劃[考慮學(xué)生數(shù)量限制]”之間并無觸發(fā)執(zhí)行關(guān)系，因?yàn)樗苯佑|發(fā)后者的特化用例“制訂優(yōu)異生選課計(jì)劃”。2023/2/418用例之間的關(guān)系（四）布局規(guī)則用例圖的布局攸關(guān)其可理解性。建議讀者采納以下布局規(guī)則：主要的參與者應(yīng)置于用例圖的左上區(qū)域。觸發(fā)用例執(zhí)行的主動(dòng)參與者應(yīng)位于用例的左面，接收用例產(chǎn)生的信息的被動(dòng)參與者應(yīng)置于用例的右面。多個(gè)用例沿垂直方向排列。如果用例A的執(zhí)行時(shí)間一定在B之前，那么最好將A置于B之上。在水平方向繪制包含關(guān)系，并將被包含的用例置于包含用例的右側(cè)。在垂直方向繪制擴(kuò)展和繼承關(guān)系，并將擴(kuò)展用例置于被擴(kuò)展用例的下方。將繼承用例置于被繼承用例的下方。2023/2/4194.1.3用例的表示在用例圖中，限于版面，只能標(biāo)示每個(gè)用例的名稱，不可能精確地描述用例的功能、參與者與用例之間的信息流、交互動(dòng)作序列等。有必要針對(duì)用例圖中的每個(gè)用例，給出文檔化的描述，內(nèi)容包括：用例名稱用例的功能或其業(yè)務(wù)目標(biāo)與用例有關(guān)的參與者用例執(zhí)行的觸發(fā)條件（可選）用例執(zhí)行的前置條件（可選）基本交互動(dòng)作過程擴(kuò)展交互動(dòng)作過程（可選）用例執(zhí)行完畢時(shí)的后置條件（可選）業(yè)務(wù)規(guī)則（可選）非功能需求（可選）2023/2/4202023/2/4214.1.4類圖類圖描述面向?qū)ο筌浖到y(tǒng)的靜態(tài)結(jié)構(gòu)。類圖的結(jié)點(diǎn)表示系統(tǒng)中的類及其屬性和操作類圖的邊表示類之間的關(guān)系。在需求獲取或業(yè)務(wù)理解的過程中，類圖可用于表達(dá)領(lǐng)域概念模型，即業(yè)務(wù)領(lǐng)域中的概念及概念之間的關(guān)系；在需求分析階段，類圖可用來表示軟件需求模型之靜態(tài)結(jié)構(gòu)部分；在軟件設(shè)計(jì)和實(shí)現(xiàn)階段，類圖表示軟件的結(jié)構(gòu)及詳細(xì)設(shè)計(jì)。類圖的構(gòu)造在面向?qū)ο蠓治雠c設(shè)計(jì)過程中處于核心地位。2023/2/422圖4.2課程注冊(cè)管理系統(tǒng)的類圖2023/2/423（一）類類的屬性在UML中表示為：[可見性]名稱[:類型][多重性][=初值][{約束特性}]類的操作在UML中表示為：[可見性]名稱[(參數(shù)表)][:返回類型][{約束特性}]其中處于“[”與“]”之間的語法成分是可選項(xiàng)。在需求工程階段，為聚焦于需求的獲取和分析并保持需求模型的簡(jiǎn)潔性，在不是特別必要的情況下并不關(guān)心這些可選項(xiàng)，也不必在需求模型中示出。2023/2/424（a）最簡(jiǎn)化的類圖元（隱藏屬性和操作部分）（b）隱藏操作部分的類圖元（c）隱藏屬性部分的類圖元（d）完整的類圖元2023/2/425圖4.3

類的表示圖元（二）類之間的關(guān)系除面向?qū)ο蠡靖拍钪械睦^承和聚合外，UML還可以表示類之間的關(guān)聯(lián)、依賴和實(shí)現(xiàn)關(guān)系。UML將聚合關(guān)系進(jìn)一步細(xì)分為（一般）聚合和組合兩種。它們的表示圖元如圖4.4所示。

（a）關(guān)聯(lián)關(guān)系的表示2023/2/426

（b）聚合關(guān)系的表示（b）聚合關(guān)系的表示圖4.4類間關(guān)系的表示圖元2023/2/427c）組合關(guān)系的表示（d）依賴關(guān)系的表示（e）實(shí)現(xiàn)關(guān)系的表示（f）繼承關(guān)系的表示關(guān)聯(lián)關(guān)系表示兩個(gè)類之間迥異于繼承關(guān)系的一種語義上、邏輯上的聯(lián)系。在代碼中表現(xiàn)為：在A類中有一個(gè)成員變量，變量的類型是B類聚合關(guān)系是關(guān)聯(lián)關(guān)系之一種。如，在“學(xué)生”與“老師”之間存在一種既非繼承、也非聚合的語義關(guān)聯(lián)，因?yàn)橐幻麑W(xué)生可能選修某名老師所開的課程設(shè)置。在關(guān)聯(lián)關(guān)系的表示圖元的兩端，可以標(biāo)示參與關(guān)聯(lián)的多重性（multiplicity）、角色名和約束特性。2023/2/428類之間的關(guān)系類之間的關(guān)系（1）多重性說明位于關(guān)聯(lián)端的類可以有多少個(gè)實(shí)例對(duì)象與另一端的類的單個(gè)實(shí)例對(duì)象相聯(lián)系，它表示參與關(guān)聯(lián)的兩個(gè)類的對(duì)象之間的數(shù)量對(duì)應(yīng)關(guān)系。UML的多重性表示符有：

1，0..1（0或者1個(gè)），0..*（0到任意多個(gè)），1..*（1到任意多個(gè)），*（與0..*相同），

m..n（m到n個(gè)，要求m<n），n..*（n到任意多個(gè)）等。如，在圖4.2中，每名學(xué)生可選0到多門課程設(shè)置，每門課程設(shè)置可以容納0到多名學(xué)生。多重性的后兩種表示符涉及到具體的數(shù)量上下界，這樣雖然可以在可視化模型中直接體現(xiàn)相關(guān)的業(yè)務(wù)規(guī)則，但是一旦規(guī)則改變，模型即須修改，所以本書并不推薦此種用法。具體的數(shù)量限制規(guī)則在類圖的伴隨文檔中描述即可，不必直接標(biāo)定于UML模型圖之中。2023/2/429類之間的關(guān)系（2）角色名描述參與關(guān)聯(lián)的類的對(duì)象在關(guān)聯(lián)關(guān)系中扮演的角色或發(fā)揮的作用。例如，在“學(xué)生”與“教師”之間的關(guān)聯(lián)中，前者扮演“學(xué)習(xí)者”的角色，后者扮演“知識(shí)傳授者”的角色。（3）約束特性說明針對(duì)參與關(guān)聯(lián)的對(duì)象或?qū)ο蠹倪壿嫾s束。在需求工程階段應(yīng)該直接采用自然語言來表示這種約束。例如，圖4.2中的“{ordered}”表示，如果一門課程設(shè)置有多位教師，那么他們之間是有序的，因?yàn)橹髦v教師必須排在助理教師之前。2023/2/430類之間的關(guān)系UML將面向?qū)ο笾械木酆细拍顓^(qū)分為（共享）聚合（aggregation）和組合（composition）兩種關(guān)系。在聚合關(guān)系下，作為部件類的對(duì)象可能是多個(gè)整體類的對(duì)象中的組成部分，比如一名學(xué)生可以同時(shí)參與多個(gè)興趣小組；在組合關(guān)系下，一個(gè)部件類的對(duì)象只能位于一個(gè)整體類的對(duì)象之中，一旦整體類對(duì)象消亡，其中包含的部件類對(duì)象也不能茍活。換句話說，整體類必須具備完整的管理部件類生命周期的職責(zé)。例如，根據(jù)圖4.2，如果一門“課程”被取消，那么，其中包含的所有“課程設(shè)置”對(duì)象均須刪除。2023/2/431UML表示法UML表示法類之間的關(guān)系假如A類的某個(gè)方法中，使用了B類，那么就說A類依賴于B類，它們是依賴關(guān)系。A類的某個(gè)方法使用B類，可能是方法的參數(shù)是B類，也可能是在方法中獲得了一個(gè)B類實(shí)例。但無論是哪種情況，B類在A類中都是以局部變量的形式存在的。依賴關(guān)系是有向的2023/2/432類之間的關(guān)系實(shí)現(xiàn)關(guān)系是一種特殊的依賴關(guān)系，它表示一個(gè)類實(shí)現(xiàn)了另一個(gè)類中定義的對(duì)外接口。2023/2/433類Circle、Rectangle實(shí)現(xiàn)了接口Shape的操作依賴和實(shí)現(xiàn)關(guān)系所處的抽象級(jí)別明顯低于繼承和關(guān)聯(lián)關(guān)系，它們與軟件需求的關(guān)系不大，但與詳細(xì)設(shè)計(jì)和軟件實(shí)現(xiàn)的關(guān)系較密切。所以，在需求工程中，尤其是在需求工程的早期，不必過多考慮依賴和實(shí)現(xiàn)關(guān)系。2023/2/434類之間的關(guān)系按照關(guān)聯(lián)關(guān)系的定義，聚合和組合都是一種特殊的關(guān)聯(lián)關(guān)系，只不過這種關(guān)聯(lián)具有明確的部分—整體含義而已。關(guān)聯(lián)和繼承都是依賴關(guān)系之一種，關(guān)聯(lián)和繼承之于依賴，相當(dāng)于聚合和組合之于關(guān)聯(lián)。從耦合度的角度看，繼承關(guān)系最強(qiáng)，組合次之，普通聚合再次之，除組合和聚合之外的普通關(guān)聯(lián)關(guān)系最弱。2023/2/435（三）關(guān)聯(lián)的方向關(guān)聯(lián)關(guān)系在分析模型中表示兩個(gè)類的邏輯聯(lián)系在設(shè)計(jì)模型和實(shí)現(xiàn)模型中，關(guān)聯(lián)的含義將以此為基礎(chǔ)逐步精化。設(shè)計(jì)模型中的關(guān)聯(lián)關(guān)系表示參與關(guān)聯(lián)的類必須具有查詢職責(zé)和關(guān)系維護(hù)職責(zé)。查詢職責(zé)是指，如果類A、B之間存在關(guān)聯(lián)，則A類應(yīng)負(fù)責(zé)針對(duì)任一A類的對(duì)象a查詢與a鏈接的所有B類的對(duì)象，并且B類也要負(fù)責(zé)提供反向的查詢功能。關(guān)系維護(hù)職責(zé)指，參與關(guān)聯(lián)的對(duì)象在其生命周期中的任意時(shí)刻均須維護(hù)它與位于另一關(guān)聯(lián)端的對(duì)象之間的鏈接。2023/2/436關(guān)聯(lián)的方向關(guān)聯(lián)可以有方向：有向關(guān)聯(lián)又稱為導(dǎo)航（Navigation），意義是：從一個(gè)關(guān)聯(lián)端（通過查詢操作）沿導(dǎo)航的方向可以到達(dá)另一端，反之則不行。如果類A、B之間的關(guān)聯(lián)是單向的，那么前述的對(duì)查詢職責(zé)、關(guān)系維護(hù)職責(zé)的要求便從對(duì)稱的雙向要求簡(jiǎn)化為單向要求，從而降低模型的復(fù)雜度。在分析模型中，并未考慮查詢職責(zé)和關(guān)系維護(hù)職責(zé)，因此不必急于確定關(guān)聯(lián)的方向。在設(shè)計(jì)模型中，必須完整地確定所有關(guān)聯(lián)的方向，因?yàn)閱蜗蜿P(guān)聯(lián)比雙向關(guān)聯(lián)要簡(jiǎn)單得多。經(jīng)推敲后認(rèn)為確有必要的雙向關(guān)聯(lián)仍可表示為無向關(guān)聯(lián)邊。2023/2/437（四）布局規(guī)則類圖往往是軟件模型圖中最復(fù)雜同時(shí)也最關(guān)鍵的一張UML視圖。為提高其可理解性，本書推薦以下布局規(guī)則：（1）盡量沿垂直方向表示繼承、實(shí)現(xiàn)關(guān)系，沿水平方向表示關(guān)聯(lián)、聚合、組合、依賴、實(shí)現(xiàn)關(guān)系。在繼承關(guān)系中，父類應(yīng)位于子類的上方；在單向關(guān)聯(lián)、依賴和實(shí)現(xiàn)關(guān)系中，方向盡量從左至右；在聚合、組合關(guān)系中，整體類一般位于部件類的左面。（2）在關(guān)聯(lián)邊上，多重性、角色名、約束特性等應(yīng)靠近關(guān)聯(lián)端。（3）如果多條邊表示相同種類的關(guān)系，它們有公共的類端點(diǎn)，并且在公共端的標(biāo)注相同，則匯合這些邊。例如，圖4.2將“用戶”與“教務(wù)管理員”、“教師”和“學(xué)生”之間的三條繼承邊匯合，布局成樹形結(jié)構(gòu)。2023/2/4384.1.5活動(dòng)圖活動(dòng)圖描述實(shí)體為完成某項(xiàng)功能而執(zhí)行的操作序列，其中的某些操作或者操作的子序列可以并發(fā)和同步?；顒?dòng)圖適合描述在沒有外部事件觸發(fā)的情況下的系統(tǒng)內(nèi)部的邏輯執(zhí)行過程；否則，狀態(tài)圖更容易描述。類似于傳統(tǒng)意義上的流程圖?；顒?dòng)圖主要用于：業(yè)務(wù)建模時(shí)，用于詳述業(yè)務(wù)用例，描述一項(xiàng)業(yè)務(wù)的執(zhí)行過程；設(shè)計(jì)時(shí)，描述操作的流程。在描繪對(duì)象之間的交互協(xié)作方面，活動(dòng)圖不如順序圖；在描繪對(duì)象的行為方面，活動(dòng)圖不如狀態(tài)圖。2023/2/439活動(dòng)圖事物活動(dòng)(ActionState)動(dòng)作的執(zhí)行起點(diǎn)(InitialState)活動(dòng)圖的開始終點(diǎn)(FinalState)活動(dòng)圖的終點(diǎn)對(duì)象流(ObjectFlowState)活動(dòng)之間的交換的信息發(fā)送信號(hào)(signalSending)活動(dòng)過程中發(fā)送事件，觸發(fā)另一活動(dòng)流程接收信號(hào)(SignalReceipt)活動(dòng)過程中接收事件，接收到信號(hào)的活動(dòng)流程開始執(zhí)行泳道(SwimLane)活動(dòng)的負(fù)責(zé)者活動(dòng)圖關(guān)系遷移(transition)活動(dòng)的完成與新活動(dòng)的開始分支(junctionpoint)根據(jù)條件，控制執(zhí)行方向分叉(fork)以下的活動(dòng)可并發(fā)執(zhí)行結(jié)合(join)以上的并發(fā)活動(dòng)再此結(jié)合圖4.5“制訂課表”用例的活動(dòng)圖2023/2/442圖4.5五種類型的活動(dòng)圖節(jié)點(diǎn)下面結(jié)合此圖描述活動(dòng)圖的建模機(jī)制。⑴活動(dòng)（activity）計(jì)算過程的抽象表示，它或者是一個(gè)基本的計(jì)算步驟，或由一系列基本的計(jì)算步驟和子活動(dòng)構(gòu)成。

如，圖4.5中包含的活動(dòng)有“驗(yàn)證用戶名和密碼”、“添加課程設(shè)置”、“修改課程設(shè)置”、“發(fā)布課表”等。⑵決策點(diǎn)（decisionpoint）

當(dāng)?shù)竭_(dá)邊為一條、離開邊有多條時(shí)，決策點(diǎn)包含監(jiān)護(hù)條件，它表示經(jīng)條件判斷后從多條后續(xù)的處理路徑中選擇一條路徑繼續(xù)推進(jìn)；

當(dāng)?shù)竭_(dá)邊有多條、離開邊為一條時(shí)，決策點(diǎn)不包含條件，它表示，只要控制流沿其中一條邊到達(dá)，則處理流程沿離開邊繼續(xù)推進(jìn)，并不等待其他到達(dá)邊上的控制流。2023/2/443兩種活動(dòng)圖的邊在決策點(diǎn)的后一種情況下，決策點(diǎn)可以省略（隱藏），直接將多條到達(dá)決策點(diǎn)的有向邊越過決策點(diǎn)指向決策點(diǎn)的后繼節(jié)點(diǎn)?？梢栽跊Q策點(diǎn)內(nèi)部或附近直接標(biāo)注條件，也可以將條件分別標(biāo)注在從決策點(diǎn)出發(fā)的多條邊上，甚至可以省略（實(shí)際上是隱藏）決策點(diǎn)，直接從前一節(jié)點(diǎn)引出多條有向邊，在每條邊上標(biāo)注條件。圖4.5包含兩個(gè)決策點(diǎn)。2023/2/444兩種活動(dòng)圖的邊⑶并發(fā)控制：表示控制流經(jīng)此節(jié)點(diǎn)后分叉成多條可并行執(zhí)行的控制流，或者多條并行控制流經(jīng)此節(jié)點(diǎn)后同步合并為單條控制流。這兩種情形依次稱為分叉（fork）和匯合（join）。前者的到達(dá)邊為一條，離開邊有多條，后者剛好相反。分叉/匯合節(jié)點(diǎn)的示例請(qǐng)見圖4.8。⑷對(duì)象：表示活動(dòng)需要輸入的對(duì)象或者作為活動(dòng)的處理結(jié)果輸出的對(duì)象。如果同一個(gè)對(duì)象在活動(dòng)圖中出現(xiàn)多次，但其狀態(tài)（或者屬性值）隨處理流程的推進(jìn)而發(fā)生變化，則需要在對(duì)象名稱后附以不同的狀態(tài)名來區(qū)分它們。2023/2/445兩種活動(dòng)圖的邊⑴控制流：連接在兩個(gè)非對(duì)象節(jié)點(diǎn)之間的有向邊，表示處理流程的順序推進(jìn)。⑵對(duì)象流：從對(duì)象節(jié)點(diǎn)指向活動(dòng)節(jié)點(diǎn)的有向邊表示將對(duì)象作為輸入數(shù)據(jù)傳入活動(dòng)；從活動(dòng)節(jié)點(diǎn)指向?qū)ο蠊?jié)點(diǎn)的有向邊表示對(duì)象是活動(dòng)的輸出數(shù)據(jù)。2023/2/4462023/2/447活動(dòng)圖活動(dòng)圖的泳道機(jī)制指，將活動(dòng)圖用形如游泳池中的泳道分成數(shù)個(gè)活動(dòng)區(qū)，每個(gè)區(qū)由一個(gè)對(duì)象或一個(gè)控制線程負(fù)責(zé)。這樣表示的活動(dòng)圖也稱泳道圖。每個(gè)活動(dòng)節(jié)點(diǎn)應(yīng)位于負(fù)責(zé)執(zhí)行該活動(dòng)的對(duì)象或線程所在的區(qū)域內(nèi)。帶泳道的活動(dòng)圖清晰地表示了對(duì)象或線程的職責(zé)、它們之間的分工、協(xié)同和同步。如，圖4.5包含三條泳道，從左至右依次由RegistrarUI、LoginManager和CurriculumManager三個(gè)對(duì)象負(fù)責(zé)。2023/2/448活動(dòng)圖活動(dòng)圖可包含初始節(jié)點(diǎn)和終止結(jié)點(diǎn)。初始節(jié)點(diǎn)的含義是，通過一條簡(jiǎn)單的有向邊指明進(jìn)入活動(dòng)圖時(shí)首個(gè)被執(zhí)行的活動(dòng)。終止節(jié)點(diǎn)表示整個(gè)活動(dòng)圖執(zhí)行完畢。每張活動(dòng)圖都應(yīng)該有唯一的初始節(jié)點(diǎn)。表示持續(xù)過程的活動(dòng)圖可以沒有終止結(jié)點(diǎn)；其他情況下，每張活動(dòng)圖至少應(yīng)包含一個(gè)終止結(jié)點(diǎn)。2023/2/4494.2需求獲取的過程模型在需求獲取階段之初，需求工程師必須學(xué)習(xí)并理解與軟件問題相關(guān)的業(yè)務(wù)知識(shí)，研究其業(yè)務(wù)背景、理解業(yè)務(wù)術(shù)語、領(lǐng)域概念及業(yè)務(wù)流程，在此基礎(chǔ)上對(duì)待解的軟件問題進(jìn)行定義定義軟件系統(tǒng)的業(yè)務(wù)目標(biāo)、業(yè)務(wù)范圍與邊界，明確其業(yè)務(wù)價(jià)值。在定義軟件問題之后，接下來應(yīng)該通過各種信息渠道獲取并記錄軟件需求。UML的用例和用例圖是表示需求的最恰當(dāng)工具之一。2023/2/450用例表示的需求：用例描述中包含交互動(dòng)作序列等細(xì)節(jié)性信息。對(duì)于大中型軟件系統(tǒng)，首先關(guān)注整體和全局，然后再逐步添加細(xì)節(jié)。為避免需求工程師過早陷入細(xì)節(jié)，本書將表示軟件需求的用例的創(chuàng)立和細(xì)化進(jìn)一步劃分為創(chuàng)建框架用例、精化框架用例兩項(xiàng)活動(dòng)。創(chuàng)建框架用例試圖通過若干框架用例盡可能完整地覆蓋需求精化框架用例是在已經(jīng)建立的框架用例的基礎(chǔ)上填充細(xì)節(jié)使每個(gè)框架用例進(jìn)化為完整的用例。再將這些用例匯聚在一起，系統(tǒng)地研究各種優(yōu)化方案的可能性并實(shí)施優(yōu)化。例如，將業(yè)務(wù)上相關(guān)或者功能上相似的多個(gè)小規(guī)模用例合并為一個(gè)用例，通過用例之間的包含關(guān)系合并多個(gè)用例中的公共子過程，等。精化后的用例及用例圖構(gòu)成可供評(píng)審的用例模型，它是需求模型的最初形態(tài)。2023/2/451需求工程師應(yīng)該邀請(qǐng)利益相關(guān)方、業(yè)務(wù)領(lǐng)域?qū)＜摇㈨?xiàng)目軟件經(jīng)理和質(zhì)量保證工程師等參與針對(duì)的用例模型的評(píng)審，發(fā)現(xiàn)問題并進(jìn)行相應(yīng)的改正或改進(jìn)。評(píng)審的主要關(guān)注點(diǎn)是用例模型的正確性、精確性、一致性和完整性。2023/2/452需求獲取的過程模型用例驅(qū)動(dòng)（usecasedriven）的需求獲取過程，主要步驟（活動(dòng)）如下：⑴定義軟件問題；⑵創(chuàng)建框架用例；⑶精化用例；⑷評(píng)審用例模型。這些步驟可按序組織為需求獲取工作流。圖4.6需求獲取工作流2023/2/4534.3定義軟件問題定義軟件問題活動(dòng)的目標(biāo)是：

理解軟件要解決的主要業(yè)務(wù)問題、業(yè)務(wù)背景，盡量消除需求工程師與用戶之間的交流障礙；明確待開發(fā)軟件系統(tǒng)的目標(biāo)、業(yè)務(wù)價(jià)值、范圍及邊界。定義軟件問題過程如下：⑴標(biāo)識(shí)客戶和用戶；⑵理解業(yè)務(wù)背景；⑶策劃并實(shí)施需求調(diào)查；⑷定義軟件系統(tǒng)的輪廓，包括其目標(biāo)、業(yè)務(wù)價(jià)值、范圍及邊界。2023/2/4544.3.1標(biāo)識(shí)客戶和用戶有兩種情形需要考慮：⑴當(dāng)軟件系統(tǒng)是專門為特定的使用方度身定制、使用方即是投資方時(shí)。建議需求工程師索取用戶的完整組織機(jī)構(gòu)圖?；诮M織機(jī)構(gòu)考慮以下幾種用戶：①用戶機(jī)構(gòu)中第一負(fù)責(zé)人或授權(quán)的信息化主管，及軟件系統(tǒng)所處理的業(yè)務(wù)部門負(fù)責(zé)人。②軟件系統(tǒng)所處理的業(yè)務(wù)的相關(guān)部門中的業(yè)務(wù)操作員工。③軟件應(yīng)用過程中負(fù)責(zé)系統(tǒng)配置、基本維護(hù)和技術(shù)支援的用戶（往往是用戶組織機(jī)構(gòu)中信息中心之類的部門）2023/2/455標(biāo)識(shí)客戶和用戶⑵如果軟件產(chǎn)品面向目前尚不能具體確定的用戶（群），開發(fā)完成后交由軟件項(xiàng)目的投資方進(jìn)行市場(chǎng)推廣，建議考慮以下幾種客戶和用戶：①投資方中為本項(xiàng)目提供資源的負(fù)責(zé)人。其角色和作用類似于⑴中第一種用戶。②投資方中負(fù)責(zé)策劃、構(gòu)思本軟件產(chǎn)品的人員。其作用和角色類似于⑴中第二、三種用戶的總和。③投資方中負(fù)責(zé)推廣、銷售本軟件產(chǎn)品的市場(chǎng)營(yíng)銷人員。他們是確立軟件產(chǎn)品的定位、特色的主要信息源。④如果軟件產(chǎn)品的最終用戶是個(gè)體，則應(yīng)考慮邀請(qǐng)有代表性的用戶參與需求獲取活動(dòng)，向其征詢各類需求并請(qǐng)其參與需求驗(yàn)證；如果軟件產(chǎn)品的最終用戶是組織機(jī)構(gòu)，則應(yīng)考慮邀請(qǐng)有代表性的組織機(jī)構(gòu)中如⑴所述的三類用戶代表參與需求獲取和需求驗(yàn)證。2023/2/456標(biāo)識(shí)客戶和用戶例4.1客戶和用戶的標(biāo)識(shí)家庭保安系統(tǒng)屬于第二種情形。其需求來源包括來自投資方的負(fù)責(zé)人、產(chǎn)品策劃者、銷售代表以及最終用戶代表。2023/2/4574.3.2理解業(yè)務(wù)背景目標(biāo)：獲得與用戶有效溝通所必備的業(yè)務(wù)知識(shí)，以提高后續(xù)的需求獲取、分析活動(dòng)的效率。獲取與目標(biāo)軟件相關(guān)的事實(shí)和假設(shè)。

方法：①獲取有價(jià)值的業(yè)務(wù)文檔。有價(jià)值的業(yè)務(wù)文檔是指對(duì)需求工程師理解業(yè)務(wù)背景、業(yè)務(wù)術(shù)語、用戶需求有所幫助的文檔，例如相關(guān)的管理制度、業(yè)務(wù)操作規(guī)范、遺留應(yīng)用系統(tǒng)的用戶文檔（例如用戶手冊(cè)、需求規(guī)約）等。②觀察并研究用戶目前（人工）業(yè)務(wù)處理流程；在系統(tǒng)工程師的幫助下研究軟件與系統(tǒng)中其他部件的協(xié)同處理流程。③關(guān)注相似或相關(guān)的現(xiàn)有軟件，思考以下問題：現(xiàn)有軟件可否在當(dāng)前軟件項(xiàng)目中直接使用？如何在當(dāng)前軟件項(xiàng)目的需求工程和軟件設(shè)計(jì)階段借鑒該軟件？2023/2/458④采用UML的類圖表示業(yè)務(wù)術(shù)語及其關(guān)系（又稱領(lǐng)域概念模型），采用UML活動(dòng)圖表示業(yè)務(wù)處理流程。⑤在研究業(yè)務(wù)背景以及與用戶交互的過程中，關(guān)注并文檔化那些對(duì)目標(biāo)軟件的定位和開發(fā)可能產(chǎn)生影響的各種外部因素，包括假設(shè)和既成事實(shí)。例如，對(duì)用戶計(jì)算機(jī)操作能力和外部系統(tǒng)性能的假設(shè)將影響軟件界面和對(duì)外接口的設(shè)計(jì)。2023/2/459例4.2領(lǐng)域概念模型與業(yè)務(wù)流程針對(duì)家庭保安系統(tǒng)，“傳感器”、“警報(bào)器”、“報(bào)警電話”和“異常事件”是全局性關(guān)鍵概念。引進(jìn)虛擬的“監(jiān)測(cè)器“概念是為了將前者與后三種概念聯(lián)系起來，引進(jìn)“門窗傳感器”和“煙霧傳感器”是為了探測(cè)“非法進(jìn)入”和“火災(zāi)”兩種異常情形。家庭保安系統(tǒng)的領(lǐng)域概念模型如圖4.7所示。家庭保安系統(tǒng)中與傳感器監(jiān)測(cè)相關(guān)的業(yè)務(wù)處理流程如圖4.8所示。2023/2/460圖4.7家庭保安系統(tǒng)的領(lǐng)域概念模型（初步）2023/2/461圖4.8家庭保安系統(tǒng)的

業(yè)務(wù)處理流程\局部2023/2/4國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院624.3.3策劃并實(shí)施需求調(diào)查需求調(diào)查的任務(wù)：理解軟件問題及業(yè)務(wù)背景，確定軟件系統(tǒng)的目標(biāo)、范圍和業(yè)務(wù)價(jià)值。需求調(diào)查的一般性方法：在需求獲取的早期，一般圍繞三方面的目標(biāo)展開需求調(diào)查：澄清需求工程師在理解軟件問題及業(yè)務(wù)背景過程中遇到的疑難問題；請(qǐng)求用戶確認(rèn)需求工程師對(duì)軟件問題和業(yè)務(wù)知識(shí)的理解；確定軟件系統(tǒng)的初步定義，包括目標(biāo)、業(yè)務(wù)價(jià)值、范圍和邊界。2023/2/463策劃并實(shí)施需求調(diào)查提出以下問題，或者與用戶共同探討這些問題，有助于達(dá)成這些需求調(diào)查目標(biāo)。（1）軟件系統(tǒng)應(yīng)解決何種業(yè)務(wù)問題？在軟件系統(tǒng)涉及的業(yè)務(wù)領(lǐng)域，有哪些改進(jìn)能夠?yàn)橛脩籼岣咝б婊騽?chuàng)造價(jià)值？軟件系統(tǒng)能夠?yàn)檫@些改進(jìn)做出何種貢獻(xiàn)？這些問題的答案部分對(duì)應(yīng)于軟件系統(tǒng)的目標(biāo)。（2）目前，與上述問題相關(guān)的業(yè)務(wù)是如何運(yùn)作的？引入軟件系統(tǒng)后，這些業(yè)務(wù)的運(yùn)作應(yīng)有哪些改進(jìn)？對(duì)這些問題的分析可進(jìn)一步明確軟件系統(tǒng)的目標(biāo)和范圍。（3）引入軟件系統(tǒng)解決上述問題后，可望帶來哪些業(yè)務(wù)方面的創(chuàng)新？這些創(chuàng)新會(huì)帶來哪些好處？這些問題的答案對(duì)應(yīng)于軟件系統(tǒng)的業(yè)務(wù)價(jià)值。

2023/2/4644.3.4定義軟件系統(tǒng)的輪廓軟件系統(tǒng)的輪廓包括業(yè)務(wù)目標(biāo)、業(yè)務(wù)價(jià)值、范圍及邊界。（一）確定業(yè)務(wù)目標(biāo)和價(jià)值在需求調(diào)查過程中已經(jīng)就軟件系統(tǒng)的業(yè)務(wù)目標(biāo)和價(jià)值與客戶/用戶進(jìn)行了探討。但需求工程師的職責(zé)并不僅止于簡(jiǎn)單地記錄用戶對(duì)待開發(fā)軟件系統(tǒng)的目標(biāo)和價(jià)值的論述，還要展開深入的分析和梳理，從中總結(jié)、挖掘出軟件系統(tǒng)的業(yè)務(wù)目標(biāo)和價(jià)值。2023/2/465定義軟件系統(tǒng)的輪廓對(duì)軟件系統(tǒng)的業(yè)務(wù)目標(biāo)的描述必須遵循以下原則：①具體而不抽象，實(shí)在而不空洞。②具有評(píng)判目標(biāo)是否達(dá)成的客觀標(biāo)準(zhǔn)。③具有可行性。必要時(shí)，應(yīng)在描述目標(biāo)的同時(shí)給出其評(píng)判標(biāo)準(zhǔn)和可行性論述。④具有明確的業(yè)務(wù)價(jià)值。軟件系統(tǒng)業(yè)務(wù)價(jià)值的描述可針對(duì)項(xiàng)目目標(biāo)逐項(xiàng)進(jìn)行，也可匯總描述整個(gè)軟件系統(tǒng)的業(yè)務(wù)價(jià)值。前者有利于清晰地表述每項(xiàng)目標(biāo)的緣由，后者有利于需求文檔的讀者從總體上把握軟件的業(yè)務(wù)價(jià)值。2023/2/466例4.3業(yè)務(wù)目標(biāo)和業(yè)務(wù)價(jià)值家庭保安系統(tǒng)的業(yè)務(wù)目標(biāo)：①在發(fā)生非法進(jìn)入或者火災(zāi)時(shí)通過警報(bào)器和電話報(bào)警，誤報(bào)率小于2%，漏報(bào)率小于1%。②支持靈活的用戶定制。

可配置的參數(shù)包括門窗傳感器的靈敏度及煙霧濃度閾值。

業(yè)務(wù)價(jià)值：①保護(hù)居家安全。②誤報(bào)率、漏報(bào)率和成本均低于市面已有同類產(chǎn)品。③通過靈活定制可適應(yīng)不同的運(yùn)行環(huán)境，潛在用戶面比現(xiàn)有同類產(chǎn)品更廣泛。2023/2/467定義軟件系統(tǒng)的輪廓（二）確定范圍和邊界目標(biāo)軟件系統(tǒng)的范圍是指軟件需要在哪些業(yè)務(wù)領(lǐng)域完成哪些功能。邊界是指，在軟件與用戶及外部系統(tǒng)協(xié)作的過程中，哪些動(dòng)作或功能不屬于軟件負(fù)責(zé)的范圍，而由用戶或外部系統(tǒng)負(fù)責(zé)。軟件系統(tǒng)的范圍取決于前面定義的目標(biāo)和業(yè)務(wù)價(jià)值，即，軟件必須提供足以實(shí)現(xiàn)其目標(biāo)和業(yè)務(wù)價(jià)值的功能。軟件的范圍與邊界的劃定是相關(guān)的，因?yàn)椋魏我豁?xiàng)業(yè)務(wù)要求的動(dòng)作或功能是相對(duì)固定的，它們要么由軟件自動(dòng)完成，要么由用戶或外部系統(tǒng)完成。范圍和邊界的設(shè)定是相輔相成的。2023/2/468例4.4范圍和邊界家庭保安系統(tǒng)的范圍和邊界定義如下:⑴本軟件系統(tǒng)必須提供以下功能：①監(jiān)測(cè)來自傳感器的輸入數(shù)據(jù)，判別是否發(fā)生非法進(jìn)入或煙霧異常。②在探測(cè)到異常情形時(shí)自動(dòng)報(bào)警，包括鳴響警報(bào)器并撥報(bào)警電話，在報(bào)警電話接通后報(bào)告異常事件的內(nèi)容。③響應(yīng)用戶命令，包括開關(guān)機(jī)命令、系統(tǒng)復(fù)位命令、配置命令及系統(tǒng)運(yùn)行日志查詢命令。⑵傳感數(shù)據(jù)的生成功能不在本軟件系統(tǒng)的范圍之內(nèi)。2023/2/4694.4創(chuàng)建框架用例目的：為了避免需求工程師過早陷入細(xì)節(jié)而忽視全局，先創(chuàng)建框架用例再填充，非一次完成每個(gè)用例的所有細(xì)節(jié)。本活動(dòng)的目標(biāo)：

提取框架用例，并通過它們完整地覆蓋用戶需求面。2023/2/470創(chuàng)建框架用例創(chuàng)建框架用例的子活動(dòng)如下：①策劃并實(shí)施用例調(diào)查；②以框架用例記錄用例調(diào)查的結(jié)果；③創(chuàng)建用例圖；④整合并評(píng)審框架用例。2023/2/4714.4.1策劃并實(shí)施用例調(diào)查用例調(diào)查的主要目標(biāo)是厘清以下問題：為實(shí)現(xiàn)待開發(fā)軟件系統(tǒng)的業(yè)務(wù)目標(biāo)和價(jià)值，針對(duì)每項(xiàng)業(yè)務(wù)，希望軟件系統(tǒng)在哪些時(shí)間點(diǎn)、提供哪些支持功能？在這些時(shí)間點(diǎn)，用戶與軟件系統(tǒng)之間需要進(jìn)行何種交互？軟件系統(tǒng)在業(yè)務(wù)處理過程中必須遵守哪些業(yè)務(wù)規(guī)則？針對(duì)預(yù)想的軟件系統(tǒng)的每項(xiàng)功能或其外部行為，希望它們滿足哪些質(zhì)量需求或約束？2023/2/472策劃并實(shí)施用例調(diào)查需求調(diào)查和用例調(diào)查的差異：調(diào)查的目標(biāo)不同，向用戶提出的問題、與用戶共同探討的問題自然也不同。用例調(diào)查的目的：主要是提取目標(biāo)軟件的功能以傳統(tǒng)的功能分解方式來組織用例調(diào)查并不恰當(dāng)，因?yàn)檫@樣會(huì)使問題的探討處于支離破碎的上下文語境之中?；谕暾臉I(yè)務(wù)處理流程或者業(yè)務(wù)自身的邏輯線索組織問題、編排需求調(diào)查進(jìn)程才是適當(dāng)?shù)姆椒?。例如，針?duì)課程注冊(cè)管理系統(tǒng)，采用“設(shè)定課程信息、制訂課表、發(fā)布課表”和“查詢課表及課程信息、制訂選課計(jì)劃”等邏輯線索就比割裂這些線索中包含的功能要好得多。2023/2/473策劃并實(shí)施用例調(diào)查在需求調(diào)查的過程中，還要關(guān)注與軟件系統(tǒng)相關(guān)的業(yè)務(wù)領(lǐng)域中的規(guī)則以及非功能需求。對(duì)業(yè)務(wù)規(guī)則的調(diào)查一般應(yīng)與業(yè)務(wù)流程中相應(yīng)處理環(huán)節(jié)的調(diào)查同步，如此才可使需求工程師與用戶之間的交流溝通比較自然流暢并保持語境完整。業(yè)務(wù)規(guī)則調(diào)查的特殊之處在于，規(guī)則往往易變，需求工程師必須通過與用戶的深入探討，結(jié)合自己對(duì)業(yè)務(wù)的理解和需求工程經(jīng)驗(yàn)，了解各種可能的規(guī)則變更。由于大多數(shù)非功能需求項(xiàng)具有跨越不同軟件項(xiàng)目的普適性，可以基于一張比較完整的非功能性需求清單（參見表4.1）

，收集利益相關(guān)方對(duì)軟件系統(tǒng)在性能、可靠性、可用性、運(yùn)行環(huán)境、外部接口、可保障性等方面的需求，見例4.6

。2023/2/4744.4.2以框架用例記錄調(diào)查結(jié)果調(diào)查結(jié)果的主要部分：框架用例，還包括業(yè)務(wù)規(guī)則和非功能需求清單。它們構(gòu)成軟件需求規(guī)約的最初基礎(chǔ)。在整理框架用例時(shí)應(yīng)注意以下事項(xiàng)：從用戶的視角而非軟件開發(fā)者的視角，采用用戶熟悉的業(yè)務(wù)術(shù)語描述用例的名稱、功能或業(yè)務(wù)目標(biāo)。用例目標(biāo)描述主要參與者使用此用例希望達(dá)成的業(yè)務(wù)目標(biāo)，但同時(shí)也應(yīng)考慮本用例其他參與者的需求。2023/2/475以框架用例記錄調(diào)查結(jié)果盡可能完整地標(biāo)識(shí)每個(gè)用例的所有參與者。參與者的命名不能使用職務(wù)頭銜，更不能使用個(gè)體名稱，因?yàn)閰⑴c者是角色而非個(gè)體。對(duì)用例的交互動(dòng)作序列的描述不必細(xì)化，甚至可以暫時(shí)忽略其交互動(dòng)作序列，更勿需考慮非典型的應(yīng)用場(chǎng)景或異常處理。僅作用于單個(gè)用例的規(guī)則和非功能需求應(yīng)該在用例描述中說明，見例4.5。作用于多個(gè)用例的規(guī)則應(yīng)與全局性的規(guī)則一道在需求規(guī)約書中以專門章節(jié)的形式出現(xiàn)，對(duì)非功能需求項(xiàng)而言也是如此，見例4.6。2023/2/476以框架用例記錄調(diào)查結(jié)果在整理非功能需求時(shí)必須要求每項(xiàng)需求都是具體的、可客觀驗(yàn)證的，否則應(yīng)再次與提出者探討如何將其具體化、如何對(duì)其進(jìn)行客觀地驗(yàn)證。例如，泛泛地要求“高性能”不是一項(xiàng)合格的質(zhì)量需求，“用戶命令的響應(yīng)時(shí)間小于1.5秒”才是具體的、可客觀驗(yàn)證的。2023/2/477例4.5框架用例針對(duì)家庭保安系統(tǒng)，其框架用例有

“命令響應(yīng)”和“傳感器監(jiān)測(cè)”。

用例名：命令響應(yīng)。業(yè)務(wù)目標(biāo)：響應(yīng)用戶的開關(guān)機(jī)、復(fù)位命令、配置命令及系統(tǒng)運(yùn)行日志查詢命令。參與者：用戶。業(yè)務(wù)規(guī)則1：在關(guān)機(jī)、復(fù)位及更改配置數(shù)據(jù)前必須輸入正確的用戶密碼。業(yè)務(wù)規(guī)則2：處于報(bào)警狀態(tài)時(shí)，系統(tǒng)不響應(yīng)配置命令。性能需求：用戶命令的響應(yīng)時(shí)間小于1.5秒。

用例名：傳感器監(jiān)測(cè)。業(yè)務(wù)目標(biāo)：接收并判別來自傳感器的數(shù)據(jù)是否正常，一旦發(fā)現(xiàn)異常即報(bào)警。參與者：各類傳感器，警報(bào)器，報(bào)警電話，顯示器。可靠性需求：誤報(bào)率小于2%，漏報(bào)率小于1%。2023/2/478例4.6質(zhì)量需求清單及調(diào)查結(jié)果⑴類別質(zhì)量需求項(xiàng)名稱需求描述說明性能Req-Performance-001用戶命令的響應(yīng)時(shí)間小于1.5秒。Req-Performance-002異常發(fā)生與報(bào)警之間的時(shí)間差不超過3秒?？煽啃訰eq-Reliability-001每周7天、每天24小時(shí)可用；在硬件無故障的前提下軟件正常運(yùn)行時(shí)間比在99.9%以上。Req-Reliability-002異常誤報(bào)率小于2%，漏報(bào)率小于1%。Req-Reliability-003本軟件的任何故障不可導(dǎo)致配置信息和日志數(shù)據(jù)的丟失。故障后系統(tǒng)在60秒內(nèi)恢復(fù)正常。易用性Req-EasyUse-001用戶可自行理解用戶手冊(cè)；通讀用戶手冊(cè)后，勿需培訓(xùn)，即可使用本軟件。Req-EasyUse-002用戶在通讀安裝手冊(cè)后，勿需培訓(xùn)，通過安裝向?qū)Ъ纯沙晒Π惭b本軟件。2023/2/479質(zhì)量需求清單及調(diào)查結(jié)果⑵類別質(zhì)量需求項(xiàng)名稱需求描述說明安全性認(rèn)證需求Req-Authentication-001在通過密碼驗(yàn)證后方可使用本軟件。權(quán)限控制需求Req-Authorization-001在關(guān)機(jī)、復(fù)位、更改配置數(shù)據(jù)及查看系統(tǒng)運(yùn)行日志前必須輸入正確的用戶密碼。審計(jì)性需求Req-Audit-001本軟件需記錄系統(tǒng)運(yùn)行日志，日志信息包括開、關(guān)機(jī)、復(fù)位時(shí)間，配置命令執(zhí)行情況，發(fā)生的異常事件，以供審計(jì)。兼容性與相關(guān)標(biāo)準(zhǔn)的兼容性Req-Compatibility-001遵循數(shù)字家居領(lǐng)域的相關(guān)業(yè)界標(biāo)準(zhǔn)，包括……版本兼容性Req-Compatibility-002版本升級(jí)時(shí)新版本完全兼容舊版本。2023/2/480質(zhì)量需求清單及調(diào)查結(jié)果⑶類別質(zhì)量需求項(xiàng)名稱需求描述說明可配置性Req-Config-001設(shè)定傳感器的數(shù)量、類型、安裝位置，門窗傳感器的靈敏度、煙霧濃度閾值以及報(bào)警電話號(hào)碼等配置參數(shù)均可定制；支持不同品牌門窗傳感器和煙霧傳感器可擴(kuò)展性Req-Extend-001未來可能的擴(kuò)展：系統(tǒng)接入Internet，用戶可遠(yuǎn)程發(fā)送命令、查看安全狀態(tài)；擴(kuò)展視頻監(jiān)控功能?？缮炜s性Req-Scalability-001目前最多支持50個(gè)傳感器；以后增至500個(gè)支持樓宇安全監(jiān)控，要求軟件系統(tǒng)不需修改即可適應(yīng)傳感器數(shù)量的增大。互操作性暫無要求。本地化與國(guó)際化Req-Intl-001支持中文和英文兩種界面，用戶可在任一界面進(jìn)行語言切換。可移植性本軟件將來需移植至……環(huán)境運(yùn)行。2023/2/4國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院814.4.3創(chuàng)建用例圖需求工程師主要關(guān)注參與者與用例之間的關(guān)系，待后面適當(dāng)?shù)臅r(shí)機(jī)再對(duì)這里創(chuàng)建的初步的用例圖進(jìn)行精化。例4.7用例圖例4.5，家庭保安系統(tǒng)的用例有“命令響應(yīng)”和“傳感器監(jiān)測(cè)”，其參與者有“用戶”、“傳感器”、“控制面板”、“警報(bào)器”和“報(bào)警電話”。前兩類參與者為主動(dòng)參與者，后三類為被動(dòng)參與者。見圖4.9。2023/2/482圖4.9家庭保安系統(tǒng)的（初步）用例圖2023/2/4834.4.4整合并評(píng)審框架用例整合和評(píng)審的目的：檢查所有的框架用例聯(lián)合起來是否足以覆蓋利益相關(guān)方的所有功能需求，是否遺漏重要的非功能需求。完整覆蓋的標(biāo)準(zhǔn)：假設(shè)所有用例和非功能需求全部實(shí)現(xiàn)，目標(biāo)軟件系統(tǒng)的業(yè)務(wù)目標(biāo)和價(jià)值是否得以實(shí)現(xiàn)？是否遺漏了位于目標(biāo)軟件系統(tǒng)的范圍之內(nèi)的功能？2023/2/4844.5精化用例本活動(dòng)的目標(biāo)是：將框架用例精化為嚴(yán)謹(jǐn)、完整的用例，精化用例圖，在此過程中根據(jù)需要適當(dāng)補(bǔ)充新的業(yè)務(wù)規(guī)則和非功能需求。精化框架用例的主要工作是：確定每個(gè)框架用例中的交互動(dòng)作序列。2023/2/485精化用例精化用例子活動(dòng)包括：①分解或合并用例②構(gòu)建完整用例③精化用例圖④精化業(yè)務(wù)規(guī)則及非功能需求以上子活動(dòng)之間不存在嚴(yán)格的時(shí)序關(guān)系。參與人員：主要參與者：需求工程師負(fù)責(zé)精化用例、識(shí)別新的業(yè)務(wù)規(guī)則和非功能需求。重要參與者：用戶和客戶負(fù)責(zé)補(bǔ)充信息或者澄清原有信息。軟件架構(gòu)師也從此活動(dòng)開始參與需求工程負(fù)責(zé)檢查用例的合理性和易理解性。參與者中至少應(yīng)有一人能夠扮演業(yè)務(wù)領(lǐng)域?qū)＜业慕巧?023/2/4864.5.1用例交互動(dòng)作序列的描述方法交互動(dòng)作序列描述用例的參與者與軟件系統(tǒng)之間的一系列交互事件，這種交互體現(xiàn)了二者之間的分工與協(xié)作。交互動(dòng)作序列有基本和擴(kuò)展兩種。基本指，在不考慮任何例外的情況下，最簡(jiǎn)單、最直接的交互動(dòng)作序列。擴(kuò)展指，在基本交互動(dòng)作序列的基礎(chǔ)上，因?yàn)樘厥馇樾蔚某霈F(xiàn)而導(dǎo)致動(dòng)作序列出現(xiàn)分支。2023/2/487用例交互動(dòng)作序列的描述方法擴(kuò)展源自兩種情況⑴存在不同于基本交互動(dòng)作序列的非典型應(yīng)用場(chǎng)景，⑵參與者或外部環(huán)境在交互過程中給軟件系統(tǒng)造成了基本交互動(dòng)作序列無法處理的異常情況。分離基本和擴(kuò)展的交互動(dòng)作序列的作用：一是為了避免需求工程師過早陷入用例中的處理細(xì)節(jié)，二是為了保持用例描述的簡(jiǎn)潔性，使用例的業(yè)務(wù)目標(biāo)不致湮滅于各種特殊情況的處理細(xì)節(jié)之中。2023/2/488（一）基本交互動(dòng)作序列的描述方法為盡量避免自然語言的歧義性和模糊性，并強(qiáng)化用例的簡(jiǎn)潔性，基本交互動(dòng)作過程的描述應(yīng)遵循以下規(guī)則：⑴采用帶結(jié)構(gòu)化序號(hào)的自然語言描述動(dòng)作序列。如，“1.2……”表示第1個(gè)步驟中的第2個(gè)子步驟，見例4.8

。⑵采用主動(dòng)語態(tài)、簡(jiǎn)單句式描述每個(gè)動(dòng)作，用詞力求簡(jiǎn)潔、清晰。采用參與者動(dòng)作、系統(tǒng)動(dòng)作交替地描述交互動(dòng)作序列。在整個(gè)項(xiàng)目范圍內(nèi)保持描述風(fēng)格的一致性。⑶統(tǒng)一使用“系統(tǒng)”指稱待開發(fā)的軟件產(chǎn)品；

參與者的名稱應(yīng)與用例描述的參與者列表中的參與者名稱相一致。2023/2/489基本交互動(dòng)作序列的描述方法⑷采用業(yè)務(wù)而非技術(shù)術(shù)語描述每個(gè)動(dòng)作，闡明參與者的意圖，絕不涉及任何用戶界面操作。界面細(xì)節(jié)的引入將導(dǎo)致用例描述變得冗長(zhǎng)、脆弱，界面的細(xì)微修改都可能導(dǎo)致用例描述失效過早引入界面細(xì)節(jié)會(huì)對(duì)后續(xù)的界面設(shè)計(jì)施加過多限制。如

“學(xué)生輸入學(xué)號(hào)和密碼，點(diǎn)擊‘確認(rèn)’按鈕；

系統(tǒng)顯示學(xué)生基本信息及當(dāng)前選課計(jì)劃”

應(yīng)修改為：“學(xué)生輸入學(xué)號(hào)和密碼；系統(tǒng)顯示學(xué)生基本信息及當(dāng)前選課計(jì)劃”2023/2/490基本交互動(dòng)作序列的描述方法⑸從用戶的視角描述系統(tǒng)行為的外部可見效果，盡量避免描述系統(tǒng)內(nèi)部的動(dòng)作。如，

“系統(tǒng)讀取用戶輸入的課程名、任課教師、上課時(shí)間及教室，從數(shù)據(jù)庫(kù)中獲取同一時(shí)間同一教師是否已安排其他課程，同一時(shí)間同一教室是否空閑，同一時(shí)間同一專業(yè)是否已安排其他課程，據(jù)此判斷是否存在課程設(shè)置沖突”應(yīng)修改為：

“用戶輸入課程名、任課教師、上課時(shí)間及教室；

系統(tǒng)報(bào)告是否存在課程設(shè)置沖突”。2023/2/491基本交互動(dòng)作序列的描述方法⑹以適當(dāng)?shù)牧６让枋雒總€(gè)動(dòng)作。通常一個(gè)用例的最外層動(dòng)作不應(yīng)超過10個(gè)。如果連續(xù)的多個(gè)動(dòng)作均表示由同一參與者向系統(tǒng)傳遞信息，應(yīng)該將這些動(dòng)作合并。如，動(dòng)作序列：1．用戶輸入課程名、任課教師。2．用戶輸入上課時(shí)間及教室。3．……應(yīng)修改為：1．用戶輸入課程名、任課教師、上課時(shí)間及教室。2．……2023/2/492基本交互動(dòng)作序列的描述方法如果動(dòng)作數(shù)量過多，可考慮將屬于同一事務(wù)（transaction）的多個(gè)動(dòng)作合并，或者采用“步驟－子步驟”的方式使動(dòng)作序列的描述更加結(jié)構(gòu)化，從而減少單個(gè)結(jié)構(gòu)層次上的動(dòng)作數(shù)量。如，動(dòng)作序列：1．用戶輸入用戶名、密碼。2．系統(tǒng)驗(yàn)證用戶身份。3．用戶輸入課程名、任課教師、上課時(shí)間及教室。4．系統(tǒng)檢查課程設(shè)置沖突。5．系統(tǒng)檢查課時(shí)數(shù)是否符合教學(xué)大綱的規(guī)定。6．系統(tǒng)提示在課表中添加課程設(shè)置成功?？尚薷臑椋?．用戶輸入用戶名、密碼；系統(tǒng)驗(yàn)證用戶身份。2．用戶輸入課程名、任課教師、上課時(shí)間及教室；系統(tǒng)檢查課程設(shè)置沖突、課時(shí)數(shù)是否符合教學(xué)大綱的規(guī)定，然后提示在課表中添加課程設(shè)置成功。2023/2/493基本交互動(dòng)作序列的描述方法或修改為：1．驗(yàn)證用戶身份：1.1用戶輸入用戶名、密碼。1.2系統(tǒng)驗(yàn)證用戶身份。2．添加并檢查課程設(shè)置：2.1用戶輸入課程名、任課教師、上課時(shí)間及教室。2.2系統(tǒng)檢查課程設(shè)置沖突、課時(shí)數(shù)是否符合教學(xué)大綱的規(guī)定，然后提示在課表中添加課程設(shè)置成功。2023/2/494基本交互動(dòng)作序列的描述方法⑺避免嵌套地使用“如果……，那么……”。因?yàn)榛窘换?dòng)作序列僅考慮最典型的場(chǎng)景，某些條件不成立時(shí)的動(dòng)作可以推遲到擴(kuò)展交互動(dòng)作過程中描述。如，基本交互動(dòng)作序列：

1．用戶輸入用戶名、密碼。2．系統(tǒng)檢查用戶名、密碼是否正確。如果正確，則：2.1用戶輸入課程名、任課教師、上課時(shí)間及教室。2.2系統(tǒng)檢查……。應(yīng)修改為：1．用戶輸入用戶名、密碼。2．系統(tǒng)檢查用戶名、密碼的有效性。3．用戶輸入課程名、任課教師、上課時(shí)間及教室。4．系統(tǒng)檢查……。2023/2/495基本交互動(dòng)作序列的描述方法⑻在一連串動(dòng)作的前部或后部描述循環(huán)、特殊的時(shí)序約束或其他有關(guān)此子動(dòng)作序列的其他說明。例如，循環(huán)可采用類似于下面的方式說明（前部）1．……步驟2-3可以循環(huán)執(zhí)行，直至……2．……特殊的時(shí)序約束可采用類似于下面的方式說明（后部）1．……2．……3．……步驟2、3發(fā)生的時(shí)序是任意的。2023/2/496基本交互動(dòng)作序列的描述方法⑼如果用例A包含子用例B，那么在A的動(dòng)作序列描述中采用帶下劃線的子用例B的名稱來引用B的交互動(dòng)作序列；類似地，如果有一個(gè)子動(dòng)作序列在A中被多次使用，或者單獨(dú)描述該子動(dòng)作序列有助于用例動(dòng)作序列的結(jié)構(gòu)清晰性，可以對(duì)其命名并通過帶下劃線的名稱引用來避免重復(fù)。例如，1．……2．用戶選擇注冊(cè)課程、撤銷注冊(cè)或確認(rèn)選課計(jì)劃：2.1用戶選擇注冊(cè)課程：執(zhí)行注冊(cè)課程子流程。

2.2用戶選擇撤銷注冊(cè)：執(zhí)行撤銷注冊(cè)子流程。

2.3用戶選擇確認(rèn)選課計(jì)劃：執(zhí)行確認(rèn)選課計(jì)劃子流程。……注冊(cè)課程子流程：……撤銷注冊(cè)子流程：……確認(rèn)選課計(jì)劃子流程：……2023/2/497（二）擴(kuò)展交互動(dòng)作序列的描述方法擴(kuò)展交互動(dòng)作序列的描述方法是：⑴標(biāo)識(shí)可能出現(xiàn)特別情形的基本交互動(dòng)作序列中的動(dòng)作的編號(hào)⑵說明擴(kuò)展分支的條件以及在此條件下的處理動(dòng)作序列⑶描述擴(kuò)展處理完成后與基本動(dòng)作序列的匯合點(diǎn)。2023/2/498擴(kuò)展條件及擴(kuò)展動(dòng)作序列編號(hào)方式一般用基本動(dòng)作序列中的動(dòng)作編號(hào)加英文字母來標(biāo)引擴(kuò)展條件，它表示在基本動(dòng)作序列中的相應(yīng)步驟可能出現(xiàn)條件所示的情形。相應(yīng)的擴(kuò)展動(dòng)作序列則以條件標(biāo)號(hào)再加動(dòng)作序號(hào)來表示。例如，“1.1a任課教師在同一時(shí)間已安排其他課程設(shè)置”表示在基本動(dòng)作序列的第1.1個(gè)步驟可能出現(xiàn)意外。“1.1a1……”表示沖突出現(xiàn)時(shí)的第1個(gè)處理動(dòng)作。為保持版面清晰，擴(kuò)展動(dòng)作序列應(yīng)基于擴(kuò)展條件向右縮進(jìn)。2023/2/499擴(kuò)展交互動(dòng)作序列的描述方法如果在基本動(dòng)作序列的同一步驟會(huì)出現(xiàn)多個(gè)分支條件，則條件標(biāo)號(hào)的字母依字母表的順序向后延伸，但這種延伸并不隱含時(shí)序關(guān)系方面的意義。最后，如果在擴(kuò)展動(dòng)作序列中再出現(xiàn)分支條件，那么可綜合采用上述條件標(biāo)號(hào)規(guī)則、擴(kuò)展動(dòng)作序列編號(hào)規(guī)則和版面編排規(guī)則，直接在一個(gè)擴(kuò)展動(dòng)作序列中嵌套地表示另一子擴(kuò)展條件及其動(dòng)作序列，見例4.8

。擴(kuò)展的嵌套不宜過深。如果確有需要，建議分離出單獨(dú)的擴(kuò)展用例以減少擴(kuò)展嵌套深度。單獨(dú)擴(kuò)展用例也可用在多個(gè)步驟擴(kuò)展出來的相同動(dòng)作序列，無論擴(kuò)展條件是否相同。2023/2/4100擴(kuò)展交互動(dòng)作序列的描述方法例如，用例“制訂課表”包含了子用例“在課表中添加課程設(shè)置”和“在課表中修改課程設(shè)置”，兩個(gè)子用例中的擴(kuò)展條件“在同一時(shí)間針對(duì)同一教師安排了多門課程設(shè)置”、“在同一時(shí)間同一教室安排了多門課程設(shè)置”、“在同一時(shí)間針對(duì)同一專業(yè)的學(xué)生安排了多門課程設(shè)置”在用例“制訂課表”中應(yīng)歸并為單個(gè)擴(kuò)展條件：“課程設(shè)置有沖突”。2023/2/41014.5.2分解或合并用例用例粒度：是指用例對(duì)應(yīng)的功能范圍相對(duì)于整個(gè)軟件產(chǎn)品的功能而言的規(guī)模比。在同一用例模型中，往往不希望用例的粒度過于懸殊。分解或合并用例的準(zhǔn)則：⑴用例具有業(yè)務(wù)意義上的相對(duì)獨(dú)立性和完整性。⑵應(yīng)遵循業(yè)務(wù)層面上的強(qiáng)內(nèi)聚、松耦合原則。⑶一個(gè)軟件系統(tǒng)的用例不宜過多用例總數(shù)一般應(yīng)控制在20以內(nèi)，最多不超過30。對(duì)于特別大型的軟件系統(tǒng)，可先分解為子系統(tǒng)，然后針對(duì)每個(gè)子系統(tǒng)分別考慮用例的粒度可借助UML包圖表示系統(tǒng)的劃分，并將用例指派到包中。⑷用例的粒度應(yīng)確保合理規(guī)模的軟件開發(fā)團(tuán)隊(duì)能夠在合理的時(shí)間周期內(nèi)實(shí)現(xiàn)該用例2023/2/4102分解或合并用例當(dāng)系統(tǒng)中用例數(shù)量很多時(shí)，可以按照以下原則適當(dāng)?shù)睾喜⒁恍┝６容^小的用例。①合并業(yè)務(wù)上關(guān)系比較密切的多個(gè)用例。例如，針對(duì)課程注冊(cè)管理系統(tǒng)，可以將“注冊(cè)課程”、“撤銷注冊(cè)”兩個(gè)用例合并為“制訂選課計(jì)劃”用例。②在同一業(yè)務(wù)范圍內(nèi)，合并功能上相似的用例。例如，在家庭保安系統(tǒng)中，“門窗監(jiān)測(cè)”和“煙霧監(jiān)測(cè)”兩個(gè)用例基本相似，但略有不同?？梢钥紤]合并它們，在交互動(dòng)作序列的表述中體現(xiàn)它們之間的差異。2023/2/41034.5.3構(gòu)建完整用例此活動(dòng)是“精化用例”的工作重心，其具體工作內(nèi)容如下。⑴重新研究用例名稱、用例目標(biāo)或功能的表述、標(biāo)識(shí)所有的參與者。用例名稱應(yīng)該采用業(yè)務(wù)術(shù)語，并且反映參與者的主要業(yè)務(wù)目標(biāo)。如果有多個(gè)參與者，難以在用例名稱中涵蓋所有參與者的業(yè)務(wù)目標(biāo)，則應(yīng)以主要參與者的主要業(yè)務(wù)目標(biāo)為準(zhǔn)。2023/2/4104構(gòu)建完整用例⑵標(biāo)識(shí)觸發(fā)和前置條件。它們?cè)谟美谐霈F(xiàn)必須滿足三個(gè)前提：具有業(yè)務(wù)意義，系統(tǒng)可檢測(cè)，不是不言自明的；否則應(yīng)予省略。應(yīng)該采用業(yè)務(wù)術(shù)語來描述觸發(fā)和前置條件。觸發(fā)和前置條件之間的關(guān)聯(lián)是：當(dāng)觸發(fā)動(dòng)作或事件發(fā)生，并且前置條件成立時(shí)，用例開始運(yùn)作。它們的差異是：觸發(fā)條件是用例啟動(dòng)的推動(dòng)力；前置條件是決定是否阻截此推動(dòng)力的過濾器。2023/2/4105構(gòu)建完整用例⑶描述或精化原有的基本交互動(dòng)作序列。需求工程師可從下述方面提煉基本交互動(dòng)作序列。①觀察現(xiàn)有的業(yè)務(wù)處理過程，思考在引進(jìn)新的軟件系統(tǒng)后如何優(yōu)化該過程。②通過訪談深入了解利益相關(guān)方希望軟件系統(tǒng)在幫助用戶完成業(yè)務(wù)目標(biāo)的過程中發(fā)揮何種作用、完成何種功能。③研究軟件系統(tǒng)如何更好地幫助用戶。④研究參與者和軟件系統(tǒng)在協(xié)同工作的過程中各自應(yīng)在何種時(shí)機(jī)、向?qū)Ψ教峁┖畏N交互信息。2023/2/4106構(gòu)建完整用例⑷提煉并描述擴(kuò)展的交互動(dòng)作序列。出現(xiàn)擴(kuò)展的交互動(dòng)作序列的原因在于，某些情況的出現(xiàn)導(dǎo)致基本交互動(dòng)作序列無法處理，這些情況也就成為擴(kuò)展動(dòng)作序列的執(zhí)行條件。提煉擴(kuò)展交互動(dòng)作序列的關(guān)鍵在于標(biāo)識(shí)擴(kuò)展條件，擴(kuò)展條件下的處理動(dòng)作序列的描述方式與基本動(dòng)作序列類似。在探究用例的擴(kuò)展條件時(shí)，最好集中列出所有可能導(dǎo)致分支和異常的條件，然后用“系統(tǒng)必須能夠檢測(cè)到該條件”、“系統(tǒng)必須能夠處理該條件導(dǎo)致的情形”兩條標(biāo)準(zhǔn)來篩選出真正的擴(kuò)展條件。例如，“用戶忘記密碼”會(huì)導(dǎo)致“系統(tǒng)驗(yàn)證用戶密碼”動(dòng)作無法進(jìn)行，但此條件卻是系統(tǒng)檢測(cè)不到的，應(yīng)改寫為“密碼輸入超時(shí)”2023/2/4107構(gòu)建完整用例應(yīng)考慮合并處理動(dòng)作相同或相似的擴(kuò)展條件。例如，“學(xué)生所選課程的總課時(shí)數(shù)超過規(guī)定的最大值”、“學(xué)生所選的必修課程的總課時(shí)數(shù)超過規(guī)定的最大值”的處理動(dòng)作類似，可合并為“總課時(shí)數(shù)超過規(guī)定的最大值”。如果擴(kuò)展相當(dāng)復(fù)雜，使得原用例的描述過于龐大或者難于理解，應(yīng)針對(duì)擴(kuò)展創(chuàng)建新的用例，并在UML用例圖中用擴(kuò)展關(guān)系（<<extend>>）連接擴(kuò)展用例和原用例。2023/2/4108構(gòu)建完整用例⑸描述用戶與軟件系統(tǒng)交互過程中傳遞的信息項(xiàng)的主要內(nèi)容。盡管不需要對(duì)所有此類信息項(xiàng)給出內(nèi)容描述，但是，如果信息項(xiàng)中包含的內(nèi)容比較豐富，并且讀者無法僅僅從信息項(xiàng)的名稱推導(dǎo)出其中的所有內(nèi)容，則需要顯式說明這些內(nèi)容。顯式說明的方式有兩種：①在使用信息項(xiàng)的動(dòng)作步驟中說明；

②對(duì)信息項(xiàng)命名，在交互動(dòng)作描述中引用此名稱，在用例描述中增加與“用例名稱”、“基本交互動(dòng)作序列”平行的條目“信息項(xiàng)”，在此條目下說明各信息項(xiàng)的內(nèi)容。如果信息項(xiàng)在多處使用，必須采用第二種說明方式。2023/2/4109構(gòu)建完整用例⑹標(biāo)識(shí)后置條件。

它在用例中出現(xiàn)也必須滿足前面(2)所述的三個(gè)前提，并且也應(yīng)該采用業(yè)務(wù)術(shù)語來描述后置條件。2023/2/4110例4.8框架用例的精化基于例4.5所述的“傳感器監(jiān)測(cè)”用例，下面給出其完整描述。

用例名：傳感器監(jiān)測(cè)。業(yè)務(wù)目標(biāo)：接收并判別來自傳感器的數(shù)據(jù)是否正常，一旦發(fā)現(xiàn)異常即報(bào)警。參與者：各類傳感器，警報(bào)器，報(bào)警電話，顯示器。前置條件：系統(tǒng)處于“監(jiān)控”狀態(tài)。基本交互動(dòng)作：1.傳感