九、我們應當怎樣做需求分析：功能角色分析與用例圖
阿新 • • 發佈：2019-01-26
在我們進行一系列需求調研工作的同時，我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析。當下一次開始進行需求調研時，我們應當首先將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答。這就是一個需求捕獲->需求整理->需求驗證->再需求捕獲的過程。
但是，當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以後，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有一個統一和有效的方法，往往採用想到哪裡做到哪裡的方式。一些問題想到了就做了，沒有想到則忽略掉了。實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何一個疏忽都可能對專案研發帶來風險。因此，我們應當採用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。不同型別的軟體專案其分析方法可能存在差異，但一般來說，資訊化管理類軟體專案通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。
需求分析不是一項一蹴而就就可以完成的工作，它需要一個長期的過程，而這個過程是一個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、巨集觀的，隨著分析工作的逐漸深入，一步步細化。按照這個思路，我們對需求的分析，首先應當從功能角色分析開始。所謂功能角色分析，就是從一個外部使用者的視角分析整個軟體系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。
對一個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪製用例圖。用例圖是UML的4+1檢視中的一種，準確地說就是那個“+1”。用例圖是貫穿整個面向物件分析/設計（OOA/D）的核心檢視，它描述的是系統到底為使用者提供了哪些功能，以及到底是哪些使用者在使用這些功能，是溝通使用者與技術人員的橋樑。運用用例檢視對業務需求進行分析、抽象、整理、提煉，進而形成抽象模型的過程稱之為用例建模，而這個模型就是用例模型。
一般地，在一個用例圖中通常有三種元素：參與者（Actor）、用例（Use Case）與系統邊界（Boundary）。用例描述的是系統為使用者提供的功能，也就是系統能為使用者做什麼，通常被繪製成一個橢圓；參與者，我認為稱為角色更加合適，也就是系統為哪些型別的使用者提供服務，他們都各自承擔哪些不同的職責，通常被繪製成一個小人兒；最後是系統邊界，也就是系統是對現實世界哪個範圍的內容進行的模擬，它涉及到軟體設計的工作範圍與工作量，通常被繪製成一個方框。但是，通常情況下系統邊界只是一個概念而不用真正繪製出來，因為被繪製成用例的必然是系統內部的功能，被繪製成參與者的必然是系統外部事物。從這個意義上講，用例圖中的參與者不僅包括人，還包括那些外部系統和自動觸發器。根據這樣一個思路，我以往常常將外部系統和自動觸發器繪製成一個小人，這常常令客戶感到困惑。隨後我改變了思路，將外部系統和自動觸發器繪製成另一種表達形式——類元符號表示法，並在構造型上標註為Actor。
上圖是一個考核系統中一個子模組的用例圖。圖中的用例就是這個系統提供給使用者的各項功能。注意，這裡僅僅是在羅列功能而不表示它們之間諸如流程呼叫等相互關係，這是一些初學者常常犯的毛病。參與者與用例通過實線關聯起來，代表的是一種使用關係。箭頭代表的是一種導航，即動作施與的方向。在這個用例圖中，普通使用者執行查詢操作，查詢系統提供的“預警監控單項查詢”、“預警監控彙總查詢”等查詢報表；每日自動觸發器觸發自動考核功能，自動考核功能從“稅收徵管系統”這樣一個外部系統中採集資料。
圖中考核管理員和執法人員代表的是兩個完全不同的角色，但他們在這個圖中體現的是一些共有的特性，即對這堆報表的查詢，因此被繪製成繼承自普通使用者。繼承是參與者間唯一的關係，代表繼承者擁有被繼承者所有的功能與許可權。除了參與者以外，用例與用例直接也存在著一些型別的關係，這我們在後面詳細講述。
在繪製用例圖時一個值得思考的細節是，用例是怎樣通過分析獲得的。這個問題，在一些客戶對資訊化管理比較有經驗的專案中不存在問題，因為在客戶提供給我們的需求文件中就清晰地劃分出了一項一項的功能。這些功能可能會在日後的需求分析工作中有所調整，但它從整體上形成了一個雛形，成為我們進行用例分析進而形成用例的依據。
但當我們面對的是一些對資訊化管理沒有經驗的客戶，情況就有些不妙了。在這種情況下，通常客戶只能給我們一些管理目標、基本想法，其它的調研工作就需要我們自己去做了。這時，我給大家的建議是，首先從組織機構上劃分清楚系統涉及哪些部門、哪些科室，然後在這個基礎上劃分出來這些部門這各個科室的人員都扮演哪些不同職能的角色，以及完成哪些業務操作。系統中的一個功能，在一般情況下是組織機構中某個（或多個）角色，為該機構某項業務流程完成的某個操作，並且這個操作應當有某個確定的結果（即產出物）。而這個功能就是我們需要提取出來的用例。雖然功能角色分析在整個需求分析過程中可能會隨著認識的深入而不斷調整，但分析過程大體是這樣進行的。
有人說，我們繪製的用例圖拿給客戶看不懂。這樣一個清晰明瞭的用例圖，輔之以我們對圖形的描述，客戶怎麼會看不懂呢？關鍵問題在於，我們沒有將用例圖的精髓弄明白，再加上出現一些常見問題，使得用例圖畫得不倫不類，客戶當然就看不明白了。現在我們看看用例繪製都有些什麼常見問題。
1. 沒有正確理解用例圖的視角。前面我反覆強調了，用例圖的視角是使用者，也就是說，站在使用者的角度來觀察的我們需要設計的系統。從這個視角，使用者看到的系統是什麼呢？當然是一項一項的功能，這些功能是客戶能夠理解的、具體的、對客戶存在價值的功能。從這個意義上說，那些技術性的功能不應當出現在這裡，或者應當描述為使用者可以理解的文字，比如“自動考核”。而那些應當繪製的用例，在取名時也應當站在使用者角度去取名。舉個簡單的例子，一個員工檔案資訊系統，以往我們總愛將用例取名為“新增員工資訊”、“更新員工資訊”、“刪除員工資訊”，這就是典型的技術人員編寫的用例。“新增員工資訊”對於使用者來講應當是做什麼呢——填寫新員工資料；“更新員工資訊”對於使用者來講又是做什麼呢——更改員工資料；“刪除員工資訊”又是什麼呢——員工登出。不論是“填寫新員工資料”、“更改員工資料”，還是“員工登出”，對於客戶都是日常工作中需要完成的操作，將用例命名為這些名字必然為使用者所理解。同時，每一個用例對於使用者來說應當是有價值的，也就是說，使用者使用這個功能是要完成一項操作，或獲得什麼資訊。比如上圖的“自動考核”會產生一批考核結果，執行“預警監控單項查詢”可以獲得預警監控結果資料。
2. 圖形繪製雜亂無章。一個系統，特別是一個大型系統，提供給使用者的功能是繁雜的。如果你想將所有的功能，不管粗的細的，都試圖繪製在一個用例圖中，幾乎沒人看得懂。我們之所以將分析設計圖形化，是因為圖形能給人形象立體的感官，使人立即就明白了其中的意思，但前提是，這個圖形是主題清晰的、形象生動的。因此，我們繪製用例圖要學會拆分，由粗到細地一個一個繪製。先整體的繪製，再劃分成各個模組一個一個詳細繪製，再進一步細化。所以，描述一個系統應當有許許多多的用例圖。
3. 用例是一個場景。在現實世界中，我們常常面對的是一個個長而複雜的操作流程，但在軟體世界裡，我們要將它們拆分成一個個的用例，怎樣拆分？一個用例必須有一個場景，也就是時間相近、地點單一的一系列操作，並且這些操作最終應當有一個明確的結果。
如上所示這個用例圖，“申辯申請”就是過錯責任人填寫了一張申辯申請單，最終的結果是將申辯申請單提交給考核管理員；“申辯受理”就是考核管理員接收了過錯責任人的申辯申請單並予以受理，當然另一個結果是對其不予受理，該申請單被退回給過錯責任人。每個用例都有確定的場景，明確的目的和結果。
功能角色分析是對系統巨集觀的、整體的需求分析，它用簡短的圖形繪製出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。
但是，當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以後，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有一個統一和有效的方法，往往採用想到哪裡做到哪裡的方式。一些問題想到了就做了，沒有想到則忽略掉了。實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何一個疏忽都可能對專案研發帶來風險。因此，我們應當採用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。不同型別的軟體專案其分析方法可能存在差異，但一般來說，資訊化管理類軟體專案通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。
需求分析不是一項一蹴而就就可以完成的工作，它需要一個長期的過程，而這個過程是一個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、巨集觀的，隨著分析工作的逐漸深入，一步步細化。按照這個思路，我們對需求的分析，首先應當從功能角色分析開始。所謂功能角色分析，就是從一個外部使用者的視角分析整個軟體系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。
對一個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪製用例圖。用例圖是UML的4+1檢視中的一種，準確地說就是那個“+1”。用例圖是貫穿整個面向物件分析/設計（OOA/D）的核心檢視，它描述的是系統到底為使用者提供了哪些功能，以及到底是哪些使用者在使用這些功能，是溝通使用者與技術人員的橋樑。運用用例檢視對業務需求進行分析、抽象、整理、提煉，進而形成抽象模型的過程稱之為用例建模，而這個模型就是用例模型。
一般地，在一個用例圖中通常有三種元素：參與者（Actor）、用例（Use Case）與系統邊界（Boundary）。用例描述的是系統為使用者提供的功能，也就是系統能為使用者做什麼，通常被繪製成一個橢圓；參與者，我認為稱為角色更加合適，也就是系統為哪些型別的使用者提供服務，他們都各自承擔哪些不同的職責，通常被繪製成一個小人兒；最後是系統邊界，也就是系統是對現實世界哪個範圍的內容進行的模擬，它涉及到軟體設計的工作範圍與工作量，通常被繪製成一個方框。但是，通常情況下系統邊界只是一個概念而不用真正繪製出來，因為被繪製成用例的必然是系統內部的功能，被繪製成參與者的必然是系統外部事物。從這個意義上講，用例圖中的參與者不僅包括人，還包括那些外部系統和自動觸發器。根據這樣一個思路，我以往常常將外部系統和自動觸發器繪製成一個小人，這常常令客戶感到困惑。隨後我改變了思路，將外部系統和自動觸發器繪製成另一種表達形式——類元符號表示法，並在構造型上標註為Actor。
上圖是一個考核系統中一個子模組的用例圖。圖中的用例就是這個系統提供給使用者的各項功能。注意，這裡僅僅是在羅列功能而不表示它們之間諸如流程呼叫等相互關係，這是一些初學者常常犯的毛病。參與者與用例通過實線關聯起來，代表的是一種使用關係。箭頭代表的是一種導航，即動作施與的方向。在這個用例圖中，普通使用者執行查詢操作，查詢系統提供的“預警監控單項查詢”、“預警監控彙總查詢”等查詢報表；每日自動觸發器觸發自動考核功能，自動考核功能從“稅收徵管系統”這樣一個外部系統中採集資料。
圖中考核管理員和執法人員代表的是兩個完全不同的角色，但他們在這個圖中體現的是一些共有的特性，即對這堆報表的查詢，因此被繪製成繼承自普通使用者。繼承是參與者間唯一的關係，代表繼承者擁有被繼承者所有的功能與許可權。除了參與者以外，用例與用例直接也存在著一些型別的關係，這我們在後面詳細講述。
在繪製用例圖時一個值得思考的細節是，用例是怎樣通過分析獲得的。這個問題，在一些客戶對資訊化管理比較有經驗的專案中不存在問題，因為在客戶提供給我們的需求文件中就清晰地劃分出了一項一項的功能。這些功能可能會在日後的需求分析工作中有所調整，但它從整體上形成了一個雛形，成為我們進行用例分析進而形成用例的依據。
但當我們面對的是一些對資訊化管理沒有經驗的客戶，情況就有些不妙了。在這種情況下，通常客戶只能給我們一些管理目標、基本想法，其它的調研工作就需要我們自己去做了。這時，我給大家的建議是，首先從組織機構上劃分清楚系統涉及哪些部門、哪些科室，然後在這個基礎上劃分出來這些部門這各個科室的人員都扮演哪些不同職能的角色，以及完成哪些業務操作。系統中的一個功能，在一般情況下是組織機構中某個（或多個）角色，為該機構某項業務流程完成的某個操作，並且這個操作應當有某個確定的結果（即產出物）。而這個功能就是我們需要提取出來的用例。雖然功能角色分析在整個需求分析過程中可能會隨著認識的深入而不斷調整，但分析過程大體是這樣進行的。
有人說，我們繪製的用例圖拿給客戶看不懂。這樣一個清晰明瞭的用例圖，輔之以我們對圖形的描述，客戶怎麼會看不懂呢？關鍵問題在於，我們沒有將用例圖的精髓弄明白，再加上出現一些常見問題，使得用例圖畫得不倫不類，客戶當然就看不明白了。現在我們看看用例繪製都有些什麼常見問題。
1. 沒有正確理解用例圖的視角。前面我反覆強調了，用例圖的視角是使用者，也就是說，站在使用者的角度來觀察的我們需要設計的系統。從這個視角，使用者看到的系統是什麼呢？當然是一項一項的功能，這些功能是客戶能夠理解的、具體的、對客戶存在價值的功能。從這個意義上說，那些技術性的功能不應當出現在這裡，或者應當描述為使用者可以理解的文字，比如“自動考核”。而那些應當繪製的用例，在取名時也應當站在使用者角度去取名。舉個簡單的例子，一個員工檔案資訊系統，以往我們總愛將用例取名為“新增員工資訊”、“更新員工資訊”、“刪除員工資訊”，這就是典型的技術人員編寫的用例。“新增員工資訊”對於使用者來講應當是做什麼呢——填寫新員工資料；“更新員工資訊”對於使用者來講又是做什麼呢——更改員工資料；“刪除員工資訊”又是什麼呢——員工登出。不論是“填寫新員工資料”、“更改員工資料”，還是“員工登出”，對於客戶都是日常工作中需要完成的操作，將用例命名為這些名字必然為使用者所理解。同時，每一個用例對於使用者來說應當是有價值的，也就是說，使用者使用這個功能是要完成一項操作，或獲得什麼資訊。比如上圖的“自動考核”會產生一批考核結果，執行“預警監控單項查詢”可以獲得預警監控結果資料。
2. 圖形繪製雜亂無章。一個系統，特別是一個大型系統，提供給使用者的功能是繁雜的。如果你想將所有的功能，不管粗的細的，都試圖繪製在一個用例圖中，幾乎沒人看得懂。我們之所以將分析設計圖形化，是因為圖形能給人形象立體的感官，使人立即就明白了其中的意思，但前提是，這個圖形是主題清晰的、形象生動的。因此，我們繪製用例圖要學會拆分，由粗到細地一個一個繪製。先整體的繪製，再劃分成各個模組一個一個詳細繪製，再進一步細化。所以，描述一個系統應當有許許多多的用例圖。
3. 用例是一個場景。在現實世界中，我們常常面對的是一個個長而複雜的操作流程，但在軟體世界裡，我們要將它們拆分成一個個的用例，怎樣拆分？一個用例必須有一個場景，也就是時間相近、地點單一的一系列操作，並且這些操作最終應當有一個明確的結果。
如上所示這個用例圖，“申辯申請”就是過錯責任人填寫了一張申辯申請單，最終的結果是將申辯申請單提交給考核管理員；“申辯受理”就是考核管理員接收了過錯責任人的申辯申請單並予以受理，當然另一個結果是對其不予受理，該申請單被退回給過錯責任人。每個用例都有確定的場景，明確的目的和結果。
功能角色分析是對系統巨集觀的、整體的需求分析，它用簡短的圖形繪製出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。