1、實驗二書面表達能力訓練一、實驗目的1. 了解UML中的事物、關系和圖。2了解需求分析的目的：給客戶帶來價值。3. 訓練書面表達能力。二、實驗內容(一) 繪圖基本練習，繪制 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é)點(Node)的繪制方法。P46-3.3.1 (7)節(jié)點Note(二) 書面表達能力訓練請根據(jù)以下“需求分析中的麻煩事？ ”的十三回答，總結以下內容：1. 需求分析有哪些麻煩事？2. 針對這些麻煩事的簡單解決方法？3. 你從這些回答中學習到哪些非需求分析方面的內容？“需求分析中的麻煩事？ ”的十三回答回答一1. 溝通問題2反復更改3.尋找潛在問題回答二1調研時人員配合不積極，實際系統(tǒng)與期望有差別2需求不確定，經(jīng)常需要改動3對需要開發(fā)的系統(tǒng)流程不是很了解，需求分析時不能抓住重點回答三1. 需求變化的

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

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

5、的擴展需要或者和客戶交待清楚。 5熟練運用多種建模方式。比如我調研的時候經(jīng)常是當場制作uml圖的。如果沒有一定得建模功底，很難當場用uml圖來引導客戶和自己的需求分析思路。6最后說一個抽象點的問題。那就是00思想。我們知道UML指引的需求分析也是面向對象的，即面向對象分析方法。在與客戶溝通 過程中，為了更好的展開面向對象分析方法，除了分析人員要有很好的 00思想之外，還要指引客戶走向面向對象的思維。這樣很有利于你和客戶達成共識，促成和諧、深度探討、共同理解的調研環(huán)境。回答五1需求很空洞，很籠統(tǒng)。經(jīng)常是領導說：我要上某某系統(tǒng)，或者我要一個某某功能。他 說不出上這個系統(tǒng)要達到的具體目標，也說不出具

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

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

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

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

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

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

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

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

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

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

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

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

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

20、case realization即可。也可以將use-case realization類型的按鈕添加到工具欄上面，在本實驗中選用第一種做法。貼圖：令 白松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中打開左側樹形瀏覽器的Comp onent View f Ma in節(jié)點，雙擊Mai n打開對應視圖。然后單擊 Toolbox工具欄上的組件按鈕，并在Main視圖編輯區(qū)單擊，即可創(chuàng)建一個組件。組件的默認名稱為 NewComponent，同理可以直接修改組件名或者打開屬性對話框來 設置更多屬性。貼圖：電

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é)點（Node）的繪制方法。P

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