在我們進(jìn)行一系列需求調(diào)研工作的同時(shí)，我們的需求分析工作也開始啟動(dòng)了。需求調(diào)研與需求分析工作應(yīng)當(dāng)是相輔相伴共同進(jìn)行的。每次參加完需求調(diào)研回到公司，我們就應(yīng)當(dāng)對(duì)需求調(diào)研的成果進(jìn)行一次需求分析。當(dāng)下一次開始進(jìn)行需求調(diào)研時(shí)，我們應(yīng)當(dāng)首先將上次需求分析的結(jié)果與客戶進(jìn)行確認(rèn)，同時(shí)對(duì)需求分析中提出的疑問交給客戶予以解答。這就是一個(gè)需求捕獲->需求整理->需求驗(yàn)證->再需求捕獲的過程。

但是，當(dāng)我們經(jīng)過一番忙碌，將需求中的第一手資料從調(diào)研現(xiàn)場捕獲回來以后，我們應(yīng)當(dāng)怎樣進(jìn)行分析呢？不少團(tuán)隊(duì)對(duì)此都比較迷茫，沒有一個(gè)統(tǒng)一和有效的方法，往往采用想到哪里做到哪里的方式。一些問題想到了就做了，沒有想到則忽略掉了。實(shí)際上，需求分析不應(yīng)當(dāng)是太公釣魚，而應(yīng)當(dāng)是拉網(wǎng)排查。任何一個(gè)疏忽都可能對(duì)項(xiàng)目研發(fā)帶來風(fēng)險(xiǎn)。因此，我們應(yīng)當(dāng)采用一套成熟而完整的分析方法，穩(wěn)步而有序地完成這部分工作。不同類型的軟件項(xiàng)目其分析方法可能存在差異，但一般來說，信息化管理類軟件項(xiàng)目通常從這幾個(gè)方面著手分析：功能角色分析、業(yè)務(wù)流程分析與業(yè)務(wù)領(lǐng)域分析。

需求分析不是一項(xiàng)一蹴而就就可以完成的工作，它需要一個(gè)長期的過程，而這個(gè)過程是一個(gè)由粗到細(xì)的過程，它體現(xiàn)了人類認(rèn)識(shí)事物的客觀規(guī)律。在需求分析的初期，我們對(duì)需求的認(rèn)識(shí)往往是整體的、宏觀的，隨著分析工作的逐漸深入，一步步細(xì)化。按照這個(gè)思路，我們對(duì)需求的分析，首先應(yīng)當(dāng)從功能角色分析開始。所謂功能角色分析，就是從一個(gè)外部用戶的視角分析整個(gè)軟件系統(tǒng)能夠提供的功能，以及這些功能到底是提供給哪些角色使用。

對(duì)一個(gè)系統(tǒng)進(jìn)行功能和角色方面的梳理和分析，可以采用的比較主流的方法之一就是繪制用例圖。用例圖是UML的4+1視圖中的一種，準(zhǔn)確地說就是那個(gè)“+1”。用例圖是貫穿整個(gè)面向?qū)ο蠓治?設(shè)計(jì)（OOA/D）的核心視圖，它描述的是系統(tǒng)到底為用戶提供了哪些功能，以及到底是哪些用戶在使用這些功能，是溝通用戶與技術(shù)人員的橋梁。運(yùn)用用例視圖對(duì)業(yè)務(wù)需求進(jìn)行分析、抽象、整理、提煉，進(jìn)而形成抽象模型的過程稱之為用例建模，而這個(gè)模型就是用例模型。

一般地，在一個(gè)用例圖中通常有三種元素：參與者（Actor）、用例（Use Case）與系統(tǒng)邊界（Boundary）。用例描述的是系統(tǒng)為用戶提供的功能，也就是系統(tǒng)能為用戶做什么，通常被繪制成一個(gè)橢圓；參與者，我認(rèn)為稱為角色更加合適，也就是系統(tǒng)為哪些類型的用戶提供服務(wù)，他們都各自承擔(dān)哪些不同的職責(zé)，通常被繪制成一個(gè)小人兒；最后是系統(tǒng)邊界，也就是系統(tǒng)是對(duì)現(xiàn)實(shí)世界哪個(gè)范圍的內(nèi)容進(jìn)行的模擬，它涉及到軟件設(shè)計(jì)的工作范圍與工作量，通常被繪制成一個(gè)方框。但是，通常情況下系統(tǒng)邊界只是一個(gè)概念而不用真正繪制出來，因?yàn)楸焕L制成用例的必然是系統(tǒng)內(nèi)部的功能，被繪制成參與者的必然是系統(tǒng)外部事物。從這個(gè)意義上講，用例圖中的參與者不僅包括人，還包括那些外部系統(tǒng)和自動(dòng)觸發(fā)器。根據(jù)這樣一個(gè)思路，我以往常常將外部系統(tǒng)和自動(dòng)觸發(fā)器繪制成一個(gè)小人，這常常令客戶感到困惑。隨后我改變了思路，將外部系統(tǒng)和自動(dòng)觸發(fā)器繪制成另一種表達(dá)形式——類元符號(hào)表示法，并在構(gòu)造型上標(biāo)注為Actor。



上圖是一個(gè)考核系統(tǒng)中一個(gè)子模塊的用例圖。圖中的用例就是這個(gè)系統(tǒng)提供給用戶的各項(xiàng)功能。注意，這里僅僅是在羅列功能而不表示它們之間諸如流程調(diào)用等相互關(guān)系，這是一些初學(xué)者常常犯的毛病。參與者與用例通過實(shí)線關(guān)聯(lián)起來，代表的是一種使用關(guān)系。箭頭代表的是一種導(dǎo)航，即動(dòng)作施與的方向。在這個(gè)用例圖中，普通用戶執(zhí)行查詢操作，查詢系統(tǒng)提供的“預(yù)警監(jiān)控單項(xiàng)查詢”、“預(yù)警監(jiān)控匯總查詢”等查詢報(bào)表；每日自動(dòng)觸發(fā)器觸發(fā)自動(dòng)考核功能，自動(dòng)考核功能從“稅收征管系統(tǒng)”這樣一個(gè)外部系統(tǒng)中采集數(shù)據(jù)。

圖中考核管理員和執(zhí)法人員代表的是兩個(gè)完全不同的角色，但他們?cè)谶@個(gè)圖中體現(xiàn)的是一些共有的特性，即對(duì)這堆報(bào)表的查詢，因此被繪制成繼承自普通用戶。繼承是參與者間唯一的關(guān)系，代表繼承者擁有被繼承者所有的功能與權(quán)限。除了參與者以外，用例與用例直接也存在著一些類型的關(guān)系，這我們?cè)诤竺嬖敿?xì)講述。

在繪制用例圖時(shí)一個(gè)值得思考的細(xì)節(jié)是，用例是怎樣通過分析獲得的。這個(gè)問題，在一些客戶對(duì)信息化管理比較有經(jīng)驗(yàn)的項(xiàng)目中不存在問題，因?yàn)樵诳蛻籼峁┙o我們的需求文檔中就清晰地劃分出了一項(xiàng)一項(xiàng)的功能。這些功能可能會(huì)在日后的需求分析工作中有所調(diào)整，但它從整體上形成了一個(gè)雛形，成為我們進(jìn)行用例分析進(jìn)而形成用例的依據(jù)。

但當(dāng)我們面對(duì)的是一些對(duì)信息化管理沒有經(jīng)驗(yàn)的客戶，情況就有些不妙了。在這種情況下，通常客戶只能給我們一些管理目標(biāo)、基本想法，其它的調(diào)研工作就需要我們自己去做了。這時(shí)，我給大家的建議是，首先從組織機(jī)構(gòu)上劃分清楚系統(tǒng)涉及哪些部門、哪些科室，然后在這個(gè)基礎(chǔ)上劃分出來這些部門這各個(gè)科室的人員都扮演哪些不同職能的角色，以及完成哪些業(yè)務(wù)操作。系統(tǒng)中的一個(gè)功能，在一般情況下是組織機(jī)構(gòu)中某個(gè)（或多個(gè)）角色，為該機(jī)構(gòu)某項(xiàng)業(yè)務(wù)流程完成的某個(gè)操作，并且這個(gè)操作應(yīng)當(dāng)有某個(gè)確定的結(jié)果（即產(chǎn)出物）。而這個(gè)功能就是我們需要提取出來的用例。雖然功能角色分析在整個(gè)需求分析過程中可能會(huì)隨著認(rèn)識(shí)的深入而不斷調(diào)整，但分析過程大體是這樣進(jìn)行的。

有人說，我們繪制的用例圖拿給客戶看不懂。這樣一個(gè)清晰明了的用例圖，輔之以我們對(duì)圖形的描述，客戶怎么會(huì)看不懂呢？關(guān)鍵問題在于，我們沒有將用例圖的精髓弄明白，再加上出現(xiàn)一些常見問題，使得用例圖畫得不倫不類，客戶當(dāng)然就看不明白了。現(xiàn)在我們看看用例繪制都有些什么常見問題。

1. 沒有正確理解用例圖的視角。前面我反復(fù)強(qiáng)調(diào)了，用例圖的視角是用戶，也就是說，站在用戶的角度來觀察的我們需要設(shè)計(jì)的系統(tǒng)。從這個(gè)視角，用戶看到的系統(tǒng)是什么呢？當(dāng)然是一項(xiàng)一項(xiàng)的功能，這些功能是客戶能夠理解的、具體的、對(duì)客戶存在價(jià)值的功能。從這個(gè)意義上說，那些技術(shù)性的功能不應(yīng)當(dāng)出現(xiàn)在這里，或者應(yīng)當(dāng)描述為用戶可以理解的文字，比如“自動(dòng)考核”。而那些應(yīng)當(dāng)繪制的用例，在取名時(shí)也應(yīng)當(dāng)站在用戶角度去取名。舉個(gè)簡單的例子，一個(gè)員工檔案信息系統(tǒng)，以往我們總愛將用例取名為“添加員工信息”、“更新員工信息”、“刪除員工信息”，這就是典型的技術(shù)人員編寫的用例。“添加員工信息”對(duì)于用戶來講應(yīng)當(dāng)是做什么呢——填寫新員工資料；“更新員工信息”對(duì)于用戶來講又是做什么呢——更改員工資料；“刪除員工信息”又是什么呢——員工注銷。不論是“填寫新員工資料”、“更改員工資料”，還是“員工注銷”，對(duì)于客戶都是日常工作中需要完成的操作，將用例命名為這些名字必然為用戶所理解。同時(shí)，每一個(gè)用例對(duì)于用戶來說應(yīng)當(dāng)是有價(jià)值的，也就是說，用戶使用這個(gè)功能是要完成一項(xiàng)操作，或獲得什么信息。比如上圖的“自動(dòng)考核”會(huì)產(chǎn)生一批考核結(jié)果，執(zhí)行“預(yù)警監(jiān)控單項(xiàng)查詢”可以獲得預(yù)警監(jiān)控結(jié)果數(shù)據(jù)。

2. 圖形繪制雜亂無章。一個(gè)系統(tǒng)，特別是一個(gè)大型系統(tǒng)，提供給用戶的功能是繁雜的。如果你想將所有的功能，不管粗的細(xì)的，都試圖繪制在一個(gè)用例圖中，幾乎沒人看得懂。我們之所以將分析設(shè)計(jì)圖形化，是因?yàn)閳D形能給人形象立體的感官，使人立即就明白了其中的意思，但前提是，這個(gè)圖形是主題清晰的、形象生動(dòng)的。因此，我們繪制用例圖要學(xué)會(huì)拆分，由粗到細(xì)地一個(gè)一個(gè)繪制。先整體的繪制，再劃分成各個(gè)模塊一個(gè)一個(gè)詳細(xì)繪制，再進(jìn)一步細(xì)化。所以，描述一個(gè)系統(tǒng)應(yīng)當(dāng)有許許多多的用例圖。

3. 用例是一個(gè)場景。在現(xiàn)實(shí)世界中，我們常常面對(duì)的是一個(gè)個(gè)長而復(fù)雜的操作流程，但在軟件世界里，我們要將它們拆分成一個(gè)個(gè)的用例，怎樣拆分？一個(gè)用例必須有一個(gè)場景，也就是時(shí)間相近、地點(diǎn)單一的一系列操作，并且這些操作最終應(yīng)當(dāng)有一個(gè)明確的結(jié)果。



如上所示這個(gè)用例圖，“申辯申請(qǐng)”就是過錯(cuò)責(zé)任人填寫了一張申辯申請(qǐng)單，最終的結(jié)果是將申辯申請(qǐng)單提交給考核管理員；“申辯受理”就是考核管理員接收了過錯(cuò)責(zé)任人的申辯申請(qǐng)單并予以受理，當(dāng)然另一個(gè)結(jié)果是對(duì)其不予受理，該申請(qǐng)單被退回給過錯(cuò)責(zé)任人。每個(gè)用例都有確定的場景，明確的目的和結(jié)果。

功能角色分析是對(duì)系統(tǒng)宏觀的、整體的需求分析，它用簡短的圖形繪制出了一個(gè)系統(tǒng)的整體輪廓。但僅僅進(jìn)行功能角色分析是遠(yuǎn)遠(yuǎn)不夠的，我們還需要在它的基礎(chǔ)上做更加詳盡的分析。

我們應(yīng)當(dāng)怎樣做需求分析
我們應(yīng)當(dāng)怎樣做需求調(diào)研：初識(shí)
我們應(yīng)當(dāng)怎樣做需求調(diào)研：拜訪
我們應(yīng)當(dāng)怎樣做需求調(diào)研：研討會(huì)
我們應(yīng)當(dāng)怎樣做需求調(diào)研：需求研討
我們應(yīng)當(dāng)怎樣做需求調(diào)研：迭代
我們應(yīng)當(dāng)怎樣做需求調(diào)研：需求捕獲（上）
我們應(yīng)當(dāng)怎樣做需求調(diào)研：需求捕獲（下）
我們應(yīng)當(dāng)怎樣做需求分析：功能角色分析與用例圖
我們應(yīng)當(dāng)怎樣做需求分析：業(yè)務(wù)流程分析（上）
我們應(yīng)當(dāng)怎樣做需求分析：業(yè)務(wù)流程分析（下）
我們應(yīng)當(dāng)怎樣做需求分析：用例說明
我們應(yīng)當(dāng)怎樣做需求分析：查詢報(bào)表分析
我們應(yīng)當(dāng)怎樣做需求分析：子用例與擴(kuò)展用例
我們應(yīng)當(dāng)怎樣做需求分析：行動(dòng)圖和狀態(tài)圖
我們應(yīng)當(dāng)怎樣做需求分析：業(yè)務(wù)領(lǐng)域分析
我們應(yīng)當(dāng)怎樣做需求分析：原文分析法
我們應(yīng)當(dāng)怎樣做需求分析：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)
我們應(yīng)當(dāng)怎樣做需求分析：非功能需求
我們應(yīng)當(dāng)怎樣做需求確認(rèn)：需求列表
我們應(yīng)當(dāng)怎樣做需求確認(rèn)：一個(gè)需求列表的實(shí)例
我們應(yīng)當(dāng)怎樣做需求確認(rèn)：快速原型法
我們應(yīng)當(dāng)怎樣做需求確認(rèn)：需求規(guī)格說明書
我們應(yīng)當(dāng)怎樣做需求確認(rèn)：評(píng)審與簽字確認(rèn)會(huì)

（續(xù)）

我們應(yīng)當(dāng)怎樣做需求分析：功能角色分析與用例圖