UML系統(tǒng)建模及系統(tǒng)分析與設(shè)計(jì)課件第3章 需求分析與用例建模

第3章需求分析與用例建模本章目的⑴掌握客戶(hù)需求分析的要點(diǎn)及需求分析規(guī)格說(shuō)明報(bào)告的書(shū)寫(xiě)格式。⑵通過(guò)繪制用例圖及其正文描述來(lái)完成客戶(hù)需求分析的方法。⑶掌握UML的用例模型建模方法。⑷掌握活動(dòng)圖的繪制方法，并且能夠繪制活動(dòng)圖。3.1客戶(hù)需求分析需求分析階段是開(kāi)發(fā)過(guò)程中第一重要的階段，如果不能準(zhǔn)確的理解客戶(hù)需要什么，那么就無(wú)法構(gòu)造出正確的系統(tǒng)。如果不了解客戶(hù)的領(lǐng)域及客戶(hù)需要解決的問(wèn)題，那么所有的用例分析都無(wú)濟(jì)于事?？蛻?hù)需求將決定整個(gè)項(xiàng)目要承辦方具體做些什么，承辦方只有明確了客戶(hù)的需求，才能進(jìn)行系統(tǒng)設(shè)計(jì)、編程、測(cè)試和維護(hù)等工作。在初始需求階段，需要獲得客戶(hù)的業(yè)務(wù)模型，然后根據(jù)業(yè)務(wù)模型建立計(jì)算機(jī)模型。要建立一個(gè)符合客戶(hù)需要的計(jì)算機(jī)系統(tǒng)，首要條件是完全徹底搞清楚客戶(hù)的業(yè)務(wù)，而不是預(yù)先假設(shè)已有一個(gè)計(jì)算機(jī)系統(tǒng)，再讓客戶(hù)假象計(jì)算機(jī)系統(tǒng)幫他們做什么。然而，實(shí)際情況是大多數(shù)情況下，用戶(hù)并不清楚自己究竟想要什么。因此，期望僅僅依靠用戶(hù)獲得完整的需求是完全不現(xiàn)實(shí)的。所以，需求分析階段，開(kāi)發(fā)人員必須進(jìn)行細(xì)致的調(diào)查研究，以便較好地理解客戶(hù)的要求。將客戶(hù)非形式的需求陳述轉(zhuǎn)化為完整的需求定義，再由需求定義轉(zhuǎn)換到相應(yīng)的需求規(guī)格說(shuō)明。需求分析階段的首要工作是要深入了解用戶(hù)的實(shí)際工作領(lǐng)域，通過(guò)客戶(hù)和軟件開(kāi)發(fā)人員之間的溝通，了解客戶(hù)的需求。然后與問(wèn)題領(lǐng)域?qū)＜矣懻摚治鰡?wèn)題領(lǐng)域的業(yè)務(wù)范圍、業(yè)務(wù)規(guī)則和業(yè)務(wù)處理過(guò)程，明確系統(tǒng)的責(zé)任、范圍和邊界，確定系統(tǒng)的需求，并建立需求模型。在UML中需求模型使用用例圖來(lái)表示。3.1.1系統(tǒng)調(diào)查系統(tǒng)調(diào)查是系統(tǒng)開(kāi)發(fā)過(guò)程中的基礎(chǔ)工作，通常分為初步調(diào)查和詳細(xì)調(diào)查，是一種十分有效的需求獲取方法，也是系統(tǒng)開(kāi)發(fā)不可缺少的過(guò)程和手段。需求獲取技術(shù)包括用戶(hù)訪(fǎng)談、用戶(hù)調(diào)查、現(xiàn)場(chǎng)觀摩用戶(hù)的工作流程、觀察用戶(hù)的實(shí)際操作、考查文檔、開(kāi)需求討論會(huì)、從行業(yè)標(biāo)準(zhǔn)及規(guī)范中提取需求、采用原型法和其他技術(shù)等。這個(gè)活動(dòng)也稱(chēng)為信息收集或者數(shù)據(jù)收集。調(diào)查研究分為兩個(gè)階段，一是初步的調(diào)查，在可行性分析階段進(jìn)行，即先投入少量的人力對(duì)系統(tǒng)進(jìn)行大致的了解，分析其開(kāi)發(fā)的可行性；二是詳細(xì)的調(diào)查，這是在系統(tǒng)分析階段進(jìn)行的，即在確定系統(tǒng)可行并立項(xiàng)后，投入大量的人力，展開(kāi)大規(guī)模、全面詳細(xì)的系統(tǒng)調(diào)查。3.1.1.1初步調(diào)查初步調(diào)查是接受客戶(hù)提出建立新系統(tǒng)的要求后，系統(tǒng)研制人員與用戶(hù)管理人員的第一次溝通。調(diào)查研究技術(shù)有：對(duì)現(xiàn)有文檔、表格和數(shù)據(jù)庫(kù)進(jìn)行抽樣；實(shí)地訪(fǎng)問(wèn)；觀察工作環(huán)境；發(fā)調(diào)查表；面談；原型化和聯(lián)合需求計(jì)劃等。初步調(diào)查的范圍是全方位的，需要對(duì)經(jīng)濟(jì)、技術(shù)、管理和開(kāi)發(fā)環(huán)境等等方面的內(nèi)容進(jìn)行調(diào)查。初步調(diào)查的重點(diǎn)是了解用戶(hù)與現(xiàn)行系統(tǒng)的總的情況，現(xiàn)行系統(tǒng)與外部環(huán)境的聯(lián)系，現(xiàn)行系統(tǒng)的現(xiàn)有資源，外界的約束條件等。具體來(lái)說(shuō)了解如下的內(nèi)容：⑴現(xiàn)行系統(tǒng)的概況。了解現(xiàn)行系統(tǒng)的規(guī)模、系統(tǒng)目標(biāo)、發(fā)展歷史、組織結(jié)構(gòu)、管理體制、人員分工、技術(shù)條件、技術(shù)水平等。⑵系統(tǒng)外部環(huán)境?，F(xiàn)行系統(tǒng)和外部環(huán)境有哪些聯(lián)系，哪些外部條件制約系統(tǒng)的發(fā)展。⑶現(xiàn)行系統(tǒng)的資源。現(xiàn)行系統(tǒng)有哪些資源，信息系統(tǒng)的狀況等。⑷用戶(hù)資源和要求。開(kāi)發(fā)新系統(tǒng)用戶(hù)可以提供的人力、物力和財(cái)力等情況，用戶(hù)的時(shí)間要求、功能要求、非功能要求和開(kāi)發(fā)目標(biāo)等。⑸現(xiàn)行系統(tǒng)存在的問(wèn)題。在初步調(diào)查中可以設(shè)計(jì)一些調(diào)查表，通過(guò)這些調(diào)查表可以更好地收集一些信息。了解現(xiàn)行系統(tǒng)存在的主要問(wèn)題。3.1.1.2詳細(xì)調(diào)查1.詳細(xì)調(diào)查的原則在進(jìn)行詳細(xì)調(diào)查時(shí)可遵循以下的原則：⑴系統(tǒng)性原則。⑵計(jì)劃性原則。⑶科學(xué)性原則。⑷前瞻性原則。2.詳細(xì)調(diào)查的內(nèi)容⑴全面調(diào)查的內(nèi)容與初步調(diào)查一樣，要了解現(xiàn)行系統(tǒng)的發(fā)展歷史、現(xiàn)狀、規(guī)模、經(jīng)營(yíng)狀況、業(yè)務(wù)范圍、與外界的聯(lián)系、確定系統(tǒng)的邊界；對(duì)系統(tǒng)的組織結(jié)構(gòu)進(jìn)行調(diào)查，了解各個(gè)部門(mén)的權(quán)限、職責(zé)、人員分工和關(guān)系等；了解系統(tǒng)的資源狀況，現(xiàn)有系統(tǒng)的物資、資金、設(shè)備、建筑平面布局和其他的資源。2.詳細(xì)調(diào)查的內(nèi)容⑵重點(diǎn)調(diào)查的內(nèi)容。詳細(xì)調(diào)查的重點(diǎn)是業(yè)務(wù)流程以及數(shù)據(jù)的調(diào)查。在進(jìn)行調(diào)查時(shí)，要弄清楚某項(xiàng)業(yè)務(wù)做什么？為什么做？由誰(shuí)來(lái)做？在哪里做？何時(shí)做以及如何做等，在做的過(guò)程中產(chǎn)生了哪些數(shù)據(jù)。即：What、Why、Who、Where、When、How數(shù)據(jù)的調(diào)查內(nèi)容主要包括輸入信息、輸出信息、信息處理過(guò)程、存儲(chǔ)方式、代碼信息和信息需求調(diào)查等。3調(diào)查的方法與策略⑴獲取信息的渠道。⑵調(diào)查數(shù)據(jù)的來(lái)源。①組織正式報(bào)告（對(duì)于手工系統(tǒng)）；②各種卡片、報(bào)表；③會(huì)議決議；④現(xiàn)行系統(tǒng)的說(shuō)明性文件（局部計(jì)算機(jī)化的系統(tǒng)）；⑤各種流程圖；⑥計(jì)算機(jī)文件（或數(shù)據(jù)庫(kù)），系統(tǒng)的數(shù)據(jù)組織結(jié)構(gòu)；⑦組織外的數(shù)據(jù)來(lái)源；⑧上級(jí)下達(dá)的各種文件和各項(xiàng)任務(wù)指標(biāo)；⑨與本單位密切相關(guān)的其它單位的有關(guān)信息。⑶調(diào)查的方法①詢(xún)問(wèn)法。②觀察法。③實(shí)驗(yàn)法。④抽樣調(diào)查法⑤查閱檔案資料法。⑥聯(lián)合需求計(jì)劃。聯(lián)合需求計(jì)劃（JointRequirementPlanning，JRP）也有的稱(chēng)為聯(lián)合應(yīng)用開(kāi)發(fā)（JAD，JointApplicationDevelopment），它是一個(gè)方法論，它將一個(gè)應(yīng)用程序的設(shè)計(jì)和開(kāi)發(fā)中的客戶(hù)或最終用戶(hù)聚集在一起，通過(guò)一連串的合作研討會(huì)獲得需求，也叫JRP會(huì)議。計(jì)劃一個(gè)JRP會(huì)議包括3個(gè)步驟1）選擇JRP會(huì)議地點(diǎn)。2）選擇JRP會(huì)議參加者。參加者包括JRP主持人、抄寫(xiě)員和用戶(hù)團(tuán)體代表。用戶(hù)和管理人員IT專(zhuān)家和其他觀察員IT專(zhuān)家和其他觀察員抄寫(xiě)員抄寫(xiě)員抄寫(xiě)員計(jì)算機(jī)投影設(shè)備黑板食物和飲料圖3.JRP會(huì)議的典型房間布局⑷調(diào)查的策略在進(jìn)行調(diào)查研究時(shí)，通常不要直接進(jìn)行面談，而是先收集可以通過(guò)其他方法收集到信息。調(diào)查研究的策略是：了解現(xiàn)有文檔、表格、報(bào)告和文件；如果合適，觀察工作中的系統(tǒng)；根據(jù)你已經(jīng)收集到的信息，設(shè)計(jì)并分發(fā)調(diào)查表，澄清你沒(méi)有完全理解的問(wèn)題；進(jìn)行面談來(lái)驗(yàn)證和澄清最困難的問(wèn)題；對(duì)于沒(méi)有理解的功能需求或者需要被驗(yàn)證的需求，可以構(gòu)造獲取原型；使用合適的調(diào)查研究技術(shù)驗(yàn)證事實(shí)。這個(gè)策略并不是不可改變的，根據(jù)實(shí)際情況選擇調(diào)查策略。但基本思想是在面談之前收集盡可能多的事實(shí)。3.1.2系統(tǒng)需求陳述 面向?qū)ο蠓治龅牡谝徊?，就是獲取用戶(hù)的需求。需求調(diào)查的目的是通過(guò)各種途徑獲取用戶(hù)的需求信息，由于在實(shí)際工作中，大部分客戶(hù)無(wú)法完整地講述其需求需求獲取是一件看似簡(jiǎn)單，做起來(lái)卻很難的一件事情。在需求獲取過(guò)程中，主要需要弄清楚3個(gè)問(wèn)題，即：明確需要獲取的信息（What）、明確所獲取信息的來(lái)源和渠道（Where）和怎樣獲取需求（How）。3.1.3系統(tǒng)需求分析 從廣義來(lái)說(shuō)需求分析包括需求的獲取、分析、規(guī)格說(shuō)明、變更、驗(yàn)證、管理等一系列需求工程。從狹義上來(lái)看需求分析是指需求的分析、定義過(guò)程。需求分析就是分析軟件用戶(hù)的需求是什么。在軟件工程中，需求分析指的是在建立一個(gè)新的或改變一個(gè)現(xiàn)存的系統(tǒng)時(shí)描寫(xiě)新系統(tǒng)的目的、范圍、定義和功能所要做的所有的工作。需求分析的目的就是發(fā)現(xiàn)和解決需求中的這些問(wèn)題并達(dá)成一致意見(jiàn)。如果在調(diào)查研究的過(guò)程中獲取的需求被查出存在問(wèn)題，就需要分析員對(duì)這些問(wèn)題進(jìn)行專(zhuān)門(mén)的分析。1.需求分析的任務(wù)需求分析階段的工作包括定義需求、分析與綜合、制訂規(guī)格說(shuō)明和評(píng)審等。⑴定義需求。定義需求就是從系統(tǒng)角度來(lái)理解軟件，確定對(duì)所開(kāi)發(fā)系統(tǒng)的綜合要求，并提出這些需求的實(shí)現(xiàn)條件，以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn)。這些需求包括：功能需求和非功能性需求。功能性需求描述一個(gè)系統(tǒng)必須提供的活動(dòng)和服務(wù)（做什么）；非功能性需求描述一個(gè)滿(mǎn)意的系統(tǒng)的其他特征、特點(diǎn)和約束條件等，1.需求分析的任務(wù)⑵分析與綜合。逐步細(xì)化所有的軟件功能，找出系統(tǒng)各元素間的聯(lián)系，接口特性和設(shè)計(jì)上的限制，分析他們是否滿(mǎn)足需求，剔除不合理部分，增加需要部分。最后，綜合成系統(tǒng)的解決方案，給出要開(kāi)發(fā)的系統(tǒng)的模型（做什么的模型）。⑶編制需求規(guī)格說(shuō)明書(shū)。描述需求的文檔稱(chēng)為軟件需求規(guī)格說(shuō)明書(shū)。需求分析階段的成果是需求規(guī)格說(shuō)明書(shū)，是提交下一階段的文檔資料。⑷評(píng)審。對(duì)功能的正確性、完整性和清晰性，以及其它需求給予評(píng)價(jià)。評(píng)審?fù)ㄟ^(guò)才可進(jìn)行下一階段的工作，否則重新進(jìn)行需求分析。2.需求分析的過(guò)程3.需求分析的特點(diǎn)⑴用戶(hù)與開(kāi)發(fā)人員很難進(jìn)行交流。⑵用戶(hù)的需求是動(dòng)態(tài)變化的。對(duì)于一個(gè)大型而復(fù)雜的軟件系統(tǒng)，用戶(hù)很難精確完整地提出它的功能和性能要求。⑶系統(tǒng)變更的代價(jià)呈非線(xiàn)性增長(zhǎng)。需求分析是軟件開(kāi)發(fā)的基礎(chǔ)。假定在該階段發(fā)現(xiàn)一個(gè)錯(cuò)誤，解決它需要用一小時(shí)的時(shí)間，到設(shè)計(jì)、編程、測(cè)試和維護(hù)階段解決，則要花2.5、5、25、100倍的時(shí)間。3.2需求建模 3.2.1用例建模

需求分析主要是定義業(yè)務(wù)用例模型。業(yè)務(wù)用例模型的目的在于描述企業(yè)的內(nèi)部組織結(jié)構(gòu)；描述企業(yè)各部門(mén)的業(yè)務(wù)；關(guān)注于角色和系統(tǒng)的交互界面。用例建模被認(rèn)為是描述信息系統(tǒng)功能需求的最佳實(shí)踐，用例模型描述系統(tǒng)外部的參與者所理解的系統(tǒng)功能。用例圖是UML圖中較為重要和常用的一種圖，常常用于軟件開(kāi)發(fā)的分析階段，也能用于軟件的系統(tǒng)測(cè)試階段。1.用例圖用例圖是描述系統(tǒng)與其他外部系統(tǒng)以及用戶(hù)之間交互的圖形，即用例圖描述了誰(shuí)將使用系統(tǒng)，用戶(hù)希望以什么方式與系統(tǒng)交互。用例圖確定系統(tǒng)中所包含的參與者、用例和兩者之間的對(duì)應(yīng)關(guān)系，它描述的是關(guān)于系統(tǒng)功能的一個(gè)概述，描述軟件應(yīng)具備哪些功能模塊以及這些模塊之間的調(diào)用關(guān)系。用例圖包含了用例和參與者，用例之間用關(guān)聯(lián)來(lái)連接以求把系統(tǒng)的整個(gè)結(jié)構(gòu)和功能反映給非技術(shù)人員（通常是軟件的用戶(hù)）。用例圖展示了用例之間以及同用例參與者之間是怎樣相互聯(lián)系的。用例模型的建立過(guò)程先畫(huà)用例圖，然后對(duì)用例圖編寫(xiě)用例說(shuō)明。在編寫(xiě)用例說(shuō)明的時(shí)候，對(duì)一些復(fù)雜的、認(rèn)為有必要的地方，繪制活動(dòng)圖、狀態(tài)圖或順序圖，方便閱讀者理解。用例圖關(guān)注的是三部分內(nèi)容：用例、參與者和關(guān)系。用例之間的關(guān)系①如果一個(gè)用例包含另一個(gè)用例的行為，則這兩個(gè)用例之間存在包含關(guān)系，或者說(shuō)一個(gè)用例使用了另一個(gè)用例的行為，被調(diào)用用例可以是事先定義好的，也可以是在各種環(huán)境下使用的公共行為，調(diào)用是無(wú)條件的。②如果對(duì)一個(gè)用例的行為添加某些額外的行為，包含此額外行為的用例和原來(lái)的用例之間就構(gòu)成了擴(kuò)展關(guān)系③如果一個(gè)用例是另一個(gè)用例的特例，這兩個(gè)用例之間就是泛化關(guān)系，父用例不具備完整的事件流，不具備執(zhí)行能力，而子用例實(shí)現(xiàn)其高級(jí)行為2.用例描述用例描述是業(yè)務(wù)事件以及用戶(hù)如何同系統(tǒng)交互以完成任務(wù)的文字描述。用例圖可以直觀地展現(xiàn)需求中的所有用例、參與者、系統(tǒng)邊界，以及它們之間的關(guān)系，但這還不足以表達(dá)需求分析所要求表達(dá)的內(nèi)容。用例圖必須輔之以用例說(shuō)明，才能完整清楚地表達(dá)。針對(duì)每一個(gè)用例都應(yīng)該有一個(gè)用例規(guī)約文檔與之相對(duì)應(yīng)，該文檔描述用例的細(xì)節(jié)內(nèi)容。3.用例建模的步驟⑴確定將要設(shè)計(jì)的系統(tǒng)范圍和它的邊界。⑵確定系統(tǒng)外的參與者。⑶從參與者（用戶(hù)）和系統(tǒng)對(duì)話(huà)的角度繼續(xù)尋找一下兩方面的特征：尋找參與者怎樣使用系統(tǒng)；系統(tǒng)向參與者提供什么樣的功能。把離用戶(hù)最近（接口）的用例作為頂層用例。⑷對(duì)復(fù)雜的用例做進(jìn)一步分解，并確定低層用例以及用例間的關(guān)系。⑸對(duì)每一用例做進(jìn)一步細(xì)化。⑹尋找每一個(gè)用例發(fā)生的前提條件和發(fā)生后對(duì)系統(tǒng)產(chǎn)生的結(jié)果。3.用例建模的步驟⑺尋找每一個(gè)用例在正常條件下的執(zhí)行過(guò)程。⑻尋找每一個(gè)用例在非正常條件下的執(zhí)行過(guò)程。⑼用UML建模工具畫(huà)出分層的用例模型圖。⑽審核用例模型。⑾編寫(xiě)用例模型圖的補(bǔ)充說(shuō)明文檔。4.業(yè)務(wù)用例建模當(dāng)進(jìn)行一個(gè)項(xiàng)目的需求分析時(shí)，首先要聽(tīng)用戶(hù)談他們的需求，或者看用戶(hù)提交的業(yè)務(wù)需求文檔。用戶(hù)一定會(huì)提出一個(gè)又一個(gè)的功能或要求，它們中的每一個(gè)要求就成為了最初的用例。分析這些用例，關(guān)注它們的每一個(gè)參與者，以及它們相互之間的關(guān)系，這就形成了最初的用例模型。在采用用例分析的方式與客戶(hù)溝通需求的時(shí)候，應(yīng)當(dāng)著重關(guān)注的是參與者及其目標(biāo)，即每個(gè)功能的參與者是誰(shuí)，完成這個(gè)功能的目標(biāo)是什么，以及如何完成這個(gè)目標(biāo)。4.業(yè)務(wù)用例建模這時(shí)的用例說(shuō)明采用概述的方式，即只進(jìn)行主成功場(chǎng)景（基本流程）的描述。此后，繼續(xù)細(xì)化用例，各個(gè)用例的替代場(chǎng)景（分支流程）逐漸被整理出來(lái)，用例再一步步細(xì)化。開(kāi)發(fā)人員對(duì)一些需求的認(rèn)識(shí)一開(kāi)始可能存在著偏差，因此，需要不斷更正用例描述。一些新的功能可能被用戶(hù)提出來(lái)，形成一些新的用例。如此反復(fù)數(shù)輪之后，項(xiàng)目需求的整體框架才逐漸清晰。然后應(yīng)該討論系統(tǒng)邊界，對(duì)用例模型進(jìn)行再一次調(diào)整。3.2.2確定系統(tǒng)邊界和范圍 1.確定系統(tǒng)的邊界任何一個(gè)系統(tǒng)都有一個(gè)邊界的問(wèn)題。邊界問(wèn)題就是確定系統(tǒng)和相鄰系統(tǒng)交接部分。定義系統(tǒng)邊界就是定義系統(tǒng)的范圍，即哪些元素屬于本系統(tǒng)，哪些元素屬于相鄰系統(tǒng)，明確系統(tǒng)目標(biāo)范圍。系統(tǒng)邊界是一個(gè)軟件系統(tǒng)需要處理的整個(gè)問(wèn)題空間的范圍。一個(gè)軟件系統(tǒng)不可能處理所有問(wèn)題，必須得給它定義這個(gè)問(wèn)題空間的范圍。2.確定系統(tǒng)的范圍在確定好系統(tǒng)的執(zhí)行者和用例后，系統(tǒng)的邊界就確定了。然后就需要確定項(xiàng)目的范圍，清晰的定義項(xiàng)目的范圍，將不需要做的事情放到一邊，同時(shí)為需要做的劃分優(yōu)先級(jí)。系統(tǒng)范圍是指整個(gè)系統(tǒng)中安全基線(xiàn)所涉及的對(duì)象和考慮的范圍，系統(tǒng)范圍確定是一個(gè)劃定系統(tǒng)安全邊界的過(guò)程，該邊界界定了安全基線(xiàn)的管轄范圍，即將系統(tǒng)劃分為內(nèi)部和外部?jī)刹糠郑到y(tǒng)內(nèi)部即為安全基線(xiàn)的系統(tǒng)范圍，系統(tǒng)外部即為系統(tǒng)環(huán)境，而系統(tǒng)安全邊界正是這兩部分的接口。3.2.3確定參與者 通常將系統(tǒng)外部與系統(tǒng)內(nèi)部交互的事物統(tǒng)稱(chēng)為參與者，也有的稱(chēng)為執(zhí)行者或者角色。參與者是在系統(tǒng)之外與系統(tǒng)交互的某人或事物，每一個(gè)執(zhí)行者都對(duì)應(yīng)一種特定的角色，每一個(gè)系統(tǒng)之外的實(shí)體對(duì)應(yīng)多種執(zhí)行者，就好比一個(gè)人在系統(tǒng)中他會(huì)有多種角色一樣，又或者幾個(gè)人可以用一個(gè)執(zhí)行者來(lái)表示，因?yàn)樗麄儗?duì)于系統(tǒng)來(lái)講屬于同一個(gè)角色。參與者是在系統(tǒng)之外，在系統(tǒng)之內(nèi)的不是參與者，參與者與系統(tǒng)有明顯的系統(tǒng)邊界。如何尋找參與者可以參考如下的信息源：標(biāo)示系統(tǒng)范圍和邊界的上下文圖；現(xiàn)有的系統(tǒng)文檔和系統(tǒng)手冊(cè)；項(xiàng)目會(huì)議和研討會(huì)的記錄；現(xiàn)有的需求文檔、項(xiàng)目章程或工作陳述。參與者總是在你的系統(tǒng)之外，他們從來(lái)都不是系統(tǒng)的一部分。為了幫助找到執(zhí)行者，可以在人、其他的軟件、硬件設(shè)備、數(shù)據(jù)存儲(chǔ)、或者網(wǎng)絡(luò)目錄中進(jìn)行尋找。參與者是在系統(tǒng)之外，透過(guò)系統(tǒng)邊界與系統(tǒng)進(jìn)行有意義交互的任何事物。通俗地講，參與者就是所要定義系統(tǒng)的使用者。尋找參與者可以從以下問(wèn)題入手：⑴

系統(tǒng)開(kāi)發(fā)完成之后，有哪些人會(huì)使用這個(gè)系統(tǒng)？⑵系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？⑶系統(tǒng)會(huì)為哪些人或其他系統(tǒng)提供數(shù)據(jù)？⑷系統(tǒng)需要與哪些其他系統(tǒng)交互？⑸系統(tǒng)是由誰(shuí)來(lái)維護(hù)和管理并保持其正常運(yùn)行？⑹系統(tǒng)需要應(yīng)付（處理）哪些硬設(shè)備？⑺誰(shuí)（或什么）對(duì)系統(tǒng)運(yùn)行產(chǎn)生的結(jié)果感興趣？⑻有沒(méi)有自動(dòng)發(fā)生的事件？3.2.4確定需求用例 用例圖中首先要明確的概念就是用例。用例是系統(tǒng)的一個(gè)功能單元，描述了參與者與系統(tǒng)發(fā)生的一次交互行為。用例，就是一件事情，要完成這件事情，需要一系列活動(dòng)。做一件事情可以有很多不同的方法和步驟，也可能會(huì)有各種各樣的意外情況，因此，這件事情由很多不同情況的集合構(gòu)成，在UML中稱(chēng)為場(chǎng)景。用例必然是以動(dòng)賓形式出現(xiàn)，用例相對(duì)獨(dú)立，但不意味用例不與其他用例交互而獨(dú)立完成參與者的目的。3.2.4確定需求用例 確定用例主要是看各參與者需要系統(tǒng)提供什么樣的服務(wù)，或者說(shuō)參與者是如何使用系統(tǒng)的。如銀行的ATM自動(dòng)提款機(jī)系統(tǒng)，用戶(hù)提款就是一個(gè)用例。用例就是一個(gè)用來(lái)描述參與者如何使用系統(tǒng)來(lái)實(shí)現(xiàn)其目標(biāo)的一組場(chǎng)景的集合。用例強(qiáng)調(diào)的是一組場(chǎng)景，在這組場(chǎng)景不多但相互之間存在功能上的共性，就像一個(gè)大功能模塊下的多個(gè)子模塊。這組場(chǎng)景中的每一個(gè)，又分別形成一個(gè)個(gè)子用例。尋找用例的方法：⑴從原始需求中尋找所包含的功能。⑵未來(lái)的系統(tǒng)，需要和哪些系統(tǒng)發(fā)生信息交互？⑶哪些人將操作未來(lái)的軟件系統(tǒng)？⑷系統(tǒng)有哪些受限的條件？⑸未來(lái)的軟件界面怎樣組織？⑹系統(tǒng)的響應(yīng)有哪些去向？3.2.5用例模型的關(guān)系 用例描述的是系統(tǒng)外部可見(jiàn)的行為，是系統(tǒng)為某一個(gè)或幾個(gè)參與者提供的一段完整的服務(wù)。從原則上來(lái)講，用例之間都是并列的，它們之間并不存在著包含從屬關(guān)系。但是從保證用例模型的可維護(hù)性和一致性角度來(lái)看，可以在用例之間抽象出包含（include）、擴(kuò)展（extend）和泛化（generalization）這幾種關(guān)系。這幾種關(guān)系都是從現(xiàn)有的用例中抽取出部分信息，然后通過(guò)不同的方法來(lái)重用這部分信息，以減少模型維護(hù)的工作量。1.UML用例圖的包含關(guān)系包含關(guān)系（include）是把幾個(gè)用例的公共行為分離成一個(gè)單獨(dú)的用例，使這幾個(gè)用例與該單獨(dú)的用例之間所建立的關(guān)系。被抽取出來(lái)的單獨(dú)的用例叫做被包含用例（Inclusion），而抽取出公共用例的幾個(gè)用例稱(chēng)為基礎(chǔ)用例（Base）。包含用例是被封裝的，代表在各種不同基本用例中復(fù)用的行為。當(dāng)某用例的事件流過(guò)于復(fù)雜時(shí)，為了簡(jiǎn)化用例的描述，可以把某一段事件流抽象成為一個(gè)被包含的用例；相反，用例劃分太細(xì)時(shí)，也可以抽象出一個(gè)基用例，來(lái)包含這些細(xì)顆粒的用例。2.UML用例圖的擴(kuò)展關(guān)系擴(kuò)展關(guān)系（extend）是將基用例中一段相對(duì)獨(dú)立并且可選的動(dòng)作，用擴(kuò)展用例加以封裝，再讓它從基用例中聲明的擴(kuò)展點(diǎn)上進(jìn)行擴(kuò)展，從而使基用例行為更簡(jiǎn)練和目標(biāo)更集中。擴(kuò)展用例為基用例添加新的行為，擴(kuò)展用例可以訪(fǎng)問(wèn)基用例的屬性對(duì)于一個(gè)擴(kuò)展用例，可以在基用例上有幾個(gè)擴(kuò)展點(diǎn)。擴(kuò)展用例帶有抽象性質(zhì)，表示用例場(chǎng)景中的某個(gè)“支流”，由特定的擴(kuò)展點(diǎn)觸發(fā)而被啟動(dòng)。與包含關(guān)系不同，擴(kuò)展表示“可選”，而不是“必需”，這意味即使沒(méi)有擴(kuò)展用例，基本用例也是完整的，如果沒(méi)有基本用例，擴(kuò)展用例不能單獨(dú)存在。表3.包含和擴(kuò)展關(guān)系的主要區(qū)別包含的用例擴(kuò)展的用例這個(gè)用例是可選的嗎否是沒(méi)有這個(gè)用例基本用例還完整嗎否是這個(gè)用例的執(zhí)行是有條件的嗎否是這個(gè)用例改變了基本用例的行為嗎否是3.UML用例圖的泛化關(guān)系泛化關(guān)系（generalization）表示子用例和父用例的相似；子用例將繼承父用例的所有結(jié)構(gòu)、行為和關(guān)系。子用例可以使用父用例的一段行為，也可以重載它。父用例通常是抽象的。在實(shí)際應(yīng)用中很少使用泛化關(guān)系，子用例中的特殊行為都可以作為父用例中的備選流存在，代表一般與特殊的關(guān)系，它的意思和面向?qū)ο蟪绦蛟O(shè)計(jì)中的繼承的概念是類(lèi)似的。子用例從父用例繼承了行為和屬性，還可以添加行為和屬性，改變已繼承的行為。3.2.6構(gòu)造業(yè)務(wù)用例模型圖建立業(yè)務(wù)模型，查找業(yè)務(wù)用例都必須使用業(yè)務(wù)主角，而不是普通參與者。業(yè)務(wù)主角是客戶(hù)實(shí)際業(yè)務(wù)里的參與者，沒(méi)有計(jì)算機(jī)，沒(méi)有抽象的計(jì)算機(jī)角色。參與者位于系統(tǒng)邊界外面，如果把邊界內(nèi)和外的參與業(yè)務(wù)的人都作為參與者建模，會(huì)混亂。。3.2.7用例規(guī)格說(shuō)明用例模型包括用例圖和用例規(guī)格說(shuō)明，有時(shí)還要輔之一些簡(jiǎn)單的活動(dòng)圖、狀態(tài)圖和順序圖等。用例說(shuō)明是對(duì)用例、參與者和系統(tǒng)邊界進(jìn)行的詳細(xì)描述。在描述過(guò)程中，還可以對(duì)一些關(guān)鍵的流程，以及這些流程中關(guān)鍵類(lèi)的狀態(tài)變化，使用活動(dòng)圖、狀態(tài)圖或順序圖進(jìn)行圖形化地展現(xiàn)。因此，詳細(xì)描述用例的方式有用例規(guī)約描述、活動(dòng)圖、狀態(tài)圖、順序圖和通信圖等。在需求分析中尚不涉及狀態(tài)問(wèn)題，所以沒(méi)有必要用狀態(tài)圖、順序圖或通信圖表示，可以使用活動(dòng)圖對(duì)用例進(jìn)行分析，因?yàn)榛顒?dòng)圖對(duì)分支、判斷、循環(huán)等流程概念的表達(dá)比其他圖清晰，適合用于描述業(yè)務(wù)過(guò)程。1.用例規(guī)約描述一個(gè)完整的用例包括參與者、前置條件、場(chǎng)景和后置條件等用例建模圖畫(huà)完以后，就要進(jìn)行描述文檔的編寫(xiě)，文檔主要用來(lái)彌補(bǔ)圖形表示的不足和增強(qiáng)系統(tǒng)的完整性。對(duì)于用例描述的內(nèi)容，一般沒(méi)有硬性規(guī)定的格式，但一些必須或者重要的內(nèi)容還是必須要寫(xiě)進(jìn)用例描述里面的。通常包括的內(nèi)容有：用例名稱(chēng)、參與者、前置條件、后置條件、基本事件流、備用事件流、異常事件流等。表3.用例描述格式使用者場(chǎng)景1場(chǎng)景2場(chǎng)景3前置條件后置條件圖3.完整的用例表3.用例描述1⑴只描述參與者的行為，沒(méi)有描述系統(tǒng)的行為用例名稱(chēng)取款用例描述客戶(hù)取款事件流基本事件流1.儲(chǔ)戶(hù)插入ATM卡，并鍵入密碼；2、儲(chǔ)戶(hù)按“取款”按鈕，并鍵入取款數(shù)目；3、儲(chǔ)戶(hù)取走現(xiàn)金、ATM卡以及收據(jù)；4、儲(chǔ)戶(hù)離開(kāi)。用例描述⑵只描述系統(tǒng)的行為，沒(méi)有描述參與者的行為用例名稱(chēng)取款用例描述客戶(hù)取款事件流基本事件流1、ATM系統(tǒng)獲得ATM卡和密碼；2、設(shè)置事務(wù)類(lèi)型為“取款”；3、ATM系統(tǒng)獲取要提取的現(xiàn)金數(shù)目；4、驗(yàn)證賬戶(hù)上是否有足夠儲(chǔ)蓄金額；5、輸出現(xiàn)金、數(shù)據(jù)和ATM卡；6、系統(tǒng)復(fù)位。用例描述2⑶描述過(guò)于冗長(zhǎng)用例名稱(chēng)客戶(hù)維護(hù)用例描述對(duì)客戶(hù)資料進(jìn)行維護(hù)事件流……備選事件流修改客戶(hù)資料1．在客戶(hù)資料維護(hù)的主界面，用戶(hù)選擇查詢(xún)某客戶(hù)資料；2．系統(tǒng)顯示符合條件的客戶(hù)資料，內(nèi)容包括；客戶(hù)編號(hào)、來(lái)源、類(lèi)型、省份、公司名稱(chēng)，同時(shí)在每行的開(kāi)始位置放置“修改”的按鈕，以便讓用戶(hù)點(diǎn)擊進(jìn)行資料修改；3．用戶(hù)選擇某客戶(hù)記錄左邊的“修改”按鈕，修改某客戶(hù)資料；4．系統(tǒng)打開(kāi)修改客戶(hù)資料界面；5．……2.使用活動(dòng)圖描述用例前面用文本描述了用例的流程（用例規(guī)格說(shuō)明）。文本描述的好處是容易被創(chuàng)建和修改，它們可以在任何地方被創(chuàng)建，可以很容易地由業(yè)務(wù)人員和開(kāi)發(fā)人員使用和分享。但是，用文字描述的復(fù)雜用例、業(yè)務(wù)過(guò)程和算法可能難以理解。復(fù)雜流程采用可視化描述就會(huì)好很多。所以，完成了業(yè)務(wù)用例圖后，可以為每一個(gè)業(yè)務(wù)用例繪制一幅活動(dòng)圖。活動(dòng)圖提供了活動(dòng)流程的可視化描述，可以是在系統(tǒng)、業(yè)務(wù)、工作流或其他過(guò)程中使用?；顒?dòng)圖關(guān)注被執(zhí)行的活動(dòng)以及誰(shuí)（或什么）負(fù)責(zé)執(zhí)行這些活動(dòng)?；顒?dòng)圖還有個(gè)很重要的使命就是從業(yè)務(wù)用例分析出系統(tǒng)用例。一個(gè)系統(tǒng)用例應(yīng)該是實(shí)際使用系統(tǒng)的用戶(hù)所進(jìn)行的一個(gè)操作，如“圖書(shū)管理”這個(gè)業(yè)務(wù)用例，可以分解出多個(gè)系統(tǒng)操作。這里要特別注意這些操作，其中很多“活動(dòng)”都很可能是一個(gè)系統(tǒng)用例（當(dāng)然，并不是每個(gè)都是）。如系統(tǒng)中至少包含以下備選系統(tǒng)用例：登錄、注銷(xiāo)登錄、查看圖書(shū)列表、修改圖書(shū)、刪除圖書(shū)。這樣，將每個(gè)業(yè)務(wù)用例都繪制出相應(yīng)的活動(dòng)圖，再將其中的“活動(dòng)”整合，就得出所有備選系統(tǒng)用例。3.3活動(dòng)圖活動(dòng)圖是UML用于對(duì)系統(tǒng)的動(dòng)態(tài)行為建模的另一種常用工具，它描述活動(dòng)的順序，展現(xiàn)從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的控制流?；顒?dòng)圖在本質(zhì)上是一種流程圖?；顒?dòng)圖著重表現(xiàn)從一個(gè)活動(dòng)到另一個(gè)活動(dòng)的控制流，是內(nèi)部處理驅(qū)動(dòng)的流程。3.3.1活動(dòng)圖的符號(hào)UML活動(dòng)圖中包含的圖形符號(hào)有：活動(dòng)狀態(tài)（Activity）、動(dòng)作狀態(tài)（Actions）、動(dòng)作狀態(tài)約束（ActionConstraints）、動(dòng)作流（ControlFlow）、開(kāi)始節(jié)點(diǎn)（InitialNode）、終止節(jié)點(diǎn)（FinalNode）、對(duì)象（Objects）、數(shù)據(jù)存儲(chǔ)對(duì)象（DataStore）、對(duì)象流（ObjectFlows）、分支與合并（DecisionandMergeNodes）、分叉與匯合（ForkandJoinNodes）、異常處理（ExceptionHandler）、活動(dòng)中斷區(qū)域（InterruptibleActivityRegion）和泳道（Partition）。如所示。3.3.2活動(dòng)圖的基本概念1.動(dòng)作狀態(tài)動(dòng)作狀態(tài)是指原子的，不可中斷的動(dòng)作，并在此動(dòng)作完成后通過(guò)完成轉(zhuǎn)換轉(zhuǎn)向另一個(gè)狀態(tài)。動(dòng)作狀態(tài)特點(diǎn)：⑴動(dòng)作狀態(tài)是原子的，它是構(gòu)造UML活動(dòng)圖的最小單位。⑵動(dòng)作狀態(tài)是不可中斷的。⑶動(dòng)作狀態(tài)是瞬時(shí)的行為。⑷動(dòng)作狀態(tài)可以有入轉(zhuǎn)換，入轉(zhuǎn)換既可以是動(dòng)作流，也可以是對(duì)象流。⑸動(dòng)作狀態(tài)與狀態(tài)圖中的狀態(tài)不同，它不能有入口動(dòng)作和出口動(dòng)作，更不能有內(nèi)部轉(zhuǎn)移。⑹在一張UML活動(dòng)圖中，動(dòng)作狀態(tài)允許多處出現(xiàn)。2.活動(dòng)狀態(tài)活動(dòng)圖包含活動(dòng)狀態(tài)。活動(dòng)狀態(tài)表示過(guò)程中命令的執(zhí)行或工作流程中活動(dòng)的進(jìn)行。與等待某一個(gè)事件發(fā)生的一般等待狀態(tài)不同，活動(dòng)狀態(tài)等待計(jì)算處理工作的完成。當(dāng)活動(dòng)完成后，執(zhí)行流程轉(zhuǎn)入到活動(dòng)圖中的下一個(gè)活動(dòng)狀態(tài)。當(dāng)一個(gè)活動(dòng)的前導(dǎo)活動(dòng)完成時(shí)，活動(dòng)圖中的完成轉(zhuǎn)換被激發(fā)?；顒?dòng)狀態(tài)不是原子的，也就是說(shuō)它們可以被中斷?？梢园鸦顒?dòng)狀態(tài)看成是一個(gè)組合，它的控制流由其他的活動(dòng)狀態(tài)和動(dòng)作狀態(tài)組成，如工資報(bào)表申報(bào)審批可以看做是一個(gè)活動(dòng)狀態(tài)，然后可分解成報(bào)表生成，報(bào)表提交，報(bào)表審批，報(bào)表發(fā)布四個(gè)動(dòng)作狀態(tài)。活動(dòng)圖的特點(diǎn)如下：⑴活動(dòng)狀態(tài)可以分解成其他子活動(dòng)或者動(dòng)作狀態(tài)。⑵活動(dòng)狀態(tài)的內(nèi)部活動(dòng)可以用另一個(gè)UML活動(dòng)圖來(lái)表示。⑶和動(dòng)作狀態(tài)不同，活動(dòng)狀態(tài)可以有入口動(dòng)作和出口動(dòng)作，也可以有內(nèi)部轉(zhuǎn)移。⑷動(dòng)作狀態(tài)是活動(dòng)狀態(tài)的一個(gè)特例，如果某個(gè)活動(dòng)狀態(tài)只包括一個(gè)動(dòng)作，那么它就是一個(gè)動(dòng)作狀態(tài)。UML中活動(dòng)狀態(tài)和動(dòng)作狀態(tài)的圖標(biāo)相同，但是活動(dòng)狀態(tài)可以在圖標(biāo)中給出入口動(dòng)作和出口動(dòng)作等信息。3.分叉控制活動(dòng)圖可以包含并發(fā)線(xiàn)程的分叉控制。對(duì)象在運(yùn)行時(shí)可能會(huì)存在兩個(gè)或多個(gè)并發(fā)運(yùn)行的控制流，為了對(duì)并發(fā)的控制流建模，UML中引入了分叉與匯合的概念。分叉用于將動(dòng)作流分為兩個(gè)或多個(gè)并發(fā)運(yùn)行的分支，而匯合則用于同步這些并發(fā)分支，以達(dá)到共同完成一項(xiàng)事務(wù)的目的。活動(dòng)圖不僅能夠表達(dá)順序流程控制還能夠表達(dá)并發(fā)流程控制，如果排除了這一點(diǎn)，活動(dòng)圖很像一個(gè)傳統(tǒng)的流程圖。4.泳道泳道將UML活動(dòng)圖中的活動(dòng)劃分為若干組，并把每一組指定給負(fù)責(zé)這組活動(dòng)的業(yè)務(wù)組織，即對(duì)象。在包含泳道的UML活動(dòng)圖中，每個(gè)活動(dòng)只能明確地屬于一個(gè)泳道。泳道是用垂直實(shí)線(xiàn)繪出，由于它們的外觀的緣故，這些區(qū)域被稱(chēng)作泳道。泳道之間的排序并不會(huì)影響語(yǔ)義。每個(gè)活動(dòng)狀態(tài)都指派了一條泳道，而轉(zhuǎn)移則可能跨越數(shù)條泳道。5.對(duì)象流對(duì)象流是動(dòng)作狀態(tài)或者活動(dòng)狀態(tài)與對(duì)象之間的依賴(lài)關(guān)系，表示動(dòng)作使用對(duì)象或動(dòng)作對(duì)對(duì)象的影響。用UML活動(dòng)圖描述某個(gè)對(duì)象時(shí)，可以把涉及到的對(duì)象放置在UML活動(dòng)圖中并用一個(gè)依賴(lài)將其連接到進(jìn)行創(chuàng)建、修改和撤銷(xiāo)的動(dòng)作狀態(tài)或者活動(dòng)狀態(tài)上，對(duì)象的這種使用方法就構(gòu)成了對(duì)象流。5.對(duì)象流對(duì)象流中的對(duì)象有以下特點(diǎn)：⑴一個(gè)對(duì)象可以由多個(gè)動(dòng)作操作。⑵一個(gè)動(dòng)作輸出的對(duì)象可以作為另一個(gè)動(dòng)作輸入的對(duì)象。⑶在UML活動(dòng)圖中，同一個(gè)對(duì)象可以多次出現(xiàn)，它的每一次出現(xiàn)表面該對(duì)象正處于對(duì)象生存期的不同時(shí)間點(diǎn)。6．活動(dòng)的分解一個(gè)活動(dòng)可以分為若干個(gè)動(dòng)作或子活動(dòng)，這些動(dòng)作和子活動(dòng)本身又可以組成一個(gè)UML活動(dòng)圖。不含內(nèi)嵌活動(dòng)或動(dòng)作的活動(dòng)稱(chēng)之為簡(jiǎn)單活動(dòng)，嵌套了若干活動(dòng)或動(dòng)作的活動(dòng)稱(chēng)為組合活動(dòng)。組合活動(dòng)有自己的名字和相應(yīng)的子UML活動(dòng)圖。3.3.3活動(dòng)圖的構(gòu)建⑴標(biāo)識(shí)需要活動(dòng)圖的用例。一個(gè)系統(tǒng)用例模型包含多幅用例圖，每幅圖又包含多個(gè)用例⑵建模每一個(gè)用例的主路徑。在創(chuàng)建用例的活動(dòng)圖時(shí)，需要先確定該用例一條明確的執(zhí)行工作流程，建立活動(dòng)圖的主路徑，然后以該路徑為主線(xiàn)進(jìn)行補(bǔ)充、擴(kuò)展和完善。⑶建模每一個(gè)用例的從路徑。。⑷添加泳道來(lái)標(biāo)識(shí)活動(dòng)的事務(wù)分區(qū)。。⑸改進(jìn)高層的活動(dòng)。⑹進(jìn)一步對(duì)細(xì)節(jié)進(jìn)行完善。對(duì)前面的活動(dòng)圖進(jìn)行補(bǔ)充和完善?；顒?dòng)圖的主要應(yīng)用有：⑴

描述用例的行為。⑵理解工作流程?；顒?dòng)圖對(duì)理解業(yè)務(wù)處理過(guò)程十分有用?？梢援?huà)出描述業(yè)務(wù)工作流的活動(dòng)圖與領(lǐng)域?qū)＜疫M(jìn)行交流，明確業(yè)務(wù)處理操作是如何進(jìn)行的，將會(huì)有怎樣的變化。⑶描述復(fù)雜過(guò)程的算法。在這種情況下使用的活動(dòng)圖和傳統(tǒng)的程序流程圖的功能是差不多的。UML的活動(dòng)圖和一般的流程圖是有區(qū)別的。UML活動(dòng)圖與流程圖的區(qū)別：⑴

流程圖著重描述處理過(guò)程，它的主要控制結(jié)構(gòu)是順序、分支和循環(huán)，各個(gè)處理過(guò)程之間有嚴(yán)格的順序和時(shí)間關(guān)系。而UML活動(dòng)圖描述的是對(duì)象活動(dòng)的順序關(guān)系所遵循的規(guī)則，它著重表現(xiàn)的是系統(tǒng)的行為，而非系統(tǒng)的處理過(guò)程。⑵UML活動(dòng)圖能夠表示并發(fā)活動(dòng)的情形，而流程圖不能。⑶UML活動(dòng)圖是面向?qū)ο蟮?，而流程圖是面向過(guò)程的。所以?xún)烧叩淖畲髤^(qū)別在于，活動(dòng)圖是以O(shè)OAD為指導(dǎo)的，是以對(duì)象為分析基礎(chǔ)，配合狀態(tài)機(jī)圖使用，為的是對(duì)用例的執(zhí)行流程進(jìn)行描述，而并不是以現(xiàn)實(shí)中的業(yè)務(wù)流程為視角。需求分析規(guī)格說(shuō)明軟件需求說(shuō)明（softwarerequirementsspecification，簡(jiǎn)稱(chēng)為SRS）的編制是為了使用戶(hù)和軟件開(kāi)發(fā)者雙方對(duì)該軟件的初始規(guī)定有一個(gè)共同的理解，使之成為整個(gè)開(kāi)發(fā)工作的基礎(chǔ)。根據(jù)國(guó)標(biāo)GB/T9385-2008計(jì)算機(jī)軟件需求規(guī)格說(shuō)明規(guī)范的要求，軟件需求說(shuō)明包括以下的內(nèi)容：1.引言1.1目的1.2范圍1.3定義、簡(jiǎn)稱(chēng)、縮略語(yǔ)1.4引用文件1.5綜述需求分析規(guī)格說(shuō)明2.總體描述2.1產(chǎn)品描述2.2產(chǎn)品功能2.3用戶(hù)特點(diǎn)2.4約束2.5假設(shè)和依賴(lài)關(guān)系2.6需求分配3.具體需求3.1外部接口需求3.1.1用戶(hù)界面3.1.2硬件接口3.1.3軟件接口3.1.4通信接口3.2類(lèi)/對(duì)象3.2.1類(lèi)/對(duì)象13.2.1.1屬性（直接的3.2.1.2功能3.2.1.3消息3.2.2類(lèi)/對(duì)象23.3性能需求3.4

設(shè)計(jì)約束3.5

軟件系統(tǒng)屬性3.6其他需求3.5需求分析用例建模案例3.5.1需求陳述“圖書(shū)管理信息系統(tǒng)”的用戶(hù)需求陳述如下：在圖書(shū)流通管理系統(tǒng)中，管理員要為每個(gè)讀者建立借閱賬戶(hù)，并給讀者發(fā)放不同類(lèi)別的借閱卡（借閱卡可提供卡號(hào)、讀者姓名、類(lèi)別、單位、職稱(chēng)等）。持有借閱卡的讀者可以借閱、歸還、預(yù)約和續(xù)借圖書(shū)，不同類(lèi)別的讀者可借閱圖書(shū)的范圍、數(shù)量和期限不同。讀者來(lái)圖書(shū)館借書(shū)，可能先查詢(xún)館中的圖書(shū)信息，查詢(xún)可以按書(shū)名、作者、圖書(shū)編號(hào)、關(guān)鍵字查詢(xún)。如果查到則記下書(shū)號(hào)，交給流通組工作人員，等待辦理借書(shū)手續(xù)。如果該書(shū)已經(jīng)被全部借出，可做預(yù)定登記，等待有書(shū)時(shí)被通知。如果圖書(shū)館沒(méi)有該書(shū)的記錄，可進(jìn)行缺書(shū)登記。3.5需求分析用例建模案例3.5.1需求陳述辦理借書(shū)手續(xù)時(shí)要先出示借閱證，借閱圖書(shū)時(shí)，先輸入讀者的借閱卡號(hào)，系統(tǒng)驗(yàn)證借閱卡的有效性和讀者是否可繼續(xù)借閱圖書(shū)。如果借閱卡無(wú)效，讓讀者到辦公室進(jìn)行補(bǔ)辦。如果借書(shū)數(shù)量超出規(guī)定，則不繼續(xù)借閱。如果有過(guò)期圖書(shū)，則需要交納罰款。如果可以借書(shū)，則顯示讀者的基本信息（包括照片）供管理員人工核對(duì)。借書(shū)時(shí)系統(tǒng)登記圖書(shū)證編號(hào)、圖書(shū)編號(hào)、借出時(shí)間和應(yīng)還書(shū)時(shí)間。如果是預(yù)約圖書(shū)，還要修改預(yù)約記錄。當(dāng)讀者還書(shū)時(shí)，流通組工作人員根據(jù)圖書(shū)證編號(hào)找到讀者的借書(shū)信息，察看是否超期。如果已經(jīng)超期，則進(jìn)行超期處罰；如果圖書(shū)有破損、丟失，則進(jìn)行破損及丟失等處罰。登記還書(shū)信息，做還書(shū)處理，同時(shí)查看是否有預(yù)定登記，如果有則發(fā)出到書(shū)通知。3.5需求分析用例建模案例3.5.1需求陳述圖書(shū)采購(gòu)人員采購(gòu)圖書(shū)時(shí)，要注意合理采購(gòu)。如果有缺書(shū)登記，則隨時(shí)進(jìn)行采購(gòu)。采購(gòu)到貨后，編目人員進(jìn)行驗(yàn)收、編目、上架、錄入圖書(shū)信息、發(fā)到書(shū)通知。圖書(shū)館管理人員定期對(duì)圖書(shū)進(jìn)行盤(pán)庫(kù)，如果圖書(shū)丟失或舊書(shū)淘汰，則將該書(shū)從書(shū)庫(kù)中清除，即圖書(shū)注銷(xiāo)。以上是圖書(shū)管理系統(tǒng)的基本需求。經(jīng)過(guò)與圖書(shū)館工作人員反復(fù)交流，他們提出了下列建議：a.當(dāng)借閱的圖書(shū)到期時(shí)，希望能夠提前用短信或電子郵件方式提示讀者。b.讀者希望能夠?qū)崿F(xiàn)網(wǎng)上查詢(xún)和預(yù)定圖書(shū)。c.應(yīng)用系統(tǒng)的各種參數(shù)設(shè)置最好是靈活的，由系統(tǒng)管理人員根據(jù)需要設(shè)定，如借閱期的上限，還書(shū)提示的時(shí)間，預(yù)定圖書(shū)的保持時(shí)間等參數(shù)。3.5.2需求分析用例建模如下：⑴確定參與者。通過(guò)對(duì)系統(tǒng)需求陳述的分析，可以確定系統(tǒng)有如下執(zhí)行者：讀者，流通組工作人員，辦公室工作人員，采購(gòu)員，編目人員。讀者可查詢(xún)圖書(shū)信息和個(gè)人借閱信息，還可以在符合續(xù)借的條件下自己辦理預(yù)約及續(xù)借圖書(shū)；流通組工作人員完成讀者借書(shū)、還書(shū)、預(yù)約和續(xù)借圖書(shū)及罰款等管理工作；辦公室工作人員為讀者辦理借書(shū)證有關(guān)事宜。采購(gòu)人員對(duì)圖書(shū)進(jìn)行訂購(gòu)；編目人員進(jìn)行圖書(shū)的編目。⑵確定用例。在確定參與者之后，結(jié)合圖書(shū)管理的領(lǐng)域知識(shí)，進(jìn)一步分析系統(tǒng)的需求，識(shí)別出的用例有：借書(shū)、還書(shū)、缺書(shū)登記、預(yù)約、取消預(yù)約、查詢(xún)、通知、讀者管理、圖書(shū)管理、處罰、采購(gòu)、編目、圖書(shū)催還等。3.5.2需求分析用例建模如下：⑶系統(tǒng)用例的審查與細(xì)化。要對(duì)系統(tǒng)用例逐一進(jìn)行審核。用例的審核必須有用戶(hù)參與，可以通過(guò)用戶(hù)訪(fǎng)談和討論會(huì)的形式對(duì)系統(tǒng)用例進(jìn)行審核。確定每一個(gè)用例實(shí)現(xiàn)了用戶(hù)的那些需求。是不是用戶(hù)的每一個(gè)需求都有相應(yīng)的用例來(lái)實(shí)現(xiàn)。基本路徑和擴(kuò)展路徑是否完備，是否存在冗余。⑷確定用例之間的關(guān)系。確定參與者和用例之后，進(jìn)一步確定用例之間的關(guān)系。3.5.2需求分析3.5.2需求分析如借閱的用例描述如下：用例名稱(chēng)：借書(shū)用例描述：當(dāng)讀者前來(lái)圖書(shū)館借書(shū)時(shí)，流通組工作人員啟動(dòng)該用例，該用例檢查讀者的有效性及借閱記錄，檢查圖書(shū)是否在庫(kù)，實(shí)現(xiàn)讀者借書(shū)活動(dòng)。參與者：管理員。前置條件：流通組工作人員要先執(zhí)行登陸用例，才能啟動(dòng)借書(shū)用例。讀者號(hào)存在圖書(shū)號(hào)存在圖書(shū)在庫(kù)后置條件：記錄了借閱信息3.5.2需求分析如借閱的用例描述如下：圖書(shū)庫(kù)存減少創(chuàng)建借還書(shū)記錄活動(dòng)的基本過(guò)程：1.輸入讀者賬號(hào)；2.輸入圖書(shū)編號(hào)；3.添加一條借書(shū)記錄；4.“圖書(shū)信息表”中“現(xiàn)有庫(kù)存量”-1；5.“讀者信息表”中“已借書(shū)數(shù)量”＋1；6.提示執(zhí)行情況；7.修改預(yù)約記錄；8.清空讀者、圖書(shū)編號(hào)等輸入數(shù)據(jù)；重復(fù)第2~第