軟體工程非功能需求分析報告

A. 求軟體工程需求分析報告範文,謝謝!!!!

3.1 引言
3.1.1 編寫目的
說明編寫這份軟體需求說明書的目的，指出預期的讀者。
3.1.2 背景
說明
a.待開發的軟體系統的名稱，
b.本項目的任務提出者、開發者、用戶及實現該軟體的計算中心或計算機網路
c.該軟體系統同其他系統或其他機構的基本的相互來往關系。
3.1.3 定義
列出本文件中用到的專門術語的定義和外文首字母組詞的原片語。
3.1.4 參考資料
列出用得著的參考資料，如:
a.本項目的經核準的計劃任務書或合同、上級機關的批文;
b.屬於本項目的其他已發表的文件，
c.本文件中各處引用的文件、資料、包括所要用到的軟體開發標准。
列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。
3.2 任務概述
3.2.1 目標
敘述該項軟體開發的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟體開發的背景材料。解釋被開發軟體與其他有關軟體之間的關系。如果本軟體產品是一項獨立的軟體，而且全部內容自含，則說明這一點。如果所定義的乒品是盧個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和介面。
3.2.2 用戶的特點
列出本軟體的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟體的預期使用頻度。這些是軟體設計工作的重要約束。
3.2.3 假定和約束
列出進行本軟體開發工作的假定和約束，例如經費限制、開發期限等。
3.3 需求規定

B. 需求開發中的非功能需求包括哪些

非功能性需求

4-1、系統需求（system requirement）用於描述包含多個子系統的產品（即系統）的頂級需求。系統可以只包含軟體系統，也可以既包含軟體又包含硬體子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。

4-2、業務規則包括企業方針、政府條例、工業標准、會計准則和計算方法等。業務規劃本身並非軟體需求，因為它們不屬於任何特定軟體系統的范圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源於業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。

4-3、功能需求記錄在軟體需求規格說明（ SRS ）中。 SRS 完整地描述了軟體系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求信息的資料庫或電子表格；或者是存儲在商業需求管理工具中的信息；而對於小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS 。除了功能需求外， SRS 中還包含非功能需求，包括性能指標和對質量屬性的描述。

4-4、質量屬性（quality attribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。

4-5、約束（constraint）限制了開發人員設計和構建系統時的選擇范圍，如局限於軟體工程學科。 註：分清楚那些是業務需求、哪些是用戶需求、哪些是功能性需求和非功能性需求對軟體的開發有著重大的指導意義，絕不可以以偏概全，錯誤地去揣摩用戶的心思；對於開發者而言，所有軟體功能的開發我們都應該一一徵求用戶的意見，對需求有了清晰的認識後再進行實質性的開發工作。

C. 軟體需求分析報告模板(完整版)

軟體需求分析報告文檔;
軟體概要設計報告文檔;
軟體詳細設計報告文檔;
軟體資料庫設計報告文檔;
軟體測試（驗收）大綱hi.gta123如有幫助，別忘了採納喲！goto365testing,測評網,

D. 軟體工程需求分析的模板

需求規格說明闡述一個軟體系統必須提供的功能和性能以及它所要考慮的限制條件,它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的
基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟體需求規格說明不應該包括設計、構造、測試或工程管理的細
節。
1)採用軟體需求規格說明模版:
採用需求規格說明書模板在你的組織中要為編寫軟體需求文檔定義一種標准模板。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統一的結構。注
意，其目的並非是創建一種全新的模板，而是採用一種已有的且可滿足項目需要並適合項目特點的模板。許多組織一開始都採用IEEE標准
830-1998(IEEE 1998)描述的需求規格說明書模板。要相信模板是很有用的，但有時要根據項目特點進行適當的改動。

1
2
3
4
5
6

A引言
目的
文檔約定
預期的讀者和閱讀建議
產品的范圍
參考文獻

B綜合描述
產品的前景
產品的功能
用戶類和特徵
運行環境
設計和實現上的限制
假設和依賴附錄

C外部介面需求附錄
用戶界面附錄
硬體介面
軟體介面
通信介面

D系統特性
說明和優先順序
激勵/響應序列
功能需求

E 其它非功能需求
性能需求
安全設施需求
安全性需求
軟體質量屬性
業務規則
用戶文檔

F其它需求

G附件
詞彙表
分析模型
待確定問題的列表


表2 需求規格說明模板

a. 引言

引言提出了對軟體需求規格說明的縱覽，這有助於讀者理解文檔如何編寫並且如何閱讀和解釋。

a . 1 目的

對產品進行定義，在該文檔中詳盡說明了這個產品的軟體需求，包括修正或發行版本號。如果這個軟體需求規格說明只與整個系統的一部分有關系，那麼就只定義文檔中說明的部分或子系統。

a.2 文檔約定

描述編寫文檔時所採用的標准或排版約定，包括正文風格、提示區或重要符號。

a.3 預期的讀者和閱讀建議

列舉了軟體需求規格說明所針對的不同讀者，例如開發人員、項目經理、營銷人員、用戶、測試人員或文檔的編寫人員。描述了文檔中剩餘部分的內容及其組織結構。提出了最適合於每一類型讀者閱讀文檔的建議。

a.4 產品的范圍

提供了對指定的軟體及其目的的簡短描述，包括利益和目標。把軟體與企業目標或業務策略相聯系。可以參考項目視圖和范圍文檔而不是將其內容復制到這里。

E. 軟體工程中的功能需求和非功能需求的區別是什麼

軟體工程中的功能需求和非功能需求的區別為：性質不同、約束不同、關聯不同。

一、性質不同

1、功能需求：功能需求定義了開發人員必須實現的軟體功能，使得用戶能完成他們的任務，從而滿足了業務需求。

2、非功能需求：非功能需求描述了系統展現給用戶的行為和執行的操作等。

二、約束不同

1、功能需求：功能需求定義了對系統提供的服務或功能的約束，包括時間約束、空間約束、開發過程約束及應遵循的標准等。

2、非功能需求：非功能需求源於用戶的限制，包括預算的約束、機構政策、與其他軟硬體系統間的互操作，以及如安全規章、隱私權保護的立法等外部因素。

三、關聯不同

1、功能需求：功能需求與軟體系統本身有關。

2、非功能需求：非功能需求不僅與軟體系統本身有關，還與系統的開發過程有關。

F. 軟體工程中需求分析的任務是什麼（具體點）

軟體需求包括 3 個不同的層次――業務需求、用戶需求和功能需求。

除此之外，每個系統還有各種非功能需求。

業務需求（Business requirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目標。

使用前景和范圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。

用戶需求（user requirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麼。

功能需求（functional requirement）規定開發人員必須在產品中實現的軟體功能，用戶利用這些功能來完成任務，滿足業務需求。

功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用「應該」對其進行描述：「系統應該發送電子郵件來通知用戶已接受其預定」。功能需求描述是開發人員需要實現什麼。

系統需求（system requirement）用於描述包含多個子系統的產品（即系統）的頂級需求。系統可以只包含軟體系統，也可以既包含軟體又包含硬體子系統。人也可以是系統的一部分，因此某些系統功能可能要由人來承擔。

業務規則包括企業方針、政府條例、工業標准、會計准則和計算方法等。業務規劃本身並非軟體需求，因為它們不屬於任何特定軟體系統的范圍。

然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實現某些特定功能。有時，功能中特定的質量屬性（通過功能實現）也源於業務規則。所以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。

功能需求記錄在軟體需求說明書（ SRS ）中。 SRS 完整地描述了軟體系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求信息的資料庫或電子表格；

或者是存儲在商業需求管理工具中的信息；而對於小型項目，甚至可能是一疊索引卡片。開發、測試、質量保證、項目管理和其他相關的項目功能都要用到 SRS 。

除了功能需求外， SRS 中還包含非功能需求，包括性能指標和對質量屬性的描述。

質量屬性（quality attribute）對產品的功能描述作了補充，它從不同方面描述了產品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對用戶或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實現的約束。

約束（constraint）限制了開發人員設計和構建系統時的選擇范圍。

行業需求：企業在招聘軟體測試人員時主要看中應聘者的項目經驗、邏輯思維能力、一定的技術能力和綜合素質，而對學歷、年齡、性別、工作經驗等的要求較低，相對於IT行業其他職位而言，軟體測試的入行更加容易。

(6)軟體工程非功能需求分析報告擴展閱讀：

工程與科學：

軟體的開發到底是一門科學還是一門工程，這是一個被爭論了很久的問題。實際上，軟體開發兼有兩者的特點。但是這並不意味著它們可以被互相混淆。很多人認為軟體工程基於計算機科學和信息科學就如傳統意義上的工程學之於物理和化學一樣。

在美國，大約40%的軟體工程師具有計算機科學的學位。在世界其他地方，這個比例也差不多。他們並不一定會每天使用計算機科學方面的知識，但是他們每天都會使用軟體工程方面的知識。

G. 請問軟體工程中的需求分析都包括那些內容

需求分析是指理解用戶需求，就軟體功能與客戶達成一致，估計軟體風險和評估項目代價，最終形成開發計劃的一個復雜過程在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟體設計打下基礎。需求分析階段包括：
·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。

·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。

·功能需求——定義了開發人員必須實現的軟體功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。

·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標准、規范和約束，操作界面的具體細節和構造上的限制。

·需求分析報告——報告所說明的功能需求充分描述了軟體系統所應具有的外部行為。「需求分析報告」在開發、測試、質量保證、項目管理以及相關項目功能中起著重要作用。
還有一個網頁去看看吧，也許對你可能有幫助。

http://hi..com/shiqyn/blog/item/77ef1c1bfa31351c8718bf00.html

還有在軟體工程的書籍上說的更清楚。