今天準備談下軟件需求分析和開發方面的話題，軟件需求是整個軟件生命周期中最重要的一個環境，但是我們注意到在當前類似SCRUM等各種敏捷方法論下，軟件需求被一再的弱化。

我一再強調，如果僅僅是需求變更，採用類似用戶故事這種方式進行需求描述和分解沒有問題，但是如果是全新的建設一個大的業務系統，那麼軟件需求就是一個系統工程，必須要進行完整的業務需求和業務建模。

需求分析和需求建模概述

01-需求究竟是什麼？

對於業務用戶來說，需求就是他們在不同的業務場景下面臨的業務問題，或者說他們希望一種解決方法來達成業務目標；而對於技術人員來說，需求就是你需要實現的軟件功能。

因此需求本身是分層的，其包含了業務需求，用戶需求，產品需求和功能需求。

業務需求簡單來說就是業務目標和範圍。
而用戶需求是用戶必須要完成的工作和任務，希望解決的問題。
軟件功能需求說明書中的軟件需求已經到了具體需要實現的軟件功能。

不同的角色對需求的理解都不一樣，而需求工程師需要做好的就是從業務需求到軟件需求的一個關鍵轉化和抽象。

即通過業務建模來實現了現實世界的抽象化模型表達。

對於完整的需求工程實際包括了需求開發和需求管理兩個方面的內容，如果實施過CMMI過程改進也可以看到，在CMMI裡面需求管理和需求開發是兩個獨立的過程域。

需求開發過程重點就是需求定義和獲取，需求分析，需求開發，需求驗證幾個關鍵內容。而對於需求管理即包括了需求變更管理，需求追蹤，需求版本和基線管理等。

02-需求分析概述

需求分析是需求工程中的核心工作，也是需求分析人員的工作重心。

在通過需求調研活動捕獲原始需求後，需求分析人員要以原始需求作為輸入，通過需求分析，選擇一種業務導向的線索將零散的需求串起來，形成體系完整、內容清晰的脈絡與框架，以指導後續的設計、開發工作，並最終將需求分析產出的工件輸出給開發團隊。

需求分析就是先分解，再提煉，並在這個過程中消除矛盾。

分解是一種自頂向下的方法，其目的是為了降低問題域的複雜度，通過對問題域的逐層分解，將問題域分解為相對獨立的更小的域，從而降低其複雜度，最後分而治之各個擊破，得到基於每個分解後域的需求分析結果。

結合原來的需求實踐可以看到，在需求分析時，也經常使用了分解的方法：將待構建的目標系統分解為模塊，再將模塊分解為不同的業務單元，最後基於業務單元分別進行分析並得到需求分析結果。

需求分析的核心內容就是分解+抽象。

基於分解後的“小塊”分別分析後會得到很多的需求分析片段，基於這些“小塊”的片段之間可能會存在一些矛盾，比如說可能存在一些重複、衝突或是邏輯上的不完整，要消除這些矛盾，就需要將片段放到更大的上下文中考慮，這是一個自底向上的過程，即抽象與提煉。

03-需求建模

建模的目的是幫助我們按照實際情況或按我們需要的樣式對系統進行可視化，提供一種詳細說明系統的結構或行為的方法，給出一個指導系統構造的模板，對我們所做出的決策進行文檔化。

建模的例子在現實生活中無處不在，比如大家常見的對於建築物的建模，通過模型建築師可以在真正建造建築物前將建築物可視化，從而可以對現實進行簡化及研究，從而使用較小的成本發現並修改問題。

另一方面，模型也是溝通過程中常用的重要手段，試想一下，如果沒有模型，建築師將如何向他人闡明設計理念，銷售人員將如何向購買者介紹及推薦？

同樣的，需求建模是需求分析的主要手段，它通過簡化、強調來幫助需求分析人員理清思路，對問題域進行研究並最終用於和上游及下游進行溝通。

如果是對於企業級的業務和需求分析，我們可以參考類似企業架構中的需求和業務建模框架，比如企業架構模型中的Zachman框架，其中的企業模型和概念模型很多就屬於需求層面內容。而類似TOGAF方法論中的業務架構和數據架構的建模思路，我們常說的ARIS的流程分析和建模方法等都可以作為我們在進行端到端需求流程和需求分析時的重要參考。

另外在需求建模過程中，我們總結如下要點需要注意：

建模只是手段，不要為了建模而建模

建築師對建築物進行建模，要麼是為了驗證自己的設計思路，要麼是需要希望通過模型進一步研究建築物以發現問題，要麼是希望通過模型向他人傳達自己的設計意圖，總之，建築師不會為了建模而建模。

同樣的，需求建模也只是需求分析的手段，要帶着目的去建模，不要為了建模而建模！

模型有很多種，不同的模型是對現實在不同精度級別的表達

還是引用現實生活中的例子來講解：售房人員在向購房者推薦房子時，通常會使用兩種模型，其一是立體的模型，其二是房子的平面模型(買過房子的人都知道，就是房書)。立體的模型可以讓購房者能比較好地感受到房子的方位，採光以及小區環境等，然而對於房子的布局以及各個部位的尺寸，使用這種模型就不太容易表達，而這正是平面模型的特長。

類似的，需求模型也有很多種，不同需求模型有不同的用處，需要在需求分析過程中根據目標來選擇不同的模型。

單個模型是不充分的

通過上面的闡述可以知道，不同的模型有不同的特點，可以在某一或某些方面對問題域進行表達，所以在需求分析過程中一般要根據目標選擇不同的模型來對問題域充分建模。

需求建模常用的模型主要包括了如下：

需求過程框架概述

今天對於需求分析最佳實踐，我基本會參考徐鋒老師的《軟件需求最佳實踐》一書進行展開說明，對於該書也推薦給所有準備系統學習需求分析和開發方法的需求人員。

SERU框架是《軟件需求最佳實踐》一書中所提倡的一套需求分析方法論，它講述了一套將目標系統分解為主題域，再分解為流程，最後得到用例以及業務實體的方法，可作為需求分析的指南。

首先對SERU模型的四個字母再做一個說明

S:Subject Area，表示子問題域，其核心思想是要通過業務來分解系統
E:Event，表示業務事件，通過業務事件能夠找到流程，通過流程能夠找到不同場景和用例。
R:Report，表示報表，統一處理查詢，分析和統計類需求。
U:Use Case，表示用例，需求組織的最小單位，到了需求分析階段的重要活動和產出。

SERU過程框架模型將需求過程分解為了三個階段，第一個階段是需求定義，重點是主題域劃分和業務事件識別。第二個階段是理清需求框架和脈絡，重點是通過業務流程圖轉到具體的領域類圖和用例圖。到了第三個階段重點就是填充需求細節，包括用例的詳細編寫，界面和交互設計等。

在SERU框架中，先根據業務相關性以及所涉及組織的職責分區，將目標系統分解成不同的主題域，在這個過程中使用構件圖對主題域劃分結果建模，不但可以表達出系統的組織結構，還可以表達出不同組織域的協作關係；

在每一個主題域中都包含一些業務事件，通過使用上下文關係圖對主題域的範圍進行建模，可以得到這些業務事件，從而得到流程；

通過流程分析並使用活動圖或跨職能流程圖對流程建模，可以清晰地分析出流程中的業務活動及它們之間的關聯關係。在對流程分析的過程中同時會發現一些報表，這些報表及流程中的業務活動將會成為用例；

經過流程分析後，流程中的業務活動已非常清晰，剔除那些與目標系統無關的業務活動後，可以將餘下的業務活動以及分析得到的報表直接轉化成用例，從而得到用例圖片段。而在對流程及報表分析過程中，可以提取出目標系統中的所要管理的業務實體，從而得到領域模型片段；

簡單總結來說就是整個需求過程框架包括了主題域，上下文，流程，報表，數據，實體六個關鍵階段和內容，因此下面我將對上述各個階段展開做下詳細描述。

主題域劃分

我們看一個傳統模塊劃分的例子，如下。

在上圖的例子中，模塊的劃分是以“物”為中心的，比如說“文檔管理”，這個模塊的中心是對“文檔”的管理，而系統中文檔與公司所有的組織均有關係，這就意味着在調研這部分的需求時，要調研幾乎所有的部門才不至於遺漏需求，而需求分析及確認時，則也幾乎要與所有部門進行確認，一方面會導致需求分析人員進行需求確認的難度，另一方面也可能會導致需求的遺漏。

另外，如上圖例子中，是通過傳統的框圖來表達系統結構，在這樣的框圖中，只能表達出系統所包含的模塊，卻無法表達出模塊之間的協作關係。

那麼，應該如何對目標系統進行第一層次的分解呢？

為了解決上面的問題，在對目標系統進行分解時應以職責即“事”為線索進行。以職責劃分角度出發將目標系統按所要處理的事務分解成不同的塊，在SERU框架中將其稱為主題域，即Subject。

主題域劃分方法與企業職責劃分及組織架構吻合度高，用戶可以只參與自己有關的主題域的需求調研，只針對與自己有關的主題域需求進行確認，有利於促進用戶參與，也有利於保證業務流程的完整性，避免業務流程被人為割裂從而產生需求遺漏。

實際在進行主題域劃分時，可以從組織結構以及組織結構中的分管領導作為切入點，將職責相同或有緊密聯繫的組織放在一起成為職責塊，再將職責塊所負責的業務域作為獨立的主題域。

主題域劃分完成後，使用UML規範中的構件圖對其建模，構件圖不僅能表達出目標系統間的結構：構件，也可以表達出不同部分之間的接口關係：構件之間的接口。

總結一下，主題域劃分的要點如下圖。

基於上面的分析我們再來看一個主題域劃分的實例。

見上圖，參考案例中體檢醫院的組織結構中共有六個部門，而這六個部門可以按職責劃分三塊：銷售、生產、後勤，其中銷售區塊負責體檢業務的推銷，生產區塊則負責體檢業務的開展，而後勤區塊則負責支持體檢醫院的日常運行。

有了上面的分析後，就可以按照上面的職責區塊將待開發的目標系統劃分為三個主題域，分別滿足銷售區塊、生產區塊以及後勤區塊業務需求。

銷售區塊所負責的業務主要是業務推銷、客戶管理等，需要納入系統管理的主要是客戶服務業務，所以對應的主題域叫做“客戶管理子系統”；生產區塊主要負責體檢業務的開展，所以對應的主題域叫做“體檢業務子系統”；而後勤區塊包括物資管理及財務管理，因財務管理已經有專用系統，所以需要納入系統管理的就是物資管理業務，所以對應的主題域叫做“物資管理子系統”。

上圖中不但使用構件表達出了主題域及系統的結構，還使用接口表達出了主題域間的接口。

上下文-主題域範圍分析

主題域劃分完成後，對於每個主題域而言，裡面究竟包含多少業務流程呢？換句話講，這個主題域的範圍有多大呢？在分析主題域範圍時，可以使用上下文關係圖來建模，使用一個上下文關係圖來表達一個主題域。

在繪製上下文關係圖時，將待分析的主題域當作黑盒子，找出所有相關的外部客戶（Customer）及內部角色(Worker)，再識別出所有外部客戶及內部角色主動發起的所有業務事件，根據這些業務事件，按序標出各個角色的反應。

在繪製上下文關係圖時，需要注意的是要先識別外部客戶主動觸發的業務事件，然後再識別內部角色主動觸發的業務事件。

為什麼要先識別外部客戶主動觸發的業務事件呢？因為外部客戶所觸發的業務事件更可能是業務流程的起點，大部分內部角色所採取的動作大部分是對外部客戶所觸發業務事件的反應。

繪製上下文關係圖是為了識別主題域中的業務事件，所以這個圖最好是在和用戶進行訪談時就繪製，在紙上繪製的草圖就是非常好的方式；若主題域較小、比較簡單或是其中的流程非常明顯時，可以不需要繪製上下文關係圖，不要為了畫圖而畫圖。

參考案例中體檢醫院的管理系統被分解為三個主題域，其中“體檢業務子系統”這個主題域主要的外部客戶就是體檢者，而內部工作人員包括服務人員、收費人員、體檢科室以及綜合科醫生。

在為這個主題域繪製上下文關係圖時，先考慮外部客戶主動發起的業務事件，體檢者最主要的業務事件就是申請體檢，也可能會在體檢過程中要求修改，這就是外部客戶主動發起的業務事件。

流程分析和識別

通過上下文關係圖對主題域進行分析後，可以得到主題域中所包含的業務事件，而這些業務事件就是業務流程的起點。

流程分析時，需要注意流程的目標性、內在性、整體性、動態性、層次性、結構性這六大特性，以及流程設計的幾大原則，具體可參考流程設計的專業書籍。

流程是需求分析的重要內容，流程圖對於和用戶確認需求以及向開發團隊傳遞需求都是非常重要的。可以選擇使用UML規範中的活動圖或商業建模標準中所推薦的跨職能流程圖對流程建模。

在繪製流程圖時，需要特別注意流程的層次性，在需求分析的早期階段最好以業務活動作為流程圖中的活動，不要過早地進入業務步驟等細節的分析。

這是SERU框架推薦的主要方法，通過對主題域進行分析並繪製上下文關係圖後，即可得到主題域中所包含的業務事件，通過對業務事件所觸發的各角色的反應形成業務流程，識別過程如下圖所示。

以下是另一個通過業務事件識別流程例子，例子所屬的業務領域為手機交易。在這個領域中，可能的業務事件有客戶下單，而為了應對這個業務事件，對應的流程就是企業的銷售流程。

除了上面提到的方法外，還可以對目標系統的主要客戶以及目標系統的業務生命周期進行研究，從而得到一些業務流程。

拿一個銷售管理系統為例，分析客戶的生命周期就可以知道存在知道、願意、購買、接收、付款等階段，那麼對應這些階段，可能的流程就有市場推廣、市場調查、訂單管理、配送、收款等流程，具體如下圖。

報表分析

通過流程分析，可以得到流程中的活動，這些活動未來將被轉換成為用例。然而，如果只進行流程分析並基於流程中的活動來轉換用例，將會遺漏一部分需求，這就是報表類的需求，因為報表類的需求一般不會體現在業務流程中。

報表類的需求是一個廣義的概念，包含查詢、統計、度量、報表等，主要特徵就是它們是數據的消費者，要麼是對業務活動的支持，要麼是對業務活動的管理，但一般不會出現在業務流程中。

在對高層進行調研時可以得到管理類的報表需求，而在對業務事件進行流程分析時，出於邏輯上的完整也可以識別到支持類的報表需求，如查詢，沒有這類需求，業務活動會難以進行。

以參考案例為例，在對高層訪談時，可能會得到這樣的信息：希望能定期對體檢業務進行統計分析，這就是一個管理類的報表需求：體檢業務周期統計報表；

在對體檢者申請體檢這個業務流程進行分析時，其中有一個業務活動“返還客戶”，即客戶人員將體檢報告返回給體檢者，服務人員在返還體檢報告時，需要對體檢者的體檢報告進行查詢並確認是否已經返還，這就是一個支持性的報表需求：查詢體檢報告返還情況。

用例分析

在傳統的需求分析過程中，用例抽取主要依靠需求分析人員的經驗，沒有統一的方法及手段，這是目前需求分析中存在主要問題之一。

在SERU框架下，經過將目標系統分解為主題域再分解為流程，流程中清晰地表達了角色所要執行的業務活動，這正是用例的內容，用例即用戶使用系統完成業務活動的場景。

除了業務活動可以轉換成為用例外，前面所進行的報表類需求也可以比較明顯地轉換成為用例。

在將業務活動及報錶轉換為用例後，使用UML中的用例圖對用例建模，用例圖不但可以表達出用戶是如何使用系統的，還可以表達出用戶與用戶之間的關係，用例與用例之間的關係。

從流程圖轉換用例

可以從流程圖中轉換用例，從流程圖轉換用例就將流程圖中業務活動轉換為用例。比如體檢者申請體檢流程中的業務活動“出具報告”就可以對應轉換為一個用例，其執行者是綜合科醫生，表達的是綜合科醫生將使用系統為體檢者出具體檢報告。

從流程圖中轉換用例時，先基於流程圖分析流程圖中的哪一些是不直接使用系統，將其排除，將餘下的職能帶區(泳道)轉為角色，將流程圖中的業務活動及判斷轉換為用例，決定活動是否要轉換為用例的標準是它是否屬於系統範疇，而決定判斷是否要轉換為用例的標準是它是否獨立。轉換過程如下圖所示。

而對於報表類需求，轉換為用例的過程是比較明顯的，一個具體的報表項可以轉換為一個用例。

用例轉換實例

通過體檢者申請體檢的業務流程轉換用例的步驟如下：

確定邊界：經過分析，體檢者不會直接使用系統，去除其對應的職責帶區。其它角色均要直接使用系統，保留。

確定角色：確定4個actor，分別為服務人員、收費人員、體檢醫生及綜合科醫生。

確定用例：按照流程圖中的職責帶區及業務活動及判斷進行分析，“服務人員”有兩個個業務活動“開單”及“返回客戶”，“開單”要在系統中進行記錄，“返回客戶”要在系統中記錄並打印，均屬於系統範疇，轉換為用例；“收費人員”只有一個業務活動“收費”，“收費”時需要在系統中操作，屬於系統範疇，轉換為用例；“體檢醫生”只有一個業務活動“體檢並記錄結果”，其中體檢與系統無關，而記錄結果需要在系統中記錄，屬於系統範疇，轉換為用例；“綜合科醫生”對應一個業務活動“出具報告”及一個判斷“體檢已完成？”，“出具報告”時需要在系統中記錄結果，屬於系統範疇，轉換為用例，而判斷則不是獨立的活動，從屬於業務活動“出具報告”，不轉換為用例。

繪製用例圖：用例確定後，可使用rose工具繪製出用例圖