?

關于我們怎樣做需求分析：

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

?

一、需求調研

初識：剛開始與客戶接觸的時候，一定要建立良好的職業微信。在對需求進行分析時，應分角色進行需求分析。并且從宏觀上制定目標與方案。

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

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

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

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

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

?

二、需求分析

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

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

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

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

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

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

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

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

非功能需求：非功能需求對于一個軟件的開發是很重要的，可以有效避免以后存在的風險。

?

三、需求確認

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

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

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

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

?

?

轉載于:https://www.cnblogs.com/xiaxiaoshu/p/7602632.html

總結

以上是生活随笔為你收集整理的阅读笔记一之《软件需求与分析》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。