閱讀筆記一之《軟體需求與分析》

本學期《軟體需求與分析》需要掌握需求調研、需求分析和需求確認三大基本內容。以下為針對每乙個內容的自己的理解。

一、需求調研

拜訪：「需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作（假如專案還有後期維護）。」在拜訪中，我們需要與客戶簡歷長期友好的關係。也一定要抱著相互尊重的態度與客戶交往，因為這個過程中不可避免的有一些阻礙專案進行的一些基層人員。還可以在其中找到一些可以幫助我們的人。

研討會：業務研討會是重要的，但同時又是靈活的，沒有乙個定式，甚至有時都不能稱之為會議。專案經理需要根據實際情況，合理地與客戶組織研討會。但不論怎樣組織，必須注意兩點：有效抑制個性化差異、分模組組織專項研討會。

需求研討：需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。

迭代：需求分析工作是乙個迭代的過程：需求捕獲->需求整理->需求驗證->再需求捕獲，需求捕獲是這個迭代過程的開始，也是整個需求分析工作中最重要的部分。每深入一步，我們的軟體就更接近客戶的滿意。所以，應該一點一步一步。

需求捕獲：還有兩類需求需要我們自己去挖掘：客戶嘴中沒有說出來的需求，和客戶壓根兒就沒有想到的需求。在真正開始這個專案的程式設計之前，可以先給客戶製作乙個模型來參考。

二、需求分析

功能角色分析與用例圖：繪製用例圖對業務需求進行分析、抽象、整理、提煉，進而形成抽象模型的過程稱之為用例建模，而這個模型就是用例模型。在畫用例圖的時候，應該盡可能的能使客戶看的懂。

業務流程分析：我們進行業務流程分析，是要分析業務流程中哪些是需要資訊化管理的，而哪些是不需要資訊化管理的。

用例說明：在對需求進行分析時，不能是空對空且不落到紙上。所以需進行用例說明。其中一些基本元素還是相同的。

查詢報表分析：乙個有效的報表往往會揭示一些客觀規律。每乙個報表都有它的主要意圖。報表作用體現的是報表對於不同使用者的真實意圖；輸出列體現的是對各個資料項及其資料**的說明；假設與約束羅列的是報表中各個資料項的運算公式、資料規則與約束；還有使用頻率、資料鏈結、非功能需求，以及最後的介面原型等。

子用例與擴充套件用例：子用例與擴充套件用例的學習，能夠幫助我們在後面的系統設計更好的復用，提高系統的內聚並降低了系統的耦合。

行**和狀態圖：行**和狀態圖能夠有效的對業務流程進行整體的描述（是與子用例與擴充套件用例相比），並且生動形象。注意「在需求分析中，狀態圖並不是必須的，它僅僅出現在你認為需要對某個物件的狀態進行說明的時候。」

業務領域分析：這是需求分析裡的最後一項工作，我們進行業務領域分析，是通過與使用者進行交流，掌握領域知識，繪製成業務領域模型，去指導我們軟體開發的過程。

原文分析法、領域驅動設計：原文分析法和領域驅動設計是指導我們的業務領域分析的兩種方法。原文分析發，是在用例說明與流程分析的基礎上進行的業務領域分析，是一項在需求研討會後整理和分析需求的工作。領域驅動設計（在我的理解）就是客戶與你之間形成一種統一語言，這種語言有助於兩者之間的交流。

非功能需求：非功能需求對於乙個軟體的開發是很重要的，可以有效避免以後存在的風險。

三、需求確認

需求列表：需求列表是用來記錄原始需求，以此來驗證最終的軟體。這樣使每一階段每乙個領域的需求分析都能夠很清楚，沒有變得越來越模糊。

快速原型法：快速原型法就是拿出乙個模型。並且在展示模型之前一定要先跟客戶說明情況，這並不是最終的軟體，也就是軟體不是一天兩天就能做出來的。

需求規格說明書：需求規格說明書要分兩種，一種是使用者需求規格說明書，另一種是產品需求規格說明書。需求規格說明書也是非常重要的，它提供了一種切實可行的解決方案。

評審與簽字確認會：需求評審會分為內部評審會與外部評審會兩部分，要分開進行。