網(wǎng)站需求分析

網(wǎng)站需求分析第一頁，共四十二頁，編輯于2023年，星期三3.1網(wǎng)站工程項(xiàng)目階段劃分3.2網(wǎng)站需求分析一般內(nèi)容3.3具體功能需求分析描述方法3.4網(wǎng)站需求分析第二頁，共四十二頁，編輯于2023年，星期三3.1網(wǎng)站工程項(xiàng)目階段劃分網(wǎng)站工程項(xiàng)目實(shí)施大致分為五個階段：（1）需求分析：準(zhǔn)確地把握用戶建立網(wǎng)站的目的，明確項(xiàng)目范圍、整體性和可操作性。具體工作包括：對用戶業(yè)務(wù)（商業(yè)、工業(yè)、教育、政務(wù)等）策略的回顧，討論、確定并按優(yōu)先次序列出需求清單，提交工程項(xiàng)目需求，安排工程項(xiàng)目實(shí)施計劃。（2）規(guī)劃設(shè)計。在需求分析階段成果的基礎(chǔ)上，對網(wǎng)站服務(wù)器系統(tǒng)選型與配置、網(wǎng)站功能、系統(tǒng)建構(gòu)（內(nèi)容設(shè)計、交互信息規(guī)劃、界面設(shè)計等）和視覺創(chuàng)意等方面進(jìn)行更詳細(xì)的分析設(shè)計。所有的分析設(shè)計需要記錄，并與用戶深入探討和改進(jìn)。如有必要，網(wǎng)站開發(fā)人員應(yīng)制作一個原型或演示系統(tǒng)，來測試網(wǎng)站建構(gòu)的概念。第三頁，共四十二頁，編輯于2023年，星期三（3）開發(fā)整合。在以上兩階段基礎(chǔ)上具體構(gòu)建網(wǎng)站，用各種方法、手段實(shí)現(xiàn)已有的構(gòu)思和規(guī)劃，最終形成一個可以被發(fā)布至互聯(lián)網(wǎng)或內(nèi)部網(wǎng)的系統(tǒng)?？赡馨ㄐ孪到y(tǒng)與原有信息資源的整合。（4）測試發(fā)布。網(wǎng)站系統(tǒng)測試包括：功能測試是測試已知網(wǎng)站所應(yīng)具有的功能，通過測試檢測每個功能是否都能正常使用；結(jié)構(gòu)測試是按照網(wǎng)站程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗(yàn)程序中的每條通路是否都有能按預(yù)定要求正確工作；性能測試：檢測網(wǎng)站系統(tǒng)相應(yīng)用戶訪問請求的速度。測試時，首先在開發(fā)環(huán)境中進(jìn)行，然后遷移至運(yùn)營環(huán)境進(jìn)行全面在線測試，直至網(wǎng)站系統(tǒng)進(jìn)入用戶的業(yè)務(wù)運(yùn)作階段。（5）管理維護(hù)。網(wǎng)站項(xiàng)目團(tuán)隊幫助用戶學(xué)會如何運(yùn)作及維護(hù)網(wǎng)站系統(tǒng)，對網(wǎng)站系統(tǒng)進(jìn)行必要的監(jiān)控、維護(hù)，以保證正常運(yùn)行，并比較衡量網(wǎng)站系統(tǒng)的目標(biāo)實(shí)現(xiàn)情況，整理形成一份計劃，以便網(wǎng)站系統(tǒng)的增強(qiáng)與升級。第四頁，共四十二頁，編輯于2023年，星期三3.2網(wǎng)站需求分析一般內(nèi)容網(wǎng)站需求分析：了解、分析、明確用戶需求，并準(zhǔn)確、清晰地以文檔形式表達(dá)出來，提供給項(xiàng)目實(shí)施的每個成員，保證實(shí)施過程按照滿足用戶需求為目的的正確方向進(jìn)行。開發(fā)人員和網(wǎng)站所有者都負(fù)有重要的責(zé)任。需求分析的原則：幫助網(wǎng)站所有者整理出他想要的、并且可實(shí)現(xiàn)的網(wǎng)站人們不一定能說清楚自己想要什么；網(wǎng)站是一個比較龐大的信息系統(tǒng)，需要一定的方法來規(guī)范需求分析的過程。包括三個階段的內(nèi)容：（1）網(wǎng)站背景分析；（2）總體需求分析；（3）具體需求分析每一階段的分析都為后一階段的工作打基礎(chǔ)。每個階段都需要與網(wǎng)站所有者進(jìn)行溝通、確認(rèn)。第五頁，共四十二頁，編輯于2023年，星期三3.2.1網(wǎng)站背景分析網(wǎng)站背景分析主要對網(wǎng)站建立者的背景情況進(jìn)行了解，以及對網(wǎng)站建立的基礎(chǔ)條件、可行性等進(jìn)行分析建立網(wǎng)站的兩種情況：已有線下業(yè)務(wù)的組織形式，網(wǎng)站為線下業(yè)務(wù)服務(wù)；純網(wǎng)上業(yè)務(wù)平臺。第六頁，共四十二頁，編輯于2023年，星期三網(wǎng)站背景分析步驟及內(nèi)容：業(yè)務(wù)背景概況了解：網(wǎng)站組織簡介（Whoareyou？）業(yè)務(wù)情況分析（Whatareyoudoing？）市場狀況分析（Howareyou？）網(wǎng)站建立背景：起因：為什么想要建立網(wǎng)站？訴求：有什么樣的網(wǎng)站構(gòu)想？第七頁，共四十二頁，編輯于2023年，星期三結(jié)合業(yè)務(wù)背景分析建立網(wǎng)站的可行性是否有能力（人力、物力、財力）運(yùn)營所構(gòu)想的網(wǎng)站？所構(gòu)想的網(wǎng)站能否有好的效果？網(wǎng)站構(gòu)想的現(xiàn)實(shí)性市場環(huán)境的競爭因素分析如何在能力的約束下獲得效果更好的網(wǎng)站可行方案。第八頁，共四十二頁，編輯于2023年，星期三例：經(jīng)管學(xué)院網(wǎng)站業(yè)務(wù)背景概況了解：經(jīng)管學(xué)院是個什么組織？經(jīng)管學(xué)院主要有哪些業(yè)務(wù)？經(jīng)管學(xué)院的規(guī)模、影響力等網(wǎng)站建立背景了解：起因：在校教師、學(xué)生不經(jīng)常在同一地點(diǎn)；考生了解學(xué)院的途徑很不方便。訴求：更大范圍宣傳學(xué)院；方便學(xué)院教師、學(xué)生工作、學(xué)習(xí)需求；可行性分析：能力效果可行方案第九頁，共四十二頁，編輯于2023年，星期三3.2.2總體需求分析總體需求分析是定義網(wǎng)站的總體范圍和目標(biāo)總體需求分析是后續(xù)建設(shè)任務(wù)的基礎(chǔ)和藍(lán)圖

主要分析內(nèi)容：建站目標(biāo)分析受眾分析網(wǎng)站定位分析第十頁，共四十二頁，編輯于2023年，星期三（1）建站目標(biāo)分析根據(jù)網(wǎng)站背景分析，定義網(wǎng)站的使命和意義，包括網(wǎng)站的服務(wù)范圍網(wǎng)站所要達(dá)到的運(yùn)行效果（近期目標(biāo)，遠(yuǎn)期目標(biāo)）如：

“本網(wǎng)站將全面介紹經(jīng)管學(xué)院的組織結(jié)構(gòu)、師資情況、招生情況、招聘情況、教學(xué)及科研發(fā)展?fàn)顩r、院系活動、社會合作活動等關(guān)于學(xué)院的全方面的信息，讓所有希望了解經(jīng)管學(xué)院的個人或組織都能夠在網(wǎng)站中方便地找到所需的信息；并在逐步地發(fā)展中成為各方與學(xué)院聯(lián)系及合作的綜合性的電子服務(wù)平臺?！钡谑豁摚菜氖?，編輯于2023年，星期三（2）受眾分析根據(jù)建站目標(biāo)，確定瀏覽者的身份和特點(diǎn)受眾分析是網(wǎng)站信息及服務(wù)內(nèi)容設(shè)置的重要依據(jù)之一主要分析內(nèi)容分析可能瀏覽網(wǎng)站的人群了解不同人群的具體特征和需求特點(diǎn)年齡、職業(yè)、生活環(huán)境等個人特征；組織類型、行業(yè)環(huán)境等組織特征；個人上網(wǎng)行為特點(diǎn)；對網(wǎng)站的信息（功能）需求特點(diǎn)?？赡苄枰M(jìn)行調(diào)查，形成《用戶調(diào)查報告》如：經(jīng)管學(xué)院網(wǎng)站的可能受眾有：在校學(xué)生及教職工、擬報考學(xué)院的考生及家長、擬求職的應(yīng)聘者、合作組織及個人、擬尋求項(xiàng)目或其它形式合作的其它組織及個人、上下級相關(guān)部門及個人、其它對學(xué)院情況感興趣的組織及個人。第十二頁，共四十二頁，編輯于2023年，星期三（3）網(wǎng)站定位分析根據(jù)受眾分析、結(jié)合競爭者分析為實(shí)現(xiàn)網(wǎng)站目標(biāo)確定網(wǎng)站的總體定位，定位包括：網(wǎng)站信息、服務(wù)內(nèi)容方面的定位；形式方面的定位，如色彩、主題風(fēng)格等如：

“經(jīng)管學(xué)院網(wǎng)站應(yīng)通過統(tǒng)一的、專業(yè)化的語言及界面，向受眾發(fā)布準(zhǔn)確、全面、及時的學(xué)院綜合信息”定位要求：符合瀏覽者的需求和特點(diǎn)；突出特色可以在競爭中占據(jù)優(yōu)勢，吸引更多瀏覽者；可能需要對同行業(yè)競爭者的情況進(jìn)行調(diào)研，形成《市場調(diào)研報告》分析獲得體現(xiàn)特色的策略第十三頁，共四十二頁，編輯于2023年，星期三3.2.3具體需求分析包括功能需求與性能需求兩方面功能需求：網(wǎng)站能做什么根據(jù)總體需求分析的指導(dǎo)逐一、詳細(xì)分析網(wǎng)站所提供的信息和功能。形成《網(wǎng)站功能描述書》性能需求：非功能性需求，是網(wǎng)站實(shí)現(xiàn)功能的效果、程度所提供服務(wù)及網(wǎng)站策略實(shí)現(xiàn)的質(zhì)量要求第十四頁，共四十二頁，編輯于2023年，星期三3.2.4非功能需求分析（一）性能需求的意義例1：考核系統(tǒng)中，每天在上班后1小時內(nèi)，將有90%的用戶會上線查看自己的考核結(jié)果。因此，在進(jìn)行考核結(jié)果查詢功能的分析中，應(yīng)寫下這樣的話：查詢必須高效（預(yù)計查詢數(shù)據(jù)量：xxx），并且支持高并發(fā)操作（預(yù)計并發(fā)用戶峰值：xxx）。有了這些描述，設(shè)計和開發(fā)人員會著重注意該功能的性能問題，測試人員也可以著重進(jìn)行該部分的性能測試。例2：在另一個項(xiàng)目中，用戶需要對大量的數(shù)據(jù)進(jìn)行選擇，進(jìn)而完成制作清冊、下派、回退等操作。在前期的需求分析中，需求人員沒有仔細(xì)分析這些操作的易用性，沒有提供給用戶批量選擇等功能第十五頁，共四十二頁，編輯于2023年，星期三（二）性能需求指標(biāo)舉例哪些是非功能需求呢？“URPS+”：即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。1可用性（Usability）可用性是一個非常寬泛的概念，它泛指那些能讓用戶順利使用系統(tǒng)的指標(biāo)，包括易用性（易操作、易理解）、準(zhǔn)確性、安全性（權(quán)限體系、訪問限制）、兼容性（服務(wù)器、客戶端的兼容度），等等。2可靠性（Reliability）可靠性就是系統(tǒng)可以可靠運(yùn)行，包括系統(tǒng)成熟度（數(shù)據(jù)吞吐量、并發(fā)用戶量、連續(xù)不停機(jī)性能等）、數(shù)據(jù)容錯度、系統(tǒng)易恢復(fù)性，等等。第十六頁，共四十二頁，編輯于2023年，星期三3性能（Performance）性能，就是用戶看到的系統(tǒng)運(yùn)行的表現(xiàn)、效果，是需求分析階段最主要的分析內(nèi)容。用戶對性能的要求沒有止境，但現(xiàn)實(shí)卻是殘酷的。性能受到許多因素的影響，包括業(yè)務(wù)需求、軟件設(shè)計、數(shù)據(jù)庫設(shè)計、系統(tǒng)部署方式，等等。其中，業(yè)務(wù)需求和部署方式，對性能的影響是最大的。第十七頁，共四十二頁，編輯于2023年，星期三（1）業(yè)務(wù)需求影響性能的。一個數(shù)據(jù)導(dǎo)出的功能，看似一個非常普通的功能。但是經(jīng)過仔細(xì)地分析我們發(fā)現(xiàn)，客戶在執(zhí)行數(shù)據(jù)導(dǎo)出前的查詢時，如果選擇時間跨度數(shù)年，查出的數(shù)據(jù)量可能達(dá)到數(shù)十萬。要將數(shù)十萬數(shù)據(jù)一次性地導(dǎo)入到一個excel文件中，這不論從運(yùn)行效率、系統(tǒng)穩(wěn)定性，還是技術(shù)可行性分析都是不可取的。最后，我們經(jīng)過與客戶的協(xié)商，一次性導(dǎo)出數(shù)據(jù)最大不超過2萬，同時提供了分頁導(dǎo)出的功能，可以讓他們選擇導(dǎo)出從第幾頁到第幾頁的數(shù)據(jù)。這樣，如果數(shù)據(jù)量大，客戶可以經(jīng)過多次將數(shù)據(jù)導(dǎo)出，數(shù)據(jù)導(dǎo)出的性能得以保證。第十八頁，共四十二頁，編輯于2023年，星期三（2）系統(tǒng)部署架構(gòu)對性能的影響也是巨大的。一個管理系統(tǒng)，是市級集中，還是省級集中，甚至全國集中，對性能的考量是不一樣的。市級集中不會過于擔(dān)心性能的問題；省級集中就必須要考量并發(fā)訪問量，是否要建立集群；全國集中就必須考量是否使用消息隊列，所有流程是否有性能瓶頸，以及采用什么技術(shù)架構(gòu)更適于并發(fā)訪問等等。第十九頁，共四十二頁，編輯于2023年，星期三4可支持性（Supportability）可支持性，就是軟件的可維護(hù)性、易變更性。在需求分析與設(shè)計階段，可支持性實(shí)際上體現(xiàn)在，我們是否能有效識別系統(tǒng)可變的需求，并能夠提供合理的方案。舉例1：

在分析和設(shè)計ERP軟件的時發(fā)現(xiàn)，應(yīng)付單需要生成憑證，隨后又發(fā)現(xiàn)應(yīng)收單、采購單、銷售發(fā)票都要生成憑證。既然這么多單據(jù)需要生成憑證，是否還有其它我們還不知道的單據(jù)也要生成憑證，是否可以有一個統(tǒng)一的接口。果不其然，核銷單、工資單、固定資產(chǎn)核定都需要生成憑證。最后我們設(shè)計成了一個統(tǒng)一的生成憑證接口。舉例2：

客戶報表在查詢SQL、過濾條件、顯示列等部分經(jīng)常變，因此設(shè)計成一套可配置的報表系統(tǒng)，大大提高了系統(tǒng)可維護(hù)性。第二十頁，共四十二頁，編輯于2023年，星期三功能需求固然重要，非功能需求同樣重要。我們在進(jìn)行非功能需求的分析時，除了制訂整體的原則以外，還要落實(shí)到各個具體的功能中，將這些功能所潛在的、特殊的非功能需求挖掘出來，提前進(jìn)行分析設(shè)計對于可行性不高的應(yīng)及時與客戶商討，才能有效地避免日后存在的這些方面的風(fēng)險。第二十一頁，共四十二頁，編輯于2023年，星期三3.3具體功能需求分析的描述方法3.3.1用例(UseCase)用例分析是一種從用戶使用角度描述需求的技術(shù)。該技術(shù)包含一定的分析視角，以及一定的呈現(xiàn)形式用例分析視角讓開發(fā)人員暫時不考慮軟件系統(tǒng)內(nèi)部的行為和結(jié)構(gòu)，而專注于清理用戶“想怎樣”去“使用”這個系統(tǒng)，以充分正確地掌握用戶需求，并最終通過“用例”來反映這些需求什么是用例？（1）用例是系統(tǒng)在響應(yīng)用戶請求時，在各種情況下的行為或功能描述（2）或是實(shí)現(xiàn)某項(xiàng)特定業(yè)務(wù)目的的所有功能第二十二頁，共四十二頁，編輯于2023年，星期三用例的呈現(xiàn)形式有“用例圖”和“用例描述”。用例圖(UseCaseDiagram)通過簡要的圖形方式反映網(wǎng)站的使用者及網(wǎng)站功能的關(guān)系；以圖形方式表示用例，有助于從較高的層次來觀察業(yè)務(wù)或域的主要功能及關(guān)系，但并不代替具體的描述文檔。用例描述(UseCaseNarrative)通過更具體的文字來說明用例的實(shí)現(xiàn)細(xì)節(jié)。用例的更全面的信息依賴于描述文檔的說明，文檔描述了每個用例的具體細(xì)節(jié)。第二十三頁，共四十二頁，編輯于2023年，星期三

3.3.2用例圖用例圖展示了一個外部用戶能夠觀察到的系統(tǒng)功能模型圖。幫助開發(fā)團(tuán)隊以一種可視化的方式、從用戶使用角度理解系統(tǒng)的功能需求。用例圖的繪制元素包括：參與者、用例、子系統(tǒng)邊框、關(guān)系1.

參與者(Actor)表示與應(yīng)用程序或系統(tǒng)進(jìn)行交互的用戶、物、組織或外部系統(tǒng)。參與者是角色，不代表特定的用戶。一個用戶可以扮演多個角色，一個參與者可以代表多個用戶。用一個小人表示。角色名稱第二十四頁，共四十二頁，編輯于2023年，星期三2.

用例(UseCase)用例就是外部可見的系統(tǒng)功能或處理過程。用橢圓表示。3.子系統(tǒng)(Subsystem)用來展示系統(tǒng)的一部分功能，這部分功能聯(lián)系緊密。用方框來描述子系統(tǒng)范圍。用例在方框以內(nèi)；參與者在方框以外下載資料子系統(tǒng)登錄搜索列表查看下載資料瀏覽者登錄瀏覽通知第二十五頁，共四十二頁，編輯于2023年，星期三4.

關(guān)系表示參與者與一個或多個用例之間的交互，或用例之間的交互。不代表數(shù)據(jù)流。用例圖中涉及的關(guān)系有：關(guān)聯(lián)、泛化、包含、擴(kuò)展。第二十六頁，共四十二頁，編輯于2023年，星期三

a.關(guān)聯(lián)(Association)關(guān)聯(lián)關(guān)系表示參與者和用例之間的通信。關(guān)聯(lián)關(guān)系用直線或箭頭表示。瀏覽通知瀏覽者啟動網(wǎng)絡(luò)打印管理員打印機(jī)查詢通知庫第二十七頁，共四十二頁，編輯于2023年，星期三【箭頭形式】：尖箭頭?！炯^指向】：指向消息接收方。如果參與者啟動了用例，箭頭指向用例；如果參與者接收了用例的指令，箭頭指向參與者。如果二者是互動的，則是直線。不同的參與者可以訪問相同的用例，一般說來它們和同一用例的交互是不一樣的如果兩種交互的目的也相同，說明他們的角色是相同的，就應(yīng)該將他們合并。第二十八頁，共四十二頁，編輯于2023年，星期三

b.泛化(Inheritance)代表一般與特殊的關(guān)系（類似于繼承）普通用戶瀏覽者登錄用戶第二十九頁，共四十二頁，編輯于2023年，星期三在用例泛化中，子用例表示父用例的特殊形式，子用例繼承了父用例的行為和屬性，也可以增加新的行為和屬性或覆蓋父用例中的行為。

父用例通常是抽象的。例：一個訂票的部分內(nèi)容，父用例是“訂票”，其兩個子用例分別是“網(wǎng)上訂票”和“電話訂票”，這兩個用例都繼承了父用例的行為，并可以添加自己的行為參與者的泛化中，子參與者繼承父參與者的所有關(guān)聯(lián)關(guān)系【箭頭指向】：指向父用例或父參與者【箭頭形式】：空心三角第三十頁，共四十二頁，編輯于2023年，星期三

c.包含(Include)一個用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行為，并把它所包含的用例行為作為自身用例的一部分，這被稱為包含關(guān)系。包含關(guān)系用來把一個較復(fù)雜用例所表示的功能分解成較小的步驟?！炯^形式】：包含關(guān)系表示為虛線箭頭加《inclusive》【箭頭方向】：箭頭從基本用例指向包含用例。

第三十一頁，共四十二頁，編輯于2023年，星期三

d.擴(kuò)展(Extend)擴(kuò)展關(guān)系是指用例功能的延伸，相當(dāng)于為基礎(chǔ)用例提供一個新的附加功能（或行為）?！炯^形式】包含關(guān)系表示為虛線箭頭加《extend》【箭頭方向】箭頭從擴(kuò)展用例指向基本用例。第三十二頁，共四十二頁，編輯于2023年，星期三擴(kuò)展關(guān)系可以有控制條件，一般情況下，基本用例的執(zhí)行不會涉及到擴(kuò)展用例，只有滿足用例的控制條件時，擴(kuò)展用例才被執(zhí)行，因此擴(kuò)展關(guān)系處理事件流的異常或者可選事件。同一個基本用例的幾個擴(kuò)展同時滿足條件時可以在一起使用?；居美恢罃U(kuò)展的任何細(xì)節(jié)，沒有擴(kuò)展用例，基本用例是完整的。第三十三頁，共四十二頁，編輯于2023年，星期三泛化、包含、擴(kuò)展的區(qū)別：比較用例之間的關(guān)系條件性：泛化中的子用例和包含中的被包含的用例會無條件發(fā)生擴(kuò)展中的延伸用例的發(fā)生是有條件的；直接性：泛化中的子用例和擴(kuò)展中的延伸用例為參與者提供直接服務(wù)包含中被包含的用例為參與者提供間接服務(wù)。包含性：泛化中的子用例及包含關(guān)系中的基礎(chǔ)用例，包含父用例及包含用例的所有內(nèi)容及其和其他用例或參與者之間的關(guān)系；對擴(kuò)展而言，延伸用例并不包含基礎(chǔ)用例的內(nèi)容，基礎(chǔ)用例也不包含延伸用例的內(nèi)容。第三十四頁，共四十二頁，編輯于2023年，星期三5、用例圖繪制步驟：⑴確定子系統(tǒng)邊界：找出系統(tǒng)外部的參與者和外部系統(tǒng)，確定系統(tǒng)的邊界和范圍。⑵分析需求：確定每一個參與者所期望的系統(tǒng)行為⑶確定用例：把這些系統(tǒng)行為命名為用例⑷分析用例關(guān)系：使用泛化、包含、擴(kuò)展等關(guān)系處理系統(tǒng)行為的公共或變更部分⑸具體化用例內(nèi)容：編制每一個用例的描述⑹繪制用例圖⑺區(qū)分基本事件流和異常情況的事件流，如有需要可以把表示異常情況的事件流作為單獨(dú)的用例來處理⑻細(xì)化用例圖，解決用例間的重復(fù)與沖突。第三十五頁，共四十二頁，編輯于2023年，星期三練習(xí)一：某餐廳為顧客提供餐食和酒水，侍應(yīng)生在顧客點(diǎn)餐后將菜單交廚房確認(rèn)和制作，顧客消費(fèi)后到收銀臺結(jié)賬。請為該餐廳的管理信息系統(tǒng)開發(fā)畫出用例圖。第三十六頁，共四十二頁，編輯于2023年，星期三用例繪制都有些什么常見問題1.不知如何入手?功能角色分析。從系統(tǒng)中包含怎樣的角色開始，逐步整理相關(guān)的功能。在這個過程中，首先，系統(tǒng)劃分幾個子系統(tǒng)幾個功能模塊。然后，為每個功能模塊繪制用例圖。2.沒有正確理解用例圖的視角。用例圖的視角是用戶從這個視角，用戶看到的系統(tǒng)是一項(xiàng)一項(xiàng)的功能，這些功能是客戶能夠理解的、具體的、對客戶存在價值的功能。舉個簡單的例子，一個員工檔案信息系統(tǒng)，以往我們總愛將用例取名為“添加員工信息”、“更新員工信息”、“刪除員工信息”，這就是典型的技術(shù)人員編寫的用例?！疤砑訂T工信息”對于用戶來講應(yīng)當(dāng)是做什么呢——填寫新員工資料；“更新員工信息”對于用戶來講又是做什么呢——更改員工資料；“刪除員工信息”又是什么呢——員工注銷。第三十七頁，共四十二頁，編輯于2023年，星期三3.圖形繪制雜亂無章。繪制用例圖要學(xué)會拆分，由粗到細(xì)地一個一個繪制。先整體的繪制，再劃分成各個模塊一個一個詳細(xì)繪制，再進(jìn)一步細(xì)化。一個系統(tǒng)，特別是一個大型系統(tǒng)，提供給用戶的功能是繁雜的。描述一個系統(tǒng)應(yīng)當(dāng)有許許多多的用例圖。如果你想將所有的功能，不管粗的細(xì)的，都試圖繪制在一個用例圖中，幾乎沒人看得懂。4.用例是一個場景。在現(xiàn)實(shí)世界中，我們常常面對的是一個個長而復(fù)雜的操作流程，但在軟件世界里，我們要將它們拆分成一個個的用例，怎樣拆分？一個用例必須有一個場景，也就是時間相近、地點(diǎn)單一的一系列操作。每個用例都有確定的場景，明確的目的和結(jié)果。舉例（見下頁）第三十八頁，共四十二頁，編輯于2023年，星期三如圖所示的用例圖，“申辯申請”就是過錯責(zé)任人填寫了一張申辯申請單，最終的結(jié)果是將申辯申請單提交給考核管理員；“申辯受理”就是考核管理員接收了過錯責(zé)任人的申辯申請單并予以受理，當(dāng)然另一個結(jié)果是對其不予受理，該申請單被退回給過錯責(zé)任人。第三十九頁，共四十二頁，編輯于2023年，星期三3.3.3用例描述(UseCaseNarrati