《咱們應當怎樣作需求分析》閱讀筆記

原文連接（轉載請註明出處）：如何作好需求分析

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

通過閱讀與思考，我認爲如下內容咱們須要掌握的：

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

（1）開研討會捕獲需求

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

（2）學會需求捕獲

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

（3）功能角色分析

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

（4）業務流程分析

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

（5）業務領域分析

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

（6）挖掘非功能需求

需求分析人員最容易忽略的部分就是非功能需求。非功能需求更加靠近的是技術，是設計，是實現，是架構師關注的內容，是需求人員最不擅長的方面，這也是非功能需求爲何經常被忽略的重要緣由。正由於如此，架構師應當儘早參與到項目中，參與到需求分析中，儘早分析需求的技術可行性，儘早考慮性能、安全性、可靠性等非功能需求，儘早開始架構設計。 非功能需求能夠簡單概括爲「URPS+」，便可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。，將咱們分析出來的功能中所潛在的、特殊的非功能需求挖掘出來，提早進行分析設計，對於可行性不高的應及時與客戶商討，纔能有效地避免往後存在的這些方面的風險。

（7）作好需求列表

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

（8）寫好需求規格說明書

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

圖示：