第4章需求分析

需求開(kāi)發(fā)過(guò)程

系統(tǒng)需求過(guò)程

需求獲取來(lái)源

需求收集方法

需求UML建模

需求原型開(kāi)發(fā)

需求規(guī)格說(shuō)明【學(xué)習(xí)目標(biāo)】4.1需求開(kāi)發(fā)過(guò)程一、需求的定義軟件需求是一個(gè)軟件系統(tǒng)所需具有的功能與性能要求，它描述了待開(kāi)發(fā)軟件系統(tǒng)的行為、特性、屬性及其約束條件。需求是指系統(tǒng)應(yīng)達(dá)到的目標(biāo)、功能、性能、環(huán)境等要求。二、需求工程需求開(kāi)發(fā)需求工程需求管理系統(tǒng)分析編寫(xiě)規(guī)格說(shuō)明問(wèn)題獲取需求驗(yàn)證需求工程任務(wù)的層次分解需求工程是指為了獲取需求和描述需求，進(jìn)行系統(tǒng)的需求調(diào)查、需求分析、需求描述、系統(tǒng)需求規(guī)格說(shuō)明活動(dòng)及其管理的過(guò)程。三、需求開(kāi)發(fā)過(guò)程需求開(kāi)發(fā)過(guò)程需求導(dǎo)出與分析過(guò)程4.2需求類型與范圍一、需求類型1.需求縱向分類業(yè)務(wù)需求是反映組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)或產(chǎn)品的業(yè)務(wù)目標(biāo)要求。它們?cè)陧?xiàng)目視圖與范圍文檔中進(jìn)行說(shuō)明。用戶需求是反映用戶對(duì)系統(tǒng)或產(chǎn)品使用中的具體處理要求。它們?cè)谟美臋n或方案文檔進(jìn)行說(shuō)明。系統(tǒng)需求是反映開(kāi)發(fā)人員必須實(shí)現(xiàn)的系統(tǒng)功能，用戶使用系統(tǒng)或產(chǎn)品能完成特定工作任務(wù)，從而達(dá)到系統(tǒng)業(yè)務(wù)目標(biāo)要求。需求分析業(yè)務(wù)需求用戶需求系統(tǒng)需求例用戶需求與系統(tǒng)需求用戶需求:

提供霍亂發(fā)生病例統(tǒng)計(jì)分析系統(tǒng)需求:

1.系統(tǒng)需具有霍亂發(fā)生病例的基本數(shù)據(jù)2.根據(jù)條件(如地區(qū)、時(shí)間段、年齡段等)對(duì)霍亂發(fā)生病例數(shù)量進(jìn)行統(tǒng)計(jì)3.給出統(tǒng)計(jì)數(shù)據(jù)表格輸出或圖形曲線輸出功能需求它指系統(tǒng)應(yīng)該提供什么樣的服務(wù)、如何對(duì)輸入做出反應(yīng)以及系統(tǒng)在特定條件下的行為等描述。非功能需求它指對(duì)系統(tǒng)提供的服務(wù)或功能遵循的約束。包括時(shí)間約束、開(kāi)發(fā)約束、標(biāo)準(zhǔn)約束、法規(guī)約束等。2.需求橫向分類系統(tǒng)將做什么?系統(tǒng)什么時(shí)候做?有多種操作模式嗎?必須執(zhí)行什么種類的計(jì)算或數(shù)據(jù)轉(zhuǎn)換？輸入/輸出數(shù)據(jù)格式是什么？在什么時(shí)間必須保存數(shù)據(jù)？1.功能需求二、需求范圍2.非功能需求問(wèn)題:什么是功能需求？什么是非功能需求？并舉例說(shuō)明。4.3需求的來(lái)源需求開(kāi)發(fā)第一步：確定需求來(lái)源，最基本的需求來(lái)源就是用戶需求。它反映了用戶對(duì)系統(tǒng)的功能與性能等方面的要求。一、需求的來(lái)源幾個(gè)典型來(lái)源：

客戶的期望或愿景

市場(chǎng)產(chǎn)品的廣告資料

當(dāng)前系統(tǒng)的問(wèn)題報(bào)告和增強(qiáng)要求

現(xiàn)有系統(tǒng)的文檔

領(lǐng)域模型二、用戶類別區(qū)分為什么要區(qū)分用戶類型？用戶在系統(tǒng)中扮演了不同角色，如業(yè)務(wù)人員、部門(mén)經(jīng)理、公司主管等，他們對(duì)系統(tǒng)有各自的需求。每一用戶類都將有自己的一系列功能和非功能要求。比如：一個(gè)沒(méi)有經(jīng)驗(yàn)或偶爾使用電腦的用戶關(guān)心系統(tǒng)是否簡(jiǎn)單易用，因此，菜單、提示符和向?qū)呛苤匾摹Ｈ欢瑢?duì)于那些一天使用幾小時(shí)產(chǎn)品的用戶，他們更關(guān)心產(chǎn)品的易用性和高效性，所以他們喜歡使用快捷鍵、宏以及腳本功能。還有一些并不一定是系統(tǒng)的直接使用者，而是通過(guò)報(bào)表或其它應(yīng)用程序訪問(wèn)產(chǎn)品的數(shù)據(jù)和服務(wù)。這些非直接的或次級(jí)的用戶也有他們的需求。4.4需求獲取方法需求開(kāi)發(fā)第二步：需求獲取，它是需求工程的主體。對(duì)于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不同用戶類的需要和限制的過(guò)程。一、需求獲取的主要方法1、訪談設(shè)定好訪談的范圍提出問(wèn)題，聽(tīng)取回答，然后反饋你的理解畫(huà)出模型，鼓勵(lì)用戶改正盡可能使用用戶的術(shù)語(yǔ)描述系統(tǒng)2、業(yè)務(wù)示范要求用戶示范如何處理特定業(yè)務(wù)的過(guò)程提出問(wèn)題，聽(tīng)取回答，然后反饋你的理解畫(huà)出該業(yè)務(wù)處理模型圖，并讓用戶確認(rèn)3、問(wèn)卷調(diào)查適合從許多人那里收集信息設(shè)計(jì)問(wèn)題，收集某項(xiàng)假設(shè)的統(tǒng)計(jì)依據(jù)收集意見(jiàn)、建議4、用戶表格和報(bào)表的收集了解用戶數(shù)據(jù)處理量、處理頻率了解用戶數(shù)據(jù)的呈現(xiàn)形式畫(huà)出該業(yè)務(wù)數(shù)據(jù)模型圖，并讓用戶確認(rèn)了解用戶表格與報(bào)表的來(lái)源與去向5、專題討論會(huì)由產(chǎn)品代表或用戶介紹業(yè)務(wù)的處理過(guò)程、業(yè)務(wù)規(guī)則、處理信息系統(tǒng)分析員記錄業(yè)務(wù)目標(biāo)、場(chǎng)景、業(yè)務(wù)規(guī)則及處理描述，并提出相關(guān)問(wèn)題畫(huà)出該業(yè)務(wù)流程模型圖，并讓用戶確認(rèn)了解用戶對(duì)系統(tǒng)的要求與期望6、快速原型建立了解用戶對(duì)原型系統(tǒng)的反饋信息了解用戶的潛在需求了解用戶的真實(shí)需求二、如何處理收集到的用戶需求？用戶提出“需要”的特性并不總是用戶真正所需的功能要求。當(dāng)收集到用戶的意見(jiàn)后，必須分析、整理這些需求意見(jiàn)，直到理解它為止。將對(duì)需求的理解寫(xiě)成文檔，然后與用戶一起探討，這是一個(gè)反復(fù)的過(guò)程，并且需要花費(fèi)時(shí)間。[實(shí)例]“煤氣管網(wǎng)GIS系統(tǒng)”用戶提出需求：“在城市地圖上進(jìn)行管網(wǎng)瀏覽時(shí)，需有一個(gè)小的窗口顯示當(dāng)前瀏覽的區(qū)域在總圖的位置”

系統(tǒng)功能：“管網(wǎng)瀏覽時(shí)，具有鷹眼功能，即有一個(gè)小的窗口顯示當(dāng)前瀏覽在鳥(niǎo)瞰圖的大致位置”

三、對(duì)需求信息進(jìn)行分類客戶提供的需求通常是零碎的、沒(méi)有條理的，需求分析者必須把代表客戶需求的許多信息分類整理，并把他們合理地編寫(xiě)信息文檔中。下圖描述了需求信息的主要類型。四、對(duì)需求進(jìn)行審查需求是正確嗎？需求是一致嗎？需求是無(wú)二義性嗎？需求是完備嗎？需求是可行嗎？需求是可測(cè)試嗎？需求是可追蹤嗎?五、需求獲取的注意事項(xiàng)項(xiàng)目范圍的定義應(yīng)恰當(dāng)需求獲取應(yīng)解決系統(tǒng)做什么，而不是怎么做需求獲取參與者不能太多需求獲取應(yīng)盡可能詳細(xì)地收集用戶提供的信息六、何時(shí)完成需求的獲取用戶不能想出更多的功能要求。用戶提出新的功能要求，可以從其它相關(guān)功能需求中獲得。用戶提出對(duì)將來(lái)產(chǎn)品的要求，而不是現(xiàn)在我們討論的特定產(chǎn)品。4.5需求建模分析需求開(kāi)發(fā)的第三步——對(duì)收集到的用戶需求進(jìn)行建模分析確定系統(tǒng)功能需求確定系統(tǒng)數(shù)據(jù)需求確定系統(tǒng)非功能性需求描述系統(tǒng)需求一、需求分析為什么需要建模？從用戶收集到的需求信息通常是一大堆雜亂的文字信息，即使你對(duì)它們進(jìn)行了分類，這些組織好的信息還不足夠使開(kāi)發(fā)人員對(duì)需求的完全理解。采用文本表示和用圖形表示結(jié)合起來(lái)繪制出對(duì)預(yù)期系統(tǒng)的完整描述。這些圖形化的表示或者分析模型可以增強(qiáng)你對(duì)系統(tǒng)需求的理解。模型可幫助檢測(cè)不一致性、模糊性、錯(cuò)誤和遺漏的需求。當(dāng)前系統(tǒng)目標(biāo)系統(tǒng)當(dāng)前系統(tǒng)邏輯模型目標(biāo)系統(tǒng)邏輯模型抽象化具體化導(dǎo)出理解需求表達(dá)需求需求建模分析二、需求建模的主要方法在需求分析階段，主要采用結(jié)構(gòu)化分析方法或面向?qū)ο蟮挠美?qū)動(dòng)分析方法對(duì)系統(tǒng)的功能和目標(biāo)需求進(jìn)行建模分析，并通過(guò)快速開(kāi)發(fā)工具建立原型，提交用戶使用原型，進(jìn)一步明確需求。1、結(jié)構(gòu)化分析方法建模方法模型表示數(shù)據(jù)流分析方法數(shù)據(jù)流圖層次數(shù)據(jù)流數(shù)據(jù)字典IDEF0分析方法活動(dòng)數(shù)據(jù)圖結(jié)構(gòu)化建模方法與模型表示數(shù)據(jù)流圖DFD數(shù)據(jù)流圖（DataFlowDiagram）是一種刻畫(huà)業(yè)務(wù)及其數(shù)據(jù)流程處理的建模技術(shù)，它用簡(jiǎn)單的圖形記號(hào)表示數(shù)據(jù)流、處理、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)源以及外部實(shí)體,從而描述系統(tǒng)功能作用。外部實(shí)體加工數(shù)據(jù)流數(shù)據(jù)存儲(chǔ)外部實(shí)體名加工名案例：學(xué)籍管理系統(tǒng)數(shù)據(jù)流程圖學(xué)籍管理系統(tǒng)頂層數(shù)據(jù)流圖招生辦學(xué)籍管理系統(tǒng)用人單位教育部新生名單

報(bào)表畢業(yè)生登記表D1學(xué)籍表學(xué)籍管理系統(tǒng)第1層數(shù)據(jù)流圖招生辦異動(dòng)管理用人單位教育部新生名單

報(bào)表D1學(xué)籍表教師系成績(jī)管理獎(jiǎng)懲管理畢業(yè)生登記表留級(jí)名單學(xué)生注冊(cè)獎(jiǎng)懲報(bào)告獎(jiǎng)懲結(jié)論成績(jī)成績(jī)單獲獎(jiǎng)名單數(shù)據(jù)流圖泡泡圖類型外部實(shí)體名外部實(shí)體加工名加工數(shù)據(jù)流數(shù)據(jù)存儲(chǔ)案例：“訂單處理——數(shù)據(jù)流圖”不提供對(duì)非功能性系統(tǒng)需求的有效理解和建模。不提供對(duì)用戶選擇的合適方法的指導(dǎo)，也沒(méi)有對(duì)方法適用的特殊環(huán)境的忠告。往往產(chǎn)生大量文檔，系統(tǒng)需求的要素被隱藏在一大堆具體細(xì)節(jié)的描述中。產(chǎn)生的模型太注重細(xì)節(jié)以致用戶覺(jué)得難以理解，因而很難去驗(yàn)證這些模型的真實(shí)性。結(jié)構(gòu)化分析方法的不足：2、面向?qū)ο蠓治龇椒ń７椒Ｐ捅硎綰ML用例圖順序圖交互圖OMT-2文本化的用例用例圖對(duì)象交互圖場(chǎng)景圖Booch文本化的用例用例圖對(duì)象交互圖場(chǎng)景圖Coad/Yourdon文本化的用例用例圖對(duì)象交互圖案例：“課程注冊(cè)系統(tǒng)——用例圖”案例：“課程注冊(cè)系統(tǒng)——順序圖”四、數(shù)據(jù)建模的主要方法數(shù)據(jù)建模也是需求分析的一個(gè)重要環(huán)節(jié)，主要有如下兩種方法。建模方法模型表示語(yǔ)義數(shù)據(jù)模型方法實(shí)體-關(guān)系圖（ER圖）IDEF1X模型方法IDEF1X圖例數(shù)據(jù)建模方法與模型表示案例：“酒店管理系統(tǒng)——ER圖”結(jié)構(gòu)化方法與面向?qū)ο蠓椒ǖ男枨蠓治瞿Ｐ捅容^事件事物實(shí)體-關(guān)系圖類圖結(jié)構(gòu)化方法面向?qū)ο蠓椒〝?shù)據(jù)流程圖數(shù)據(jù)字典小說(shuō)明用例圖活動(dòng)圖順序圖4.6統(tǒng)一建模語(yǔ)言（UML）概述

統(tǒng)一建模語(yǔ)言（UML）是一個(gè)用于描述系統(tǒng)模型的面向?qū)ο蠼ＵZ(yǔ)言。它統(tǒng)一了GradyBooch、JimRumbangh、和IvarJacobson三位大師的面向?qū)ο蠼Ｃ枋稣Z(yǔ)言(Booch、OMT、OOSE)，并對(duì)其做了進(jìn)一步的發(fā)展，最終成為廣泛接受的面向?qū)ο蠼ＵZ(yǔ)言。UML已被OMG所采用，現(xiàn)成為業(yè)界的建模語(yǔ)言標(biāo)準(zhǔn)。UML的演化一、UML的特點(diǎn)

統(tǒng)一了面向?qū)ο竽Ｐ驮氐亩x和表示法，以及對(duì)模型表示的規(guī)定，使得對(duì)系統(tǒng)的建模有章可循。又因有標(biāo)準(zhǔn)的語(yǔ)言工具可用，有利于保正系統(tǒng)的建模質(zhì)量。

提供了簡(jiǎn)潔的表達(dá)面向?qū)ο笾械母鞣N概念和模型元素。

可視化、表示能力強(qiáng)。系統(tǒng)的邏輯模型或?qū)崿F(xiàn)模型均可用UML

模型圖形清晰表示，并提供用戶的擴(kuò)展支持。獨(dú)立開(kāi)發(fā)過(guò)程。可支持其他面向?qū)ο箝_(kāi)發(fā)和傳統(tǒng)的軟件開(kāi)發(fā)過(guò)程。二、UML在軟件開(kāi)發(fā)中的應(yīng)用UML是一個(gè)完整的建模語(yǔ)言，支持系統(tǒng)開(kāi)發(fā)的不同階段：在需求描述階段，可以用用例來(lái)捕獲用戶需求。通過(guò)用例建模，描述系統(tǒng)感興趣的外部角色及其對(duì)系統(tǒng)的功能要求。在系統(tǒng)分析階段主要關(guān)心問(wèn)題域中的主體（如類和對(duì)象等）和機(jī)制，以及它們相互間的關(guān)系。為實(shí)現(xiàn)用例，類之間需要協(xié)作，這可以用UML動(dòng)態(tài)模型來(lái)描述。在系統(tǒng)設(shè)計(jì)階段，使用（類圖、對(duì)象圖、活動(dòng)圖、狀態(tài)圖、序列圖、協(xié)作圖、包圖、組件圖、部署圖），定義軟件系統(tǒng)體系結(jié)構(gòu)和組件技術(shù)細(xì)節(jié)。在系統(tǒng)實(shí)現(xiàn)階段，應(yīng)用面向?qū)ο缶幊陶Z(yǔ)言將來(lái)自設(shè)計(jì)階段的類轉(zhuǎn)換成實(shí)際的代碼。在系統(tǒng)測(cè)試階段，集成測(cè)試使用組件圖和協(xié)作圖；系統(tǒng)測(cè)試用例圖來(lái)驗(yàn)證系統(tǒng)的行為；驗(yàn)收測(cè)試由用戶進(jìn)行，以驗(yàn)證系統(tǒng)測(cè)試的結(jié)果是否滿足在分析階段確定的需求。1.RationalRose介紹RationalRose是美國(guó)Rational軟件公司在軟件工程專家Booch、Jacobson、Rumbaugh等人主持下研制的面向?qū)ο驝ASE的可視化工具，它支持面向?qū)ο笙到y(tǒng)建模、模型集成、源代碼生成、系統(tǒng)測(cè)試、文檔生成、反向工程、項(xiàng)目管理、團(tuán)隊(duì)開(kāi)發(fā)，以及InternetWEB發(fā)布等功能，形成一個(gè)強(qiáng)大的軟件開(kāi)發(fā)集成環(huán)境。目前RationalRose工具的有三種版本：RoseModeler,可對(duì)系統(tǒng)創(chuàng)建模型，但不支持代碼的產(chǎn)生和逆向

轉(zhuǎn)出工程代碼。RoseProfessional,可產(chǎn)生一種語(yǔ)言代碼。RoseEnterprise,可產(chǎn)生多種語(yǔ)言代碼，如C++、Java、Ada、CORBA、COM、VisualBasic、XML、Oracle等。三、UML建模工具2.其它建模工具1)MicrosoftVisioVisio是美國(guó)Microsoft軟件公司繪圖工具產(chǎn)品，它可以用來(lái)繪制建筑結(jié)構(gòu)、電氣結(jié)構(gòu)、網(wǎng)絡(luò)結(jié)構(gòu)、軟件結(jié)構(gòu)、數(shù)據(jù)庫(kù)結(jié)構(gòu)、網(wǎng)站結(jié)構(gòu)、組織機(jī)構(gòu)、業(yè)務(wù)模型等圖形。同樣它也可用繪制UML模型圖。2)VisibleAnalystVisibleAnalyst是可視系統(tǒng)公司的CASE工具產(chǎn)品，它不但可以用來(lái)設(shè)計(jì)傳統(tǒng)的軟件模型（如數(shù)據(jù)流圖、ER實(shí)體關(guān)系圖），也可用來(lái)設(shè)計(jì)UML模型。3)TogetherTogether是Borland公司的CASE工具產(chǎn)品，它不但可以用來(lái)設(shè)計(jì)UML模型,還可支持幾種面向?qū)ο笳Z(yǔ)言的往返工程。4.7UML用例圖模型

在早期的面向?qū)ο箝_(kāi)發(fā)方法中，都是以自然語(yǔ)言來(lái)描述系統(tǒng)的功能需求。這樣的做法沒(méi)有一個(gè)統(tǒng)一的格式，缺乏描述的形式化，隨意性較大，容易產(chǎn)生理解上的含混和不準(zhǔn)確性。當(dāng)UML用例圖（Usecasediagram）模型提出后，這些問(wèn)題得到了很好地解決。

一、什么是用例圖模型UML的用例模型一種描述系統(tǒng)功能性需求的方法。詳細(xì)描述系統(tǒng)與外界環(huán)境的交互場(chǎng)景。二、用例圖的組成用例圖由如下元素組成：角色(Actor)：也稱為參與者，它代表系統(tǒng)的用戶。系統(tǒng)邊界(Systemscope)：它確定系統(tǒng)的范圍。用例(Usecase)：它代表系統(tǒng)提供的服務(wù)。關(guān)聯(lián)（Association）：它表示角色與用例間的關(guān)系。UML的用例圖1、用例圖中的關(guān)聯(lián)1）角色與用例的關(guān)聯(lián)角色與用例的關(guān)聯(lián)表示角色與用例相關(guān)性。在UML中是使用一條實(shí)線連接角色與用例，如下圖所示。選課系統(tǒng)的用例關(guān)聯(lián)2）角色與角色的關(guān)聯(lián)角色與角色的關(guān)聯(lián)用來(lái)表示一般角色與特殊角色的泛化關(guān)系。在UML圖中，使用帶空心三角箭頭的實(shí)線表示。如下圖所示：3）用例與用例的關(guān)聯(lián)用例與用例的泛化關(guān)聯(lián)用來(lái)表示一般用例與特殊用例的繼承關(guān)系。在UML圖中，使用帶空心三角箭頭的實(shí)線表示。如下圖所示：

用例之間也可存在關(guān)聯(lián)。這些關(guān)聯(lián)包括：泛化關(guān)聯(lián)包含關(guān)聯(lián)擴(kuò)展關(guān)聯(lián)此外，系統(tǒng)分析員也可以利用UML的擴(kuò)充機(jī)制自定義用例的關(guān)聯(lián)。用例之間的泛化關(guān)系用例與用例的包含關(guān)聯(lián)用來(lái)表示一個(gè)用例的行為包含了另一個(gè)用例中的行為。在UML圖中，使用帶虛線箭頭表示，并在線上標(biāo)有構(gòu)造型<<include>>。如下圖所示：成績(jī)管理用例與用例的擴(kuò)展關(guān)聯(lián)用來(lái)表示一個(gè)用例的行為擴(kuò)展了另一個(gè)用例的行為。在UML圖中，使用帶虛線箭頭表示，并在線上標(biāo)有構(gòu)造型<<extend>>。如下圖所示：包含關(guān)聯(lián)與擴(kuò)展關(guān)聯(lián)的區(qū)別：包含關(guān)聯(lián)中關(guān)系是必須的，擴(kuò)展關(guān)聯(lián)中的關(guān)系是可選擇的。圖書(shū)管理系統(tǒng)用例細(xì)化商品訂購(gòu)用例圖2、用例圖示例三、如何建立用例圖模型創(chuàng)建用例圖模型有3項(xiàng)任務(wù)：找出系統(tǒng)中的角色和用例。細(xì)化描述每個(gè)用例。建立用例圖模型結(jié)構(gòu)。1）從系統(tǒng)中識(shí)別出角色1、找出系統(tǒng)中的角色和用例如何從系統(tǒng)中識(shí)別出角色?1）誰(shuí)使用系統(tǒng)的主要功能？2）誰(shuí)需要系統(tǒng)的支持以完成其日常工作任務(wù)？3）誰(shuí)負(fù)責(zé)維護(hù)、管理并保持系統(tǒng)正常運(yùn)行？4）系統(tǒng)需要應(yīng)付（或處理）哪些硬設(shè)備？5）系統(tǒng)需要和哪些外部系統(tǒng)交互？6）誰(shuí)（或什么）對(duì)系統(tǒng)運(yùn)行產(chǎn)生的結(jié)果感興趣？在識(shí)別出了角色之后，就需要從系統(tǒng)識(shí)別用例：2）從系統(tǒng)中識(shí)別用例通過(guò)回答下述問(wèn)題來(lái)幫助識(shí)別用例：角色的任務(wù)是什么？角色為系統(tǒng)提供什么信息?角色需要通知系統(tǒng)外部有突然變化嗎？系統(tǒng)需要通知角色正在發(fā)生的事情嗎？2、細(xì)化描述用例規(guī)約成績(jī)管理案例:成績(jī)管理功能需求用例圖模型例超市進(jìn)銷(xiāo)存系統(tǒng)需求分析——用例圖建模1、超市進(jìn)銷(xiāo)存系統(tǒng)的需求描述如下：

（1）銷(xiāo)售①售貨員接收顧客的商品訂購(gòu)，輸入顧客購(gòu)買(mǎi)的商品，計(jì)算總價(jià)；②顧客付款并接收購(gòu)物打印清單；③售貨員保存顧客購(gòu)買(mǎi)商品的記錄數(shù)據(jù)到系統(tǒng)。

（2）庫(kù)存①庫(kù)存管理員每天進(jìn)行盤(pán)點(diǎn)一次；清點(diǎn)商品數(shù)目及狀況。②庫(kù)存管理員當(dāng)發(fā)現(xiàn)庫(kù)存商品有損壞時(shí)，及時(shí)向相關(guān)部門(mén)報(bào)損；③在供應(yīng)商的商品到貨時(shí)，庫(kù)存管理員首先檢查商品是否合格，并將合格的商品入庫(kù)處理；當(dāng)商品進(jìn)入賣(mài)場(chǎng)時(shí)，進(jìn)行商品出庫(kù)處理。（3）訂貨①訂貨員用新商品供應(yīng)商信息更新供應(yīng)商數(shù)據(jù)庫(kù)的信息；②訂貨員統(tǒng)計(jì)庫(kù)存商品是否低于庫(kù)存下限，然后制作訂貨單。

（4）統(tǒng)計(jì)①經(jīng)理能夠使用系統(tǒng)的統(tǒng)計(jì)功能，了解商品銷(xiāo)售情況、庫(kù)存情況、供應(yīng)商情況，以便進(jìn)行合理的營(yíng)銷(xiāo)策略。②經(jīng)理按市場(chǎng)情況適時(shí)變動(dòng)商品價(jià)格。3、超市進(jìn)銷(xiāo)存系統(tǒng)的用例圖建模

1）系統(tǒng)角色

超市服務(wù)的對(duì)象是顧客，超市系統(tǒng)內(nèi)部員工可以按人員的職能來(lái)分類。下圖是超市進(jìn)銷(xiāo)存管理系統(tǒng)角色分析的用例圖。2）超市進(jìn)銷(xiāo)存管理系統(tǒng)的頂層用例圖3）銷(xiāo)售管理子系統(tǒng)的用例圖銷(xiāo)售管理子系統(tǒng)的部分用例描述：4）訂貨管理子系統(tǒng)的用例圖訂貨管理子系統(tǒng)的部分用例描述：5）庫(kù)存管理子系統(tǒng)的用例圖庫(kù)存管理子系統(tǒng)的部分用例描述：庫(kù)存管理子系統(tǒng)的部分用例描述：6）統(tǒng)計(jì)分析子系統(tǒng)的用例圖統(tǒng)計(jì)分析子系統(tǒng)的部分用例描述：7）身份驗(yàn)證子系統(tǒng)的用例圖身份驗(yàn)證子系統(tǒng)的部分用例描述：采用UML用例圖，描述銀行ATM機(jī)系統(tǒng)的需求模型練習(xí)：一、什么是活動(dòng)圖

活動(dòng)圖是一種用于描述系統(tǒng)行為的模型視圖，它可用來(lái)描述過(guò)程（業(yè)務(wù)過(guò)程、工作流、事件流等）中的活動(dòng)及其遷移。簡(jiǎn)單地講，活動(dòng)圖是“OO流程圖”。4.7UML活動(dòng)圖二、活動(dòng)圖的主要應(yīng)用1．描述用例的行為

活動(dòng)圖對(duì)用例描述尤其有用，它可建模用例的工作流，顯示用例內(nèi)部和用例之間的路徑；它也可以向讀者說(shuō)明需要滿足什么條件用例才會(huì)有效，以及用例完成后系統(tǒng)保留的條件或者狀態(tài)。2．理解工作流程

活動(dòng)圖對(duì)理解業(yè)務(wù)處理過(guò)程十分有用。可以畫(huà)出描述業(yè)務(wù)工作流的活動(dòng)圖與領(lǐng)域?qū)＜疫M(jìn)行交流，明確業(yè)務(wù)處理操作是如何進(jìn)行的，將會(huì)有怎樣的變化。3．描述復(fù)雜過(guò)程的算法

在這種情況下使用的活動(dòng)圖不過(guò)是UML版的程序流程圖，常規(guī)的順序、分支過(guò)程在活動(dòng)圖中都能得到充分的表現(xiàn)。三、活動(dòng)圖的基本元素活動(dòng)圖示意活動(dòng)操作狀態(tài)轉(zhuǎn)移對(duì)象流分岔決策聯(lián)結(jié)活動(dòng)圖保留了許多傳統(tǒng)的流程圖的特征，它包含如下元素。活動(dòng)

活動(dòng)在活動(dòng)圖中，用來(lái)指示要完成某項(xiàng)工作的動(dòng)作或表示工作流的步驟。其UML標(biāo)記符是一個(gè)帶有圓角的矩形，如下圖所示。2.操作

可以用操作在活動(dòng)中增加更多詳細(xì)的步驟。操作是活動(dòng)中執(zhí)行的小步驟。3.狀態(tài)

狀態(tài)的標(biāo)記符與活動(dòng)類似，也是帶圓角的矩形，但狀態(tài)的圓角比較小，如下圖所示。4．轉(zhuǎn)移

轉(zhuǎn)移用來(lái)指示一種狀態(tài)到另一個(gè)狀態(tài)的控制流。5、決策

決策是基于判斷條件選擇控制流繼續(xù)的方向。決策的UML符號(hào)是一個(gè)小菱形標(biāo)記符，然后從這里再按條件控制分支轉(zhuǎn)移到滿足條件的活動(dòng)，如下圖所示。例描述教師記錄學(xué)生成績(jī)用例的活動(dòng)圖1.泳道

泳道可以使活動(dòng)圖非常整潔，因?yàn)樗鼈冊(cè)诤艽蟪潭壬显鰪?qiáng)了活動(dòng)圖的可讀性。泳道使用幾個(gè)大矩形框表示，如下圖所示。四、學(xué)習(xí)活動(dòng)圖中的其他標(biāo)記符

案例:CDC疾病監(jiān)測(cè)直報(bào)流程

活動(dòng)圖中可以輸入和輸出對(duì)象，并可以修改對(duì)象狀態(tài)。在活動(dòng)圖上用對(duì)象流表示這些。如下圖所示。2．對(duì)象流1.采用UML活動(dòng)圖，建模描述圖書(shū)借閱流程2.采用UML活動(dòng)圖，建模研究生選課流程練習(xí)：4.8需求原型驗(yàn)證一、為什么需要原型開(kāi)發(fā)需要原型開(kāi)發(fā)的理由：系統(tǒng)開(kāi)發(fā)周期長(zhǎng)，需要較長(zhǎng)時(shí)間才能使用戶看到產(chǎn)品的雛形，用戶的需求變更反饋會(huì)使系統(tǒng)開(kāi)發(fā)增加較大工作量與開(kāi)支。開(kāi)發(fā)方與用戶在開(kāi)發(fā)初期對(duì)系統(tǒng)的需求均不完全清楚。系統(tǒng)規(guī)模大，且可分塊實(shí)現(xiàn)。實(shí)例

“城市煤氣管網(wǎng)GIS系統(tǒng)”二、選擇原型方法與實(shí)現(xiàn)技術(shù)拋棄式原型實(shí)現(xiàn)方法是在原型達(dá)到預(yù)期目的以后將它拋棄，所以可以花最小的代價(jià)盡快地建立該原型。拋棄式原型方法適合解決需求中的不確定性、二義性、不完整性或含糊性問(wèn)題，以減少在繼續(xù)開(kāi)發(fā)時(shí)存在的風(fēng)險(xiǎn)。拋棄式原型可幫助用戶和開(kāi)發(fā)者想象如何實(shí)現(xiàn)需求和可以發(fā)現(xiàn)需求中的漏洞。拋棄式原型還可以使用戶判斷出這些需求是否可以完成必要的業(yè)務(wù)過(guò)程。進(jìn)化式原型實(shí)現(xiàn)方法是將原型系統(tǒng)逐漸地演化為產(chǎn)品系統(tǒng)。與拋棄型原型的快速、粗略的特點(diǎn)相比，演化型原型一開(kāi)始就必須具有健壯性和產(chǎn)品質(zhì)量級(jí)的代碼。因此，對(duì)于描述相同的功能，建立進(jìn)化型原型比建立拋棄型原型所花的時(shí)間要多。一個(gè)演化型原型必須設(shè)計(jì)為易于升級(jí)和優(yōu)化的，因此，必須重視軟件系統(tǒng)性和完整性的設(shè)計(jì)原則。原型開(kāi)發(fā)實(shí)現(xiàn)技術(shù)：第四代技術(shù)可復(fù)用軟件構(gòu)件技術(shù)形式化規(guī)約和原型實(shí)現(xiàn)環(huán)境討論：下列哪些系統(tǒng)適合拋棄型原型開(kāi)發(fā)實(shí)現(xiàn)？哪些系統(tǒng)適合演化型原型開(kāi)發(fā)實(shí)現(xiàn)？全自動(dòng)洗衣機(jī)控制系統(tǒng)