第4章需求獲取

第四章需求獲取

4.1軟件需求的初始表示

4.2需求獲取的過程模型

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

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

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

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

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

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

類的表示圖元（二）類之間的關(guān)系除面向?qū)ο蠡靖拍钪械睦^承和聚合外，UML還可以表示類之間的關(guān)聯(lián)、依賴和實現(xiàn)關(guān)系。UML將聚合關(guān)系進一步細分為（一般）聚合和組合兩種。它們的表示圖元如圖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）實現(xiàn)關(guān)系的表示（f）繼承關(guān)系的表示關(guān)聯(lián)關(guān)系表示兩個類之間迥異于繼承關(guān)系的一種語義上、邏輯上的聯(lián)系。在代碼中表現(xiàn)為：在A類中有一個成員變量，變量的類型是B類聚合關(guān)系是關(guān)聯(lián)關(guān)系之一種。如，在“學生”與“老師”之間存在一種既非繼承、也非聚合的語義關(guān)聯(lián)，因為一名學生可能選修某名老師所開的課程設置。在關(guān)聯(lián)關(guān)系的表示圖元的兩端，可以標示參與關(guān)聯(lián)的多重性（multiplicity）、角色名和約束特性。2023/2/428類之間的關(guān)系類之間的關(guān)系（1）多重性說明位于關(guān)聯(lián)端的類可以有多少個實例對象與另一端的類的單個實例對象相聯(lián)系，它表示參與關(guān)聯(lián)的兩個類的對象之間的數(shù)量對應關(guān)系。UML的多重性表示符有：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“命令響應”和“傳感器監(jiān)測”。

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

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

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

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

“學生輸入學號和密碼，點擊‘確認’按鈕；

系統(tǒng)顯示學生基本信息及當前選課計劃”

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

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

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

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

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

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

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

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

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

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

用例名：傳感器監(jiān)測。業(yè)務目標：接收并判別來自傳感器的數(shù)據(jù)是否正常，一旦發(fā)現(xiàn)異常即報警。參與者：各類傳感器，警報器，報警電話，顯示器。前置條件：系統(tǒng)處于“監(jiān)控”狀態(tài)?；窘换幼鳎?.傳感