軟件需求分析方法

軟件需求分析（Software Reguirement Analysis）是研究用戶需求獲得的東西，徹底理解用戶對軟件需求的完整功能，確認用戶軟件功能需求，創建可確認的、可驗證的一個基本依據。

軟件需求分析是一個項目的開端，也是項目實施最重要的關鍵點。據有關的機構分析結果代表，咱們設計的軟件產品存在不完整性、不正確性等問題80％以上是需求分析錯誤所致使的，並且因爲需求分析錯誤形成根本性的功能問題尤其突出。所以，一個項目的成功軟件需求分析是關鍵的一步。

1、 軟件需求分析理論

若是咱們用數學方法來描述軟件需求分析，能夠將一個應用軟件定義爲S，可能應用軟件涉及功能性問題很是廣，咱們用抽象化理論分析，能夠劃分爲各個功能域，能夠用D一、D二、… Dn表示，那麼，咱們能夠用一個表達式描述爲

S={D1，D2，D3，…Dn}
可是，功能域Di依然存在着有若干個問題P一、P二、P三、… Pm組成，而且每一個功能對應於子系統中的一個軟構件，咱們能夠表示爲
     Di={P1，P2，P3，…Pm}
一樣，功能Pj有若干個行爲F一、F二、F三、… Fk，每一個行爲對應於軟構件中的實現方法

Pj={F1，F2，F3，…Fk}

一個軟件包含了全部功能的集合，同時包含了實現全部功能的全部方法和算法描述。需求分析是依據於用戶需求，通過需求問題識別，進行分析、消化與綜合，制訂規格說明，評審，分爲四個階段，造成用戶需求與設計同步，設計知足用戶需求目標。

需求分析方法始終貫穿着吸取、同化、貫徹方法和手段，用商業化行爲解決需求與實現中存在的矛盾，解決用戶需求與商業化產品融通，解決規範與個性化追求。

2、 軟件需求分析目標

軟件需求分析的主要實現目標：

1）對實現軟件的功能作全面的描述，幫助用戶判斷實現功能的正確性、一致性和完整 性，促使用戶在軟件設計啓動以前周密地、全面地思考軟件需求；

2）瞭解和描述軟件實現所需的所有信息，爲軟件設計、確認和驗證提供一個基準；

3）爲軟件管理人員進行軟件成本計價和編制軟件開發計劃書提供依據；

需求分析的具體內容能夠概括爲六個方面：軟件的功能需求，軟件與硬件或其餘外部系統接口，軟件的非功能性需求，軟件的反向需求，軟件設計和實現上的限制，閱讀支持信息。

軟件需求分析應儘可能提供軟件實現功能需求的所有信息，使得軟件設計人員和軟件測試人員再也不須要需求方的接觸。這就要求軟件需求分析內容應正確、完整、一致和可驗證。此外，爲保證軟件設計質量，便於軟件功能的休整和驗證，軟件需求表達無岔意性，具備可追蹤性和可修改性。

2.一、      軟件功能需求

軟件的功能需求是整個需求分析最主要、最關鍵和最複雜的部分，它描述軟件的各類可能的條件下，對全部可能輸入的數據信息，應完成那些具體功能，產生什麼樣的輸出。描述軟件功能需求是應注意下面幾點：

1）功能需求的完整性和一致性

對功能的描述應包含與功能相關的信息，並應具備內在的一致性（即各類描述之間不矛盾、不衝突）。應注意如下幾點：

（1）    給出觸發功能的各類條件（如：控制流、運行狀態、運行模式等）；

（2）    定義各類可能性條件下的全部可能的輸入（包括合法的輸入空間和非法的輸入空間）；

（3）    給出各類功能間可能的相互關係（如各個功能間的控制流、數據流、信息流，功能運行關係：順序、重複、選擇、併發、同步）；

（4）    給出功能性的主要級別（如：基本功能、可由設計者選擇逐步實現的功能、可由設計者改變實現的功能等）；

（5）    儘量不使用「待定」這樣的詞。全部含有待定內容的需求都不是完整的文件，若是出現待定的部分，必須進行待定部份內容說明，落實負責人員、落實實施日期。

2）功能描述的無岔意性和可追蹤性

需求功能描述的無岔意性、可追蹤性和規範化：

（1）    功能描述必須清晰地描述出怎樣輸入到怎樣輸出，而且輸入、輸出描述應對應有數據流描述、控制流描述圖，這些描述必須與其它地方描述一致；

（2）    能夠用語言、方程式、決策表、矩陣或圖等對功能的描述。若是選用語言描述必須使用結構化的語言，描述前必須說明該步驟（或子功能）的執行是順序，選擇，重複，仍是併發，而後說明步驟邏輯。整個描述必須單入單出。

（3）    描述時，每個功能名稱和參照編號必須惟一，且不要將多個功能混在一塊兒進行描述，這樣便於功能的追蹤和修改。

（4）    功能描述應注意需求說明和程序設計的區別。需求設計僅僅是軟件的功能設計，它給出軟件運行的的外部功能描述，以及爲了實現這一外部功能必須作哪些事情（採用和種數據結構，定義多個模塊，接口間的接口等）是設計階段的事情，功能描述不該涉及到那些細節問題，以免給軟件設計帶來沒必要要的約束。

2.二、      軟件與硬件或其餘外部系統接口

軟件與硬件或其它外部系統接口包括下述內容：

（1）    人機接口：說明輸入、輸出的內容、屏幕安排、格式等要求；

（2）    硬件接口：說明端口號，指令集，輸入輸出信號的內容與數據類型，初始化信號源，傳輸通道號和信號處理方式。

（3）    軟件接口：說明軟件的名稱、助記符、規格說明、版本號和來源；

（4）    通信接口：指定通信接口和通信協議等描述。

2.三、      軟件的非功能性需求

軟件非功能性需求是指軟件性能指標，容限等功能之外的需求。通常指下述內容：

（1）    時間需求：輸入、輸出頻率，輸入、輸出響應時間，各類功能恢復時間等；

（2）    處理容限、精度、採樣參數的分辨率，偏差處理等；

（3）    可靠性的MTBF要求，可維護性、安全性要求等。（對可能的不正常的輸入給以正常響應是可靠性的重要內容，這屬於功能性需求。）

2.四、      軟件反向需求

軟件的反向需求描述軟件在那些狀況下不能作什麼。這一條是隨軟件實際要求而定。有兩類情形須要採用反向需求的形式。第一種狀況：某些用戶需求適宜採用反向形式說明，如數據安全性要求屬於這類形式。第二種狀況：對一些可靠性和安全性要求較高的軟件，有些必須描述軟件不能作些什麼。如控制點火時序，咱們必須交代清楚在那些狀況下不能點火，不然會形成故障。

2.五、      軟件設計和實現上的限制

軟件設計和實現上的限制主要指對軟件設計者的限制。如軟件運行環境的限制（選擇計算機類型，使用配置，操做系統的限制等）、設計工具的限制（使用語言、執行的標準）和保密要求等。

2.六、      閱讀支持信息

這部份內容是爲了更好的幫助咱們理解用戶需求，也是爲了使需求便於修改和追蹤。其自己並非對需求的描述，但它影響到需求分析的可讀性，也屬於需求分析的一個重要部分。通常目錄、需求背景信息、內容索引、交叉引用表、註釋等均屬於這個部分的內容。

3、 軟件需求分析人員組織

軟件需求分析其根本性問題是理解用戶功能需求，由此軟件需求分析其實是與客戶間交流過程完成的目標。要求咱們組織適當的參與人員進行交流活動。

需求分析是一個綜合團隊的工做，是在需求分析理論的指導下，對用戶須要進行漸進方式逐步深化；經過不斷變化方式造成具體約束；努力實現需求功能目標造成特點效果的商業化產品。需求分析是一個商業行爲，徹底是一個商業化操做，要求有商業、技術等結合的團隊共同合做，解決需求和設計的同步，設計符合需求。

項目涉及內容，項目大小都須要咱們考慮參加軟件需求分析工做團退的人數，配置合理的參與人員。通常咱們必須有商務活動人員，項目管理人員，設計技術人員等參加，並且要求組織人員必須明確負責範圍，以及明確工做目標，保證明施的有效性。

4、 軟件需求分析方法

爲了保證項目的正常實施，而且可以順利的完成，咱們必須增強項目管理和重視項目分析工做。咱們只有從實際出發，切切實實地把握用戶需求，把握用戶需求目標，把握用戶未來功能界定，保證咱們開發工做正確性方向。

4.1、重點監控軟件需求分析辦法

因爲軟件項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟件需求分析的重要性是不言而喻的，同時需求分析又的的確確難作。其緣由基本是因爲如下狀況形成的。

4.1.1、客戶說不清楚需求

有些客戶對需求只有朦朧的感受，固然說不清楚具體的需求。例如全國各地的不少部門、機構、單位在進行應用系統以及網絡建設時，客戶方的辦公人員大多不清楚計算機網絡有什麼用，更缺少IT系統建設方面的專家和知識。此時，用戶就會要求軟件系統分析人員替他們設想需求。工程的需求存在必定的主觀性，爲項目將來建設埋下了潛在的風險。

4.1.2、需求自身常常變更

根據以往的歷史經驗，隨着客戶方對信息化建設的認識和本身業務水平的提升，他們會在不一樣的階段和時期對項目的需求提出新的要求和需求變動。事實上，歷史上沒有一個軟件的需求改動少於三次的！因此必須接受「需求會變更」這個事實，在進行需求分析時要懂得防患於未然，儘量地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟件的核心建築在穩定的需求上，同時留出變動空間。諮詢監理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，因此也必須積極參與到需求分析的準備中來，以便協助客戶方和承建方來界定「作什麼」、「不作什麼」的系統功能界限。

4．1．三、分析人員或客戶理解有誤

軟件系統分析人員不可能都是全才，更不多是行業方面的專家。客戶表達的需求，不一樣的分析人員可能有不一樣的理解。若是分析人員理解錯了，可能會致使之後的開發工做勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：「主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜裏能射出強光……有趣的是，車裏住着一種叫做‘人’的寄生蟲，這些寄生蟲徹底控制了車。」因此分析人員知識的專注性也會形成需求分析的誤解和失敗。這時，諮詢監理公司就必須根據實際的項目需求調研計劃，提醒承建方增強業務瞭解程度和注重溝通技巧。

4.2、有效性軟件需求分析三步法

根據以往的工程經驗，需求分析工做方法，應該定位在「三個階段」（也稱「三步法」）。

4.2.1、「訪談式Visitation」階段

這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，瞭解現有的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體狀況、客觀的信息。創建起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的接口人。

實現手段：訪談、調查表格

輸出成果：調查報告、業務流程報告

4.2.2、「誘導式Inducement」階段

這一階段是在承建方已經瞭解了具體用戶方的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬件、軟件實現方案，作出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶採用誘導式、啓發式的調研方法和手段，和用戶一塊兒探討業務流程設計的合理性、準確性、便易性、習慣性。用戶能夠操做簡單演示的DEMO，來感覺一下整個業務流程的設計合理性、準確性等等問題，及時地提出改進意見和方法。

實現手段：拜訪（誘導）、原型演示

輸出成果：調研分析報告、原型反饋報告、業務流程報告

4.2.3、「確認式Afirm」階段

這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，並能清晰地向用戶描述系統的業務流設計目標。用戶方能夠經過審查業務流程報告、數據項表以及操做承建方提供的DEMO系統，來提出反饋意見，並對已經可接受的報告、文檔簽字確認。

實現手段：拜訪（回顧、確認），提交業務流程報告、數據項表；原型演示系統

輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（後三者能夠統一納入需求分析報告中，提交用戶方、監理方進行確認和存檔）

總體來說，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和採用，對用戶和承建方都一樣提供了項目成功的保證。固然在系統建設的過程當中，特別在採用迭代法的開發模式時，需求分析的工做需一直進行下去，而在後期的需求改進中，工做則基本集中在後兩個階段中。

5、 軟件需求分析工具

咱們根據用戶需求，經過反覆討論、分析，最終明確一個惟一性的用戶需求，這個結果其實就是咱們的軟件需求分析報告。通常咱們採用Word、PowerPoint、Visio、ProntPage、Excel等Office工具，同時可能採用一些開發工具，如VC或BC等，一樣也會使用一些圖形工具，如Potoshop、調色板等畫圖工具。

使用各類工具表達軟件需求分析，其具體表達手段能夠分爲：

l        效果圖描述。主要是用戶UI界面的描述反映用戶需求功能；

l        邏輯圖描述。根據用戶需求功能，使用抽象化理論，以及需求分析理論，對用戶需求功能進行全面的分析，創建功能性邏輯關係圖，流程邏輯關係圖等；

l        關係圖表描述。主要是對信息關係、數據庫表格、接口函數等描述；

l        工程數學描述。分析用戶需求，分析用戶需求信息，運用工程數學進行算法推導，進行合理化需求分析推導；

l        甘地圖描述。主要是軟件項目工做安排，開發週期預估；

l        其它方法描述。保證完整性合理性的有效描述。

6、 軟件需求分析評估

軟件需求分析評估是爲了檢查咱們進行軟件需求分析工做，保證軟件需求分析工做正確性、完整性、有效性、合理性、可確認性、可實施性，徹底保證用戶所需求的功能。

6.一、組織結構與責任管理

咱們對組織結構與責任管理的評估主要有：參與人員任務和責任界面的明確；安排計劃按時完成情況；相互間的協調能力情況。

6.二、知足用戶需求的功能

咱們進行需求分析的目的是完整、準確地描述用戶的需求，跟蹤用戶需求的變化，將用戶的需求準確地反映到系統的分析和設計中，並使系統的分析、設計和用戶的需求保持一致。

需求分析的特色是需求的完整性、一致性和可追溯性。完整性：是準確、全面的描述用戶的需求。一致性：是經過分析整理，剔除用戶需求矛盾的方面，規範用戶需求。可追溯性：有兩個方面的含義，整理和規範的需求，其一，須要不斷的和用戶進一步交流，保持和用戶最新的需求一致。其二，和系統分析（設計）保持一致。

所以在需求分析以前咱們必須創建需求分析技術層面的基本框架，從技術上保證需求分析的要求，在此基礎上咱們進行的需求分析才能知足項目對需求分析的要求。

6.三、保證可實施性

咱們必須以用戶軟件需求爲依據，以求實的態度詳細的、準確的、完整的編寫軟件需求分析，避免空想世界，空中樓閣的想法；避免無邏輯性、無核心的描述；避免無量化思惟，無實際空間概念。

6.四、需求分析評價指標

主要有這麼幾個指標：功能性、完整性、正確性、邏輯性、表現性、合理性，可實施性等。

6.五、工做週期

評價人員投入，以及費用支出的合理性問題。正確制定工做週期，保證軟件項目的順利完成。

6.六、需求不肯定更改與可確認保證

可確認需求功能是實現用戶需求的基本保證，若是不可確認的、不肯定更改存在，將會阻礙軟件實現，或者軟件設計存在着不完整性缺陷，或者存在着不可實施性問題，咱們必須區分是功能性障礙問題，仍是將來性問題。若是不可以明確是將來性問題，則必須調整功能需求，化解不肯定更改的問題。所以，判斷不肯定性更改是一個很是重要的問題