原文連結(轉載請註明出處)：https://dmego.me/2017/09/29/good_demand_and_analysis.html

前言

這學期的《軟體需求與分析》課可以說是軟體工程專業比較重要的一門課。如何做好軟體需求分析就等同於如何做好一個專案。客戶對需求一改再改，如果我們只是一味的去抱怨，而不去思考客戶對需求更改的原因是什麼，不瞭解業務，那我們做出來的產品肯定得不到客戶的認可。
通過閱讀我們應當怎樣做需求分析這一系列的文章，我總結出來做好軟體需求分析需求從這幾方面入手。首先是做需求調研，就是採集需求這個階段，在這個階段其實是一個反覆迴圈的過程：需求捕獲——需求整理——需求驗證——再需求捕獲…；在每一次做完需求調研後就要做一次需求分析，並且等到下一次去做需求調研時，我們應該首先將上一次的需求分析結果與客戶進行確認。然而在每次的需求分析階段其實也是一個比較複雜的分析過程，我們需求畫大量的UML圖（例如用例圖），對角色功能進行分析，對業務流程進行分析等。最後我們還需要做好需求確認工作，寫好需求規格說明書然後評審簽字確認。

要點提煉

許多需求分析工作都是從需求調研開始的，需求調研工作既是一份技術活更是一份體力活。它要求我們具有一種理解能力，設計能力，更要求我們具有一種與人交往與溝通的能力。

開研討會捕獲需求

我們需求獲得客戶的需求，必須要了解業務，要想了解業務，一是可以學習相關的知識，最有效的方法就是開業務研討會，需求研討會等，在會上我們不但可以更好的和客戶交流整個流程，還可以討論一些比較細節的地方。但是在組織研討會的同時必須注意兩點：有效抑制個性化差異，分模組組織專項研討會。

學會需求捕獲

整個需求分析過程是一個迭代的過程，在需求捕獲這個階段，往往不是考驗我們的專業知識，而是涉及人際交往，溝通理解等方面。如果學會了如何捕獲客戶的需求，那我們的專案成功的概率就會得到質的飛躍。在學會捕獲需求之前我們要清楚的認識到軟體需求不僅僅是客戶嘴裡說出來的。還有兩類需求需要我們自己去發現：一是客戶嘴裡沒有說的需求，二是客戶壓根沒有想到的需求。知道這些後如果我們不能更好的處理與客戶交流的方式，那一切都是百搭，在與客戶討論需求過程中，態度決定一切，既不能讓自己處於被動狀態，對客戶提出的所有需求都記下來然後不加分析地給開發人員；也不能盲目主動，不分析客戶的需求，按照自己的想法來，最後交付的時候客戶說這不是自己想要的軟體。最明智的做法是先跟客戶談業務，先談論業務流程，在此階段我們還要多問為什麼，這樣可以讓我們深入地瞭解這些領域的知識，站在客戶的角度去思考問題，進而能夠深入理解客戶為什麼要提出他們的那些業務需求。

功能角色分析

當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來後我們就要對需求進行行之有效的分析，而這種分析首先應當從功能角色分析開始，所謂的功能角色分析就是從一個外部使用者的視角分析整個軟體系統能夠提供的功能，以及這些功能到底提供給那些角色使用。而對一個系統進行功能和角色方面的梳理和分析，可以採用畫用例圖的方法。運用這種方法對業務需求進行分析、抽象、整理、提煉進而形成用例模型。
我們在畫用例圖的過程中不能以一個開發者的角色來繪製，許多描述資訊也絕不能按照開發者的思維和習慣去寫，而是要貼近客戶，因為用例圖的視角是使用者。所以描述資訊應該迎合使用者平時的習慣用語。

業務流程分析

做好角色分析後，最重要的一步就是要做好業務流程分析。文章作者在這一章中用了許多例子來說明問題，在分析ERP對企業流程改進的例子中，作者分析出來的思路是清除低效環節、簡化業務瓶頸、整合可用資源，以及將繁瑣任務自動化。計算機資訊化管理並不是萬能的，它並不能代替現實世界中的所有工作。因此我們進行業務流程分析，就是要分析業務流程中哪些是需要資訊化管理的，而哪些則不需要。另外，業務流程分析的另一個重要的分析內容就是流程差異化分析。不同的領導有不同的思路，不同的單位有不同的情況。因此，我們在進行流程分析的時候，常常面臨流程差異化的問題。

業務領域分析

在需求分析工作中，最後一項分析工作就是業務領域分析啦。業務領域分析，就是對需求分析中涉及到的業務實體，以及它們相互之間關聯關係的分析。什麼叫業務領域，就是客戶所在的知識領域，譬如財務人員所在的是財務領域，稅務人員所在的是稅務領域。不同的知識領域擁有各自不同的領域知識，需求分析人員就應該通過客戶中的領域專家去學習這些知識、掌握這些要點，並最終體現在我們的需求分析中。我們進行業務領域分析，就是通過與使用者進行交流，掌握領域知識，然後繪製成業務領域模型，去指導我們軟體開發的過程。其中，我們可以通過兩種分析方法一步步進行分析：原文分析法與領域驅動設計。

挖掘非功能需求

需求分析人員最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技術，是設計，是實現，是架構師關注的內容，是需求人員最不擅長的方面，這也是非功能需求為什麼常常被忽略的重要原因。正因為如此，架構師應當儘早參與到專案中，參與到需求分析中，儘早分析需求的技術可行性，儘早考慮效能、安全性、可靠性等非功能需求，儘早開始架構設計。 非功能需求可以簡單歸納為“URPS+”，即可用性（Usability）、可靠性（Reliability）、效能（Performance）、可支援性（Supportability）以及其它（+）。，將我們分析出來的功能中所潛在的、特殊的非功能需求挖掘出來，提前進行分析設計，對於可行性不高的應及時與客戶商討，才能有效地避免日後存在的這些方面的風險。

做好需求列表

需求列表，又稱之為需求跟蹤表，是最原始的、使用者對業務需求的描述。它不摻雜任何需求分析人員對業務需求的分析與設計，而是以簡短扼要的語句，以業務人員的口吻表述的，今後要開發的這個系統應當提供給他們的各項功能。 首先，需求列表不摻雜我們對業務需求的任何分析與設計，這是需求列表的核心，也是它存在的意義。其次，需求列表應當是站在業務人員的視角，對業務需求的簡明扼要的描述。在需求列表中應當剔除那些客戶對系統設計的內容。最後，需求列表也不是一步到位的，而是經過由粗到細逐漸整理形成的。

寫好需求規格說明書

我們之所以要編寫自己的需求規格說明書，就是要本著實事求是、切實可行的態度，去描述使用者的業務需求。那些不可行的需求被摒棄，或者換成更加可行的解決方案。這就是需求規格說明書的重要作用。領域驅動設計所提倡的就是要讓使用者、需求分析員、開發人員站在一個平臺，使用統一的語言（一種混合語言），來表達大家都清楚明白的概念 。我們不能拿著使用者編寫的原始需求就開始開發，只有依據自己的公司、專案、特別是需求分析中採用的方法，寫出一份既是從使用者角度描述的系統業務需求說明書，又是一份指導開發人員完成設計與開發的技術性文件。

圖示