軟體需求分析

需求分析也稱為軟體需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細緻的調研和分析，準確理解使用者和專案的功能、效能、可靠性等具體要求，將使用者非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。[1]

中文名需求分析

外文名requirement analysis

別稱

軟體需求分析

定義

通過分析，確定系統功能的過程

方法

功能分析法等

所屬學科

軟體工程

1 目標

2 原則

3 內容

4 過程

5 方法

6 特點

編輯需求分析是軟體計畫階段的重要活動，也是軟體生存週期中的乙個重要環節，該階段是分析系統在功能上需要「實現什麼」，而不是考慮如何去「實現」。需求分析的目標是把使用者對待開發軟體提出的「要求」或「需要」進行分析與整理，確認後形成描述完整、清晰與規範的文件，確定軟體需要實現哪些功能，完成哪些工作。此外，軟體的一些非功能性需求(如軟體效能、可靠性、響應時間、可擴充套件性等)，軟體設計的約束條件，執行時與其他軟體的關係等也是軟體需求分析的目標。[2] 編輯

為了促進軟體研發工作的規範化、科學化，軟體領域提出了許多軟體開發與說明的方法，如結構化方法、原型化法、物件導向方法等。這些方法有的很相似。在實際需求分析工作中．每一種需求分析方法部有獨特的思路和表示法，基本都適用下面的需求分析的基本原則。

(1)側重表達理解問題的資料域和功能域。對新系統程式處理的資料，其資料域包括資料流、資料內容和資料結構。而功能域則反映它們關係的控制處理資訊。

(2)需求問題應分解細化，建立問題層次結構。可將複雜問題按具體功能、效能等分解並逐層細化、逐一分析。

(3)建立分析模型。模型包括各種圖表，是對研究物件特徵的一種重要表達形式。通過邏輯檢視可給出目標功能和資訊處理間關係，而非實現細節。由系統執行及處理環境確定物理檢視，通過它確定處理功能和資料結構的實際表現形式。[1] 編輯

需求分析的內容是針對待開發軟體提供完整、清晰、具體的要求，確定軟體必須實現哪些任務。具體分為功能性需求、非功能性需求與設計約束三個方面。

1．功能性需求

功能性需求即軟體必須完成哪些事，必須實現哪些功能，以及為了向其使用者提供有用的功能所需執行的動作。功能性需求是軟體需求的主體。開發人員需要親自與使用者進行交流，核實使用者需求，從軟體幫助使用者完成事務的角度上充分描述外部行為，形成軟體需求規格說明書。

2．非功能性需求

作為對功能性需求的補充，軟體需求分析的內容中還應該包括一些非功能需求。主要包括軟體使用時對效能方面的要求、執行環境要求。軟體設計必須遵循的相關標準、規範、使用者介面設計的具體細節、未來可能的擴充方案等。

3．設計約束

一般也稱做設計限制條件，通常是對一些設汁或實現方案的約束說明。例如，要求待開發軟體必須使用oracle資料庫系統完成資料管理功能，執行時必須基於linux環境等。

編輯需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

問題識別：就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、效能需求(要達到什麼指標)、環境需求(如機型、作業系統等)、可靠性需求(不發生故障的概率）、安全保密需求、使用者介面需求、資源使用需求(軟體執行是所需的記憶體、cpu等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。

分析與綜合：逐步細化所有的軟體功能，找出系統各元素間的聯絡，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

編輯目前，軟體需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開發過程及特點出發，軟體開發一般採用軟體生存週期的開發方法，有時採用開發原型以幫助了解使用者需求。在軟體分析與設計時，自上而下由全域性出發全面規劃分析，然後逐步設計實現。

從系統分析出發，可將需求分析方法大致分為功能分解方法、結構化分析方法、資訊建模法和物件導向的分析方法。

(1)功能分解方法。

將新系統作為多功能模組的組合。各功能義可分解為若干子功能及介面，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能介面。

(2)結構化分析方法。

結構化分析方法是一種從問題空間到某種表示的對映方法，是結構化方法中重要且被普遍接受的表示系統，由資料流圖和資料詞典構成並表示。此分析法又稱為資料流法。其基本策略是跟蹤資料流，即研究問題域中資料流動方式及在各個環節上所進行的處理，從而發現資料流和加工。結構化分析可定義為資料流、資料處理或加工、資料儲存、端點、處理說明和資料字典。

(3)資訊建模方法。

它從資料角度對現實世界建立模型。大型軟體較複雜；很難直接對其分析和設計，常借助模型。模型是開發中常用工具，系統包括資料處理、事務管理和決策支援。實質上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、資訊模型、資料模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開發階段及開發層次一同建立的。建立系統常用的基本工具是e—r圖。經過改進後稱為資訊建模法，後來又發展為語義資料建模方法，並引入了許多物件導向的特點。

資訊建模可定義為實體或物件、屬性、關係、父型別/子型別和關聯物件。此方法的核心概念是實體和關係，基本工具是e-r圖，其基本要素由實體、屬性和聯絡構成。該方法的基本策略是從現實中找出實體，然後再用屬性進行描述。

(4)物件導向的分析力法。

物件導向的分析方法的關鍵是識別問題域內的物件，分析它們之間的關係，並建立三類模型，即物件模型、動態模型和功能模型。物件導向主要考慮類或物件、結構與連線、繼承和封裝、訊息通訊，只表示物件導向的分析中幾項最重要特徵。類的物件是對問題域中事物的完整對映，包括事物的資料特徵(即屬性)和行為特徵(即服務)。[1]

編輯需求分析的特點及難點，主要體現在以下幾個方面。

(1)確定問題難。主要原因：一是應用領域的複雜性及業務變化，難以具體確定；二是使用者需求所涉及的多因素引起的，比如執行環境和系統功能、效能、可靠性和介面等。

(2)需求時常變化。軟體的需求在整個軟體生存週期，常會隨著時間和業務而有所變化。有的使用者需求經常變化，一些企業可能正處在體制改革與企業重組的變動期和成長期，其企業需求不成熟、不穩定和不規範，致使需求具有動態性。

(3)交流難以達到共識。需求分析涉及的人事物及相關因素多，與使用者、業務專家、需求工程師和專案管理員等進行交流時，不同的背景知識、角色和角度等，使交流共識較難。

(4)獲取的需求難以達到完備與一致。由於不同人員對系統的要求認識不盡相同，所以對問題的表述不夠準確，各方面的需求還可能存在著矛盾。難以消除矛盾，形成完備和一致的定義。

(5)需求難以進行深入的分析與完善。需求理解對不全面準確的分析，客戶環境和業務流程的改變。市場趨勢的變化等。也會隨著分析、設計和實現而不斷深入完善，可能在最後重新修訂軟體需求。分析人員應認識到需求變化的必然性，並採取措施減少需求變更對軟體的影響。對必要的變更需求要經過認真評審、跟蹤和比較分析後才能實施

軟體需求分析

軟體需求分析

軟體需求分析

軟體需求分析

相關推薦