信息系統(tǒng)分析與設(shè)計(jì)

1、實(shí)驗(yàn)二書面表達(dá)能力訓(xùn)練一、實(shí)驗(yàn)?zāi)康?. 了解UML中的事物、關(guān)系和圖。2了解需求分析的目的：給客戶帶來價值。3. 訓(xùn)練書面表達(dá)能力。二、實(shí)驗(yàn)內(nèi)容(一) 繪圖基本練習(xí)，繪制 UML中的事物1. 掌握繪制類(class)的繪制方法。P42-3.3.1 (1 )類class2. 掌握接口( In terface)的繪制方法。P43-3.3.1 (2)接口 In terface3. 掌握用例(Use Case)的繪制方法。 P44-3.3.1 (3)用例 Use case4. 掌握協(xié)作(Collaboration )的繪制方法。 P45-3.3.1 (4)協(xié)作 Collaboration5. 掌握組件

2、(Component)的繪制方法。 P45-3.3.1 (6)組件 Component6. 掌握節(jié)點(diǎn)(Node)的繪制方法。P46-3.3.1 (7)節(jié)點(diǎn)Note(二) 書面表達(dá)能力訓(xùn)練請根據(jù)以下“需求分析中的麻煩事？ ”的十三回答，總結(jié)以下內(nèi)容：1. 需求分析有哪些麻煩事？2. 針對這些麻煩事的簡單解決方法？3. 你從這些回答中學(xué)習(xí)到哪些非需求分析方面的內(nèi)容？“需求分析中的麻煩事？ ”的十三回答回答一1. 溝通問題2反復(fù)更改3.尋找潛在問題回答二1調(diào)研時人員配合不積極，實(shí)際系統(tǒng)與期望有差別2需求不確定，經(jīng)常需要改動3對需要開發(fā)的系統(tǒng)流程不是很了解，需求分析時不能抓住重點(diǎn)回答三1. 需求變化的

3、太快。這說明客戶的想法不斷在進(jìn)化，這是好事，早變不如遲變！ 不過客戶經(jīng)常推翻自己想法的話，這就需要我們好好引導(dǎo)了。2. 相關(guān)人員討論不到重點(diǎn)。越是基層員工，越容易糾纏細(xì)節(jié)而忘記根本。需要選擇有價值的員工以及這些基層員工的領(lǐng) 導(dǎo)，問他們的根本想法。3. 各個人的意見總是不統(tǒng)一。一些解決方案：找出意見不同者的共同利益，“設(shè)計(jì)”出各方都滿意的需求。以及讓意見不同者的領(lǐng)導(dǎo)來發(fā)揮主導(dǎo)作用。不過以上問題的根本原因就是客戶對需求的認(rèn)識還不夠深，解決問題的根本辦法就是項(xiàng)目組提升需求分析的能力，給客戶提出有價值的需求方案并得到客戶的認(rèn)可?；卮鹚?1行業(yè)知識的把握和學(xué)習(xí)。如果是老行業(yè)，需要經(jīng)?？偨Y(jié)提煉。如果面對新

4、行業(yè)，要具有快速學(xué)習(xí)接受新行業(yè)的經(jīng) 驗(yàn)和能力。2對訪問客戶的定位?？蛻粲泻芏喾N，有的是領(lǐng)導(dǎo)級別的， 有的是具體做事的， 有的是行業(yè)專家等等。我們經(jīng) 常沒有權(quán)利選擇自己想要訪問客戶，所以面對你一無所知的客戶， 要先直接或者間接問一些跟客戶相關(guān)的信息，然后給你面對的客戶一個準(zhǔn)確的定位。面對不同類型的客戶， 有不同的調(diào)研重點(diǎn)和調(diào)研方向。3挖掘潛在和本質(zhì)的需求。這個難免與第一點(diǎn)有關(guān)系一一與需求人員對業(yè)務(wù)知識的掌握程度有關(guān)。不過除此之外， 也有需求人員的分析經(jīng)驗(yàn)有關(guān)。這里的經(jīng)驗(yàn)特指那些不與具體業(yè)務(wù)知識相關(guān)的經(jīng)驗(yàn)。比如當(dāng)你聽到兩個有關(guān)聯(lián)的對象時，一定要搞清楚他們的00關(guān)系和數(shù)量關(guān)系。4把握常變需求，做相應(yīng)

5、的擴(kuò)展需要或者和客戶交待清楚。 5熟練運(yùn)用多種建模方式。比如我調(diào)研的時候經(jīng)常是當(dāng)場制作uml圖的。如果沒有一定得建模功底，很難當(dāng)場用uml圖來引導(dǎo)客戶和自己的需求分析思路。6最后說一個抽象點(diǎn)的問題。那就是00思想。我們知道UML指引的需求分析也是面向?qū)ο蟮?，即面向?qū)ο蠓治龇椒āＴ谂c客戶溝通 過程中，為了更好的展開面向?qū)ο蠓治龇椒?，除了分析人員要有很好的 00思想之外，還要指引客戶走向面向?qū)ο蟮乃季S。這樣很有利于你和客戶達(dá)成共識，促成和諧、深度探討、共同理解的調(diào)研環(huán)境?；卮鹞?需求很空洞，很籠統(tǒng)。經(jīng)常是領(lǐng)導(dǎo)說：我要上某某系統(tǒng)，或者我要一個某某功能。他 說不出上這個系統(tǒng)要達(dá)到的具體目標(biāo)，也說不出具

6、體需要什么功能，涉及哪些使用部門等。 通常這個時侯領(lǐng)導(dǎo)的手下們也并不清楚領(lǐng)導(dǎo)的想法。當(dāng)我們按照自己的思路和想象分析完 后，把想到的東西羅列給領(lǐng)導(dǎo)看，他只會說，這些功能全部都要，所有方面都要涉及等。而 這樣的結(jié)果是系統(tǒng)很復(fù)雜，但可能很多流程和實(shí)際并不相符，還有很多功能永遠(yuǎn)都不會使用到。2需求提出者并沒有想清楚，所以提出的需求經(jīng)常變化。有時自己提出的要求過一段被 自已否定，甚至不承認(rèn)是自已提出的，然后又提出一個不同的要求，反反復(fù)復(fù)。3提出需求的人沒有多少耐心，軟件設(shè)計(jì)者對需求者的業(yè)務(wù)流程并不熟悉，所以在理解 需求時會有偏差，但提出需求的人不愿花時間做深入的交流，只是把自已的想法點(diǎn)到為止。4很少會有

7、這樣一個人，他懂得所有部門所有崗位的需求，能站在一個更高的層次，以 放眼全局的眼光來描述需求。作為需求分析人員， 通常面對的是零散的、只考慮自已部門方便的、不全面的需求，在不熟悉業(yè)務(wù)流程的情況下，想整理清楚幾乎象登天。5提出需求的人沒有前詹性，只考慮眼前，做出來的系統(tǒng)用不了多久又要更改回答六1、找不到真正的干系人尤其是業(yè)務(wù)提出者， 系統(tǒng)決策者等上層用戶。 與此類用戶無法有效溝通，不能明白領(lǐng)導(dǎo)的真實(shí)意圖，潛在需求，只是圍繞在中間和下面人員，糾纏于業(yè)務(wù)細(xì)節(jié)，很容易走偏，帶來 反復(fù)、拖期。2、太想把需求一次性搞完。例如在2個周內(nèi) 或者 在*時間內(nèi)，按照瀑布流程或里程碑要求，完成該項(xiàng)目的需求分析工作，

8、公司流程這樣規(guī)定的，公司領(lǐng)導(dǎo)很多也是這樣要求的，都想來個“一次搞完萬事大吉”做完需求就可以指導(dǎo)項(xiàng)目后面各個階段的運(yùn)行了，豈不知需求的獲取 和 客戶的交流，是貫穿項(xiàng)目始終的， 項(xiàng)目組和客戶對需求，尤其是潛在需求的認(rèn)識、達(dá)成共識，是需要一個 循序漸進(jìn)的過程的。3、我們不是業(yè)務(wù)專家?，F(xiàn)在的軟件項(xiàng)目，很多都是針對某個行業(yè)做深度開發(fā)的或者 在已有的多個系統(tǒng)基礎(chǔ)上做集成，然后再開發(fā)新應(yīng)用的。這種情況下，對該行業(yè)的知識、背景、趨勢、專業(yè)等不到一 定程度的了解，很難與用戶有效的溝通起來，僅僅是用戶講你來記的聽課方式，用戶也不會有很多交流興趣的。至少我們自己像個專家或者帶個類似角色的人充當(dāng)專家或者先找行業(yè)專家做

9、好課前輔導(dǎo)。以上僅僅是對工程類項(xiàng)目需求分析遇到的問題。做產(chǎn)品開發(fā)，涉及的內(nèi)容可能會更多?；卮鹌?、需求分析需要針對重點(diǎn)，找到最終用戶；但是現(xiàn)實(shí)卻是參與者都在發(fā)言，不知道該聽誰 的，不該聽誰的，并且可能沒有一個真正用戶。2、由于參與者多，導(dǎo)致的需求變更問題，反復(fù)存在。3、需求文案、文檔等說明不能完全滲透至開發(fā)或者最終用戶，導(dǎo)致開發(fā)結(jié)果令用戶不滿， 耽誤時間，浪費(fèi)成本。應(yīng)對建議：分析各種用戶的關(guān)系、各自的利益關(guān)注點(diǎn)等，能幫助我們識別出真正的需求，解決各種用戶之間的利益矛盾點(diǎn)。深入理解客戶的業(yè)務(wù)，站在比客戶更高的高度，這樣才能做到“給客戶帶來價值”。要做到以上的要求，難度是超高的，希望本課程能給大家

10、帶來幫助！回答八1、客戶和用戶不重視需求分析，在進(jìn)行需求調(diào)研時，不能積極配合，往往是有各種事情， 打斷調(diào)研工作。有時客戶（信息中心的人）重視了，但用戶不重視。當(dāng)然，也有自身原因， 由于對用戶業(yè)務(wù)不夠了解，常常造成雙方溝通存在偏差，影響效率，又因項(xiàng)目進(jìn)度等要求， 造成需求分析工作草草結(jié)束。2、用戶不能準(zhǔn)確表達(dá)其需求，計(jì)算機(jī)技術(shù)人員理解的和用戶說的不一致。3、業(yè)務(wù)較復(fù)雜時，需要對業(yè)務(wù)進(jìn)行優(yōu)化，但用戶常有抵觸。而按現(xiàn)有業(yè)務(wù)做的軟件，常常感覺并不能帶來多少便利。 如果僅僅是簡單將現(xiàn)有業(yè)務(wù)從手工變?yōu)樾畔⒒?，一般并不能帶來多大的生產(chǎn)力提升，需要我們在需求分析的時候能吃透業(yè)務(wù)，提出更好的、更有價值的需求解決

11、方案?；卮鹁?我遇到的情況是已經(jīng)有產(chǎn)品了，新的項(xiàng)目多半是在既有產(chǎn)品之上開發(fā)1如何減少需求對既有設(shè)計(jì)的影響？有時客戶很強(qiáng)勢，提出一些對既有產(chǎn)品結(jié)構(gòu)有很大影響但有不得不答應(yīng)的要求。2界面需求不好明確，經(jīng)常是后期作出來了，客戶看到了讓改。功能需求還有具體化的可能， 那純界面的需求如何設(shè)計(jì)？3市場部提出的功能需求文檔不明確，往往都是一句話?；卮鹗乙瞾碚f說 最近遇到的情況。1, 甲方需求接口人，為假設(shè)甲方知道某些領(lǐng)域術(shù)語或者知識。2, 甲方在1中基于假設(shè)的條件下，會一股腦兒的把他知道的告訴你。3，甲方需求接口人告訴你的時候，你不可能快速理解。并且他也可能并不知道你不理解。應(yīng)對建議：1, 不打斷甲方需求

12、接口人，讓他總體上概述一下。2, 根據(jù)總體概述用 UC圖 描述粗粒度的系統(tǒng)概貌， 不明白立馬問甲方。 一定要再總體上用 UC描述出系統(tǒng)的功能點(diǎn)。3, 根據(jù)某個UC圖里面的功能點(diǎn)，再細(xì)分，可以用靜態(tài)或者動態(tài)方法細(xì)分。在分析的時候要一定有一張領(lǐng)域知識的術(shù)語表，不懂地方隨時溝通并記錄， 在開始的時候先讓甲方總體介紹。然后自己用UC畫出輪廓，然后細(xì)分，千萬別讓客戶一股腦的沒邏輯或邏輯很少的把業(yè)務(wù)知 識倒給你?；卮鹗?、客戶對業(yè)務(wù)認(rèn)知度不夠，無決策權(quán)，反復(fù)確認(rèn)需求過程時導(dǎo)致客戶不滿。2、客戶對分析需求時提出的技術(shù)性難題置之不理，認(rèn)為這不是作為甲方的自己應(yīng)該關(guān)心的 問題。3、項(xiàng)目經(jīng)理盲目的遵從客戶要求，

13、導(dǎo)致項(xiàng)目組開發(fā)進(jìn)度一再修改，拖延到最后無法交差?；卮鹗隽藥啄觊_發(fā)，現(xiàn)在才轉(zhuǎn)做軟件設(shè)計(jì)， 其實(shí)說是軟件設(shè)計(jì)但是我覺得我最需要做的就是需求 分析。目前我工作的城市對需求分析不是很重視，大部分軟件公司都是接到項(xiàng)目就開始著手開發(fā)了，即使有需求分析環(huán)節(jié)也是要求一兩天就出來結(jié)果。而且，很多需求都是由客戶部的人轉(zhuǎn)述給我們，我們沒有機(jī)會真正接觸到客戶甚至用戶。我感覺需求分析最麻煩的事情是：1、項(xiàng)目負(fù)責(zé)人不重視需求分析的重要性，長期以來的軟件開發(fā)習(xí)慣讓大家更重視開發(fā)。2、需求分析人員接觸不到真正的用戶，大部分需求分析人員最多只能接觸到客戶，由客戶來說明需要實(shí)現(xiàn)什么業(yè)務(wù)。 但是客戶描述的角度是以他自身出發(fā)，不

14、能真正地反應(yīng)用戶的需求。3、客戶至上的心理枷鎖會讓需求人員在分析的時候過多地在意客戶提出來的具體細(xì)節(jié)，而忽視了軟件的真正需求和目標(biāo)，會陷入細(xì)節(jié)的糾結(jié)中無法自拔。4、客戶需求變更頻繁，其實(shí)潛在的問題應(yīng)該是需求分析人員沒有認(rèn)識到我們設(shè)計(jì)軟件到底 需要解決什么問題。根本原因就是需求分析人員的業(yè)務(wù)認(rèn)知程度一直低于客戶對業(yè)務(wù)的認(rèn)知 程度，無法理解客戶的真正需求。5、需求分析人員對業(yè)務(wù)的不熟悉，容易造成客戶怎么提就怎么設(shè)計(jì)，思維被固化。6、需求分析的范圍界定不清楚，經(jīng)常在分析過程中為了某一功能而增加另一功能，造成范圍越擴(kuò)越大，到最后無法繼續(xù)進(jìn)行。7、需求分析人員也很想了解業(yè)務(wù)，但是不知道如何下手了解。 這

15、些是我做需求分析的一些困惑吧，希望在不久的一天自己能夠想明白，不再困惑。回答十三簡單說說我對需求分析和軟件設(shè)計(jì)的感受：需求分析：易學(xué)難精，不懂軟件設(shè)計(jì)不會寫代碼的話，也可以做好需求分析工作，但很難達(dá)到更高的境界，我見到的需求分析很牛的人，他們同時也是（或者是曾經(jīng)是）程序的設(shè)計(jì)高手或者是骨灰級的程序員。軟件設(shè)計(jì)：難學(xué)難精，優(yōu)秀的軟件設(shè)計(jì)師必須具備分析需求的能力，很多設(shè)計(jì)的問題其實(shí)是與需求分析密不可分的。三、實(shí)驗(yàn)要求1 繪圖題：請用文字簡單說明繪制過程，如需貼圖請將繪制圖片請黏貼到相應(yīng)的位置。2文字題：請用最簡潔明了的方式表達(dá)可以是文字、表格或圖混合的方式。3. 實(shí)驗(yàn)二提交時間：3月23日。四、實(shí)

16、驗(yàn)報告1.實(shí)驗(yàn)報告內(nèi)容（一）繪圖基本練習(xí)，繪制UML中的事物1.掌握繪制類（class）的繪制方法。P42-3.3.1 （1 ）類class過程描述：在Rose中打開左側(cè)樹形瀏覽器的 Logical View 宀Mai n節(jié)點(diǎn)，雙擊 Ma in打開對應(yīng)視 圖。然后單擊 Toolbox工具欄上的類按鈕，并在Main視圖編輯區(qū)單擊，即可創(chuàng)建一個類。NewClass表示默認(rèn)創(chuàng)建的類名，單擊選中后再單擊NewClass字符串可以修改類名。雙擊類圖或者右鍵單擊類圖，在彈出菜單中選擇Open Specification命令，系統(tǒng)會彈出類圖屬性設(shè)置對話框，可以對類進(jìn)行進(jìn)一步設(shè)置。貼圖：好 Ratidnal

17、Rose - jritriedl* - pCleis Diagram:View /産 百 Edit Viwr Fchtat Ekows總 Report Queiy dc：e Add-Ins Window* Help匚刁bl盂筆氏忌睢二JI同PS冏間冃阪4 孤G女|IT-Cl r：4 Cut Tit*Q /I 宙CJggJ'ef） ciusir，一 /2. 掌握接口（ In terface）的繪制方法。 P43-3.3.1 （2）接口 In terface過程描述：在Rose中打開左側(cè)樹形瀏覽器的Logical View 宀Mai n節(jié)點(diǎn)，雙擊 Ma in打開對應(yīng)視圖。然后單擊 Tool

18、box工具欄上的接口按鈕，并在Main視圖編輯區(qū)單擊，即可創(chuàng)建一個接口。New In terface表示默認(rèn)接口的名稱，選中后再單擊Newl nterface字符串可以修改接口名稱。右鍵單擊接口并在彈出菜單中選擇Options t stereotype Display命令，可以看到接口的四種顯示方式，分別是None、Label、Decoration和Icon （Icon為默認(rèn)的顯示方式）。貼圖:用例 Use case3.掌握用例(Use Case)的繪制方法。P44-3.3.1 (3) 過程描述：在Rose中打開左側(cè)樹形瀏覽器的User Case View 宀視圖。然后單擊 Toolbox工具

19、欄上的用例按鈕，并在MainMain節(jié)點(diǎn)，雙擊 Main打開對應(yīng) 視圖編輯區(qū)單擊，即可創(chuàng)建一個NewUseCase 修改Open Specification命令，在彈出的屬性設(shè)置用例。NewUseCase表示默認(rèn)接口的名稱，用戶可以選中用例再單擊文字 名稱，也可以右鍵單擊圖標(biāo)在彈出菜單中選擇 對話框中進(jìn)行設(shè)置。貼圖：4. 掌握協(xié)作(Collaboration )的繪制方法。P45-3.3.1 (4)協(xié)作 Collaboration過程描述：在Rose中并沒有直接提供繪制協(xié)作的方法。用戶可以首先繪制一個用例，打開屬性設(shè)置對話框，然后在其屬性設(shè)置對話框中的Stereotype下拉框中選擇 use-

20、case realization即可。也可以將use-case realization類型的按鈕添加到工具欄上面，在本實(shí)驗(yàn)中選用第一種做法。貼圖：令 白松I- U疋匚MF DiBgriini: Uie 色訥* 丿 KAair<| 箕y. File- Edit Wew Fd-nnst Qfdwke ReficrtTook Add-Ins LWrtdcw Help_ r X宅殆凈畔口 K H； ®* c暫（latabLiJJE ijllse C«t 鬥沖d!IbLDL1 7. . dl di*.;El a« a cs k1： i am糸rFs底 lla*L Vi

21、 #*禮/1* 廠氣Mr CeJiabMr' -耳 *1 T T1 砸/Ht DI JtsLi.'. &E 2. FL|BiA£aAlLlAl辿5. 掌握組件(Component)的繪制方法。 P45-3.3.1 (6)組件 Component過程描述：在Rose中打開左側(cè)樹形瀏覽器的Comp onent View f Ma in節(jié)點(diǎn)，雙擊Mai n打開對應(yīng)視圖。然后單擊 Toolbox工具欄上的組件按鈕，并在Main視圖編輯區(qū)單擊，即可創(chuàng)建一個組件。組件的默認(rèn)名稱為 NewComponent，同理可以直接修改組件名或者打開屬性對話框來 設(shè)置更多屬性。貼圖：電

22、t RdTiDH jil- turtitled) - CORlp&rigirt jUrarnrlLEiiinparN&fTtrMdiflj買kl Hie Edit 訥 cv Farm nt iBrcmsE Rqpcrt Quefy Task Add-Ins kWindow Help-呂 XH V Ri F S罟口曲苗也國世ESQ泛&幻B / 亡 C ffl二I|_|前* 杠業(yè)也 莊 iJllM C«t 巧 圧 OOil-口匚Mb虹:U邛4F . ''La(/Ifrui H.«L; pi h：讓 FL6掌握節(jié)點(diǎn)（Node）的繪制方法。P

23、46-3.3.1 （7）節(jié)點(diǎn)Note過程描述:在Rose中雙擊Deployment View 打開對應(yīng)視圖。然后單擊Toolbox工具欄上的處理器按鈕或者設(shè)備按鈕，并在右側(cè)視圖編輯區(qū)單擊，即可創(chuàng)建一個節(jié)點(diǎn)。處理器默認(rèn)名稱為 NewProcessor，設(shè)備默認(rèn)名稱為 NewDevice 。貼圖:（二）（三）書面表達(dá)能力訓(xùn)練1 需求分析有哪些麻煩事？2.3針對這些麻煩事的簡單解決方法？4. 你從這些回答中學(xué)習(xí)到哪些非需求分析方面的內(nèi)容？你的總結(jié)描述：1 需求分析有哪些麻煩事？答：簡而言之需求分析中的麻煩之處分為三部分：重視度低、溝通問題和頻繁改動。首先， 存在一部分的客戶與從業(yè)人員對需求分析并不重視。對于客戶而言，這樣的不重視很可能演變?yōu)閷τ谛枨竺枋龅目斩矗豪缰皇呛唵蔚卣f要有什么系統(tǒng)或功能，卻不進(jìn)行具體的詳細(xì)敘述與表達(dá)，甚至不能積極配合； 對于少部分從業(yè)尤其是項(xiàng)目負(fù)責(zé)人來說，對需求分析的不重視也會致使直接開始軟件的開發(fā)過程，從而引發(fā)后續(xù)的問題。其次，客戶與開發(fā)者之間、甚至開發(fā)者內(nèi)部存在的溝通問題，也一直在各個方面對需求設(shè)計(jì)產(chǎn)生負(fù)面的影響。譬如“客戶想法至上”、“各個人意見總是不統(tǒng)一”、“開發(fā)者想法與客戶要求不同”等等都是這一方面的常見問題，欠于溝通與理解錯誤往往導(dǎo)致設(shè)計(jì)到后期再重新推倒重來。最后，客戶方對要求頻繁反復(fù)的改動更是深深困擾著從業(yè)者們。客戶的需求