在我們進行一系列需求調研工作的同時，我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析。當下一次開始進行需求調研時，我們應當首先將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答。這就是一個需求捕獲->需求整理->需求驗證->再需求捕獲的過程。
但是，當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以后，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有一個統一和有效的方法，往往采用想到哪里做到哪里的方式。一些問題想到了就做了，沒有想到則忽略掉了。實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何一個疏忽都可能對項目研發帶來風險。因此，我們應當采用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。不同類型的軟件項目其分析方法可能存在差異，但一般來說，信息化管理類軟件項目通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。
需求分析不是一項一蹴而就就可以完成的工作，它需要一個長期的過程，而這個過程是一個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、宏觀的，隨著分析工作的逐漸深入，一步步細化。按照這個思路，我們對需求的分析，首先應當從功能角色分析開始。所謂功能角色分析，就是從一個外部用戶的視角分析整個軟件系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。
對一個系統進行功能和角色方面的梳理和分析，可以采用的比較主流的方法之一就是繪制用例圖。用例圖是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. 用例是一個場景。在現實世界中，我們常常面對的是一個個長而復雜的操作流程，但在軟件世界里，我們要將它們拆分成一個個的用例，怎樣拆分？一個用例必須有一個場景，也就是時間相近、地點單一的一系列操作，并且這些操作最終應當有一個明確的結果。
如上所示這個用例圖，“申辯申請”就是過錯責任人填寫了一張申辯申請單，最終的結果是將申辯申請單提交給考核管理員；“申辯受理”就是考核管理員接收了過錯責任人的申辯申請單并予以受理，當然另一個結果是對其不予受理，該申請單被退回給過錯責任人。每個用例都有確定的場景，明確的目的和結果。
功能角色分析是對系統宏觀的、整體的需求分析，它用簡短的圖形繪制出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。
我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會
（續）
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
