軟件需求與分析須要掌握的內容

  讀了老師推薦的這篇博文，我以爲需求分析真的是一門博大精深的學問，本來只是以爲需求分析就是找一個用戶簡單的詢問她想要什麼，就給他作一個軟件來就行，可是讀了博文以後發現需求分析原來有這麼多須要注意的地方。

  需求分析需掌握的技能：

  1.初識  咱們應與客戶深刻了解後，運用咱們專業知識，提出比客戶的原始需求更加合理、可操做的解決方案，讓客戶感受你說的正是他們想要的。若是可以這樣，客戶不只可以欣然接收你提出的方案，並且會感受你很是專業，你在客戶心目中的形象也會無形中提升，使你有更多的機會提出有利於開發的可行方案，下降開發的風險。

還要與不一樣層次的用戶具體交流

  2.拜訪

需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工做（假如項目還有後期維護）。在這漫長的時間裏，咱們須要依靠客戶這個羣體的幫助，一步一步掌握真實可靠的業務需求。不只如此，技術這東西總有不如意甚至實現不了的地方，咱們須要客戶的理解與包容，這都須要有良好的客戶關係。按照如今的軟件運做理念，軟件項目已經不是一錘子的買賣，而是長期的、持續不斷的提供服務。按照這樣的理念，軟件供應商與客戶創建的是長期雙贏的戰略協做關係，這更須要咱們與客戶創建長期友好的關係。

  3.討論會

採用這種集中式的研討，可使問題的處理變得高效而及時。固然，也會因地區化差別而出現多個方案，每一個方案都是合理的，咱們必須在軟件中分別對其進行處理的狀況。

將業務人員劃分爲多個業務組也是一項比較成功的經驗。因爲業務人員自身的侷限，不可能對全部業務領域的細節全面掌握，每每老是有本身熟悉的部分，也有本身不熟悉的部分。劃分業務組，可讓業務人員分別在本身最熟悉的業務範圍內參與討論，能夠有效提升業務討論的質量。同時，一個管理系統涉及的業務是複雜而系統的，若是劃分紅多個模塊並行地進行業務討論，也能夠大大提升業務研討的工做效率。

  4.需求談論

在認識了客戶的業務領域以後，咱們才能去分析他們提出的全部原始需求。他們爲何要提出這項需求，提這項需求的目的是什麼？只有通過這樣的分析，咱們才能深入地理解需求，進而運用咱們的專業知識，提出更加合理的技術方案。但很是遺憾，咱們在需求分析中經常不是這樣作的，甚至當軟件都開發出來了，需求分析人員都說不出客戶爲何要提出這個需求，更談不上了解業務操做流程。一句經典的話是：「客戶讓咱們這樣作的。」

總之，咱們作需求分析，眼界不能僅僅停留在軟件自己，應當更開闊一些，應當擴展到跟這個業務有關的那些領域知識中。需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有創建在這種分析基礎上的軟件研發，才能保證需求的正確與變動的可控。

  5.迭代

當咱們完成了一系列的分析整理並造成文檔之後，應當對及時地與客戶進行反饋，確認咱們的理解是否正確，也就是需求驗證工做。需求驗證工做應當貫穿整個研發週期，而且在不一樣時期表現出不一樣的形式。首先，在需求分析階段，需求驗證工做表現爲對需求理解是否正確的信息反饋。需求分析人員與客戶再次坐在一塊兒，一項一項描述咱們對需求的整理和理解，客戶則時不時地對一些問題進行糾正，或者更加深刻地加以描述。咱們則認真地記錄，回來整理，並等待下一次的驗證。在需求分析後期，咱們還能夠製做一些簡單的原型，更加形象地描述咱們對需求的理解，會使咱們與客戶的溝通更加順暢。隨後的設計開發階段，咱們則應當以迭代開發的形式進行。每開發完一個迭代週期，將開發的成果與客戶反饋。這樣作的結果是，客戶能夠及時地提出咱們對需求理解的誤差，或者及時提出對咱們設計不滿意的地方，使咱們存在的問題獲得及時地發現與解決。問題及時的解決，使咱們修復問題的代價得以降至最小。以後，當開發進入到驗收測試階段，咱們則是與客戶一道，一項一項地驗證咱們的軟件是否知足需求列表中要求的業務需求。最後，當軟件迎來下一次升級開發時，咱們將開啓另外一次輪迴。

  6.需求捕獲

客戶在提出來一系列業務操做之後，最後提出了一個統計報表的功能。這個統計報表是從前面這一系統操做數據中統計出來的，所以咱們就對這些業務操做及其結果數據進行了一個詳細的分析，最後發現根據這些數據統計出來的數據存在不少的問題，甚至可能出現相互矛盾的地方。隨後咱們與客戶就這些問題進行了深刻地探討，最終客戶不得不認可，他當初在設計這個報表的時候考慮不周全。在提出問題的同時，咱們又提出了咱們的解決方案，這是很是關鍵的。當咱們提出咱們的合理化建議之後，客戶欣然接受了。同時，客戶對咱們這種很是專業的分析與處理過程大加讚揚，無形中也提升了咱們在客戶心目中的威望。

不只如此，客戶做爲一個羣體，客戶與客戶以前對同一問題也可能存在不一樣的見解，這特別突出地體如今那些多組織機構的管理系統中。所以，對於一些客戶非正式的場合提出的需求咱們要仔細甄別。一個比較可行的方法就是，先在一些非正式的場合單獨跟客戶聊，產生第一手資料，最後將這些需求在比較正式的場合，如各部門參加的業務討論會、有用戶表明參加的需求評審會、需求定稿簽字確認會等等，以比較正式的形式討論和肯定下來。

  7.功能角色分析和用例圖

面對的是一些對信息化管理沒有經驗的客戶，狀況就有些不妙了。在這種狀況下，一般客戶只能給咱們一些管理目標、基本想法，其它的調研工做就須要咱們本身去作了。這時，我給你們的建議是，首先從組織機構上劃分清楚系統涉及哪些部門、哪些科室，而後在這個基礎上劃分出來這些部門這各個科室的人員都扮演哪些不一樣職能的角色，以及完成哪些業務操做。系統中的一個功能，在通常狀況下是組織機構中某個（或多個）角色，爲該機構某項業務流程完成的某個操做，而且這個操做應當有某個肯定的結果（即產出物）。而這個功能就是咱們須要提取出來的用例。雖然功能角色分析在整個需求分析過程當中可能會隨着認識的深刻而不斷調整，但分析過程大致是這樣進行的。

有人說，咱們繪製的用例圖拿給客戶看不懂。這樣一個清晰明瞭的用例圖，輔之以咱們對圖形的描述，客戶怎麼會看不懂呢？關鍵問題在於，咱們沒有將用例圖的精髓弄明白，再加上出現一些常見問題，使得用例圖畫得不三不四，客戶固然就看不明白了。如今咱們看看用例繪製都有些什麼常見問題。

1. 沒有正確理解用例圖的視角。前面我反覆強調了，用例圖的視角是用戶，也就是說，站在用戶的角度來觀察的咱們須要設計的系統。從這個視角，用戶看到的系統是什麼呢？固然是一項一項的功能，這些功能是客戶可以理解的、具體的、對客戶存在價值的功能。從這個意義上說，那些技術性的功能不該當出如今這裏，或者應當描述爲用戶能夠理解的文字，好比「自動考覈」。而那些應當繪製的用例，在取名時也應當站在用戶角度去取名。舉個簡單的例子，一個員工檔案信息系統，以往咱們總愛將用例取名爲「添加員工信息」、「更新員工信息」、「刪除員工信息」，這就是典型的技術人員編寫的用例。「添加員工信息」對於用戶來說應當是作什麼呢——填寫新員工資料；「更新員工信息」對於用戶來說又是作什麼呢——更改員工資料；「刪除員工信息」又是什麼呢——員工註銷。不管是「填寫新員工資料」、「更改員工資料」，仍是「員工註銷」，對於客戶都是平常工做中須要完成的操做，將用例命名爲這些名字必然爲用戶所理解。同時，每個用例對於用戶來講應當是有價值的，也就是說，用戶使用這個功能是要完成一項操做，或得到什麼信息。好比上圖的「自動考覈」會產生一批考覈結果，執行「預警監控單項查詢」能夠得到預警監控結果數據。

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

3. 用例是一個場景。在現實世界中，咱們經常面對的是一個個長而複雜的操做流程，但在軟件世界裏，咱們要將它們拆分紅一個個的用例，怎樣拆分？一個用例必須有一個場景，也就是時間相近、地點單一的一系列操做，而且這些操做最終應當有一個明確的結果。

  8.業務流程分析

咱們進行業務流程分析，就是要分析業務流程中哪些是須要信息化管理的，而哪些則不須要。信息化管理過細，無疑會加劇基層業務人員的負擔（這也正是爲何許多基層業務人員會排斥信息化系統的緣由），而適當的信息化管理則能夠提升工做效率。試想一下，若是你工做中的每個步驟都必須在計算機中操做一下，怎麼不讓人煩呢？而若是在工做中一旦須要先查一個什麼信息，或者須要計算一下，系統當即能夠替你完成這些工做，或者那些過去基本靠吼的操做，如今立馬經過信息化就傳遞過去了，怎麼不讓人舒心呢？咱們作信息化管理，不是要加劇人的負擔，而應是下降人的負擔。以這樣的思路去進行流程分析才能設計出優秀的、人見人愛的管理系統出來。所以，我作需求分析，最喜歡下到基層去了解基層業務人員的需求，去分析怎樣設計流程才能提升他們的工做效率，而避免加劇他們的負擔。「水能載舟，也能覆舟。」一套系統是否能順利推行下去，基層人員是否支持每每起到十分重要的做用。另外，業務流程分析的另外一個重要的分析內容就是流程差別化分析。不一樣的領導有不一樣的思路，不一樣的單位有不一樣的狀況。所以，咱們在進行流程分析的時候，經常面臨流程差別化的問題。咱們說企業信息化就是一次改革，這首先體如今業務流程的規範化操做，也就是消除這種流程差別。但不一樣的單位有不一樣的狀況，這特別體如今不一樣地域和文化的不一樣，又經常形成這種流程差別不可避免。分與合，分治與一統，經常是一個都要兼顧的問題，很是微妙，咱們要當心處理。在這個問題上你也許會問，使用工做流引擎就能夠了嘛。工做流引擎不是萬能的，它只能解決一部分問題，更多的問題還須要咱們的分析人員去分析與處理。

  9.用例說明

用例標識：就是用例的編號，通常採用「項目編號-子系統編號-模塊編號-序號」來編號。

用例名稱：沒啥可說的，就是用例圖中該用例的名稱。注意用例的命名規則：用例名稱一般是一個動詞短語或短句，而不是一個名詞短語。它能夠是一個動詞（如：自動考覈），一個動賓短語（如：提取存款），一個被動句（如：發票填報），或者一個主謂句（如：用戶提款，這個不推薦，由於主語就是參與者，顯得有些多餘）。

用例類型：在我看來，不一樣類型的用例，其用例說明的格式是不同的。以上給出的是「業務操做」類用例的格式，它更加着重地在描述業務操做的流程。而「查詢報表」類用例則沒有什麼流程，它更加着重地在描述報表格式及顯示內容（後面再給出）。還有用例類型還包括「子用例」、「擴展用例」。

用例描述：對該用例的功能定義、要實現的業務需求，以及誰（參與者）應該如何使用進行描述。同時，這部分還能夠總體概述實現業務需求的主要流程，以及與其它用例、其它外部系統的關係。經過用例描述，閱讀者能夠對該用例有一個總體的認識。

參與者：用例圖中該用例的參與者，一般是業務操做的觸發者和施與對象（如外部系統）。

觸發事件：誰幹了什麼，觸發了這個用例。

前置條件：在觸發該用例相關操做前必須達到的條件。

事件流：這是用例說明中最重要的部分，它詳細描述了該用例可能出現的全部流程。
1. 基本流程：另外一個名稱更能表達它的意義：最佳流程（The Best Flow）。它描述的是該用例以最佳的、最正常的方式流轉，沒有出現任何異常，而且最終成功完成操做的流程。基本流程在編寫時，應當經過數字對流程中的每一步進行編號。
2. 擴展流程：或者叫「分支流程」，它描述的是基本流程在流轉過程當中可能出現的全部分支。擴展流程最大的特色就是，它應當是在基本流程的某一步驟發生的分支，所以它的編號規則是「基本流程號+序號」。基本流程號就是發生分支的那一個基本流程的編號。在同一個基本流程上發生多個分支時，它們的序號從1依次開始編號。
另外一種狀況是，某個擴展流程自己擁有多個步驟，這時應當在「基本流程號+自身序號」的基礎上再添加序號，如「2.1.1」。
擴展流程在描述時，應當首先描述進入這個分支的條件，即「若是××則××」、「當××時××」。
3. 異常流程：就是發生異常狀況時的處理流程。注意，用例說明是站在用例角度進行的說明，所以這裏並非咱們一般同樣的發生程序異常的處理流程，而是用戶在處理業務操做時發生的異常狀況，如：若是顧客不能提供身份證，則••••••

後置條件：又稱爲「成功保證」，就是執行基本流程得到成功之後所達到的狀態（條件）。後置條件每每體現的是執行該用例的最終目的。如：完成用戶檔案的填寫並提交。

非功能需求：簡稱爲「URPS+」，便可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。這一部分的需求分析至關重要而又最容易被忽略，後面咱們再詳細討論。

假設與約束：就是隱藏於業務功能中的各項規則與條件，如各類邏輯條件、計算公式、環境限制等等。

優先級：沒啥可說的，最關鍵的是怎麼去評定。這裏我賣一個官子，在需求評審階段，我會給你們一個比較準確而又可操做的評定方法。

除此以外，我還每每在每個用例說明的後面與該用例相關的需求列表，便於需求跟蹤。用例分析實質是需求人員的一份設計。既然是設計就可能出現誤差，最終偏離原始的需求（這種狀況特別容易出如今往後的升級維護中）。所以，將需求列表附在用例後面，便於往後的需求評審與確認。當每次須要升級時，則添加上新的需求，或對以往的需求進行更新。

  10.查詢報表分析

報表做用：就是描述參與者使用這個報表作什麼。若是有多個參與者，每個都應當描述。

報表內容：用簡短的話描述一下。

輸出列：羅列報表的輸出列，若是須要的話，還應對輸出列進行說明，或描述它的數據來源。

使用頻率：參與者使用它的頻率，便於設計者考慮報表的查詢效率。

數據連接：哪些數據項有連接，連接到什麼報表，或顯示什麼數據。

最後依然是那個需求列表，便於業務需求的跟蹤。

查詢報表的需求分析與通常的業務操做的需求分析存在着巨大的差別。而許多需求分析人員沒有認識到這一點，這每每致使對查詢報表的分析不到位，爲項目的研發帶來風險，所以在這裏咱們認真探討一下。

一個有效的報表，每每不是對數字的簡單堆砌，它經過一組一組的數據，揭示的都是一些客觀規律、複雜活動與發展趨勢。客戶方的領導，特別是那些中層和高層領導，經過對這些報表的閱讀，就能夠掌握他們的工做進程、增強他們的人員管理、發現他們的管理漏洞、指導他們的戰略決策。總之一句話，每一個報表都有他們的設計意圖。

好比說，一份工做月報，領導但願看到的，是按時間、按項目、按部門統計的各項工做的進展狀況，以及有哪些異常狀況，以便領導監控各項工做可以順利完成；一份銷售報表，領導但願看到的，是按產品、按區域、按顧客類型統計的各項產品的銷售狀況，以便領導制訂銷售計劃與各類營銷戰略。沒有弄清楚一個報表的真實意圖，就不算真正理解了這個報表的業務需求。

同時，報表的數據項應當都是來源與系統中各項操做的結果數據。許多業務系統的操做流程都是紛繁複雜的，其中還包括各類狀況。更復雜的，一些商業智能與分析決策系統，報表所需的各類數據，甚至來源與各類各樣的外部系統。分析一個報表的數據來源，就是在梳理各類業務流、數據流，以及各類數據間的關係。若是這方面的分析不到位，最終設計出來的報表每每是不許確的。

另外，用戶使用報表的頻率，經常決定了報表設計的方式。若是報表中的數據老是在實時變化，而且用戶老是在密切關注這些數據的變化，那麼報表必須設計成實時查詢的；若是用戶並非十分關注數據的實時變化，而且老是以天（或者月，或者年）來查看報表，則報表能夠設計成按天（或者月，或者年）來預運算統計數字，使得報表查詢效率顯著提升，能夠保證更多的併發訪問。

最後，一個報表的核心就是展示給客戶的報表格式，以及報表與報表間的各類連接。需求人員在進行需求分析階段，應當準確地與客戶敲定這些格式，並最終在用例說明中體現出來。報表格式是否體現客戶的意圖，報表數據項是否都能在系統中取到，數據間的邏輯關係是否正確，報表格式是否技術可行，都是需求分析人員在前期就必需要分析到位的內容。不然，報表是項目後期可能出現頻繁需求變動的重災區。

全部這些分析，都體如今了我提供給你們的用例說明格式中。報表做用體現的是報表對於不一樣用戶的真實意圖；輸出列體現的是對各個數據項及其數據來源的說明；假設與約束羅列的是報表中各個數據項的運算公式、數據規則與約束；還有使用頻率、數據連接、非功能需求，以及最後的界面原型，等等。只要咱們把這些都分析到了，咱們的查詢報表就分析到位了。

  11.子用例和擴展用例

在用例中還存在許多擴展流和異常流。當系統在運行到基本流程中某個步驟時，因爲知足了某個分支條件或異常條件，這時系統就從基本流程流轉到了擴展流或異常流中。擴展流和異常流其實不那麼涇渭分明。在業務邏輯上擴展流依然是一種正常的操做，僅僅只是正常操做的另外一個操做，而異常流其自己就是有什麼東西不對勁了，須要進行一些異常處理，好比用戶密碼輸錯了、用戶忘帶身份證了，等等。擴展流和異常流最終均可能回到基本流程中，也可能不能回來，而從另外一個結束點結束。

與子用例類似，擴展流和異常流中的流程若是相對獨立、能夠爲其它流程所共享，則能夠提取出來，造成一個單獨的用例，叫擴展用例。若是擴展用例是直接從基本流程中某個環節擴展出來，則該環節被成爲擴展點，進入擴展用例的條件叫擴展條件。在用例圖中，擴展關係被繪製成一根虛線，從擴展用例指向被擴展的用例，並標註爲extend。

用例分析中對子用例與擴展用例的分析，使咱們對系統的設計，從一開始就將公共的、可共享的部分提取出來，使咱們在往後的設計與開發中得以很好地複用，提升了系統的內聚並下降了系統的耦合，是一個優秀軟件設計的開始。

  12.行動圖和狀態圖

將參與者由繁瑣的泳道改成了用例圖中的小人。同時，在這張圖中還增長了對象流與對象。圖中，自動考覈結果、申辯申請單、調整後考覈結果，都是數據對象，是該流程中相關環節操做的結果。從活動節點指向對象的虛線箭頭，則表示了一個對象流，如「申辯申請」活動指向「申辯申請單」的虛線箭頭，表示了申辯申請活動的最終結果是產生申辯申請單；從「調整後考覈結果」指向「過錯追究」的虛線箭頭，表示過錯追究活動讀取了調整後考覈結果。

固然，活動圖還有其它的元素，但我我的認爲其實並不實用，使用以上元素就足以表述咱們的業務流程了。活動圖打破了子系統與子系統的壁壘、用例與用例的壁壘，使咱們可以從總體上了解整個系統的流程，所以經常使用在對整個系統的概述、對整個子系統的概述，以及對整個功能模塊的概述中。同時，與其它視圖同樣，活動圖也應當有它的文字說明，以便對圖中的每一個活動節點、分支進行描述。但對於一些流程相對簡單，甚至沒有什麼流程的查詢報表類功能模塊，繪製它們的活動圖則顯得有些牽強附會。

  13.業務領域分析

在需求分析工做中，最後一項分析工做就是業務領域分析啦。業務領域分析，就是對需求分析中涉及到的業務實體，以及它們相互之間關聯關係的分析。前面咱們談到了功能角色分析，或者說用例分析，它是從總體的角度對整個系統人機交互的分析與整理。隨後咱們談到了業務流程分析，它是在對系統人機交互的分析與整理的基礎上，更加細緻的去分析和整理那些業務流程，以及組成這些流程的一個個業務操做。業務流程分析是對系統進行的一種動態的分析，分析的是那些行爲，那些操做。可是，全部的行爲，全部的操做，最終施與的對象都是那些實體。這句話怎麼理解呢？好比，咱們執行填寫操做，施與的對象必然是那些表單，最終產生的結果必然是造成一份完整的表單，表單就是那個行爲施與的對象。再好比，咱們執行查詢操做，施與的對象必然是一個報表，最終產生的結果必然是查看到了這個報表的結果。這裏的表單、報表，都是存在於系統的靜態實體，它們中的大多數也最終以數據結構的形式持久化保存於系統的數據庫中。所以，系統中應當有哪些實體，這些實體都有哪些屬性，被賦予了哪些行爲，它們之間的相互關係是怎樣的，就成爲了業務領域分析的重要內容，而業務領域分析也就成爲了對系統進行的一種靜態分析。

  14.原文分析法

在進行原文分析的時候，咱們首先要作的事情就是對用例說明中事件流部分的文字描述，提取其中的名詞。在這個實例中都有些什麼名詞呢？這些名詞我在用例中用藍色標註了出來，通過整理就是這些：觸發器、考覈指標（簡稱指標）、執法行爲、指標定義、過錯標準（過錯判斷標準）、過錯行爲、考覈結果、年度、月份、機關、分子數、分母數、過錯數、正確率。

領域模型中的實體，每每就在咱們經過原文分析提取出來的這些名詞中，但須要咱們進行進一步分析。並非全部名詞均可以成爲實體，那麼哪些能夠呢，而哪些又不能呢？首先，系統外的參與者不能。系統外的參與者是觸發本系統某個事件的人或者物，但它自己存在於系統以外，好比用戶使用鼠標點擊了一個按鈕，而領域模型是描述系統以內的事物，所以系統外的參與者應當被排除。本例中的觸發器就是系統外的參與者（參見《功能角色分析與用例圖》），它應當被排除。

其次，系統以內的事物轉化到領域模型中，可能會變成兩種東西：實體與實體中的屬性。什麼變成實體而什麼變成實體中的屬性呢？自身有本身的屬性，能夠成爲系統中行爲的執行者或施與者的，纔是實體。好比考覈指標就是實體，由於它有它的考覈標準、過錯行爲、分子數、分母數、過錯數、正確率等屬性，它在系統中會去執行考覈，因此是實體；分子數是否是實體呢？它僅僅是一個數據，沒有本身的屬性和方法。另外一個判斷是實體仍是屬性的方法就是判斷它將如何持久化。若是一個事物被持久化到數據庫中時是一個表，則是一個實體；若是僅僅是表中的一個字段，則是一個屬性。

然而，是實體仍是屬性並非那麼絕對，關鍵看系統對這個事物進行怎樣的處理。好比過錯標準是一個實體仍是一個屬性呢？若是咱們在系統中僅僅是一個文字描述則是考覈指標中的一個屬性，若是須要對它進行分解，有它的判斷公式，須要讓它去執行判斷，則應當是一個實體。在需求分析的初期，能夠先將其設計成一個屬性，待往後的細化階段再進行調整。

另一個很是重要、值得咱們着重關注的地方是名詞的多義性。在本例中，咱們考察一下「過錯行爲」這個名詞。「一種過錯行爲」與「一個過錯行爲」顯然不是一個概念。「一種過錯行爲」表明的是一種類型，有它的過錯定義與判斷標準；「一個過錯行爲」則表明的是一個實例，一個執法行爲中的某個錯誤的行爲。正由於它們概念上的差別，咱們在領域模型中將其分爲「過錯類型」與「過錯行爲」。

  15.領域驅動設計

當咱們站在技術人員的視角去繪製設計圖時，客戶必然看不懂，由於圖中使用的都是專業的術語、專業的符號，表達的都是專業的設計思想。反過來，若是咱們站在業務人員的視角去繪製設計圖時，狀況就不同了。若是一個用例圖，圖中的功能都是客戶平常常常作的業務操做，而且命名都是業務人員可以理解的業務術語，試問客戶會不理解嗎？一樣，在領域模型中，咱們按照客戶的思路，運用客戶的術語，去繪製一個一個的對象，按照他們的思路去描繪對象間的關係，描繪對象間的操做，他們真的就會看不明白嗎？這說得彷佛有一些抽象，咱們舉一個實際的例子吧。

有一次，我與客戶在討論一個考覈系統，首先客戶描述着他們的需求：
客戶：咱們這個考覈系統是由許多個考覈指標組成的，每一個考覈指標就標誌着咱們的某項工做的完成狀況。每一個考覈指標中有一個分母數，標誌某段時間全部應當完成的工做數量，有一個分子數，標誌這段時間正確完成的工做數量，最後還有一個過錯數，標誌那些錯誤的，或者沒有按時完成的工做數量。
需求人員：爲何是分子分母？
客戶：由於最後要計算正確率，用正確率來考覈一個單位完成工做的狀況。
這樣，咱們在紙上繪製出一個考覈指標，在屬性中寫下分母數、分子數、過錯數、正確率。

需求人員：那麼每一個考覈指標都有一個過錯判斷標準了？
客戶：固然啦，每一個考覈指標都有它的過錯判斷標準。一個考覈指標可能會有多個過錯行爲，每個過錯行爲都有各自的過錯判斷標準，任何一個過錯了，這個執法行爲就算過錯啦。
需求人員：先等等，你剛纔提到執法行爲了。執法行爲和考覈指標是什麼關係？
客戶：哦，執法行爲嘛，就是執法人員對某個用戶執行的一次業務操做。考覈指標中的分母數就是全部執法行爲的個數；分子數就是正確的執法個數；過錯數就是錯誤的執法個數。
這樣，咱們就繪製出這樣一個草圖：



客戶看了這個草圖有些不一樣明白：過錯類型是什麼東西？
需求人員：過錯類型就是某種類型的過錯行爲呀，它定義了某種過錯行爲，有它的過錯判斷標準。下面這個過錯行爲就是那些具體的過錯，好比張三今天犯了什麼錯，李四明天犯了什麼錯。
客戶：哦，明白。這兩個箭頭怎麼跟其它箭頭不同，後面還跟了個菱形框？
需求人員：哦，這表明的是包含關係，表示一個考覈指標包含了多個類型的過錯行爲呀。

通過一番交流，咱們已經明白客戶的意思了，客戶也明白咱們畫的圖了。你們對彼此的交流都比較滿意。

全部的愛情都是以浪漫開始的，需求分析也不如此。隨着需求分析的不斷深刻，咱們發現問題了。在這張圖中，咱們把執法行爲與過錯行爲僅僅描述爲一對多的包含關係，彷佛沒有什麼特別的。但對大量考覈指標具體需求的分析，咱們才發現其實不是這樣簡單。當考覈指標只有一種過錯行爲的時候，那很是簡單，這個過錯行爲對就是對，錯就是錯。但當考覈指標存在多種過錯行爲的時候，狀況就複雜了，必須分紅三種狀況：

1. 一個執法行爲同時包含多種過錯行爲，每一個過錯行爲就是一個考覈點，任意一個考覈點錯了整個就判錯，只有全部考覈點都正確才判正確。這種狀況就像填一個表單，全部數據項都填對了纔算對，任意一個錯了就算錯，而後畫出這樣一個對象圖：



2. 雖然一個考覈指標定義了多個過錯行爲，但它把全部執法行爲分爲多個類型，每一個類型的執法行爲只對應一個過錯行爲，這個過錯行爲對就是對，錯就是錯：



3. 最後一種就是那些限期完成的考覈指標，正確的行爲只有一個：按時完成的行爲，過錯行爲卻有兩個：逾期完成與逾期未完成。



雖然圖形有些複雜，但這正是表明了現實世界業務的複雜性。咱們拿着這些圖與客戶進行了簡單的描述，因爲圖中的全部元素都是用客戶熟悉的術語描述的，所以他們很快就可以理解。同時，開發人員拿到這樣一個圖，很快就制訂了四套不一樣的方案，來分別解決四種不一樣的狀況。

隨後，在對這四種狀況更加深刻的分析時，咱們發現第一種狀況在計算過錯數時彷佛有一些問題。在第一種狀況中，一個執法行爲包含了多個過錯行爲，若是出現了過錯，過錯數算幾？假如一個執法行爲包含三個過錯行爲，若是都作對了，分子數算1；但假若有2個過錯行爲錯了，過錯數算2？還有那一個正確的行爲呢？這彷佛有些矛盾！當咱們向業務人員提出這個問題時，他也有些懵了，這樣的結果彷佛是咱們雙方都沒有預料到的。通過反覆的思考與討論，最後咱們作出這樣的決定：將原有的過錯數拆分紅過錯戶與過錯數。在以上狀況中，若是一個執法行爲有2個過錯行爲錯了，過錯戶爲1，過錯數爲2。試想，若是不對需求進行如此深刻分析與理解，能發現這樣的問題嗎？若是不及早發現這樣的問題，是否會給項目後期帶來巨大的風險？

應該說，從最初的粗淺認識，深刻到後來對四種狀況的認識，正是體現了DDD的另外一個思想：持續學習。需求人員在開始一個新的管理系統的分析工做時，都有可能面臨着一個全新的業務領域。在這個領域中，他們不可能一晚上成爲專家，也沒必要要成爲專家。他們須要時間去學習領域知識，但這並不意味着學習全部的領域知識，而是與軟件相關的領域知識。作財務軟件，你沒必要考財務師，但你必需要學會與財務軟件相關的財務知識。你對領域模型的認識被延伸到了整個軟件生命週期中，包括以後一次一次的升級完善。你每認識深刻一點兒，就可能會體現到你的分析設計中，並最終體如今開發的軟件中。你對領域知識認識再深刻一點兒，軟件就再完善一分。

  16.非功能需求

簡單概括爲「URPS+」，便可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而這5部分咱們能夠進一步細化。

可用性是一個很是寬泛的概念，它泛指那些能讓用戶順利使用系統的指標，包括易用性（易操做、易理解）、準確性、安全性（權限體系、訪問限制）、兼容性（服務器、客戶端的兼容度），等等。

可靠性就是系統能夠可靠運行，包括系統成熟度（數據吞吐量、併發用戶量、連續不停機性能等）、數據容錯度、系統易恢復性，等等。

性能，我認爲是需求分析階段最主要的分析內容。用戶對性能的要求沒有止境，但現實倒是殘酷的。性能受到許多因素的影響，包括業務需求、軟件設計、數據庫設計、系統部署方式，等等。其中，業務需求和部署方式，對性能的影響是最大的，咱們必須在需求分析階段就想清楚，解決掉。有一次，客戶提出了一個數據導出的功能，這看似一個很是普通的功能。可是通過仔細地分析咱們發現，客戶在執行數據導出前的查詢時，若是選擇時間跨度數年，查出的數據量可能達到數十萬。要將數十萬數據一次性地導入到一個excel文件中，這不論從運行效率、系統穩定性，仍是技術可行性分析都是不可取的。最後，咱們通過與客戶的協商，一次性導出數據最大不超過2萬，同時提供了分頁導出的功能，可讓他們選擇導出從第幾頁到第幾頁的數據。這樣，若是數據量大，客戶能夠通過屢次將數據導出，數據導出的性能得以保證。

系統部署架構對性能的影響也是巨大的。一個管理系統，是市級集中，仍是省級集中，甚至全國集中，對性能的考量是不同的。市級集中不會過於擔憂性能的問題；省級集中就必需要考量併發訪問量，是否要創建集羣；全國集中就必須考量是否使用消息隊列，全部流程是否有性能瓶頸，以及採用什麼技術架構更適於併發訪問等等。而這一切都是系統架構師應當考量的內容。

最後一個內容，也是最容易被忽略的一個內容，就是可支持性。可支持性，就是軟件的可維護性、易變動性。可支持性對於客戶是透明的，不可見的，所以客戶一般不關心這個。因爲時間緊、人員素質良莠不齊，這部分也經常爲管理者所忽略。但試問，誰沒有維護糟糕系統的痛苦經歷？誰們的系統維護了數年通過數次升級後還能維護？在需求分析與設計階段，可支持性實際上體如今，咱們是否能有效識別系統可變的需求，並可以提供合理的方案。這體現的也是架構師的功底。一次分析和設計ERP軟件的時候，我發現應付單須要生成憑證，隨後又發現應收單、採購單、銷售發票都要生成憑證。既然這麼多單據須要生成憑證，是否還有其它咱們還不知道的單據也要生成憑證，是否能夠有一個統一的接口。果不其然，覈銷單、工資單、固定資產覈定都須要生成憑證。最後咱們設計成了一個統一的生成憑證接口。還有一次，咱們發現客戶報表在查詢SQL、過濾條件、顯示列等部分常常變，所以設計成一套可配置的報表系統，大大提升了系統可維護性。

  17.需求列表

需求列表，又稱之爲需求跟蹤表，是最原始的、用戶對業務需求的描述。它不摻雜任何需求分析人員對業務需求的分析與設計，而是以簡短扼要的語句，以業務人員的口吻表述的，從此要開發的這個系統應當提供給他們的各項功能。

首先，需求列表不摻雜咱們對業務需求的任何分析與設計，這是需求列表的核心，也是它存在的意義。從用例模型到領域模型咱們不難發現，它是一個分析與設計的過程。需求分析員對業務需求進行捕獲、認識、理解之後，須要結合軟件專業知識進行分析設計，還要聽取系統架構師和設計師對需求可行性的分析，最後才整理和編寫出用例模型。在這樣一個過程當中，隨着業務需求複雜度的提升，以及各類技術分析的摻雜，最終的結果頗有可能偏離原有的業務需求。這種偏離經常表現爲對業務需求正確性與完整性的偏離，即需求已經變味兒了，或者某些需求項目缺失。需求列表就是那個最開初的、最完整的、正確的業務需求。用這樣一個列表來開始咱們的分析，最後用它來驗證咱們的設計，使之成爲咱們的分析設計之旅樹立的一個正確的航標。有了這樣一個航標，就可使咱們最終可以到達一個正確的彼岸。

其次，需求列表應當是站在業務人員的視角，對業務需求的簡明扼要的描述。一個紛繁複雜的、業務龐大的管理系統，通過整理之後，被分解成一個一個的需求項目。每一個需求項目是一句簡明扼要的話。簡明扼要意味着清晰易懂；分解成需求項目意味着分解複雜問題爲簡單問題。每一次與業務人員討論完業務需求之後，咱們就整理成這樣一個需求列表，使咱們與客戶的討論都有一個清晰明瞭的討論結果。當下一次與業務人員討論時，咱們拿出咱們上一次討論的需求列表，又使下一次的討論有一個基點，使業務討論能以演進的方式推動下去，提升咱們的工做效率。

然而，需求列表中應當剔除那些客戶對系統設計的內容。前面咱們提到，客戶，特別是那些對信息化建設有必定經驗的客戶，容易提一些對系統設計的指望，好比什麼功能應當作成什麼樣子，功能界面是怎樣的。客戶提的這些意見，也許不是最佳的，咱們通過深刻的分析設計之後，可能會提出一些更加合理的方案。所以，這樣內容不能成爲咱們驗證系統功能的基石，於是不該當寫入需求列表中。需求列表描述的更應當是客戶對軟件功能的意圖，即客戶使用這個功能所達到的目的，而不是功能的具體實現。這一點咱們在後面經過具體實例詳細說明。

  18.一個需求列表的實例

這是一個公司內部的評審系統，它分爲制訂評審計劃、執行評審、製做評審報告與問題跟蹤四部分。通過初次與評審人員的業務討論之後，咱們整理出這樣一個需求列表：

1．評審發起人填寫一份評審計劃，詳細記錄評審時間、評審內容、評審者、評審地點，制訂評審組長，並預計評審工做量，發起一個評審任務。
2．評審者在收到郵件後，進入評審任務中，對評審內容進行評審，同時填寫並提交各自的評審意見。
3．評審組長彙總全部的評審意見，並在評審會上依次過全部的評審意見，對評審意見進行修改或刪除，填寫問題跟蹤，造成這次評審會上最終的評審意見及問題跟蹤表。
4．評審組長製做評審報告，並造成評審結論，以郵件的形式通知全部評審者。
5．全部評審者對評審報告進行回覆意見，若是都選擇贊成，評審組長關閉這次評審。
6．評審組長跟蹤全部問題，並能夠依次關閉每一個問題。

固然，在這個需求列表中，客戶提出了一些名詞，好比評審計劃、評審意見、評審組長等。咱們在整理需求列表的同時，應當注意整理這些名稱，弄清它的內涵外延，以及它們相互之間的關係、做用。這將爲咱們後面的領域模型分析提供素材。毫無疑問，這樣的需求列表過於粗略。於是在後面的業務討論中，咱們逐項對它們進行了細化：

1．評審發起人填寫一份評審計劃，詳細記錄評審時間、評審內容、評審者、評審地點，制訂評審組長，並預計評審工做量，發起一個評審任務。
1.1 評審時間應當分爲數個階段分別制訂時間計劃，如評審準備、評審會議、評審報告；
1.2 評審內容應當能夠上傳數個文件，分別描述文件的內容、做者、編寫日期、版本號，供評審者下載與查看；
1.3 填寫評審者時，選擇一個評審者爲評審組長，評審發起人不能是評審組長；
1.4 評審地點與預計評審工做量只需直接填寫；

在咱們後面的用例分析中，咱們對這段需求列表進行了大量的分析設計。但這些都是設計與實現，它們會出如今後面的用例分析及其模型中，卻不該出如今需求列表中。在後來的升級開發中，客戶又提出了發郵件通知的功能。將該功能描述出來，並添加到需求列表中：

1.5 評審計劃提交之後，以郵件的形式發送給每一個評審者，通知該評審任務。

有了這樣的需求列表，當需求分析工做完成時，咱們將一項一項檢查用例模型是否知足需求列表的內容；當軟件開發完成時，咱們將一項一項檢查軟件功能是否知足需求列表的內容；當用戶驗收時，咱們一樣使用需求列表，一項一項檢查咱們的軟件是否知足用戶需求。

  19.快速原型法

咱們就應當在需求分析階段拿出實物，用實物與用戶確認需求，這就是快速原型法的基本思想。快速原型法，簡稱原型法（Prototyping），是20世紀80年代提出的一種從設計思想、工具、手段都全新的系統開發方法。它摒棄了那種一步步周密細緻地調查分析，而後逐步整理出文字檔案，設計開發，最後才能讓用戶看到軟件結果的繁瑣做法。當咱們捕獲了一批業務需求之後，就當即使用快速可視化工具開發出一個原型，交給用戶去試用、補充和修改。再提出一些新的需求之後，再開發一版新的原型。原型法的關鍵就是這個快速開發。不用考慮性能、美觀、可靠，原型的目的就是模擬客戶的需求，與客戶進行確認的。整個需求分析的過程就是「捕獲需求->原型開發->確認需求->再捕獲需求」的過程。

原型開發的快速與模擬到什麼程度，是一對矛盾，咱們要去把握。要快速開發，必然不可能和最終交付的軟件系統如出一轍，許多複雜問題被簡化，非關鍵性流程被忽略，這就是所謂的模擬。所以，模擬到什麼程度是關鍵，既能說明問題，又不耽誤時間。根據個人經驗，通常能拿出界面，並能夠走通關鍵性流程就能夠了。一些快速開發平臺爲快速原型法提供了可能。

當用戶拿到原型能夠本身操做時，需求研討的氣氛當即變得不太同樣了。當用戶享受原型給他們帶來體驗的快感時，需求被源源不斷地被提出來。這時候的需求，就再也不是枯燥無味的文字遊戲，而是生動形象的圖形界面。往後，若是項目採用迭代開發，讓用戶看着軟件一點兒一點兒地成長，這又是多麼美妙的體驗啊。與此同時，你與用戶的信任也在一步一步創建起來，軟件風險在下降，項目將朝着正確方向前進。

快速原型法是美妙的，它給你與用戶帶來了從未有過的體驗。但美妙的同時，也會帶來一些的尷尬，沒必要要的誤會，咱們必定要注意。最多見的誤會就是讓用戶將原型誤覺得最終交付的系統。開發一個系統須要持續數月，但你倒好，幾天就搞定了，爲何還要在這個系統上投入大量資金呢？若是對方領導開始有這樣的想法時，雙方就開發費用進行的談判就有一些不妙了。因此在給用戶看到原型前，必定要跟用戶解釋清楚。

  20.需求規格說明書

理論上講，需求規格說明書（Requirement Specification）分爲用戶需求規格說明書和產品需求規格說明書。用戶需求規格說明書是站在用戶角度描述的系統業務需求，是用於與用戶簽字確認業務需求；產品需求規格說明書是站在開發人員角度描述的系統業務需求，是指導開發人員完成設計與開發的技術性文檔。可是，我認爲，用戶需求規格說明書與產品需求規格說明書的差異並不大。領域驅動設計所提倡的就是要讓用戶、需求分析員、開發人員站在一個平臺，使用統一的語言（一種混合語言），來表達你們都清楚明白的概念。從這個角度將，需求規格說明書就應當是一個，不區分用戶需求規格說明書和產品需求規格說明書。

那麼需求規格說明書怎麼寫呢？不一樣的公司、不一樣的人、不一樣的項目，特別是在需求分析中採用不一樣的方法，寫出來的需求規格說明書格式都是不同的。在這裏，我給你們一個，採用RUP統一建模的方式分析需求，編寫需求規格說明書的模板，供你們參考。

1．引言
1.1 編寫目的
如題，描述你編寫這篇文檔的目的和做用。但最關鍵的是，詳細說明哪些人可使用這篇文檔，作什麼。需求規格說明書是用來作什麼的？毫無疑問，首先供用戶與開發公司確認軟件開發的業務需求、功能範圍。其次呢，固然就是指導設計與開發人員設計開發系統。固然，還包括測試人員設計測試，技服人員編寫用戶手冊，以及其它相關人員熟悉系統。描述這些，能夠幫助讀者肯定，閱讀這篇文檔是否能夠從中得到幫助。

1.2 業務背景
描述業務背景，是爲了讀者瞭解與該文檔相關的人與事。你能夠羅列與文檔相關的各類事件，也能夠描寫與項目相關的企業現狀、問題分析與解決思路，以及觸發開發該項目的大背景、政策法規，等等。

1.3 項目目標（或任務概述）
就是項目能爲用戶帶來什麼利益，解決用戶什麼問題，或者說怎樣纔算項目成功。前面提到過，這部分對項目成功做用巨大。

1.4 參考資料
參考資料的名稱、做者、版本、編寫日期。

1.5 名詞定義
沒啥可說的，就是文檔中可能使用的各類術語或名詞的定義與約定，你們能夠根據須要刪減。

2．總體概述
這部分是對系統總體框架性地進行描述。

2.1 總體流程分析
繪製的總體行動圖，及其對它的說明。

2.2 總體用例分析
繪製的總體用例圖，以及對每一個用例的用例說明。若是項目比較大，存在多個子系統，能夠將用例圖改成構件圖，詳細描述每一個子系統及其相互的接口調用。

2.3 角色分析
一個用例圖，描述系統中全部的角色及其相互關係。在隨後的說明中，詳細說明每一個角色的定義及其做用。

這部分還能夠根據項目須要編寫其它的內容，如部署方案、網絡設備、功能結構、軟件架構、關鍵點難點技術方案，等等。

3．功能需求
3.1 功能模塊（子系統）
一個一個描述系統中的每一個功能模塊（或子系統），即總體用例分析中的每一個用例。這部分是需求規格說明書最主要的部分。

3.1.1 用例圖
繪製該模塊的用例圖（詳見《功能角色分析與用例圖》）。

3.1.2 用例說明
對用例圖中的每一個用例編寫用例說明（詳見《用例說明》）。

3.1.3 領域模型
爲用例繪製領域模型，並編寫領域模型說明，對每一個實體進行說明。對實體的說明包括對實體的定義、屬性說明、行爲說明、實體關係說明等等。若是實體間關係複雜，還要使用對象圖說明實體關係的全部狀況（如《領域驅動設計》中的描述）。

4．非功能需求
這裏描述的是軟件對非功能需求的通常要求，即總體設計原則。那些與具體功能相關的非功能需求應該放在用例說明的「非功能需求」部分（詳見《非功能需求》）。

5．接口需求
若是項目涉及到與外部系統的接口，則編寫這部分需求。
5.1 接口方案
詳細描述採用什麼體系結構與外部系統的接口。
5.2 接口定義
接口的中文名、英文名、功能描述、參數、返回值、使用者、使用頻率，等等。

  21.評審與簽名確認會

，用戶對需求的變動只發生在某些固定的範圍內，弄清楚了這些範圍，咱們的問題就迎刃而解了。

1. 總體需求不變，具體細節變化。咱們說需求是分層次的，總體框架、功能模塊、每一個操做的細節。若是用戶變動到了將整個框架都推翻了，這個項目就別作了。因此總體框架是必須在需求分析階段完成的，是往後不可能改變的。功能模塊可能要變，但一般是某個部分在變，而更多的是那些具體操做的細節在變。

2.  界面風格與操做易用性是最容易發生變動的。咱們說用戶看到軟件之後不滿意，其實主要是對界面風格與操做性不滿意，而不是軟件功能。界面不夠美觀，操做不方便，不符合用戶的操做習慣，都是形成用戶不滿意的地方。

3.  增長其它功能。軟件是對現實的模擬，而現實也是複雜多變的。咱們與用戶在進行業務流程分析時，也許一些流程沒有考慮到，或者還有特殊狀況須要處理。這些是客戶要求增長功能的主要動因。

通過以上分析，需求分析階段要作到什麼程度就能夠清楚了：總體框架與功能模塊必須肯定下來，至於各個功能模塊下的具體操做，儘可能作，能到什麼程度先到什麼程度。至於界面風格與操做性，咱們能夠在往後迭代開發的每一個迭代期，拿出樣品之後再與用戶確認。

OK，萬事俱備只欠東風，當全部工做都完備之後，咱們的需求分析工做開始進入最後收尾的階段。咱們說，需求分析階段的產出物是需求列表與需求規格說明書，而最終結束的里程碑無疑就是需求評審會了，或者說與用戶的簽字確認會。

需求評審會的主要目的就是確認需求，以便以此開始咱們的設計開發工做。從理論上說，需求評審會應當由用戶表明，與項目經理、需求分析員、系統架構師、設計人員、測試人員、QA經理，還有公司相關領導參加。但實際上，讓如此多不一樣角色的人彙集在一塊兒開會是不現實的。所以，咱們能夠將需求評審會分爲內部評審會與外部評審會兩部分來開比較現實。

處理外部問題，必先要從內部統一思想。先召開一個內部評審會，聽聽系統架構師、設計人員、測試人員、QA經理對需求分析工做的意見，而後由領導講講話，佈置一下後面的工做，是十分有必要的。按照個人經驗，系統架構師這時的做用至關重要，他應當仔細閱讀需求，仔細思考技術是否可行，以及預測該系統是否可以達到用戶方領導對該項目制訂的目標。若是答案是否認，當即進行調整。

最後就是與用戶的外部需求評審會了。外部需求評審會，也可稱爲簽字確認會議，就是與用戶就需求規格說明書進行評審，最後簽字確認。用戶簽過字的東西，不可能徹底抑制住用戶的變動，但至少從很大程度上抑制住了用戶的大改。然而，在召開外部需求評審會以前，咱們建議你們就需求規格說明書，先與各個單位或部門的用戶表明討論並肯定下來，避免在最終的簽字確認會上出現分歧，影響工做進度。畢竟你們都不容易，工做一大堆，聚在一塊兒不容易。

通過數月的分析討論，最終在一片和諧的氣氛中，雙方領導在需求規格說明書上簽字，項目開始進入一個新的輪迴。在這個輪迴中，是焦頭爛額、不勝其苦，仍是如履薄冰、最終順利交付，是與許多因素有關的。但我想說，一份高質量的需求分析一定起到決定性的做用，一定爲往後的軟件開發掃清了許多許多的地雷。

  最後，本文內容部分來自http://blog.csdn.net/yqmfly/article/details/7679781