需求提取與分析

1、目錄第1部分 需求概述11.1需求分析概述11.1.1需求定義11.1.2需求分析概述11.2需求分類21.2.1軟件運(yùn)行期質(zhì)量21.2.2軟件開發(fā)期質(zhì)量31.2.3約束31.2.4不同類型需求對設(shè)計(jì)的影響31.3需求的層次性41.4需求的易變更性41.5需求捕捉的工具41.6需求分析內(nèi)容51.6.1確定業(yè)務(wù)目標(biāo)51.6.2確定業(yè)務(wù)領(lǐng)域范圍及業(yè)務(wù)流程51.6.3建立用例模型51.6.4建立用例規(guī)約61.6.5確定系統(tǒng)非功能需求6第二部分 需求提取與需求建模72.1需求建?；靖拍?2.1.1參與者72.1.2用例72.1.3場景82.1.4用例規(guī)格說明92.2用例建模122.2.1識別系統(tǒng)主要

2、參與者122.2.2識別系統(tǒng)的業(yè)務(wù)和業(yè)務(wù)流程122.2.3業(yè)務(wù)流程描述工具活動(dòng)圖132.2.4建立基本用例模型142.2.5建立用例之間的關(guān)系152.3應(yīng)用實(shí)例某汽車制造廠車輛訂購用例模型162.2.1參與者分析162.3.2車輛訂購業(yè)務(wù)流程分析業(yè)務(wù)建模172.3.3車輛訂購基本用例模型182.3.4車輛訂購用例模型優(yōu)化192.4系統(tǒng)順序圖21第3部分 分析與領(lǐng)域建模233.1分析的基本任務(wù)233.2 領(lǐng)域模型的基本概念233.2.1領(lǐng)域模型233.2.2領(lǐng)域模型的表示233.2.3領(lǐng)域概念類識別253.2.4規(guī)格說明概念類273.3領(lǐng)域模型的重要性283.3類對象間的關(guān)系293.3.1繼承關(guān)

3、系（inheritance）293.3.2聚合關(guān)系303.3.3關(guān)聯(lián)關(guān)系303.3.4關(guān)聯(lián)類313.3.5受限關(guān)聯(lián)313.3.6與時(shí)間間隔有關(guān)的屬性的處理323.4建立領(lǐng)域模型323.5領(lǐng)域模型的優(yōu)化323.6領(lǐng)域概念類的屬性333.7使用包來組織領(lǐng)域模型333.8領(lǐng)域概念類與設(shè)計(jì)類、軟件類的表示差別333.9應(yīng)用實(shí)例343.9.1候選概念類提取343.9.2概念類間關(guān)系的建立353.9.3產(chǎn)品訂購領(lǐng)域模型353.9.4產(chǎn)品訂購包模型363.10 er模型與領(lǐng)域模型之間的內(nèi)在聯(lián)系361數(shù)據(jù)庫設(shè)計(jì)概述381.1數(shù)據(jù)庫設(shè)計(jì)的基礎(chǔ)性381.2 數(shù)據(jù)庫設(shè)計(jì)模型381.3 基本概念381.4數(shù)據(jù)庫設(shè)計(jì)的

4、內(nèi)容391.5數(shù)據(jù)庫設(shè)計(jì)中的誤解392數(shù)據(jù)庫概念模型設(shè)計(jì)402.1實(shí)體的識別412.2實(shí)體間聯(lián)系的識別412.3概念模型設(shè)計(jì)應(yīng)遵從的原則422.4應(yīng)該注意的問題422.3數(shù)據(jù)庫概念模型設(shè)計(jì)實(shí)例432.3.1五征產(chǎn)品訂貨432.3.2東風(fēng)銷售管理473數(shù)據(jù)庫邏輯模型設(shè)計(jì)523.1轉(zhuǎn)換原則523.2數(shù)據(jù)庫邏輯設(shè)計(jì)應(yīng)用實(shí)例533.2.1五征產(chǎn)品計(jì)劃單數(shù)據(jù)庫邏輯設(shè)計(jì)533.2.2東風(fēng)汽車訂購數(shù)據(jù)庫邏輯設(shè)計(jì)543.2.3東風(fēng)汽車銷售數(shù)據(jù)庫邏輯設(shè)計(jì)544數(shù)據(jù)庫優(yōu)化設(shè)計(jì)554.1表的合并554.3表的縱向分解564.4表的橫向分解574.5中間表的使用585數(shù)據(jù)庫索引585.1理論基礎(chǔ)-數(shù)據(jù)庫表索引的組織5

5、85.2數(shù)據(jù)庫索引的建立585.3序列號的利與弊59第1部分 需求概述1.1需求分析概述1.1.1需求定義軟件需求是“用戶到底需要軟件為他/她做什么”。ieee對需求的定義：1.用戶所需的解決某個(gè)問題或達(dá)到某個(gè)目標(biāo)所要具備的條件或能力；2.系統(tǒng)或系統(tǒng)組件為符合合同、標(biāo)準(zhǔn)、規(guī)范或其它正式文檔而必須滿足的條件或必須具備的能力；3.上述第一項(xiàng)或第二項(xiàng)中定義的條件和能力的文檔表述。rup對需求的定義：需求描述了系統(tǒng)必須滿足的條件或提供的能力，它可以是直接來自客戶需要，也可以來自合同、標(biāo)準(zhǔn)、規(guī)范或其它有正規(guī)約束力的文檔。根據(jù)上面的定義，需求的本質(zhì)是：系統(tǒng)必須提供的能力和必須滿足的條件。需求的表示形式是：

6、系統(tǒng)“應(yīng)該做什么的規(guī)格說明”。需求分析的目的是：揭示系統(tǒng)應(yīng)該做什么并達(dá)成一致。需求的最根本的挑戰(zhàn)在于：交流并記錄什么是真正需要的，并能夠清楚地向用戶和開發(fā)團(tuán)隊(duì)的成員講解。1.1.2需求分析概述需求分析是軟件工程學(xué)的經(jīng)典術(shù)語之一，名符其實(shí)的含義是對用戶需求進(jìn)行分析，旨在產(chǎn)生一份明確、規(guī)范的需求定義。從這個(gè)意義上講“分析是解決做什么而不是解決怎么做的問題”是無愧無挑剔的。通常用“做什么”和“怎么做”來區(qū)分“分析”和“設(shè)計(jì)”，但人們在“做什么”和“怎么做”的問題上總會(huì)出現(xiàn)理解上的含糊不清。問題的根源在于人們對軟件工程中“分析”這個(gè)術(shù)語的含義有不同的理解-有時(shí)把它作為“需求分析”的簡稱，有時(shí)是指“系統(tǒng)

7、分析”，有時(shí)則作為需求分析和系統(tǒng)分析的總稱。但迄今為止的各種分析方法（包括結(jié)構(gòu)化分析和面向?qū)ο蠓治觯┲?，真正屬于需求分析的?nèi)容所占的分量并不大，更多的內(nèi)容是給出一種系統(tǒng)建模方法（包括一種表示法和相應(yīng)的建模過程指導(dǎo)），告訴分析員如何建立一個(gè)能夠滿足（由需求定義所描述的）用戶需求的系統(tǒng)模型。分析員大量的工作是對系統(tǒng)的應(yīng)用領(lǐng)域進(jìn)行調(diào)查和研究并抽象地表示這個(gè)系統(tǒng)。確切地講，這些工作應(yīng)該叫做系統(tǒng)分析，而不是需求分析。它既是對“做什么”問題的進(jìn)一步明確，也在相當(dāng)程度上涉及到“怎么做”的問題。在一般的需求論述中，需求分析包括需求調(diào)研和需求分析。需求調(diào)研是需求獲?。ɑ虿蹲剑┑倪^程，所以把需求調(diào)研稱為“需求獲取

8、”或“需求捕捉”，需求分析的目的和結(jié)果是對需求進(jìn)行準(zhǔn)確定義。所謂“準(zhǔn)確定義”是弄清用戶的真正需求，包括企業(yè)決策層的期望（開發(fā)目標(biāo)）和直接使用系統(tǒng)的用戶的需求（決策層人員可能不直接使用系統(tǒng)，但對系統(tǒng)的期望更大、更高，系統(tǒng)更應(yīng)該努力去實(shí)現(xiàn)決策層的意圖），把這些需求用文字和圖表的形式描述出來，并且其描述沒有二義性。但一般的自然語言很難做到無二義性描述，沒有理論指導(dǎo)也可能使需求描述帶有任意性，用特定的分析方法和對應(yīng)的建模工具來“準(zhǔn)確定義”需求以減少二義性，是普遍采用的方法。用這些分析方法和工具定義需求的過程稱為“建模”，用結(jié)構(gòu)化分析方法建立的需求模型稱為系統(tǒng)的邏輯模型（功能模型），用面向?qū)ο蠓治龇椒ń?/p>

9、立的模型稱為領(lǐng)域（對象）模型。這些模型往往不是用于與用戶交流，主要是用于系統(tǒng)開發(fā)人員之間的交流。在建立模型過程中和所建立的模型已經(jīng)“在相當(dāng)程度上涉及到怎么做的問題”，建模元素的選擇和粒度的把握都與“怎么做”有關(guān)，只是在一個(gè)非常高的抽象層上考慮“怎么做”的問題，或者說是在意識上參雜了今后“怎么做”的因素。建立得好的需求分析模型與設(shè)計(jì)模型有很好的映射關(guān)系，也是在很大程度上考慮了今后“怎么做”的問題。在傳統(tǒng)的軟件工程中，需求分析作為軟件生存周期的一個(gè)階段，盡管有需求獲取和分析的兩個(gè)任務(wù)，這兩個(gè)任務(wù)沒有嚴(yán)格地劃分時(shí)間段，在需求獲取過程中要進(jìn)行分析，在分析過程中要不斷地進(jìn)行調(diào)研和完善。那時(shí)，沒有嚴(yán)格地區(qū)

10、分需求獲取的工具是什么，需求分析的工具是什么，都是采用數(shù)據(jù)流圖和數(shù)據(jù)字典。這兩個(gè)任務(wù)總是交叉重復(fù)地進(jìn)行，直到所建立的系統(tǒng)需求模型（數(shù)據(jù)流程圖系統(tǒng)邏輯模型）達(dá)到用戶要求為止，需求提取的工具和分析的工具都是相同的工具。而且也明確地指出需求分析報(bào)告主要用于用戶交流，作為用戶和開發(fā)者之間的契約，是需求驗(yàn)收的依據(jù)。在統(tǒng)一過程和uml提出后，特別是軟件迭代開發(fā)方法提出后，把需求和分析分成了兩個(gè)不同的階段，有時(shí)也叫需求獲?。ɑ蛐枨蟛东@）和需求分析，每個(gè)階段有完全不同的目標(biāo)和任務(wù)，包括建模工具和建立的模型都完全不同。需求捕捉階段主要采用用例模型捕捉功能需求，需求分析階段主要采用對象模型，建立領(lǐng)域?qū)ο箝g的協(xié)作關(guān)

11、系。但是，雖然把需求捕捉和需求分析劃分為兩個(gè)階段，但它們卻是相互伴隨、交叉進(jìn)行的，很難有區(qū)分的界限。需求獲取所建立的模型主要用于與用戶交流，需求分析模型是開發(fā)組織自己的文檔，根本無法用于與用戶交流，也不用于與用戶交流。隨著軟件工程研究的發(fā)展，軟件組件技術(shù)的廣泛使用，軟件的敏捷構(gòu)造越來越受到關(guān)注。軟件敏捷構(gòu)造的核心是保持軟件組件與領(lǐng)域業(yè)務(wù)的一致性，即組件與業(yè)務(wù)對齊。如果做到了組件與業(yè)務(wù)對齊，企業(yè)業(yè)務(wù)的重組只需要對軟件組件間的關(guān)系重定義，這正是軟件工程要達(dá)到的理想目標(biāo)。要做到這一點(diǎn)，對軟件需求提出了很高的要求需要從組織或領(lǐng)域體系結(jié)構(gòu)要識別和捕捉領(lǐng)域需求。1.2需求分類需求可分為兩類：（1）功能性需

12、求-系統(tǒng)應(yīng)該提供什么功能。（2）非功能需求-系統(tǒng)的特定特性或約束。軟件需求功能需求非功能需求質(zhì)量屬性約束運(yùn)行期質(zhì)量屬性開發(fā)期質(zhì)量屬性系統(tǒng)的特定特性主要指系統(tǒng)的質(zhì)量屬性。系統(tǒng)質(zhì)量屬性可分為軟件運(yùn)行期質(zhì)量屬性和軟件開發(fā)期質(zhì)量屬性。1.2.1軟件運(yùn)行期質(zhì)量軟件運(yùn)行期質(zhì)量指用戶在使用軟件過程中對軟件質(zhì)量的要求，包括易用性（人性化因素、幫助等）、性能（響應(yīng)時(shí)間、吞吐量、準(zhǔn)確性、有效性、資源利用率）、安全性、可伸縮性、持續(xù)可用性、互操作性、可靠性和魯棒性。通常把軟件運(yùn)行期質(zhì)量稱為軟件外部質(zhì)量，即用戶能夠直接感受到的質(zhì)量。易用性：指軟件系統(tǒng)容易使用的程度。性能：指軟件系統(tǒng)及時(shí)提供相應(yīng)服務(wù)的能力。性能包括響應(yīng)

13、時(shí)間（也稱速度）、吞吐量（單位時(shí)間處理的交易數(shù)）、持續(xù)高速性（保持持續(xù)高速處理的能力-在網(wǎng)絡(luò)系統(tǒng)中，這點(diǎn)是很難的）。一個(gè)系統(tǒng)可能保證典型操作的快速響應(yīng)，但不一定能保證持續(xù)高速。性能和效率是同一問題的“表”、“理”的兩個(gè)方面，性能為“表”，效率為“里”。效率指軟件系統(tǒng)對cpu處理器和存儲器這兩大資源的處理效率。安全性：指軟件系統(tǒng)同時(shí)兼顧向合法用戶提供服務(wù)，以及防止非授權(quán)使用的能力。持續(xù)可用性：指軟件長時(shí)間無故障運(yùn)行的能力。如有的系統(tǒng)要求提供7*24小時(shí)服務(wù)就是持續(xù)可用性的要求?？缮炜s性：指當(dāng)用戶數(shù)量和數(shù)據(jù)量增加時(shí)，軟件系統(tǒng)維持高服務(wù)質(zhì)量的能力?；ゲ僮餍裕褐副拒浖到y(tǒng)與其它軟件系統(tǒng)交換數(shù)據(jù)和相互調(diào)

14、用服務(wù)的難易程度?？煽啃裕很浖到y(tǒng)在一定時(shí)間內(nèi)無故障運(yùn)行的能力。魯棒性：也稱健壯性、容錯(cuò)性。指軟件系統(tǒng)在用戶進(jìn)行了非法操作、相連的軟硬件系統(tǒng)發(fā)生了故障、以及其他非正常情況的時(shí)候，系統(tǒng)仍能正常運(yùn)行的能力。有時(shí)也把持續(xù)可用性、魯棒性也歸類為可靠性。這時(shí)的可靠性就不是特指某種能力，而是一般意義下的可靠性。在軟件開發(fā)過程中，需要對上述特性中特別指出的特性進(jìn)行特殊設(shè)計(jì)，特別是要通過架構(gòu)設(shè)計(jì)來保證，即成為架構(gòu)設(shè)計(jì)關(guān)注的重點(diǎn)。1.2.2軟件開發(fā)期質(zhì)量軟件開發(fā)期質(zhì)量：為保證軟件的可維護(hù)性而在軟件開發(fā)過程中應(yīng)該關(guān)注的軟件質(zhì)量屬性，包括軟件的可擴(kuò)展性、可重用性、可移植性、易理解性、易測試性和可維護(hù)性。軟件開發(fā)期質(zhì)

15、量屬性稱為“軟件內(nèi)部質(zhì)量屬性”，即不深入到軟件代碼內(nèi)部是無法覺察到的軟件質(zhì)量屬性。這部分軟件質(zhì)量屬性往往不會(huì)被用戶通過需求的形式提出，而是軟件開發(fā)團(tuán)隊(duì)?wèi)?yīng)該自覺地保證，所以有的學(xué)者將其稱為隱含質(zhì)量屬性?？蓴U(kuò)展性：為適應(yīng)新需求或需求變化為軟件增加功能的能力。有時(shí)稱為靈活性?？芍赜眯裕褐赜密浖到y(tǒng)或其一部分的能力的難易程度?？蓽y試性：對軟件測試以證明滿足需求規(guī)約的難易程度。在實(shí)際工作中主要指進(jìn)行單元測試，插樁測試的難易程度?？删S護(hù)性：在修改bug、增加功能、提高質(zhì)量屬性等而定位修改點(diǎn)并適時(shí)修改的難易程度?？梢浦残裕簩④浖到y(tǒng)從一個(gè)運(yùn)行環(huán)境轉(zhuǎn)移到另一個(gè)運(yùn)行環(huán)境的難易程度。易理解性：設(shè)計(jì)被開發(fā)人員理解的

16、難易程度。任何一個(gè)開發(fā)期質(zhì)量屬性的滿足都可能增加軟件開發(fā)成本。1.2.3約束系統(tǒng)的約束是需求獲取的重要內(nèi)容。約束不是行為，是設(shè)計(jì)或項(xiàng)目的限制條件。這些限制條件也屬于需求，但通常稱為約束來強(qiáng)調(diào)其限制性。這些約束是在系統(tǒng)開發(fā)前已經(jīng)存在的一些事實(shí)或因素，新系統(tǒng)的開發(fā)無法回避這些事實(shí)或因素。約束主要包括：系統(tǒng)開發(fā)的資源約束：如網(wǎng)絡(luò)環(huán)境、操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)、開發(fā)工具、硬件等。新系統(tǒng)的開發(fā)必須以這些現(xiàn)有資源為基礎(chǔ)，軟件架構(gòu)（特別是系統(tǒng)的運(yùn)行架構(gòu)和物理架構(gòu)）必須考慮這些資源的有效利用和限制（實(shí)現(xiàn)技術(shù)的限制）。接口約束：如與本系統(tǒng)關(guān)聯(lián)的系統(tǒng)是哪些，其接口約束是什么。新系統(tǒng)可能接受其它系統(tǒng)提供的數(shù)據(jù)作為輸

17、入，其輸出數(shù)據(jù)作為其它系統(tǒng)的輸入。操作約束：如系統(tǒng)操作環(huán)境中的管理要求。如身份認(rèn)證必須通過第三方認(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ī)章等。在現(xiàn)行的軟件開發(fā)中，軟件需方單位的信息化往往不是從零開始，而是有相當(dāng)?shù)幕A(chǔ)，他們對新系統(tǒng)的開發(fā)具有極大的約束。如開發(fā)的系統(tǒng)是某個(gè)大系統(tǒng)的子系統(tǒng)，大系統(tǒng)已經(jīng)開發(fā)了一部分，該子系統(tǒng)必須滿足于已開發(fā)部分的相互約束關(guān)系，必須為后續(xù)子系統(tǒng)奠定某些基礎(chǔ)。新開發(fā)的系統(tǒng)可以直接從某個(gè)或某些現(xiàn)有系統(tǒng)中獲得原始數(shù)據(jù)等。這些都是新系統(tǒng)開發(fā)最重要的約束。1.2.4不同類型需求對設(shè)計(jì)的影響功能需求影響

18、軟件架構(gòu)，而軟件架構(gòu)必須適應(yīng)功能需求的變化。但功能需求并不決定軟件架構(gòu)。質(zhì)量需求主要影響系統(tǒng)的架構(gòu)設(shè)計(jì)，在功能需求確定的情況下，系統(tǒng)架構(gòu)設(shè)計(jì)主要針對非功能需求。在軟件設(shè)計(jì)中，軟件架構(gòu)設(shè)計(jì)對功能性需求的主要考慮是高適應(yīng)性。約束性需求將直接影響系統(tǒng)的架構(gòu)設(shè)計(jì)；此外，有的約束性需求將轉(zhuǎn)化為功能需求，如“銀行系統(tǒng)必須執(zhí)行統(tǒng)一的利率”是對開發(fā)銀行系統(tǒng)的一條約束，該約束使待開發(fā)的系統(tǒng)必須提供調(diào)整利率的使用功能；約束還可能轉(zhuǎn)化為質(zhì)量束性需求，如系統(tǒng)預(yù)期用戶的計(jì)算機(jī)應(yīng)用水平普遍不高，因此要求待開發(fā)的系統(tǒng)有較高的易用性。實(shí)踐證明，忽略質(zhì)量屬性和約束性要求，必然導(dǎo)致系統(tǒng)失敗。結(jié)論：軟件架構(gòu)要主動(dòng)適應(yīng)功能需求的變化

19、，要從根本上支持軟件質(zhì)量屬性要求，必須遵守約束的限制。1.3需求的層次性組織的不同層次人員對需求有不同的要求。由不同層次人員的需求構(gòu)成需求的三個(gè)層次：業(yè)務(wù)需求：組織要達(dá)到的目標(biāo)業(yè)務(wù)目標(biāo)用戶需求：用戶使用系統(tǒng)來做什么行為需求：開發(fā)人員需要實(shí)現(xiàn)什么對高層管理人員而言，希望軟件系統(tǒng)能幫助他們達(dá)到業(yè)務(wù)目標(biāo)。對系統(tǒng)實(shí)際使用人員而言，希望系統(tǒng)提供的能力能輔助他們更好地完成日常業(yè)務(wù)工作。對開發(fā)人員來說，為了滿足用戶諸多需求、或滿足不同用戶需求、或滿足不同層次用戶需求，而覺察到的需求（如果不補(bǔ)充這些需求，要滿足用戶覺察到的需求就顯得比較困難）。高層管理人員的需求與系統(tǒng)實(shí)際使用人員的需求可以起到相互驗(yàn)證和印證的

20、作用。通過實(shí)際使用者的需求來印證達(dá)到高層管理人員的業(yè)務(wù)目標(biāo)要求，從中可以發(fā)掘出一些需求。用管理者的業(yè)務(wù)目標(biāo)要求來驗(yàn)證實(shí)際使用者需求的范圍和合理性（業(yè)務(wù)流程）。需求層次的關(guān)注在于在需求之間建立起“可跟蹤性”，避免因遺漏需求而造成軟件“達(dá)不到要求”，也避免開發(fā)人員一廂情愿地為用戶“制造”沒有實(shí)際意義的無用功能。從需求的層次性看，需求并不完全是“用戶的要求”，除了直接使用系統(tǒng)的“用戶”的要求外，還包括并不直接使用系統(tǒng)的“高層管理人員”的要求，和開發(fā)系統(tǒng)的開發(fā)人員的要求。在系統(tǒng)開發(fā)過程中，他們的要求同樣要得到滿足。如果不關(guān)注“高層管理人員”的要求，系統(tǒng)開發(fā)就沒有明確的目標(biāo)，系統(tǒng)的功能將是零散而脆弱的，

21、極易受到變更的沖擊。不滿足開發(fā)人員的要求，軟件的開發(fā)、維護(hù)和移植變得非常困難。開發(fā)人員、開發(fā)管理人員和維護(hù)人員非常關(guān)心開發(fā)期質(zhì)量屬性，但最終用戶不會(huì)提出、一般也提不出這類質(zhì)量要求。通常稱這類質(zhì)量屬性為隱含質(zhì)量需求。運(yùn)行期質(zhì)量屬性是軟件系統(tǒng)在運(yùn)行期間，最終用戶可以直接感受到的一類質(zhì)量屬性，這些質(zhì)量屬性直接影響用戶對軟件產(chǎn)品的滿意度?？梢哉J(rèn)為，運(yùn)行期質(zhì)量需求來自使用系統(tǒng)的用戶，開發(fā)期質(zhì)量需求更多來自系統(tǒng)維護(hù)人員，即開發(fā)的系統(tǒng)更便于維護(hù)。1.4需求的易變更性需求的變更是最讓人頭痛的事。任何需求變更意味著時(shí)間和金錢的消耗。同時(shí)需求變更引起對系統(tǒng)的修改將降低開發(fā)期質(zhì)量屬性的質(zhì)量，并引入更多bug，從而降

22、低運(yùn)行期質(zhì)量屬性的質(zhì)量。軟件架構(gòu)設(shè)計(jì)的重要目標(biāo)是：使軟件架構(gòu)能支持業(yè)務(wù)功能在一定范圍內(nèi)“隨需應(yīng)變”。不同需求的易變更性不同：功能需求最容易變化。在架構(gòu)設(shè)計(jì)中，應(yīng)劃分少量長期穩(wěn)定的功能，同時(shí)也應(yīng)區(qū)分功能點(diǎn)本身趨于穩(wěn)定，只是功能行為常常變化的功能。質(zhì)量屬性需求最為穩(wěn)定。約束性需求的穩(wěn)定性則稍差。技術(shù)趨勢發(fā)生變化、法律法規(guī)重新界定和用戶組織調(diào)整改組等都可能引起約束性需求變更。1.5需求捕捉的工具（1）傳統(tǒng)工具-業(yè)務(wù)流程圖和數(shù)據(jù)流程圖對于復(fù)雜的系統(tǒng)，如管理信息系統(tǒng)，先通過業(yè)務(wù)流程圖對業(yè)務(wù)過程進(jìn)行描述，再將其轉(zhuǎn)換為數(shù)據(jù)流程圖。數(shù)據(jù)流圖是系統(tǒng)業(yè)務(wù)功能及其數(shù)據(jù)流動(dòng)的描述，是系統(tǒng)的邏輯模型。（2）uml提供的

23、工具-活動(dòng)圖和用例模型活動(dòng)圖可以有效地描述業(yè)務(wù)流程。用例模型包括用例圖和用例規(guī)格說明。用例捕捉功能需求，其非功能性記錄在用例規(guī)格說明中。后面只考慮uml描述工具。1.6需求提取內(nèi)容1.6.1確定業(yè)務(wù)目標(biāo)一個(gè)項(xiàng)目要被開發(fā)，要撥款立項(xiàng)，一定有它的業(yè)務(wù)目標(biāo)。對于一個(gè)系統(tǒng)開發(fā)，業(yè)務(wù)目標(biāo)占有非常重要的位置，它明確規(guī)定了建立該軟件系統(tǒng)的最終目的。業(yè)務(wù)目標(biāo)是組織或客戶方的高層對未來系統(tǒng)的期望。業(yè)務(wù)目標(biāo)的確定需要從企業(yè)信息化的全局來考慮和規(guī)劃，使其開發(fā)的系統(tǒng)成為企業(yè)信息化系統(tǒng)中相對獨(dú)立的、支持全局應(yīng)用的、不可替代的重要組成部分。避免開發(fā)的系統(tǒng)解決的問題的層次太低，隨著對信息化的要求的提高而很快過時(shí)。項(xiàng)目業(yè)務(wù)目

24、標(biāo)通常由需方高層領(lǐng)導(dǎo)參與確定。要避免業(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é)作還可以通過進(jìn)一步細(xì)化業(yè)務(wù)目標(biāo)，對每個(gè)業(yè)務(wù)目標(biāo)列出一組高度概括的功能性需求。這種高度概括的功能性需求通常稱為“特性”，表明“為了達(dá)到所期望的業(yè)務(wù)目標(biāo)，未來系統(tǒng)應(yīng)該在大方向上具有哪些方面的特性，每個(gè)特性再有一組功能來支撐?！比鐦I(yè)務(wù)目標(biāo)“幫助項(xiàng)目經(jīng)理更好地控制項(xiàng)目”的特性有：任務(wù)管理跟蹤進(jìn)度查看報(bào)表任務(wù)分配和重分配對應(yīng)每個(gè)特性的功能可以用“用例”來描述，即一個(gè)特性對應(yīng)一組用例。1.6.2確定業(yè)務(wù)領(lǐng)域范圍及

25、業(yè)務(wù)流程業(yè)務(wù)目標(biāo)的實(shí)現(xiàn)需要通過具體的業(yè)務(wù)領(lǐng)域（有時(shí)也稱職能域）以及具體的業(yè)務(wù)及流程來體現(xiàn)，使業(yè)務(wù)目標(biāo)落實(shí)到實(shí)處。這將引起企業(yè)組織機(jī)構(gòu)的調(diào)整和業(yè)務(wù)流程重組，以滿足業(yè)務(wù)目標(biāo)的要求。1.6.3建立用例模型所謂用戶需求，就是用戶希望軟件系統(tǒng)能為他做什么。用例圖技術(shù)是捕捉用戶需求最合適的技術(shù)。用例名是用戶需求最直觀、最簡便的反映。業(yè)務(wù)流程分析將捕捉到大部分用例，但不是全部用例，還需要補(bǔ)充一些與管理人員相關(guān)、但與具體業(yè)務(wù)活動(dòng)不一定直接相關(guān)的用例和與信息查詢相關(guān)的用例。1.6.4建立用例規(guī)約用例從一個(gè)較高層次描述了用戶功能需求，解決了軟件系統(tǒng)要“做什么”的問題，但還需要知道用戶“希望如何做”的行為需求，否則

26、還是不知道如何開發(fā)系統(tǒng)。這里的“如何做”是從用戶角度看他們“希望如何做”，而不是軟件系統(tǒng)是如何做，所以還是屬于需求捕捉的內(nèi)容。用戶“希望如何做”是軟件系統(tǒng)“如何做”的依據(jù)。因此，用例規(guī)約中對系統(tǒng)行為的描述是以用戶為中心展開的，便于與用戶交流。在用例規(guī)約中，將詳細(xì)定義用戶對用例運(yùn)行期間的質(zhì)量要求和約束。不一定所有用例都要建立用例規(guī)約。有的用例使用“用例簡述”就足夠了。如果一個(gè)用例基本事件流對需求分析人員來說不是很清楚，而且可能涉及到非功能要求，就需要用“用例規(guī)約”來詳細(xì)描述。在需求分析階段可以通過用例界面的“預(yù)設(shè)計(jì)”可以更好地描述用例。真正設(shè)計(jì)是從實(shí)現(xiàn)角度來考慮問題，“預(yù)設(shè)計(jì)”是從與用戶交流角度

27、來考慮問題。用例實(shí)現(xiàn)：用例實(shí)現(xiàn)不是真正編碼實(shí)現(xiàn)用例對應(yīng)的功能，而是考慮為了實(shí)現(xiàn)用例定義的功能，需要哪些類，以及這些類的對象之間如何交互來完成最終的功能。用例實(shí)現(xiàn)是從功能需求向設(shè)計(jì)方案過渡的紐帶，通過分析一組關(guān)鍵用例的用例實(shí)現(xiàn)，可以獲得未來系統(tǒng)的理想化的職責(zé)模型。這個(gè)職責(zé)模型是規(guī)劃架構(gòu)機(jī)制、滿足高質(zhì)量屬性要求的基礎(chǔ)。用例規(guī)約也稱用例規(guī)格說明。1.6.5確定系統(tǒng)非功能需求通過對用例規(guī)約的分析和總結(jié)，歸納出系統(tǒng)的非功能需求，特別是用戶對系統(tǒng)運(yùn)行期的質(zhì)量需求和約束。用例規(guī)約是系統(tǒng)運(yùn)行期質(zhì)量需求和約束的主要來源。一般來說，開發(fā)期質(zhì)量屬性需求主要來自系統(tǒng)開發(fā)人員和維護(hù)人員。第二部分 需求提取與需求建模2.

28、1需求建模基本概念需求提取的建模包括業(yè)務(wù)建模和用例建模。業(yè)務(wù)建模是確定項(xiàng)目對應(yīng)的業(yè)務(wù)領(lǐng)域所包含的業(yè)務(wù)和業(yè)務(wù)流程，并用所選擇的業(yè)務(wù)流程描述工具進(jìn)行描述。用例建模是以用例為基本單位來描述用戶的功能需求。與用例模型相關(guān)的概念包括：參與者，用例，場景2.1.1參與者參與者：直接與系統(tǒng)交互的外部事物所扮演的角色。該定義強(qiáng)調(diào)了3點(diǎn)：參與者對系統(tǒng)而言是外部的；參與者直接與系統(tǒng)交互，即參與者要直接使用系統(tǒng)來支持他的業(yè)務(wù)工作。強(qiáng)調(diào)參與者所扮演的角色，而不是特定的人或事物。一個(gè)特定的人可能扮演幾種角色，可以作為系統(tǒng)的多個(gè)參與者。時(shí)間可以作為參與者，通常用時(shí)間發(fā)生器來表示。有些系統(tǒng)的功能是通過系統(tǒng)設(shè)定的時(shí)間來驅(qū)動(dòng)的

29、。這里的參與者主要指系統(tǒng)業(yè)務(wù)功能的使用者。系統(tǒng)管理員不是這種意義的參與者。因?yàn)樗皇鞘褂孟到y(tǒng)功能完成與單位業(yè)務(wù)有關(guān)的工作。他使用系統(tǒng)的輔助功能實(shí)現(xiàn)對特定的人及其角色的管理，使參與者在自己角色范圍內(nèi)使用系統(tǒng)。每個(gè)參與者使用一個(gè)具有業(yè)務(wù)意義的名稱命名。為了把系統(tǒng)的用戶都考慮到，有時(shí)使用“主要參與者”和“次要參與者”的提法，主要參與者使用系統(tǒng)實(shí)現(xiàn)自己的業(yè)務(wù)目標(biāo)。次要參與者為系統(tǒng)提供服務(wù)。系統(tǒng)管理員就是系統(tǒng)的次要參與者，其目標(biāo)就是管理主要參與者，使他們按照事先的約定使用系統(tǒng)，保證系統(tǒng)有效運(yùn)行。需求獲取的首要任務(wù)就是識別主要參與者。主要參與者驅(qū)動(dòng)了用例。用例總是有參與者開始的。用例從參與者的角度來編寫的

30、。識別參與者是需求提取的首要任務(wù)，誰是系統(tǒng)的客戶，他們需要系統(tǒng)做什么，他們希望在什么時(shí)候、什么地點(diǎn)做什么，這些都是系統(tǒng)設(shè)計(jì)要考慮的重要因素。2.1.2用例用例就是需求。從根本上說，用例就是功能需求。用例是一種被廣泛使用的用于發(fā)現(xiàn)和記錄需求的機(jī)制。被認(rèn)為是一種最好地理解需求和描述需求的技巧。在統(tǒng)一過程中，用例被推薦作為發(fā)現(xiàn)和定義需求的主要方法。用例為項(xiàng)目相關(guān)人員提供了一種簡單而易懂的機(jī)制來了解目標(biāo)和系統(tǒng)需求。用例圖描述的是軟件系統(tǒng)為用戶或外部系統(tǒng)提供的（系統(tǒng)級）服務(wù)，清晰地界定了系統(tǒng)的功能范圍，有利于從宏觀上反映系統(tǒng)功能的大局。1、用例的定義用例：參與者想要系統(tǒng)做的事情。具體表現(xiàn)為用戶如何使用系

31、統(tǒng)來達(dá)到其目標(biāo)的一組情節(jié)。例如在超市，“處理銷售”的用例描述為：一個(gè)顧客攜帶欲采購的商品到達(dá)收費(fèi)口。收銀員使用系統(tǒng)輸入商品信息，系統(tǒng)給出商品的清單和累加值。顧客交款。收銀員輸入支付信息，系統(tǒng)對付款信息進(jìn)行計(jì)算，更新庫存信息，并給出余額信息；系統(tǒng)打印購物清單。顧客得到收據(jù)，然后攜帶商品離開。只有對用例表現(xiàn)出的情節(jié)進(jìn)行真實(shí)、完整、準(zhǔn)確地描述，才能捕捉到對系統(tǒng)需求有價(jià)值的東西。2、用例的粒度參與者想要系統(tǒng)做的事情有大有小，有抽象的事情，有具體的事情。參與者想要系統(tǒng)做的什么樣的事情那些可以作為一個(gè)用例，哪些事情又不能算一個(gè)用例。這實(shí)際上涉及到用例的粒度問題。指導(dǎo)原則1：在進(jìn)行需求獲取時(shí)，應(yīng)專注于“基本

32、業(yè)務(wù)過程”（ebp）級別的用例?；緲I(yè)務(wù)過程：由一個(gè)人在某個(gè)時(shí)間某個(gè)地點(diǎn)執(zhí)行的一項(xiàng)任務(wù)，這個(gè)任務(wù)是對某一個(gè)業(yè)務(wù)事件的反應(yīng)，而且可以增加可度量的業(yè)務(wù)價(jià)值，并且能夠保持?jǐn)?shù)據(jù)狀態(tài)的一致。用例不是類似“刪除一個(gè)記錄”或“打印一個(gè)清單”這樣簡單的小步驟。用例也不是一個(gè)需要好幾天和很多對話才能完成的工作，例如“談判一個(gè)供貨合同”，它是能夠在一個(gè)對話、幾分鐘或一個(gè)小時(shí)的時(shí)間就可以完成的任務(wù)。依照up的定義，用例強(qiáng)調(diào)了能夠增加可見的或可度量的業(yè)務(wù)價(jià)值，而且能夠使系統(tǒng)和數(shù)據(jù)處于穩(wěn)定和一致的狀態(tài)中（表示該做的一件事做完了）。用例沒有層次結(jié)構(gòu)的概念，即用例就是系統(tǒng)參與者要系統(tǒng)幫助干的一件不可細(xì)分的事情，不存在把一個(gè)

33、用例分解成粒度更小的用例。后面講到用例優(yōu)化時(shí)，可能存在從用例中抽象出更小的用例，主要是從實(shí)現(xiàn)角度考慮，對用例進(jìn)行某種優(yōu)化措施，為系統(tǒng)設(shè)計(jì)提供更多的信息。ebp級別的用例就是用戶對系統(tǒng)的業(yè)務(wù)功能需求。在進(jìn)行需求獲取時(shí)，我們應(yīng)主要關(guān)注ebp級別的主要用例，通常稱他們?yōu)榛居美Ｓ美Ｖ饕紤]ebp級別的用例。比基本用例粒度小的用例可能完不成“可度量的業(yè)務(wù)價(jià)值”的一件事情，比基本用例粒度大的用例可能需要多個(gè)參與者去完成或多個(gè)時(shí)間段去完成。為了獲得ebp級別的用例，必須非常熟悉用戶的業(yè)務(wù)流程，用戶任何一項(xiàng)有意義的業(yè)務(wù)活動(dòng)，如果需要系統(tǒng)的支持，就構(gòu)成了一個(gè)ebp級別的用例。用例的命名必須具有明顯的業(yè)務(wù)

34、領(lǐng)域特征，而不是計(jì)算機(jī)化的語言。3、用例與目標(biāo)參與者都有自己的目標(biāo)，并使用系統(tǒng)來幫助自己實(shí)現(xiàn)目標(biāo)。一個(gè)ebp級別上的用例通常被稱為一個(gè)用戶目標(biāo)級別上的用例，以強(qiáng)調(diào)用例應(yīng)該幫助系統(tǒng)的用戶實(shí)現(xiàn)自己的目標(biāo)。（這里強(qiáng)調(diào)“用戶目標(biāo)級別”，不是企業(yè)目標(biāo)、組織目標(biāo)、系統(tǒng)目標(biāo)）?！胺辣I”是企業(yè)級目標(biāo)，不是用戶級目標(biāo)，因此不是一個(gè)ebp?！跋蛳到y(tǒng)證明身份并被驗(yàn)證”也不是一個(gè)ebp，因?yàn)樗鼪]有增加可見的或可以度量的業(yè)務(wù)價(jià)值?！暗卿洝笔且粋€(gè)次要目標(biāo)，是為其它有用的事情服務(wù)的。如“我今天登錄了20次”不會(huì)留下任何有價(jià)值的東西?！坝脩艄芾怼笔窍到y(tǒng)目標(biāo)，不是用戶級目標(biāo)。4、可觀察的返回值每個(gè)用例的實(shí)例產(chǎn)生了對特定參與者而

35、言可觀察的返回值?？捎^察的返回值實(shí)際上是告訴參與者是否實(shí)現(xiàn)了其業(yè)務(wù)價(jià)值。如果一個(gè)用例不會(huì)告訴參與者任何東西，對參與者來說，它沒有任何價(jià)值，這肯定不是參與者的目標(biāo)要求。2.1.3場景場景：參與者與系統(tǒng)之間的一系列特定的活動(dòng)和交互，通常稱為“用例的實(shí)例”。場景是使用系統(tǒng)的一個(gè)特定情節(jié)或用例的一條執(zhí)行路徑。一個(gè)用例就是一個(gè)描述參與者使用系統(tǒng)來達(dá)到目標(biāo)的一組相關(guān)的成功場景和失敗場景的集合。例如，客戶在超市選擇購買的商品后到收銀臺驗(yàn)貨和付款中，“收銀員掃描儀錄入商品數(shù)據(jù)顧客交款收銀員退余款打印購物清單”是一個(gè)場景；同樣，“收銀員掃描儀錄入商品數(shù)據(jù)顧客交卡收銀員刷卡打印購物清單”也是一個(gè)場景；“收銀員掃描

36、儀錄入商品數(shù)據(jù)顧客交卡收銀員刷卡（卡中錢不足時(shí)）顧客交款收銀員退余款打印購物清單”還是一個(gè)場景。場景可分為主要場景和次要場景。一個(gè)用例只有一個(gè)主要場景，但可以包含多個(gè)次要場景。每個(gè)場景表示參與者達(dá)到其目標(biāo)的一個(gè)情節(jié)。在主要場景中，如果與某一步所希望的事件不同，就會(huì)引出一個(gè)次要場景。2.1.4用例規(guī)格說明用例不是圖表，而是文本文檔。用例圖表示對用例的抽象描述，用例規(guī)范化文檔（用例規(guī)格說明）是對用例的詳細(xì)描述，在up中稱為詳述用例。用例圖和詳述用例就像數(shù)據(jù)流圖和數(shù)據(jù)字典一樣，被同時(shí)使用，共同構(gòu)成用例模型。用例規(guī)范化文檔是領(lǐng)域模型、設(shè)計(jì)模型、部署模型、設(shè)計(jì)模式選擇的依據(jù)。用例描述主要包括主要成功場景

37、和擴(kuò)展。主要成功場景：描述了能夠滿足項(xiàng)目相關(guān)人員興趣的典型的成功路徑，通常稱為基本流程。擴(kuò)展：描述與基本流程不一致的方面，如達(dá)到目標(biāo)的不同選項(xiàng)。擴(kuò)展也稱為次要場景。主要場景一定對應(yīng)一個(gè)基本的成功場景，主要場景中沒有出錯(cuò)處理的內(nèi)容。次要場景的基本目的是對應(yīng)一個(gè)不同于主要場景某個(gè)點(diǎn)的不同的選項(xiàng)，其中可能包含出錯(cuò)處理。用例規(guī)格說明的格式有多種多樣，表示的形式有單列式和雙列式。單列式將參與者與系統(tǒng)的交互按步驟順序列出。雙列式將參與者的行為和系統(tǒng)的職責(zé)分開各列一列。表1-1的格式是常見的一種用例規(guī)格說明的格式。表1-1 用例規(guī)格說明格式表用例編號：用例名稱主要參與者項(xiàng)目相關(guān)人員及其興趣前置條件后置條件（

38、成功后的保證）主要成功場景（或基本流程）擴(kuò)展（或替代流程）特殊需求技術(shù)與數(shù)據(jù)的變化列表發(fā)生頻率待解決的問題下面“處理銷售”用例規(guī)格說明就是這種風(fēng)格。用例1：處理銷售主要參與者：收銀員項(xiàng)目相關(guān)人員及其興趣：收銀員：希望能夠準(zhǔn)確、快速地輸入，而且沒有支付錯(cuò)誤，因?yàn)槭浙y員如果少收了錢就要從他的薪金中扣除相應(yīng)的金額。售貨員：希望自動(dòng)更新銷售提成。顧客：希望購買過程能夠省力，并得到快速的服務(wù)。希望得到購買證明，以便退貨。公司：希望準(zhǔn)確地記錄交易，并滿足顧客的要求。希望保證支付授權(quán)服務(wù)的信息被記錄。希望有一定的容錯(cuò)性，即使某些服務(wù)暫時(shí)不可用（如遠(yuǎn)程信用卡驗(yàn)證）也能允許收款。希望能夠自動(dòng)啟動(dòng)，快速地更新賬目

39、和庫存信息。政府稅務(wù)機(jī)關(guān)：希望能從每筆交易中提取稅金。可能存在多個(gè)稅務(wù)機(jī)關(guān)，如國家級、市級和縣級。支付授權(quán)服務(wù)：希望按照正常的格式和協(xié)議收到數(shù)字授權(quán)的請求。希望準(zhǔn)確計(jì)算給商店的應(yīng)付款。前置條件：收銀員必須已經(jīng)被識別和授權(quán)。后置條件：存儲銷售信息；準(zhǔn)確計(jì)算稅金；更新賬目和庫存信息；記錄提成；生成收據(jù)；記錄支付授權(quán)的許可。主要成功場景：1.顧客攜帶購買的商品或服務(wù)到達(dá)pos機(jī)收費(fèi)口。2.收銀員開始一次新的銷售。3.收銀員輸入商品標(biāo)識。4.系統(tǒng)記錄單件商品，并顯示該商品的描述、價(jià)格和累加值。收銀員重復(fù)34步，直到處理完所有商品。5.系統(tǒng)顯示總值并計(jì)算稅金。6.收銀員請顧客付款。7.顧客支付，系統(tǒng)處理

40、支付。8.系統(tǒng)記錄完整的銷售信息，并將銷售和支付信息發(fā)送到外部的記賬系統(tǒng)（進(jìn)行記帳和提成）和庫存系統(tǒng)（更新庫存）。9.系統(tǒng)打印收據(jù)。10.顧客帶著商品和收據(jù)離開。擴(kuò)展：*a.任何時(shí)刻，發(fā)生以下狀況，系統(tǒng)將失?。?為了支持恢復(fù)操作和正確地記帳，要保證所有交易的敏感狀態(tài)和事件都能夠從場景中的任何一步中恢復(fù)。1.收銀員重啟系統(tǒng)、登錄，請求恢復(fù)上次狀態(tài)。2.系統(tǒng)重建之前的狀態(tài)。 2a.系統(tǒng)恢復(fù)過程中檢測到異常： 1.系統(tǒng)向收銀員指示錯(cuò)誤，記錄此錯(cuò)誤，并進(jìn)入一個(gè)清空狀態(tài)。 2.收銀員開始一次新的銷售。3a.非法標(biāo)識 1.系統(tǒng)指示錯(cuò)誤并拒絕輸入。3b.有多個(gè)具有相同類別的商品（其數(shù)量不是一個(gè)，而是多個(gè)），

41、不需要跟蹤每個(gè)商品的唯一身份： 1.收銀員可以輸入商品類別的標(biāo)識和數(shù)量。3-6a.顧客要求收銀員從已輸入的商品中去掉一個(gè)商品： 1.收銀員輸入商品標(biāo)識并將其刪除。 2.系統(tǒng)顯示更新后的累加值。3-6b.顧客要求收銀員取消交易： 1.收銀員在系統(tǒng)中取消交易。3-6c收銀員暫停銷售： 1.系統(tǒng)記錄銷售信息。收銀員能夠在任何一臺pos終端上恢復(fù)操作。4a.系統(tǒng)生成的商品價(jià)格不是顧客想要的價(jià)格（顧客抱怨太貴，要求減價(jià)）： 1.收銀員重寫價(jià)格。 2.系統(tǒng)顯示新的價(jià)格。5a.系統(tǒng)檢測到與外部的稅金計(jì)算系統(tǒng)的通信故障： 1.系統(tǒng)要pos機(jī)節(jié)點(diǎn)上重啟此業(yè)務(wù)，并繼續(xù)。 1a.系統(tǒng)檢測到服務(wù)無法重啟。 1.系統(tǒng)指

42、示錯(cuò)誤發(fā)生。 2.收銀員可以手工計(jì)算稅金并輸入，也可以取消此銷售。5b.顧客聲稱他們符合打折條件（例如，雇員或優(yōu)先顧客）： 1.收銀員發(fā)出打折請求。 2.收銀員輸入顧客的個(gè)人身份信息。 3.系統(tǒng)按照打折條款給出折扣價(jià)值。5c.顧客要求使用信用卡結(jié)帳： 1.收銀員發(fā)出信用卡結(jié)帳請求。 2. .收銀員輸入顧客的個(gè)人身份信息。 3.系統(tǒng)按從信用卡上扣除貨款。6a.顧客想用現(xiàn)金支付，但隨身現(xiàn)金不足： 1a.顧客使用替代的支付手段。 1b.顧客告訴收銀員：他要取消此銷售，收銀員在系統(tǒng)上取消此銷售。7a.現(xiàn)金支付： 1.收銀員輸入收取的現(xiàn)金數(shù)額。 2.系統(tǒng)給出應(yīng)找的余額，并彈出現(xiàn)金抽屜。 3.收銀員放入收

43、取的現(xiàn)金，并拿出應(yīng)找的余額給顧客。 4.系統(tǒng)記錄現(xiàn)金支付。7b.信用卡支付： 1.顧客輸入信用卡帳號。 2.系統(tǒng)向外部的信用卡授權(quán)服務(wù)系統(tǒng)發(fā)送支付授權(quán)請求，并請求批準(zhǔn)此支付。 2a.系統(tǒng)檢測到與外部系統(tǒng)的通信故障： 1.系統(tǒng)向收銀員指示發(fā)生了錯(cuò)誤。 2.收銀員請求顧客更換支付方式。 3.系統(tǒng)收到批準(zhǔn)付款的指示，并向收銀員指示付款被批準(zhǔn)。 3a.系統(tǒng)收到拒絕付款的指示： 1.系統(tǒng)向收銀員指示付款被拒絕。 2.收銀員請求顧客更換支付方式。4.系統(tǒng)記錄信用卡支付，其中包括支付的批準(zhǔn)。5.系統(tǒng)給出信用卡支付的簽名輸入機(jī)制。6.收銀員要求顧客做出一個(gè)信用卡支付簽名。顧客簽名。7c.支票支付7d.記帳支付

44、7e.顧客出示優(yōu)惠卷：1.在付款之前，收銀員記錄每張優(yōu)惠卷，并從系統(tǒng)中扣除相應(yīng)的價(jià)值。系統(tǒng)記錄已使用的優(yōu)惠卷以備記帳之用。1a.輸入的優(yōu)惠卷并不適用任意購買的商品。1.系統(tǒng)向收銀員指示錯(cuò)誤。9a.有的商品有回扣： 1.系統(tǒng)給出回扣表格，并為每個(gè)回扣商品提供回扣收據(jù)。9b.顧客要求禮物收據(jù)（不顯示價(jià)格）： 1.收銀員請求禮物收據(jù)，系統(tǒng)給出禮物收據(jù)。特殊要求：使用大型平面顯示器上的觸摸屏界面。文本信息要能夠在1米之外看清。90%的信用卡授權(quán)機(jī)構(gòu)的響應(yīng)應(yīng)在30秒內(nèi)收到。在訪問遠(yuǎn)程服務(wù)（如庫存系統(tǒng)）失敗的情況下保證可靠的恢復(fù)操作。支持多種語言顯示。在步驟3和步驟7中可以插入新的業(yè)務(wù)規(guī)則。技術(shù)與數(shù)據(jù)的變

45、化列表：3a.商品標(biāo)識可以用跳馬掃描或鍵盤輸入。3b.商品標(biāo)識可以是upc、ean、jan或sku等不同的編碼方式。7a.信用卡帳號信息可以使用讀卡器或鍵盤輸入。7b.記錄在紙面收據(jù)上的信用卡支付簽名。但我們預(yù)測，兩年內(nèi)會(huì)有許多顧客希望使用數(shù)字簽名。發(fā)生頻率：可能持續(xù)發(fā)生。待解決的問題：什么是稅法的變化？研究遠(yuǎn)程服務(wù)的恢復(fù)問題。不同的業(yè)務(wù)需要什么樣的定制？收銀員是否必須退出系統(tǒng)后帶走他們的現(xiàn)金抽屜？顧客是否可以直接用讀卡機(jī)，而不必收銀員代勞？內(nèi)容解釋： 1、用例應(yīng)該包含什么？ 答案：用例應(yīng)該包含滿足所有的項(xiàng)目相關(guān)人員興趣的內(nèi)容。以相關(guān)人員的興趣作為視點(diǎn)來觀察，會(huì)為我們提供一種徹底的、系統(tǒng)化的程

46、序，用來發(fā)現(xiàn)和記錄所有必須的行為。2、前置條件：規(guī)定了用例中的一個(gè)場景開始之前必須為“真”的條件。前置條件在用例中不會(huì)被檢驗(yàn)，如收銀員已經(jīng)成功“登錄”或“收銀員已經(jīng)被識別和授權(quán)”。3、后置條件：用例成功結(jié)束后必須為“真”的條件。這一“保證”應(yīng)該滿足所有項(xiàng)目相關(guān)人員的需要。4、主要成功場景：也稱為“基本流程”，描述了滿足相關(guān)人員興趣的典型的成功路徑，通常不包括任何條件和分支。5、擴(kuò)展：比成功場景更重要，更復(fù)雜，不滿足基本流程中的部分都要進(jìn)行描述。6、特殊要求：主要描述與用例相關(guān)的非功能要求。7、技術(shù)和數(shù)據(jù)的變化列表：記錄在技術(shù)上可能有變化的內(nèi)容，往往描述的是“應(yīng)該怎樣做”，但它們對設(shè)計(jì)決策有重要

47、影響。2.2用例建模用例模型是所有用例的集合，是系統(tǒng)功能和環(huán)境的模型用例模型設(shè)計(jì)步驟：識別系統(tǒng)主要參與者識別待開發(fā)系統(tǒng)所涉及的業(yè)務(wù)業(yè)務(wù)建模定義滿足用戶級目標(biāo)的用例。用例與面向?qū)ο鬅o關(guān)，書寫用例不是在進(jìn)行面向?qū)ο蠓治觥Ｓ美莡p的關(guān)鍵和核心。用例驅(qū)動(dòng)開發(fā)：功能需求主要記錄在用例中。團(tuán)隊(duì)為了完成或?qū)崿F(xiàn)用例而設(shè)計(jì)相互協(xié)作的對象和子系統(tǒng)。2.2.1識別系統(tǒng)主要參與者系統(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à)值所在。在識別系統(tǒng)主要參與者時(shí)的首要工作就是列出所有系統(tǒng)最終用戶。有的主要參與者的大部分業(yè)務(wù)工作都可能需要

48、系統(tǒng)支持，如學(xué)校的“教務(wù)管理員”，有的主要參與者可能很少使用系統(tǒng)。如各個(gè)“審批”人員，當(dāng)別人把所有工作都作了，他只需“審核”一下就行了。在識別主要參與者的過程中，最容易把這些大量的干“審核”或“審批”的主要參與者忽略掉，因?yàn)樗褂孟到y(tǒng)的時(shí)間很少，就認(rèn)為他不是主要參與者。任何人，只要他需要使用系統(tǒng)來行使自己的“職責(zé)”，哪怕只有一小點(diǎn)“職責(zé)”，他就是系統(tǒng)的主要參與者。2.2.2識別系統(tǒng)的業(yè)務(wù)和業(yè)務(wù)流程一個(gè)軟件系統(tǒng)的目標(biāo)和范圍確定后，與之對應(yīng)的業(yè)務(wù)就確定了。主要參與者指使用系統(tǒng)來實(shí)現(xiàn)自己目標(biāo)的參與者。五征產(chǎn)品計(jì)劃單的填寫由五征廠的業(yè)務(wù)員完成，如果用系統(tǒng)來實(shí)現(xiàn)產(chǎn)品計(jì)劃單的填寫（表現(xiàn)為訂單申請），則業(yè)務(wù)

49、員為主要參與者。產(chǎn)品計(jì)劃單的填寫不能由業(yè)務(wù)員一個(gè)人說了算，必須有經(jīng)銷商參與，申請什么產(chǎn)品，如何配置，數(shù)量是多少，只能由經(jīng)銷商決定，但這項(xiàng)業(yè)務(wù)活動(dòng)是由業(yè)務(wù)員完成的，所以經(jīng)銷商是次要參與者，他協(xié)助五征業(yè)務(wù)員制定產(chǎn)品計(jì)劃單，或?yàn)闃I(yè)務(wù)員制定產(chǎn)品計(jì)劃單提供服務(wù)，但他不直接使用系統(tǒng)來完成這項(xiàng)工作。在一項(xiàng)業(yè)務(wù)工作中，有多個(gè)業(yè)務(wù)活動(dòng)，每個(gè)業(yè)務(wù)活動(dòng)可能由不同的參與者完成，每個(gè)參與者都有自己的業(yè)務(wù)目標(biāo)。如五征產(chǎn)品計(jì)劃（產(chǎn)品訂購）業(yè)務(wù)有如下業(yè)務(wù)活動(dòng)：業(yè)務(wù)員填寫產(chǎn)品計(jì)劃單經(jīng)銷商負(fù)責(zé)人簽字認(rèn)可經(jīng)銷商開具匯票營業(yè)部評審人評審并簽字認(rèn)可經(jīng)銷商獲取認(rèn)可信息（表現(xiàn)為經(jīng)銷商查詢訂單狀態(tài)）這些業(yè)務(wù)活動(dòng)按時(shí)間順序構(gòu)成了訂單業(yè)務(wù)的完整

50、業(yè)務(wù)流程（不考慮訂單的執(zhí)行），其中的每一個(gè)業(yè)務(wù)活動(dòng)的完成都對應(yīng)著一個(gè)用戶目標(biāo)，實(shí)現(xiàn)這些目標(biāo)的軟件功能都可以抽象為一個(gè)ebp級別的用例。在列出業(yè)務(wù)活動(dòng)時(shí)，所遵循的基本原則是：每個(gè)業(yè)務(wù)活動(dòng)只有一個(gè)人在特定的地點(diǎn)和特定的時(shí)間完成。無論再小的事情，如果要多個(gè)人完成、或必須在多個(gè)時(shí)間完成、或可能（必須）在多個(gè)地點(diǎn)完成，就要分解成多個(gè)業(yè)務(wù)活動(dòng)，在用自然語言敘述業(yè)務(wù)流程時(shí)也必須遵循這樣的原則。在用例建模中，最容易犯的錯(cuò)誤是把用例模型中的用例與系統(tǒng)層次功能模型中功能模塊相對應(yīng)，把高層模塊作為基本用例，用包含關(guān)系的子用例來擴(kuò)展高層模塊的下層模塊。這是極其錯(cuò)誤的做法。必須強(qiáng)調(diào)：ebp級別的用例是用例建模必須堅(jiān)持的

51、基本原則。ebp級別的用例既不一定對應(yīng)層次功能結(jié)構(gòu)的上層功能模塊，也不一定對應(yīng)下層（葉結(jié)點(diǎn)）的功能模塊。它們是兩種完全不同的功能需求分析方法。2.2.3業(yè)務(wù)流程描述工具活動(dòng)圖業(yè)務(wù)流程描述了一個(gè)業(yè)務(wù)所包含的業(yè)務(wù)活動(dòng)和業(yè)務(wù)活動(dòng)之間的關(guān)聯(lián)關(guān)系。業(yè)務(wù)活動(dòng)之間的關(guān)聯(lián)關(guān)系反映業(yè)務(wù)狀態(tài)的變化及狀態(tài)遷移，即業(yè)務(wù)流程描述就是業(yè)務(wù)建模。業(yè)務(wù)建模就是以業(yè)務(wù)活動(dòng)為基本元素，描述一個(gè)業(yè)務(wù)從開始到結(jié)束所經(jīng)歷的業(yè)務(wù)活動(dòng)及業(yè)務(wù)的狀態(tài)轉(zhuǎn)移。uml沒有明確給出業(yè)務(wù)建模工具。一個(gè)業(yè)務(wù)模型現(xiàn)在還沒有直接自動(dòng)化地轉(zhuǎn)化為計(jì)算機(jī)可實(shí)現(xiàn)的模型的方法和技術(shù)。業(yè)務(wù)模型是給項(xiàng)目相關(guān)人員與用戶交流使用的，業(yè)務(wù)建模是軟件開發(fā)人員了解業(yè)務(wù)系統(tǒng)的基本方法

52、，是用例提取的基本來源。uml的活動(dòng)圖被推薦作為業(yè)務(wù)建模的工具?；顒?dòng)圖是用于描述流程化操作（工作流），并支持并發(fā)的主要工具，包括算法描述、用例實(shí)現(xiàn)過程描述等?；顒?dòng)圖的核心概念是活動(dòng)，活動(dòng)是完成一個(gè)任務(wù)（一個(gè)領(lǐng)域業(yè)務(wù)或一個(gè)系統(tǒng)任務(wù)）所必需執(zhí)行的處理步驟，是必須要做的活動(dòng)?；顒?dòng)圖使用符號：（1）初始狀態(tài)(活動(dòng)起點(diǎn))：用黑色小圓圈表示 表示業(yè)務(wù)（工作流）的開始。（2）終止?fàn)顟B(tài)（活動(dòng)終點(diǎn)）：用“牛眼”表示 表示業(yè)務(wù)（工作流）的結(jié)束（3）活動(dòng)：用圓角矩形表示該圖符在活動(dòng)圖中有時(shí)也稱動(dòng)作或動(dòng)作狀態(tài)。在不同的用途中可以有不同的稱呼，在業(yè)務(wù)建模中稱活動(dòng)比較合適。表示在某個(gè)時(shí)候要完成的一件工作。（4）活動(dòng)遷移：

53、用帶方向的線段表示 表示從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的轉(zhuǎn)移，或表示兩個(gè)活動(dòng)之間的聯(lián)系。箭頭表示活動(dòng)的步驟或順序。（5）分支和合并分支與合并往往同時(shí)使用，相當(dāng)于結(jié)構(gòu)化程序設(shè)計(jì)中對分支的要求-具有唯一的入口和唯一的出口。對于分支，其菱形框中應(yīng)給出條件表達(dá)式，表示按照條件的真或假選擇一個(gè)分支。（6）分叉與聚合（匯合）-描述并發(fā)與同步分叉具有一條引入遷移和兩條或多條引出遷移，表示由一個(gè)活動(dòng)的完成引出多個(gè)并行活動(dòng)的執(zhí)行。匯合具有兩條或多條引入遷移和一條引出遷移，表示多個(gè)活動(dòng)并發(fā)流的同步點(diǎn)，多個(gè)活動(dòng)都完成時(shí)才啟動(dòng)后繼的活動(dòng)。其引入的條數(shù)與對應(yīng)得分叉的引出條數(shù)一致。并發(fā)與同步往往同時(shí)存在于一個(gè)活動(dòng)中，他們反映了系

54、統(tǒng)任務(wù)的一些本質(zhì)特征。并發(fā)常常位于活動(dòng)圖中的靠前的活動(dòng)中，而同步則常位于后面的活動(dòng)中。描述并發(fā)和同步是活動(dòng)圖的優(yōu)勢。（7）泳道：指明活動(dòng)的執(zhí)行對象或組織。參與者1參與者n在活動(dòng)圖中，用泳道將業(yè)務(wù)中不同參與者參與的活動(dòng)用明顯的界限分開，便于明顯劃分每個(gè)參與者的職責(zé)。泳道技術(shù)假定：每個(gè)活動(dòng)被明確地分配到一個(gè)泳道，即不能跨越兩個(gè)或兩個(gè)以上泳道。在業(yè)務(wù)建模中，規(guī)定每個(gè)業(yè)務(wù)活動(dòng)只能由一個(gè)主要參與者在一個(gè)地點(diǎn)一個(gè)時(shí)間內(nèi)就可以完成，則一個(gè)活動(dòng)就對應(yīng)著一個(gè)ebp級的用例。帶有泳道的活動(dòng)圖被認(rèn)為是業(yè)務(wù)建模的最優(yōu)秀的方法和工具?；顒?dòng)圖除了上述圖形符號外，還可以加進(jìn)表示活動(dòng)的輸入和輸出的圖符。如用于描述業(yè)務(wù)流程，可

55、以加進(jìn)表示文檔之類的符號，表示活動(dòng)結(jié)束的輸出或活動(dòng)的輸入；在描述對象協(xié)作時(shí)，可以加入對象的符號。2.2.4建立基本用例模型指導(dǎo)原則2：在建立用例模型時(shí)，不考慮用戶界面，專注于參與者的意圖和系統(tǒng)職責(zé)。系統(tǒng)職責(zé)是實(shí)現(xiàn)參與者的意圖。如果活動(dòng)圖中每個(gè)活動(dòng)只限于在一個(gè)泳道中，在一個(gè)地點(diǎn)一個(gè)時(shí)間內(nèi)可以完成，則一個(gè)活動(dòng)就是一個(gè)ebp級的用例。所謂基本用例指一個(gè)ebp級別的用例?；居美Ｐ椭赣苫居美龢?gòu)成的系統(tǒng)功能模型。以用例為基礎(chǔ)的系統(tǒng)功能模型的圖式表示稱為用例圖，是用例模型的抽象描述。用例圖包括參與者（角色）、系統(tǒng)邊界、用例、參與者與用例的關(guān)聯(lián)關(guān)系。系統(tǒng)邊界用矩形框表示。通過矩形框的邊線明確劃分系統(tǒng)內(nèi)和系統(tǒng)外。用例用橢圓表示，橢圓內(nèi)放用例名（有的教科書上把用例放在橢圓的外邊）。用例放在矩形框內(nèi)，表示是系統(tǒng)內(nèi)部元素。參與者用“稻草人”圖符表示。參與者放在矩形框外，表示參與者是與系統(tǒng)有關(guān)的外部元素，是系統(tǒng)的直接使用者。參與者與用例之間的關(guān)聯(lián)關(guān)系通過參與者與用例之間的連線表示。用例由某個(gè)參與者來驅(qū)動(dòng)（啟動(dòng)）執(zhí)行，所以每個(gè)用例必須與系統(tǒng)外部參與者關(guān)聯(lián)，并把執(zhí)行結(jié)果的值通過一定的方式反饋給用戶。如果一個(gè)參與者沒有與用例建立關(guān)聯(lián)關(guān)系，則說明該參與者不應(yīng)