軟件需求分析(軟件需求分析報告范文)

軟件需求分析

需求分析就是對客戶提出的“要求”或者“需求”進行深入細致地調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什么，為系統設計、系統完善和系統維護提供依據。

需求分析是項目計劃階段非常重要的環節，該環節決定了需要“實現什么”，為下一步如何去“實現”提供了明確的方向。

進行需求分析需要做到以下幾點：

（一）需求獲取：在準備階段，我們首先要確定需求獲取的目標及范圍，根據你的目標來選擇對應的方式獲取需求。

（二）需求分類：一般情況下，我們會根據對象的不同，將需求分為業務需求、用戶需求、功能需求等。

（三）需求篩選：有些需求是偽需求，有些需求則不具備實現價值，我們可以通過真實性、價值性、可行性三個維度來篩選需求，過濾掉虛假的、不可行的、沒有價值、價值不大或投入產出比不理想的需求。

（四）需求提煉：對剩下的需求進行提煉，目的在于從獲取的表面需求中提煉出客戶的本質需求。找出“為什么要做”比“做什么”更重要。

（五）需求優先級排序：挖掘到客戶的真實目的后，我們需要根據不同維度的需求歸類方法，如KANO模型分析法、投入產出比ROI等，對其進行歸納整理并排出優先級，幫助產品有條理地安排開發秩序，避免盲目排序。

（六）產出需求文檔：通過以上的分析，我們需要將收集到的需求進行分析、匯總、歸類，輸出產出需求文檔，為接下來的工作做好鋪墊。

以上是對需求分析的一些理解和思路，做好需求分析工作之后，就可以對可實現的需求進行落地方案的跟進。

軟件需求的分析方法

軟件需求分析方法大體分為如下四類：結構化方法、面向對象方法、面向控制方法和面向數據方法。限于篇幅，將主要從結構化方法和面向對象方法以及RUP三個方面進行簡要的探討。 面向對象（Object Oriented, OO）的方法把分析建立在系統對象以及對象間交互的基礎之上，使得我們能以3個最基本的方法框架——對象及其屬性、分類結構和集合結構來定義和溝通需求。面向對象的問題分析模型從3個側面進行描述，即對象模型(對象的靜態結構)、動態模型(對象相互作用的順序)和功能模型(數據變換及功能依存關系)。需求工程的抽象原則、層次原則和分割原則同樣適用于面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分．每一級抽象都重復對象建模(對象識別)一動態建模(事件識別)一功能建模(操作識別)的過程，直到每一個對象實例在物理(程序編碼)上全部實現為止。
面向對象需求分析(OORA)利用一些基本概念來建立相應模型，以表達目標系統的不同側面。盡管不同的方法所采用的具體模型不盡相同，但都無外乎用如下五個基本模型來描述軟件需求：
整體—部分模型：該模型描述對象(類)是如何由簡單的對象（類）構成的。將一個復雜對象(類)描述成一個由交互作用的若干對象(類)構成的結構的能力是OO途徑的突出優點。該模型亦稱聚合模型。
分類模型：分類模型描述類之間的繼承關系。與聚合關系不同，它說明的是一個類可以繼承另一個或另一些類的成分，以實現類中成分的復用。
類—對象模型：分析過程必須描述屬于每個類的對象所具有的行為，這種行為描述的詳細程度可以根據具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以采用比較形式的途徑來精確地描述其輸入、輸出及其相應的類型甚至使用偽碼或小說明的形式來詳細刻畫。
對象交互模型：一個面向對象的系統模型必須描述其中對象的交互方法。如前所述，對象交互是通過消息傳遞來實現的。事實人對象交互也可看作是對象行為之間的引用關系。因此，對象交互模型就要刻畫對象之間的消息流。對應于不同的詳細程度，有不同的消息流描述分析，分析人員應根據具體館況而選擇。一般地，一個詳細的對象交互模型能夠說明對象之間的消息及其流向，并且同時說明該消息將激活的對象及行為。一個不太詳細的對象交互模型可以只說明對象之間有消息，并指明其流向即可。還有一種狀況就是介于此兩者之間。
狀態模型：在狀態模型中，把一個對象看作是一個有限狀態機，由一個狀態到另一狀態的轉變稱作狀態轉換。狀態模型將對象的行為描述成其不同狀態之間的通路。它也可以刻畫動態系統中對象的創建和廢除，并稱由對象的創建到對象的廢除狀態之間的退路為對象的生存期。
狀態模型既可以用狀態轉換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。 RUP（Rational Unified Process）是Rational公司開發和維護的過程產品。RUP是工程化的軟件開發過程，它提供了在開發機構中分派任務和責任的紀律化方法。RUP不僅僅是一個簡單的過程，而是一個通用的過程框架，可用于各種不同類型的軟件系統、各種不同的應用領域、各種不同類型的組織、各種不同的功能級別以及各種不同的項目規模。RUP的突出特點可以由以下三個關鍵詞來體現——用例驅動、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來指導迭代過程中的工作，而用例則確定了目標井驅動每次迭代的工作。
進行需求分析的基礎是要獲得用戶的需要，為了完成這一工作，必須建立業務模型，通過描述業務規則、業務邏輯，明確業務過程并對其進行規范、優化。對于一個系統，在建立業務模型時，應從3個方面來描述其特性：功能、行為、數據，對應于這些特性。 基于上述分析可知，結構化分析方法與面向對象分析方法的區別主要體現在兩個方面：
* 將系統分解成于系統的方式不同。前者將系統描述成一組交互作用的處理，后者則描述成一組交互作用的對象。
* 子系統之間的交互關系的描述方式不一樣。前者加工之間的交互是通過不太精確的數據流來表示的，而后者對象之間通過消息傳遞交互關系。
因此，面向對象軟件需求分析的結果能更好地刻畫現實世界，處理復雜問題，對象比過程更具有穩定性，便于維護與復用。

軟件需求分析4個步驟

一、需求分析理論

軟件需求涉及功能性問題非常廣，我們用抽象化理論分析，可以劃分各個功能域，用不同的數字代替，軟件——S，功能域——A1、A2……An

S＝{A1、A2、……An}

但是功能域B又存在若干問題P1、P2……Pm組成，并且每個功能對應于子系統中的一個軟構件，可以表示為-B＝{P1、P2、……Pm}

功能G有若干個行為F1、F2、……Fj，每個行為對應于軟件構件中的實現方法

G＝{F1、F2……Fj}

一個軟件包含了所有功能的集合，同時包含了實現所以功能的所有方法和算法描述。需求分析是依據用戶動機，經過需求問題識別，進行分析、消除分馳和綜合，編寫用戶故事，評審；形成用戶需求與設計同步，設計滿足用戶需求目標。

需求開發方法貫穿這個產品生命周期，利用不同的開發方法論進行挖掘需求，幫助用戶找到問題，梳理問題，判斷產品實現功能的正確性、一致性和完整性，促使用戶在軟件設計啟動之前進行周密的、全面的思考軟件產品功能，用商業化行為解決需求與現實中存在的矛盾，解決用戶需求與商業化產品功能融合，解決規范和個性化需求。
二、軟件需求開發的目標

1、對實現的軟件做一個全面的描述，幫助用戶找到問題矛盾解決用戶場景痛點，幫助用戶在進行產品規劃時做到周密，全面產品定位需求

2、了解和描述軟件實現所需的全部信息，為產品設計、確認和驗證提供一個基準

3、為軟件產品管理人員進行軟件產品成本評估和編輯軟件開發計劃書提供保障

需求開發-軟件功能需求、軟硬接口、非功能性需求、設計約束、反向需求、閱讀支持信息。

軟件需求分析盡量提供軟件實現功能需求的全部信息，使軟件設計人員和測試人員不在需要和需求方進行接觸，保證需求分析的一致性和完整性。

三、軟件功能需求

描述軟件功能實現注意——

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

2、功能描述的無異議和可追蹤

3、功能描述清洗和功能可測試

四、軟硬接口

1、人機接口

2、硬件接口

3、軟件接口

4、通訊接口
五、非功能性需求

1、運行環境

2、時間需求

3、處理容限、精度、異常處理機制等

4、可靠性要求、可維護性、安全性

軟件需求分析的內容是

需求分析也稱為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什么的過程。
需求分析的內容是針對待開發軟件提供完整、清晰、具體的要求，確定軟件必須實現哪些任務。具體分為功能性需求、非功能性需求與設計約束三個方面。
信管網致力于為廣大信管從業人員、愛好者、大學生提供專業、高質量的課程和服務，解決其考試證書、技能提升和就業的需求。
信管網軟考課程由信管網依托10年專業軟考教研傾力打造，官方教材參編作者和資深講師坐鎮，通過深研歷年考試出題規律與最新大綱，深挖核心知識與高頻考點，為學員考試保駕護航。面授、直播＆錄播，多種班型靈活學習，滿足不同學員考證需求，降低課程學習難度，使學習效果事半功倍。

如何進行軟件需求分析

何進行軟件需求分析，簡而言之不是幾句話可以描述清楚的，這里給你一些方法功能參考。

首先，在進行軟件需求分析之前，得有一份軟件說明書或者軟件需求規格說明書，因為這個是我們進行需求分析的對象。但是這個需求規格書寫的質量怎么樣，實際上是決定了軟件項目的進度、成本甚至成敗的？為什么這么說呢？因為當前軟件開發這個行業最大的問題是需求質量低下，這個導致了項目成本至少增加了30%以上，這也是為什么軟件這個行業有錢的公司不多的主要原因。或者說能做出一份有質量的需求規格說明書將體現這個企業的掙錢能力，但現實是絕大多數企業都像人月神話中描述的一樣：一步一步踏入了泥潭。。。由于這個工作產品如此重要，因此通過過個步驟來保證它的質量：需求策劃、獲取、分析、確認以及后期需求管理，尤其是變更管理。如果想了解具體的每個步驟的詳細內容可以聯系我。
其次，如果需求規格說明書有了，我們怎么分析呢？在具體說明分析方法之前，首先我們要明確一個問題：需求分析到底是在分析什么？其目的是什么？其實我們絕大多數的需求工程師都不太清楚或者不能明確的回答這些問題，從而導致他們花費了大量的時間來寫用例（ur ca），寫了很多關系復雜甚至連需求人員都看不明白或者越看越糊涂的東西，因為他們認為這樣后續的開發、測試人員就能開明白了，事實上是這樣的嗎？根本不是，如果是的話，我們的軟件行業中的絕大多數企業活的普遍不那么悲慘了。。。回到軟件開發，我們來想一下，我們開發這個東西給誰用？是自己嗎？？？如果是自己事情就簡單了，因為需求都在自己腦子里面了，就算不完整起碼也不會缺多少，但問題正好相反，99.999999%的情況下我們是為別人或者說我們的用戶開發的，也就是說需求其實是在客戶的腦子了，而不是我們的腦子里！！！我們的首要目的應該是如何通過一套完整的套路把需求從客戶的腦子里面傳輸到我們的腦子里面，然后按照規格化（這個是另外一個重點）的方式把它按照說明書一樣描述出來讓后續人員能夠看得清清楚楚、明明白白，這個步驟是最關鍵的一環，因為我們的絕大多數客戶都不會寫需求規格說明書，所以這個任務落在我們的身上。那么我們到底都問什么不會丟需求呢？這個是有一套方法和模板來指導需求人員和UI工程師（調研時就需要畫原型，可以稍微想一下這么做的好處）來獲取完整的需求。只有這樣，才能獲取有質量的需求。
那么說了這么多，分析到底是干什么的呢？分析就是需求人員首先自己要系統的檢查一下需求來保障需求的質量，記住不是保證，是保障，它就像軟件開發中的評審或測試一樣，是保障產品的質量進行的檢查活動，它們不能保證質量，只是保障作用。就像我們考試一樣，你認真的答完題了，還是需要認真的檢查一遍，因為這個是人的天性之一。那么問題來了，怎么進行檢查或者從哪些方面進行檢查呢？我推薦的策略是先外后內、先系統后模塊、先功能后非功能、先業務后屬性，通過整套方法下來可以幫我們查到不少之前遺漏、寫錯、或者矛盾的地方，當然也包括可能不是客戶需要的needs，只是expectation。這個工作比獲取要簡單一些，但是是一個繁雜的活，要逐項逐項的檢查每一個需求的內容以保障需求的質量。到底檢查哪些內容呢？這個太多了，就不羅列了。

如何進行軟件需求分析

軟件需求分析免費下載

鏈接:https://pan.baidu.com/s/1qNBwqvbRS5ziBSIeanLQAQ

提取碼:qoyw

需求分析也稱為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什么的過程。