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

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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

（續(xù)）

我們應當怎樣做需求分析：功能角色分析與用例圖