如何寫需求分析說明書?

General 更新 2024-12-26

軟件需求說明怎麼寫

如何寫需求分析報告（軟件需求說明書GB856T-88）

近來學校的一些科研項目又在申報了，一些學弟開始Q我一些軟件工程上書面的問題。大概的總結了下，寫到這裡。本文涉及到的是需求分析部分的書寫，主要是根據國家標準文檔中的要求來的。

在互聯網公司或者一些敏捷開發的公司裡，其實大家都是秉承著重開發，重討論，而輕文檔的態度。這個輕文檔並不是指沒有文檔或者幾乎不做文檔，而是在嚴格的文檔流程中解脫出來，只把最最實際的部分寫出來。這個特徵是有互聯網本身迭代週期短，版本發佈快等特點決定的。而在實際的兼職項目的時候，同學們就要注意了，最重要的應該就是在籤合同的時候一定要附上最清楚的一份需求分析，雖然這份需求說明可能不是按照某些標準文檔而來的，描述清楚每個功能達到的效果，而這個效果一定要讓客戶點頭確認，而不能出現“應該是”、“可能是”、“也許是”這樣的模糊回答。否則在項目後期就會比較難過了。在學校申請的項目和大型公司項目開發中，是重視文檔流程的，一部一部來。所以還是看情況來對待文檔的深度和標準。

一、目錄：目錄要用word的 “引用”—>”目錄”，自動生成目錄，一般都是要三級目錄。通常這部分基本都不需要改結構，直接更新頁碼即可。

二、內容部分。國家標準軟件需求說明書G856T-88下載

1引言

1.1編寫目的

說明編寫這份軟件需求說明書的目的，指出預期的讀者。

（這部分說明需求分析報告的概況，例如：本X需求分析報告是為S系統而編寫的。+S系統的兩句話概述。+本X報告旨在使U1（需求者）明確S系統的要求和細節，給U2(開發人員)瞭解需求實現的難度和困難，最終提供給U3（審核人、管理者）討論和審核，達到溝通效果）

1.2背景

說明：

a．待開發的軟件系統的名稱；

b．本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；

c．該軟件系統同其他系統或其他機構的基本的相互來往關係。

（這部分可以將a,b,c分為2部分，例子如下：

1.2.1項目概況

本需求分析報告所預期開發的軟件系統是:S。S是（不是則無）SS系統的某一個功能子模塊，S和S1、S2等系統之間的聯繫，以及概述其他系統的狀態等等。

1.2.2任務分配

a. 任務提出者：xxx

b. 軟件開發者：xx

c. 產品使用者：xx

d. 文檔編寫者：xx

e. 預期產品使用者：xx

）

1.3定義

列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。

（這部分很簡單，就是描述專業詞彙，比如

1. XML(Extensible Markup Language)即可擴展標記語言,它與HTML一樣,都是SGML(Standard Generalized Markup Language,標準通用標記語言)。

2. Word2, 解釋。。。

）

1.4參考資料

列出用得著的參考資料，如：

a．本項目的經核準的計劃任務書或合同、上級機關的批文；

b．屬於本項目的其他已發表的文件；

c．本文件中各處引用的文件、資料、包括所要用到的軟件開發標準。列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。

2任務概述

2.1目標

敘述該項軟件開發的意圖、應用目標、作用範圍以及其他應向讀者說明的有關該軟件開發的背景材料。解釋被開發軟件與其他有關軟件之間的關係。如果本軟件產品是一項獨立的軟件，而且全部內容自含，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則......

軟件需求分析說明書怎麼寫

1.基本依據，可以依據可行性分析

2系統概述，系統目標

3.分析方法揣 4.信息採集

5.系統功能，包括用戶界面等

如何寫需求分析報告

資源簡介教會你如何寫需求分析報告~~·需求分析說明書 1 、系統功能結構圖（ HIPO 圖）（在該功能結構圖中選一個子系統進行逐層分解） 2 、系統功能說明（對以上選中的子系統進行功能描述） 3 、現有系統的業務流程圖及說明（對以上選中的子系統繪製手工系統或舊的計算機系統的業務流程圖並進行簡單的功能說明） 4 、新系統的業務流程圖及說明（對以上選中的子系統繪製計算機系統下的業務流程圖（重組後的）並進行簡單的功能說明）採購管理系統分析採購是企業物資供應部門按已確定的物資供應計劃，通過市場採購、加工訂製等各種渠道，取得企業生產經營活動所需要的各種物資的經濟活動，採購業務的狀況會影響到企業的整體運營狀況。通常情況，企業的採購業務通常由採購部來執行—— 製造部根據銷售定單制定生產計劃，企業生產製造系統根據生產技術部提供的有關材料定額資料以及製造部提供的生產計劃，考慮現有庫存情況，生成採購計劃。採購部根據採購計劃分別進行國內採購和國外採購。採購管理系統主要進行採購訂單、採購入庫單和採購的管理。採購業務發生後，採購部將採購錄入採購管理系統，採購物料入庫時，採購部儲運科根據驗收單在庫存管理系統中錄入入庫單；財務部根據採購和物料驗收單據進行採購結算，系統自動生成相關憑證，登記相關庫存帳。課程設計應該遞交哪些文檔？課程設計應提交一份課程設計報告，課程設計報告包括以下幾個方面的內容：①封面、②目錄、③ 系統可行性分析報告、④系統分析報告、⑤課程設計小組成員清單。如何撰寫課程設計報告？課程設計報告包括兩個方面的內容，一個是系統可行性分析報告，一個是系統分析報告。可行性分析報告簡單的來講我們要求大家寫兩個方面的內容，首先是對企業目前的狀況進行描述，指出企業需要用計算機來進行管理（即需要信息系統），然後從經濟上、技術上、管理上闡述企業是否具備了相應的條件，最後得出系統是否可行的結論。我們的課程設計是基於系統可行來進行的。用文字把以上內容描述清楚就是我們的可行性分析報告。最快線程間數據交換算法有效避免鎖競爭下載通過IBM存儲解決方案應對信息爆炸問題HTML5 Audio API開發遊戲音樂您的IT安全來自System X服務器下載《從有限資源到無限發展潛力》Windows應用商店全新的商機

系統的需求規格說明書怎麼寫? 5分

百度文庫上有模板！

用戶需求說明書與需求規格說明書有什麼本質區別？求詳解。謝謝

1、用戶需求說明書是用戶的需求，需要和用戶確認的；需求規格說明書是系統需求主要是對內的。你考慮了一個對外一個對內。而且需求管理的時候也需要用到用戶需求

2、

優點：用戶的語言與設計人員的語言是不同的，所以需要有面向不同人員的文檔。

缺點：層次越多，信息損失的越多，誤解的概率就越大。

權衡的結果：基本上是依據項目的規模而定。

3、這要看你們的項目管理採用的規範。

如果是cmmi就需要，敏捷就取消

4、如果你非要省掉一個的話，我傾向於寫用戶需求，因為搞系統的時候要始終明白用戶在想什麼，要解決什麼問題

需求規格相對不是很重要，具體實現用戶需求的時候，你可以有各種方案，這個是用戶不關心的。要是用戶需求就已經理解錯了，軟件規格讓用戶簽字好哪裡放什麼文本框用什麼佈局有意義麼？最後還不是給你翻掉

5、一個是給用戶看的，一個給程序員看的

6、當然需要，需求管理不弄好，後期客戶扯皮怎麼辦？

7、1、用戶需求說明書是軟件設計的根本，用戶需要簽字畫押，詳細設計基於這個寫的，怎能不需要。

2、後期有扯皮的時候有依據，不至於什麼都沒有。

8、這個東西少不得，做的詳細點是對自己負責，後期意義重大

需求階段的工作主要分為兩個方面，為“需求開發”和“需求管理”頂

從我們的經驗來講

“需求管理”需要產出的文檔大體上包含【需求管理計劃、需求檢查表、需求跟蹤表（包含矩陣圖）、需求變更狀態跟蹤表，以及與其配套產出的指南型文件】

“需求開發”需要產出的文檔大體上包含【需求規格說明書，需求規格說明書檢查表，需求開發指南等】

需求分析報告：一般是對某個市場或者是客戶群來講的，類似於調研報告，重點是體現出產品要滿足哪些功能，哪些是重點、熱點。

需求說明書：是根據與現場實際客戶進行溝通，把客戶的需求進行整理，CMMI中有標準的模板，重點是站在客戶的角度講產品功能。

需求規格說明書：是從業務規則講起的，細一點偏向於軟件的概要設計。是從開發、測試的角度去講產品功能，裡面要包含原型界面、業務接口、活動圖等。

項目需求分析怎麼寫

項目需求分析的概念　　需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發計劃的一個複雜過程。（這個和我在微軟體驗到的又不太一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟件設計打下基礎。需求分析階段結束後，要求得到：1.SRS文檔(System Requirement Specificatio鄲); 2.DRM 文檔；3.Acceptance Plan. 從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。

狹義上理解：需求分析指需求的分析、定義過程。一、為什麼要需求分析　　需求分析就是分析軟件用戶的需求是什麼.如果投入大量的人力，物力,財力,時間,開發出的軟件卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發一個軟件,最後卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟件,而你在軟件開發前期忽略了軟件的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發for windows的軟件,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.

需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟件開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟件系統的開發中,他的作用要遠遠大於程序設計. 二、需求分析的任務　　簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解用戶的各項要求,並準確地表達所接受的用戶需求.三、需求分析的過程　　需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.

問題識別

就是從系統角度來理解軟件,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標準.這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型,操作系統等),可靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟件運行是所需的內存,CPU等),軟件成本消耗與開發進度需求,預先估計以後系統可能達到的目標.

分析與綜合

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

制訂規格說明書

即編制文檔,描述需求的文檔稱為軟件需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.

評審

對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。四、需求分析的方法　　需求分析的方法有很多.這裡只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.

原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟件的一個早期可運行的版本,它實現了目標系統的某些或全部功能.

原型化方法就是儘可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個......

怎麼編寫用戶業務需求分析

需求分析

格式

1 引言

1.1 編寫目的

【說明】目標：對用戶的需求進行收集、整理與分析，弄清楚系統究竟要 “幹什麼”及“由誰幹”，並用合乎規範的文字及圖表予以描述。不需要說明“怎麼幹”，因為那是設計階段的事情。有關文字與圖表應儘量讓用戶便於理解。

預期讀者：用戶方的相關業務人員、雙方的開發人員和系統維護人員。

作用：實現開發方與用戶方的雙向溝通，是把業務需求計算機化的關鍵步驟。

為下一階段的概要設計工作提供依據。當用戶的需求發生變更時，應添寫補充說明；如變動過大可形成新版本。

軟件需求說明（Software Requirements Specification）的主要作用為：

 為用戶方與開發方建立共同協議奠定基礎。

 提高開發效率、強化進度控制。

 為項目的的評測與驗收提供依據。

 便於移植。

 作為系統不斷提高的基礎。

1.2 編寫背景

1.2.1 系統名稱及版本號

【說明】形如“網銀三期***系統V3.0.0”。其中，版本號的格式為“XX.XX.XX”，X為阿拉伯數字，左“0”可省略。

1.2.2 使用者

【說明】適應對象和範圍。主要指預期讀者，也供有關領導審閱。

1.2.3 與其它系統的關係

【說明】在用戶現有的及預期的整個應用系統中，給本系統準確定位。用示意圖及相應的文字予以說明。

2 用戶的基本情況

2.1 系統建設背景

【說明】項目背景與依據、現有基礎、項目規模、預期目標等。可繁可簡，格式自定。

2.2 組織機構與職能

【說明】用層次示意圖及相應文字表示(如果需要開發的系統與部門沒有直接依賴關係此節可省略,本章隨後的小節數將順次減1)，

加註：組織機構的層次數、數目、各個機構的職能簡述。

2.3 用戶特點

【說明】所在行業特徵、操作人員與系統維護人員的數量、學歷與水平、數據量大小、使用頻度等。

2.4 用戶業務分析

【說明】在本部分，希望系統分析人員能夠對用戶業務現狀進行分析、對用戶對本系統的未來發展方向作出一定的預測等。以便設計人員對業務及其發展有所瞭解，增強系統設計的前瞻性。

2.5 計算機應用現狀

【說明】可繁可簡，格式自定。

3 業務需求

3.1 項目概述

【說明】

第一、指明項目的開發意圖、應用目標（總目標、分期目標）、作用範圍、預期效益等。

第二、指明在輸入信息轉變為輸出信息的過程中，為了滿足用戶的業務需求，應用軟件必須完成的基本功能(採用自然語言敘述)。但此時不要求對基本功能進行分解。

第三、如果本系統與其他系統相關聯，則應確定本系統的基本功能邊界（可採用圖示+文字說明的形式，用藍色標示出本系統的功能，用綠色標示出相關係統的功能）。

3.2 約束條件

3.2.1 費用約束

【說明】預計投資金額概算、其中軟硬件費用的比例、資金分期到位計劃。

3.2.2 進度約束

【說明】預計完成日期、分步實施期限。

3.2.3 其它約束

【說明】場地面積限制、通信設施基礎、其它干擾因素。

注意：任何計算機系統都不是包羅萬象的；用戶自身的能力也是有限的。輕諾必寡信。故應特別指出：由於哪些條件的約束，本系統不能滿足哪些業務需求與系統需求。

本章主要介紹項目的總體業務功能,要求站在客戶的角度把握系統需求.

3.3 性能需求

【說明】依據ISO9000標準及我們的理解，下面列出了軟件的6組性能，共涵蓋21個子特性。這些性能/子特性的相對重要性並不是等同的。編寫時，......