軟件需求提取與分析

軟件需求提取與分析第1頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求分析的重要性需求分析的目標(biāo)是為系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)提供足夠的指導(dǎo)和信息支持。如果需求分析不充分，則設(shè)計(jì)和實(shí)現(xiàn)很難進(jìn)行；如果設(shè)計(jì)和實(shí)現(xiàn)中涉及的內(nèi)容無(wú)法與需求建立對(duì)應(yīng)關(guān)系，則顯得多余。對(duì)論文而言，就是失敗之作。軟件開發(fā)類論文評(píng)價(jià)的基本標(biāo)準(zhǔn)之一：需求與設(shè)計(jì)和實(shí)現(xiàn)的一致性，即任何需求必須在設(shè)計(jì)和實(shí)現(xiàn)中得到體現(xiàn)，任何設(shè)計(jì)與實(shí)現(xiàn)必須與需求有對(duì)應(yīng)關(guān)系。第2頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求分析概述

在傳統(tǒng)的軟件工程中，需求分析作為軟件生存周期的一個(gè)階段，盡管有需求獲取和分析的兩個(gè)任務(wù)，這兩個(gè)任務(wù)沒(méi)有嚴(yán)格地劃分時(shí)間段，在需求獲取過(guò)程中要進(jìn)行分析，在分析過(guò)程中要不斷地進(jìn)行調(diào)研和完善。需求獲取和需求分析的工具都是采用數(shù)據(jù)流圖和數(shù)據(jù)字典。明確地指出需求分析報(bào)告主要用于用戶交流。在統(tǒng)一過(guò)程和UML提出后，特別是軟件迭代開發(fā)方法提出后，把需求和分析分成了兩個(gè)不同的階段，有時(shí)也叫需求獲?。ɑ蛐枨蟛东@）和需求分析，每個(gè)階段有完全不同的目標(biāo)和任務(wù)，包括建模工具和建立的模型都完全不同。需求捕捉階段主要采用用例模型捕捉功能需求，需求分析階段主要采用對(duì)象模型，建立領(lǐng)域?qū)ο箝g的協(xié)作關(guān)系。需求獲取所建立的模型主要用于與用戶交流，需求分析模型是開發(fā)組織自己的文檔，不用于與用戶交流。第3頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求分類（1）功能性需求----系統(tǒng)應(yīng)該提供什么功能。（2）非功能需求----系統(tǒng)的特定特性或約束。軟件需求功能需求非功能需求質(zhì)量屬性約束運(yùn)行期質(zhì)量屬性開發(fā)期質(zhì)量屬性第4頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月軟件運(yùn)行期質(zhì)量

用戶在使用軟件過(guò)程中對(duì)軟件質(zhì)量的要求，包括：

易用性：指軟件系統(tǒng)容易使用的程度。

性能：指軟件系統(tǒng)及時(shí)提供相應(yīng)服務(wù)的能力。性能包括響應(yīng)時(shí)間、吞吐量、持續(xù)高速性。

安全性：指軟件系統(tǒng)同時(shí)兼顧向合法用戶提供服務(wù)，以及防止非授權(quán)使用的能力。

持續(xù)可用性：指軟件長(zhǎng)時(shí)間無(wú)故障運(yùn)行的能力。如有的系統(tǒng)要求提供7*24小時(shí)服務(wù)就是持續(xù)可用性的要求。

可伸縮性：指當(dāng)用戶數(shù)量和數(shù)據(jù)量增加時(shí)，軟件系統(tǒng)維持高服務(wù)質(zhì)量的能力。

互操作性：指本軟件系統(tǒng)與其它軟件系統(tǒng)交換數(shù)據(jù)和相互調(diào)用服務(wù)的難易程度。

可靠性：軟件系統(tǒng)在一定時(shí)間內(nèi)無(wú)故障運(yùn)行的能力。

魯棒性：也稱健壯性、容錯(cuò)性。有時(shí)也把持續(xù)可用性、魯棒性也歸類為可靠性。第5頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月軟件運(yùn)行期質(zhì)量為保證軟件的可維護(hù)性而在軟件開發(fā)過(guò)程中應(yīng)該關(guān)注的軟件質(zhì)量屬性，有時(shí)將其稱為隱含質(zhì)量屬性。包括：

可擴(kuò)展性：為適應(yīng)新需求或需求變化為軟件增加功能的能力。有時(shí)稱為靈活性。

可重用性：重用軟件系統(tǒng)或其一部分的能力的難易程度。

可測(cè)試性：對(duì)軟件測(cè)試以證明滿足需求規(guī)約的難易程度。在實(shí)際工作中主要指進(jìn)行單元測(cè)試，插樁測(cè)試的難易程度。

可維護(hù)性：在修改Bug、增加功能、提高質(zhì)量屬性等而定位修改點(diǎn)并適時(shí)修改的難易程度。

可移植性：將軟件系統(tǒng)從一個(gè)運(yùn)行環(huán)境轉(zhuǎn)移到另一個(gè)運(yùn)行環(huán)境的難易程度。

易理解性：設(shè)計(jì)被開發(fā)人員理解的難易程度。任何一個(gè)開發(fā)期質(zhì)量屬性的滿足都可能增加軟件開發(fā)成本。。第6頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月約束

約束不是行為，是設(shè)計(jì)或項(xiàng)目的限制條件，強(qiáng)調(diào)其限制性，新系統(tǒng)的開發(fā)無(wú)法回避這些事實(shí)或因素。約束主要包括：

系統(tǒng)開發(fā)的資源約束：如網(wǎng)絡(luò)環(huán)境、操作系統(tǒng)、數(shù)據(jù)庫(kù)管理系統(tǒng)、開發(fā)工具、硬件等。新系統(tǒng)的開發(fā)必須考慮這些資源的有效利用和限制。

接口約束：本系統(tǒng)關(guān)聯(lián)的系統(tǒng)是哪些，新系統(tǒng)可能接受其它系統(tǒng)提供的數(shù)據(jù)作為輸入，其輸出數(shù)據(jù)作為其它系統(tǒng)的輸入。

操作約束：系統(tǒng)操作環(huán)境中的管理要求。如身份認(rèn)證必須通過(guò)第三方認(rèn)證機(jī)構(gòu)的認(rèn)證，以網(wǎng)絡(luò)為基礎(chǔ)的業(yè)務(wù)處理，在網(wǎng)絡(luò)不通的情況下如何處理業(yè)務(wù)等。

政策約束：行業(yè)標(biāo)準(zhǔn)，企業(yè)標(biāo)準(zhǔn)，法律法規(guī)、政府規(guī)章等。第7頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求的層次性

組織的不同層次人員對(duì)需求不同，通常有三個(gè)層次：

業(yè)務(wù)需求：組織要達(dá)到的目標(biāo)—業(yè)務(wù)目標(biāo)

用戶需求：用戶使用系統(tǒng)來(lái)做什么

行為需求：開發(fā)人員需要實(shí)現(xiàn)什么高管人員希望軟件系統(tǒng)能幫助他們達(dá)到業(yè)務(wù)目標(biāo)。系統(tǒng)實(shí)際使用者希望系統(tǒng)提供的能力能輔助他們更好地完成日常業(yè)務(wù)工作。開發(fā)人員為滿足用戶諸多需求而覺(jué)察到的需求。高層管理人員的需求與系統(tǒng)實(shí)際使用人員的需求可以起到相互驗(yàn)證和印證的作用。如果不關(guān)注“高層管理人員”的要求，系統(tǒng)開發(fā)就沒(méi)有明確的目標(biāo)，系統(tǒng)的功能將是零散而脆弱的，極易受到變更的沖擊。不滿足開發(fā)人員的要求，軟件的開發(fā)、維護(hù)和移植變得非常困難。第8頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求提取內(nèi)容

●確定業(yè)務(wù)目標(biāo)

●確定業(yè)務(wù)范圍和業(yè)務(wù)流程

●建立用例模型

●建立用例規(guī)約

●確定非功能需求第9頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月確定業(yè)務(wù)目標(biāo)

業(yè)務(wù)目標(biāo)系統(tǒng)開發(fā)中占有非常重要的位置，它明確規(guī)定了建立該軟件系統(tǒng)的最終目的。業(yè)務(wù)目標(biāo)是客戶方高層對(duì)未來(lái)系統(tǒng)的期望。通過(guò)確定業(yè)務(wù)目標(biāo)可以避免系統(tǒng)解決的問(wèn)題的層次太低而很快過(guò)時(shí)。項(xiàng)目業(yè)務(wù)目標(biāo)要避免太抽象、太空洞，如“實(shí)現(xiàn)XX信息化”。一個(gè)項(xiàng)目管理系統(tǒng)的業(yè)務(wù)目標(biāo)定義為：●幫助項(xiàng)目經(jīng)理更好地控制項(xiàng)目●幫助項(xiàng)目經(jīng)理更有效地分配資源●幫助項(xiàng)目成員之間更流暢地協(xié)作通過(guò)細(xì)化業(yè)務(wù)目標(biāo)，列出一組高度概括的功能性需求。如業(yè)務(wù)目標(biāo)“幫助項(xiàng)目經(jīng)理更好地控制項(xiàng)目”的特性有：●任務(wù)管理●跟蹤進(jìn)度●查看報(bào)表●任務(wù)分配和重分配第10頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月確定業(yè)務(wù)范圍和業(yè)務(wù)流程業(yè)務(wù)目標(biāo)的實(shí)現(xiàn)需要通過(guò)具體的業(yè)務(wù)領(lǐng)域（有時(shí)也稱職能域）以及具體的業(yè)務(wù)及業(yè)務(wù)流程來(lái)體現(xiàn)，使業(yè)務(wù)目標(biāo)落實(shí)到實(shí)處。這將引起企業(yè)組織機(jī)構(gòu)的調(diào)整和業(yè)務(wù)流程重組，以滿足業(yè)務(wù)目標(biāo)的要求。業(yè)務(wù)（有時(shí)也稱業(yè)務(wù)過(guò)程）：是需要做的相對(duì)獨(dú)立的工作（或任務(wù)）。業(yè)務(wù)流程：是完成工作所經(jīng)歷的業(yè)務(wù)活動(dòng)及順序。業(yè)務(wù)活動(dòng)：是基本的、不可再分的最小功能單元（通常指一個(gè)人在一個(gè)地點(diǎn)一個(gè)不可間斷的時(shí)間內(nèi)可以完成的工作）。第11頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月建立用例模型所謂用戶需求，就是用戶希望軟件系統(tǒng)能為他做什么。用例圖技術(shù)是捕捉用戶需求最合適的技術(shù)。用例名是用戶需求最直觀、最簡(jiǎn)便的反映。業(yè)務(wù)流程分析將捕捉到大部分用例，但不是全部用例，還需要補(bǔ)充一些與管理人員相關(guān)、但與具體業(yè)務(wù)活動(dòng)不一定直接相關(guān)的用例和與信息查詢相關(guān)的用例。第12頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月建立用例規(guī)約用例是用戶“希望如何做”的行為需求。這里的“如何做”是從用戶角度看他們“希望如何做”，而不是軟件系統(tǒng)是如何做，所以還是屬于需求捕捉的內(nèi)容。用戶“希望如何做”是軟件系統(tǒng)“如何做”的依據(jù)。在用例規(guī)約中，將詳細(xì)定義用戶對(duì)用例運(yùn)行期間的質(zhì)量要求和約束。不一定所有用例都要建立用例規(guī)約。有的用例使用“用例簡(jiǎn)述”就足夠了。如果一個(gè)用例基本事件流對(duì)需求分析人員來(lái)說(shuō)不是很清楚，而且可能涉及到非功能要求，就需要用“用例規(guī)約”來(lái)詳細(xì)描述。第13頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月確定非功能需求通過(guò)對(duì)用例規(guī)約的分析和總結(jié)，歸納出系統(tǒng)的非功能需求，特別是用戶對(duì)系統(tǒng)運(yùn)行期的質(zhì)量需求和約束。用例規(guī)約是系統(tǒng)運(yùn)行期質(zhì)量需求和約束的主要來(lái)源。一般來(lái)說(shuō)，開發(fā)期質(zhì)量屬性需求主要來(lái)自系統(tǒng)開發(fā)人員和維護(hù)人員，通過(guò)成為隱含的非功能需求。要善于抓住對(duì)用戶來(lái)說(shuō)至關(guān)重要的非功能需求，這種非功能需求往往決定系統(tǒng)的命運(yùn)。如特殊的性能問(wèn)題、特殊的安全性問(wèn)題、典型的運(yùn)行機(jī)制問(wèn)題。若存在與其它系統(tǒng)的交互，互操作性是必須考慮的。特定的約束對(duì)系統(tǒng)的制約是架構(gòu)設(shè)計(jì)必須考慮的問(wèn)題。第14頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法需求提取的建模包括業(yè)務(wù)建模和用例建模。業(yè)務(wù)建模是確定項(xiàng)目對(duì)應(yīng)的業(yè)務(wù)領(lǐng)域所包含的業(yè)務(wù)和業(yè)務(wù)流程，并用所選擇的業(yè)務(wù)流程描述工具進(jìn)行描述。用例建模是以用例為基本單位來(lái)描述用戶的功能需求。與用例模型相關(guān)的概念包括：參與者，用例，場(chǎng)景第15頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模--參與者

直接與系統(tǒng)交互的外部事物所扮演的角色。①參與者對(duì)系統(tǒng)而言是外部的；②參與者直接與系統(tǒng)交互，直接使用系統(tǒng)來(lái)支持其業(yè)務(wù)。③強(qiáng)調(diào)參與者所扮演的角色，而不是特定的人或事物。時(shí)間可以作為參與者，通常用時(shí)間發(fā)生器來(lái)表示。參與者主要指系統(tǒng)業(yè)務(wù)功能的使用者。系統(tǒng)管理員不是這種意義的參與者。因?yàn)樗皇鞘褂孟到y(tǒng)功能完成與單位業(yè)務(wù)有關(guān)的工作。他使用系統(tǒng)的輔助功能實(shí)現(xiàn)對(duì)特定的人及其角色的管理，使參與者在自己角色范圍內(nèi)使用系統(tǒng)。每個(gè)參與者使用一個(gè)具有業(yè)務(wù)意義的名稱命名。需求獲取的首要任務(wù)就是識(shí)別主要參與者。識(shí)別參與者是需求提取的首要任務(wù)，誰(shuí)是系統(tǒng)的客戶，他們需要系統(tǒng)做什么，他們希望在什么時(shí)候、什么地點(diǎn)做，這些都是系統(tǒng)設(shè)計(jì)要考慮的重要因素。第16頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建?！美美菂⑴c者想要系統(tǒng)做的事情。具體表現(xiàn)為用戶如何使用系統(tǒng)來(lái)達(dá)到其目標(biāo)的一組情節(jié)。例如在超市，“處理銷售”的用例描述為：一個(gè)顧客攜帶欲采購(gòu)的商品到達(dá)收費(fèi)口。收銀員使用系統(tǒng)輸入商品信息，系統(tǒng)給出商品的清單和累加值。顧客交款。收銀員輸入支付信息，系統(tǒng)對(duì)付款信息進(jìn)行計(jì)算，更新庫(kù)存信息，并給出余額信息；系統(tǒng)打印購(gòu)物清單。顧客得到收據(jù)，然后攜帶商品離開。只有對(duì)用例表現(xiàn)出的情節(jié)進(jìn)行真實(shí)、完整、準(zhǔn)確地描述，才能捕捉到對(duì)系統(tǒng)需求有價(jià)值的東西。第17頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模—用例的粒度指導(dǎo)原則1：在進(jìn)行需求獲取時(shí)，應(yīng)專注于“基本業(yè)務(wù)過(guò)程”（EBP）級(jí)別的用例。基本業(yè)務(wù)過(guò)程：由一個(gè)人在某個(gè)時(shí)間某個(gè)地點(diǎn)執(zhí)行的一項(xiàng)任務(wù)，這個(gè)任務(wù)是對(duì)某一個(gè)業(yè)務(wù)事件的反應(yīng)，而且可以增加可度量的業(yè)務(wù)價(jià)值，并且能夠保持?jǐn)?shù)據(jù)狀態(tài)的一致。用例沒(méi)有層次結(jié)構(gòu)的概念，即用例就是系統(tǒng)參與者要系統(tǒng)幫助干的一件不可細(xì)分的事情，不存在把一個(gè)用例分解成粒度更小的用例。

EBP級(jí)別的用例就是用戶對(duì)系統(tǒng)的業(yè)務(wù)功能需求。在進(jìn)行需求獲取時(shí)，應(yīng)主要關(guān)注EBP級(jí)別的主要用例，通常稱他們?yōu)榛居美?。比基本用例粒度小的用例可能完不成“可度量的業(yè)務(wù)價(jià)值”的一件事情，比基本用例粒度大的用例可能需要多個(gè)參與者去完成或多個(gè)時(shí)間段去完成。用例的命名必須具有明顯的業(yè)務(wù)領(lǐng)域特征第18頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建?！美c目標(biāo)參與者都有自己的目標(biāo)，并使用系統(tǒng)來(lái)幫助自己實(shí)現(xiàn)目標(biāo)。一個(gè)EBP級(jí)別上的用例通常被稱為一個(gè)用戶目標(biāo)級(jí)別上的用例，以強(qiáng)調(diào)用例應(yīng)該幫助系統(tǒng)的用戶實(shí)現(xiàn)自己的目標(biāo)。（這里強(qiáng)調(diào)“用戶目標(biāo)級(jí)別”，不是企業(yè)目標(biāo)、組織目標(biāo)、系統(tǒng)目標(biāo)）。

“防盜”是企業(yè)級(jí)目標(biāo)，不是用戶級(jí)目標(biāo)，因此不是一個(gè)EBP。

“向系統(tǒng)證明身份并被驗(yàn)證”也不是一個(gè)EBP，因?yàn)樗鼪](méi)有增加可見的或可以度量的業(yè)務(wù)價(jià)值?！暗卿洝笔且粋€(gè)次要目標(biāo)，是為其它有用的事情服務(wù)的。如“我今天登錄了20次”不會(huì)留下任何有價(jià)值的東西。

“用戶管理”是系統(tǒng)目標(biāo)，不是用戶級(jí)目標(biāo)。第19頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建?！捎^察的返回值每個(gè)用例的實(shí)例產(chǎn)生了對(duì)特定參與者而言可觀察的返回值?？捎^察的返回值實(shí)際上是告訴參與者是否實(shí)現(xiàn)了其業(yè)務(wù)價(jià)值。如果一個(gè)用例不會(huì)告訴參與者任何東西，對(duì)參與者來(lái)說(shuō)，它沒(méi)有任何價(jià)值，這肯定不是參與者的目標(biāo)要求。第20頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模—場(chǎng)景場(chǎng)景：參與者與系統(tǒng)之間的一系列特定的活動(dòng)和交互，通常稱為“用例的實(shí)例”。場(chǎng)景是使用系統(tǒng)的一個(gè)特定情節(jié)或用例的一條執(zhí)行路徑。一個(gè)用例就是一個(gè)描述參與者使用系統(tǒng)來(lái)達(dá)到目標(biāo)的一組相關(guān)的成功場(chǎng)景和失敗場(chǎng)景的集合。例如，客戶在超市選擇購(gòu)買的商品后到收銀臺(tái)驗(yàn)貨和付款中，“收銀員掃描儀錄入商品數(shù)據(jù)顧客交款收銀員退余款打印購(gòu)物清單”是一個(gè)場(chǎng)景；同樣，“收銀員掃描儀錄入商品數(shù)據(jù)顧客交卡收銀員刷卡打印購(gòu)物清單”也是一個(gè)場(chǎng)景；“收銀員掃描儀錄入商品數(shù)據(jù)顧客交卡收銀員刷卡（卡中錢不足時(shí)）顧客交款收銀員退余款打印購(gòu)物清單”還是一個(gè)場(chǎng)景。場(chǎng)景可分為主要場(chǎng)景和次要場(chǎng)景。一個(gè)用例只有一個(gè)主要場(chǎng)景，但可以包含多個(gè)次要場(chǎng)景。每個(gè)場(chǎng)景表示參與者達(dá)到其目標(biāo)的一個(gè)情節(jié)。在主要場(chǎng)景中，如果與某一步所希望的事件不同，就會(huì)引出一個(gè)次要場(chǎng)景。。第21頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法—識(shí)別主要參與者系統(tǒng)主要參與者就是系統(tǒng)的業(yè)務(wù)用戶。在這里，我們反復(fù)強(qiáng)調(diào)“業(yè)務(wù)用戶”，因?yàn)殚_發(fā)一個(gè)軟件系統(tǒng)的目的就是為他們的業(yè)務(wù)工作服務(wù)的，這是系統(tǒng)的價(jià)值所在。在識(shí)別系統(tǒng)主要參與者時(shí)的首要工作就是列出所有系統(tǒng)最終用戶。任何人，只要他需要使用系統(tǒng)來(lái)行使自己的“職責(zé)”，哪怕只有一小點(diǎn)“職責(zé)”，他就是系統(tǒng)的主要參與者。主要參與者不是具體人，而是抽象的職能名。但也不能太抽象了，以致無(wú)法辨認(rèn)他們的腳色。有的主要參與者的大部分業(yè)務(wù)工作都可能需要系統(tǒng)支持，如學(xué)校的“教務(wù)管理員”，有的主要參與者可能很少使用系統(tǒng)，如各個(gè)“審批”人員，當(dāng)別人把所有工作都作了，他只需“審核”一下就行了。在識(shí)別主要參與者的過(guò)程中，最容易把這些大量的干“審核”或“審批”的主要參與者忽略掉，因?yàn)樗褂孟到y(tǒng)的時(shí)間很少，就認(rèn)為他不是主要參與者。第22頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法—識(shí)別系統(tǒng)業(yè)務(wù)一個(gè)業(yè)務(wù)（有時(shí)呈業(yè)務(wù)過(guò)程）指一件有始有終要干的事。多個(gè)業(yè)務(wù)之間可能沒(méi)有明顯的界限，需要對(duì)業(yè)務(wù)領(lǐng)域有深入的了解和豐富的經(jīng)驗(yàn)積累。如教學(xué)管理的業(yè)務(wù)科分為：教學(xué)計(jì)劃管理教學(xué)安排選課管理考試管理成績(jī)提交成績(jī)更正每個(gè)業(yè)務(wù)都有一個(gè)持續(xù)的時(shí)間區(qū)間，可能有多個(gè)人相互協(xié)作，有多個(gè)業(yè)務(wù)活動(dòng)按照一定順序和規(guī)則進(jìn)行。第23頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月用例建模方法—業(yè)務(wù)流程建模每個(gè)業(yè)務(wù)都有一個(gè)持續(xù)的時(shí)間區(qū)間，通過(guò)多人相互協(xié)作，使多個(gè)業(yè)務(wù)活動(dòng)按照一定順序和規(guī)則進(jìn)行，由此構(gòu)成了完整的業(yè)務(wù)流程。其中的每一個(gè)業(yè)務(wù)活動(dòng)的完成都對(duì)應(yīng)著一個(gè)用戶目標(biāo)，實(shí)現(xiàn)這些目標(biāo)的軟件功能都可以抽象為一個(gè)EBP級(jí)別的用例。業(yè)務(wù)流程分析是最關(guān)鍵的需求分析，是系統(tǒng)功能需求的主要來(lái)源，可以捕捉80%的功能需求。遵循的基本原則：每個(gè)業(yè)務(wù)活動(dòng)只有一個(gè)人在特定的地點(diǎn)和特定的時(shí)間完成。無(wú)論再小的事情，如果要多個(gè)人完成、或必須在多個(gè)時(shí)間完成、或可能（必須）在多個(gè)地點(diǎn)完成，就要分解成多個(gè)業(yè)務(wù)活動(dòng)。

第24頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月業(yè)務(wù)流程描述工具—活動(dòng)圖橢圓：活動(dòng)。分叉：并發(fā)轉(zhuǎn)移匯合：并發(fā)后的交匯分支：條件轉(zhuǎn)移合并開始狀態(tài)：可選結(jié)束狀態(tài)：可選第25頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月業(yè)務(wù)流程描述工具—活動(dòng)圖泳道：把一個(gè)活動(dòng)圖的矩形框垂直分成若干個(gè)區(qū)域，每個(gè)區(qū)域?yàn)橐粋€(gè)泳道，對(duì)應(yīng)著一個(gè)業(yè)務(wù)參與者。將參與者參與的活動(dòng)畫在該矩形區(qū)域內(nèi)。

帶有泳道的活動(dòng)圖被認(rèn)為是業(yè)務(wù)建模的最優(yōu)秀的方法和工具。

學(xué)生教師系主任院長(zhǎng)教務(wù)員第26頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月業(yè)務(wù)流程描述工具—活動(dòng)圖實(shí)例

學(xué)生教師系主任院長(zhǎng)教務(wù)員提交成績(jī)更改申請(qǐng)?zhí)峤怀煽?jī)更改意見更改更改確認(rèn)更改確認(rèn)成績(jī)更改成績(jī)更改查閱YN成績(jī)更改業(yè)務(wù)流程第27頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法—建立基本用例模型如果活動(dòng)圖中每個(gè)活動(dòng)只限于一個(gè)泳道，在一個(gè)地點(diǎn)一個(gè)時(shí)間內(nèi)可以完成，則一個(gè)活動(dòng)就是一個(gè)EBP級(jí)的用例。所謂基本用例指一個(gè)EBP級(jí)別的用例。基本用例模型指由基本用例構(gòu)成的系統(tǒng)功能模型。在基本用例模型中，除了參與者與用例之間的關(guān)聯(lián)關(guān)系外，用例之間是相互獨(dú)立的。這種獨(dú)立性是用例完整性的體現(xiàn)?；居美Ｐ椭械膮⑴c者就是系統(tǒng)權(quán)限管理中的角色?；居美Ｐ椭械挠美窍到y(tǒng)權(quán)限分配的基本對(duì)象。參與者與基本用例的關(guān)聯(lián)關(guān)系就是系統(tǒng)中角色與資源（功能模塊）之間的映射關(guān)系。所以，基本用例模型是系統(tǒng)角色與權(quán)限管理設(shè)計(jì)的依據(jù)。每個(gè)用例是系統(tǒng)實(shí)現(xiàn)的基本功能單元。第28頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法--基本用例模型—用例圖用例圖：以用例為基礎(chǔ)的系統(tǒng)功能模型的圖式表示，是用例模型的抽象描述。用例圖包括參與者（角色）、系統(tǒng)邊界、用例、參與者與用例的關(guān)聯(lián)關(guān)系。系統(tǒng)邊界用矩形框表示。通過(guò)矩形框的邊線明確劃分系統(tǒng)內(nèi)和系統(tǒng)外。用例用橢圓表示，橢圓內(nèi)放用例名。用例放在矩形框內(nèi)，表示是系統(tǒng)內(nèi)部元素。參與者用“稻草人”圖符表示。參與者放在矩形框外，表示參與者是與系統(tǒng)有關(guān)的外部元素，是系統(tǒng)的直接使用者。系統(tǒng)名放在矩形框內(nèi)頂部。第29頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法--基本用例模型—用例圖例提交成績(jī)更改申請(qǐng)?zhí)峤怀煽?jī)更改意見成績(jī)更改查閱更改確認(rèn)成績(jī)更改學(xué)生教務(wù)員教師系主任院長(zhǎng)第30頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法--基本用例模型—用例規(guī)約一個(gè)用例在功能上具有完整性。首先，從系統(tǒng)的角度而言，每個(gè)用例都必須從輸入開始，直到產(chǎn)生結(jié)果輸出給參與者，否則就不成其為一個(gè)用例。其二，用例刻畫系統(tǒng)的功能需求，但它不是簡(jiǎn)單地記錄功能需求，而是要完整地描述系統(tǒng)功能，包括用例執(zhí)行的步驟、執(zhí)行過(guò)程中可能產(chǎn)生的諸多變化情況、錯(cuò)誤情況和異常情況。所以，用例圖只是系統(tǒng)功能的抽象描述，還必須通過(guò)用例規(guī)格說(shuō)明進(jìn)行詳細(xì)描述，才能充分反映用例所包含的內(nèi)涵。第31頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法—用例關(guān)聯(lián)用例可以相互關(guān)聯(lián)，用關(guān)系來(lái)描述用例之間的關(guān)聯(lián)。關(guān)系只是一種組織機(jī)制，用于改善用例的交流和理解，減少文本的重復(fù)說(shuō)明。在用例建模中，為了使用例更簡(jiǎn)潔，在用例模型中引入了兩種關(guān)系：包含關(guān)系（include）（也稱使用關(guān)系（uses））擴(kuò)展關(guān)系（extend）第32頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法--用例關(guān)聯(lián)—包含關(guān)系

包含關(guān)系（include或use）指一個(gè)用例包含另一個(gè)用例。被包含的用例通常是包含用例的一部分，即是包含用例對(duì)應(yīng)的功能需求的子功能。在用例模型中，如果發(fā)現(xiàn)某些用例具有部分相似的行為。則可以把這部分相似的行為抽取出來(lái)單獨(dú)作為一個(gè)“抽象用例”供它們使用，由此構(gòu)成了用例之間的“包含”關(guān)系。必須強(qiáng)調(diào)被包含用例一定是包含用例的一部分，具體體現(xiàn)在：如果包含用例被執(zhí)行，被包含用例一定被執(zhí)行。指導(dǎo)原則：當(dāng)兩個(gè)或兩個(gè)以上獨(dú)立的用例中有重復(fù)的內(nèi)容而要想避免這種重復(fù)時(shí)，可以應(yīng)用包含關(guān)系。在上例中，教師“提交成績(jī)更改意見”和主管責(zé)任人“更改確認(rèn)”都要先“查詢成績(jī)更改單”，所以可以把“查詢成績(jī)更改單”作為兩個(gè)基本用例的被包含用例。第33頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法--用例關(guān)聯(lián)—擴(kuò)展關(guān)系

每個(gè)基本用例，都有一個(gè)基本的成功場(chǎng)景。除此之外，可能還有其它成功場(chǎng)景。對(duì)其它成功場(chǎng)景，可以用一個(gè)擴(kuò)展用例來(lái)描述。擴(kuò)展關(guān)系指一個(gè)用例的某個(gè)行為可能被另一個(gè)用例擴(kuò)展。如顧客在超市購(gòu)買商品，一般用現(xiàn)金支付，但還有其他支付，如儲(chǔ)蓄卡、代購(gòu)卷支付?？梢园选艾F(xiàn)金支付”作為“基本”行為，把其他每種支付作為一個(gè)“特殊”行為。在用例建模中，把這種“特殊”行為作為擴(kuò)展用例。被擴(kuò)展的用例本身是完整的，擴(kuò)展用例只是在遇到對(duì)應(yīng)特殊情況時(shí)才可能被調(diào)用執(zhí)行。指導(dǎo)原則：對(duì)插入基用例的條件或可選行為建模。如“提交成績(jī)更改申請(qǐng)”過(guò)程中，可以增加“保存申請(qǐng)草稿”和“讀取申請(qǐng)草稿”可以顯得更靈活一些。第34頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月需求建模方法--優(yōu)化后的用例建模提交成績(jī)更改申請(qǐng)?zhí)峤怀煽?jī)更改意見成績(jī)更改查閱更改確認(rèn)成績(jī)更改學(xué)生教務(wù)員教師系主任院長(zhǎng)保存申請(qǐng)草稿讀取申請(qǐng)草稿查詢成績(jī)更改單Includeextend第35頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建模—基本任務(wù)

分析的基礎(chǔ)是用例模型，最重要的是用例規(guī)格說(shuō)明。分析的基本任務(wù)是從用例規(guī)格說(shuō)明中提取出重要的業(yè)務(wù)領(lǐng)域概念，建立領(lǐng)域模型。領(lǐng)域模型是系統(tǒng)分析師對(duì)待開發(fā)系統(tǒng)所屬領(lǐng)域的理解，是對(duì)用例模型中所涉及的對(duì)象及其關(guān)系的抽象。因此：領(lǐng)域模型不是與用戶交流的工具，而是對(duì)領(lǐng)域抽象的工具，因?yàn)轭I(lǐng)域用戶只能提出要求系統(tǒng)做什么，基本上不知道、也不懂得計(jì)算機(jī)領(lǐng)域有關(guān)對(duì)象的概念。業(yè)務(wù)流程圖和用例模型才是與用戶交流的工具。第36頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建?！I(lǐng)域模型

領(lǐng)域是待建軟件系統(tǒng)所面對(duì)的特定的業(yè)務(wù)領(lǐng)域。領(lǐng)域模型是對(duì)實(shí)際業(yè)務(wù)領(lǐng)域的抽象，它“穿透”用戶想要的功能的表象，專注于分析業(yè)務(wù)領(lǐng)域本身，發(fā)掘重要的、最為穩(wěn)固的業(yè)務(wù)領(lǐng)域概念，并建立業(yè)務(wù)領(lǐng)域概念之間的關(guān)系。在領(lǐng)域建模中，一個(gè)被管理領(lǐng)域?qū)ο缶褪且粋€(gè)概念類。即一個(gè)概念類就是觀察問(wèn)題的一個(gè)視點(diǎn)、事物或者對(duì)象。領(lǐng)域模型是意義顯著的領(lǐng)域概念和詞匯的一個(gè)可視化表示。也稱為概念模型、領(lǐng)域?qū)ο竽Ｐ?。領(lǐng)域建模是面向?qū)ο蠓治龅暮诵墓ぷ鳌?/p>

特別聲明：領(lǐng)域模型中只涉及領(lǐng)域概念，表示的概念是特定領(lǐng)域（問(wèn)題域）的概念（如訂單，發(fā)票，提貨單），而不是訂單關(guān)系表、提貨關(guān)系表、接口、方法等，不涉及與系統(tǒng)實(shí)現(xiàn)相關(guān)的任何計(jì)算機(jī)術(shù)語(yǔ)。

領(lǐng)域模型不會(huì)因系統(tǒng)功能變化而變化。第37頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建?！I(lǐng)域模型的表示

建立領(lǐng)域模型時(shí)，通常用類圖和狀態(tài)圖來(lái)描述。在UML中，領(lǐng)域模型可以用不定義操作。第38頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建模—領(lǐng)域概念的識(shí)別

領(lǐng)域概念的明顯特點(diǎn)是問(wèn)題領(lǐng)域中的專門名詞—領(lǐng)域詞匯。例如在線拍賣系統(tǒng)的詞匯表為：拍賣：一種銷售方式，將拍賣項(xiàng)賣給競(jìng)拍價(jià)格最高者。拍賣活動(dòng)：一次拍賣的組織。拍賣項(xiàng)：拍賣的物品的統(tǒng)稱。起拍價(jià)：一開始的競(jìng)拍最低價(jià)成交價(jià)：拍賣結(jié)束時(shí)刻的最高競(jìng)拍價(jià)。買家：參與競(jìng)買者。賣家：提供貨物，并以拍賣方式出售貨物者。成交：以符合拍賣活動(dòng)規(guī)則的方式，拍賣項(xiàng)的所有權(quán)從賣家過(guò)讓為競(jìng)拍價(jià)格最高的買家，買家按成交價(jià)支付。詞匯表中的詞匯不一定都是領(lǐng)域模型中的類名稱，但一定包含了所有類名稱：拍賣活動(dòng)、拍賣項(xiàng)、買家（“喊出”成交價(jià)的買家）、賣家。一些詞匯描述了對(duì)象之間關(guān)聯(lián)，如“成交”，或者對(duì)象的關(guān)鍵屬性，如“起拍價(jià)”、“成交價(jià)”。第39頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建模--拍賣領(lǐng)域模型

第40頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建模--領(lǐng)域概念類的識(shí)別

產(chǎn)品訂購(gòu)單第41頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域概念類的識(shí)別

領(lǐng)域概念類：產(chǎn)品訂購(gòu)單：屬性包括：編號(hào)，填單日期，要求發(fā)貨日期，實(shí)際發(fā)貨日期訂購(gòu)車輛：訂單的一行描述了一個(gè)訂購(gòu)的車輛。屬性包括：編號(hào)，其它特征，數(shù)量。表格中，型號(hào)、駕駛室、后橋、車廂、柴油機(jī)、輪胎等稱為產(chǎn)品的配置，但又是一種產(chǎn)品，有它們自身的屬性，表格中只填它們的標(biāo)識(shí)碼。其中“型號(hào)”不是一個(gè)簡(jiǎn)單代碼，而是代表一種車型，所以“型號(hào)”用概念類“車型”更容易理解一些。訂貨單位、訂貨單位負(fù)責(zé)人、銷售部、業(yè)務(wù)員、評(píng)審人、匯款單等都是與訂單相關(guān)的概念。第42頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月領(lǐng)域建模--產(chǎn)品訂購(gòu)領(lǐng)域模型

第43頁(yè)，課件共50頁(yè)，創(chuàng)作于2023年2月規(guī)格說(shuō)明概念類

用領(lǐng)域概念類描述對(duì)象可能存在的問(wèn)題：對(duì)象信息因?qū)ο蟠嬖诙嬖?，因?qū)ο髣h除而消失。如車型信息、車輛配置信息。實(shí)際上，車輛信息在車輛沒(méi)有銷售之前已經(jīng)存在了?？捎靡?guī)格說(shuō)明概念類來(lái)描述這些信息。這類概念類只有屬性，沒(méi)有行為能力。在圖書管理中，書的信息獨(dú)立于書的存在。人們通常先看到書的信息后才決定是否獲取書。下面情況下需要規(guī)格說(shuō)明概念類：（1