軟體工程的需求模型

Ⅰ 什麼是需求分析，其目標是什麼《軟體工程》

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

需求分析的目標是把用戶對待開發軟體提出的要求或需要進行分析與整理，確認後形成描述完整、清晰與規范的文檔，確定軟體需要實現的功能，完成的工作。此外，軟體的一些非功能性需求、軟體設計的約束條件、運行時與其他軟體的關系等也是軟體需求分析的目標。

(1)軟體工程的需求模型擴展閱讀：

需求分析階段分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

1、問題識別：從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標准。這些需求包括功能需求、性能需求、環境需求、可靠性需求、安全保密需求、用戶界面需求、資源使用需求、軟體成本消耗與開發進度需求。

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

3、制訂規格說明書： 編制文檔，描述需求。需求分析階段的成果是需求規格說明書，向下一階段提交。

4、評審：對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。

Ⅱ 在軟體工程中什麼是需求分析

一。 確定對系統的綜合要求
1. 功能需求
這方面的需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能。
2. 性能需求
性能需求指定系統必須滿足的定時約束或容量約束，通常包括速度(響應時間)、信息量速率、主存容量、磁碟容量、安全性等方面的需求。
3. 可靠性和可用性需求
可靠性需求定量地指定系統的可靠性。
可用性與可靠性密切相關，它量化了用戶可以使用系統的程度。
4. 出錯處理需求
這類需求說明系統對環境錯誤應該怎樣響應。例如，如果它接收到從另一個系統發來的違反協議格式的消息，應該做什麼?注意，上述這類錯誤並不是由該應用系統本身造成的。
5. 介面需求
介面需求描述應用系統與它的環境通信的格式。常見的介面需求有：用戶介面需求；硬體介面需求；軟體介面需求；通信介面需求。
6. 約束
設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件。在需求分析階段提出這類需求，並不是要取代設計(或實現)過程，只是說明用戶或環境強加給項目的限制條件。常見的約束有：精度；工具和語言約束；設計約束；應該使用的標准；應該使用的硬體平台。
7. 逆向需求
逆向需求說明軟體系統不應該做什麼。理論上有無限多個逆向需求，我們應該僅選取能澄清真實需求且可消除可能發生的誤解的那些逆向需求。
8. 將來可能提出的要求
應該明確地列出那些雖然不屬於當前系統開發范疇，但是據分析將來很可能會提出來的要求。
注意：舉例讓學生理解：這樣做的目的是，在設計過程中對系統將來可能的擴充和修改預做准備，以便一旦確實需要時能比較容易地進行這種擴充和修改。
二 。分析系統的數據要求
任何一個軟體系統本質上都是信息處理系統，系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌，對軟體設計有深遠影響，因此，必須分析系統的數據要求，這是軟體需求分析的一個重要任務。
分析系統的數據要求通常採用建立數據模型的方法（舉例）。

三。 導出系統的邏輯模型
綜合上述兩項分析的結果可以導出系統的詳細的邏輯模型，通常用數據流圖、實體-聯系圖、狀態轉換圖、數據字典和主要的處理演算法描述這個邏輯模型。
四。 修正系統開發計劃
根據在分析過程中獲得的對系統的更深入更具體的了解，可以比較准確地估計系統的成本和進度，修正以前制定的開發計劃。

Ⅲ 如何將需求模型轉變為軟體分析模型

軟體工程范圍內，這個問題幾句話也說不清楚，推薦搜一篇文檔：將分析模型轉換為軟體設計。

Ⅳ 軟體工程導論 什麼是需求分析在需求分析階段,建立目標系統的邏輯模型的具體做法

所謂"需求分析"，是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼數據，要得到什麼結果，最後應輸出什麼。可以說，在軟體工程當中的「需求分析」就是確定要計算機「做什麼」。
具體做法:首先確定目標系統與當前系統的邏輯差別；然後將變化部分看作是新的處理步驟，對功能圖及對象圖進行調整；最後由外及里對變化的部分進行分析，推斷其結構，獲得目標系統的邏輯模型。通常用數據流圖、數據字典和主要的處理演算法描述這個邏輯模型

Ⅳ 軟工建模九張圖 瀑布模型 軟體生命周期 需求工程中的分析模型 將分析模型轉化為軟體設計 談對其的理解

第九章設計工程軟體設計是軟體工程過程的技術核心，它開始於需求分析和需求建模完成.

Ⅵ 軟體工程需求分析的模板

需求規格說明闡述一個軟體系統必須提供的功能和性能以及它所要考慮的限制條件,它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的
基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。除了設計和實現上的限制，軟體需求規格說明不應該包括設計、構造、測試或工程管理的細
節。
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 產品的范圍

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

Ⅶ 總結歸納主要的軟體工程模型，並任意選定其中的一種過程模式，介紹其特點及你對該模型的理解。

主要的軟體過程模型有：瀑布模型，演化模型（如增量模型、原型模型、螺旋模型）、噴泉模型、基於構件的開發模型和形式方法模型等。
瀑布模型（waterfall model）是1970年有W.Royce提出的，它給出了軟體生存周期活動的固定順序，上一階段的活動完成後向下一階段過渡，最終得到所開發的軟體產品。瀑布模型如下圖所示，有時也稱為軟體生存周期模型。

瀑布模型中，上一階段的活動完成並經過評審後才能開始下一階段的活動，其特徵是：
（1）接受上一階段的結果作為本階段活動的輸入。
（2）依據上一階段活動的結果實施本階段應完成的活動。
（3）對本階段的活動進行評審。
（4）將本階段活動的結果作為輸出，傳遞給下一階段。
瀑布模型是最早出現的也是應用最廣泛的過程模型，對確保軟體開發的順利進行、提高軟體項目的質量和開發效率起到重要作用。
在大量的實踐過程中，瀑布模型也逐漸暴露出它的不足。首先，客戶常常難以清楚地描述所有的要求，而且在開發過程中，用戶的需求也常常會有所變化，使得不少軟體的需求存在著不確定性；在某個活動中發現的錯誤常常是由前一階段活動的錯誤引起的，為了改正這一錯誤必須回到前一階段，這就導致了瀑布的倒流，也就是說，實際的軟體開發很少能按瀑布模型的順序沒有迴流地順流而下。其次，瀑布模型使得客戶在測試完成以後才能看到真正可運行的軟體，此時，如果發現不滿足客戶需求的問題（由於需求不確定性），那麼修改軟體的代價是巨大的。
不是任何軟體都可採用瀑布模型的，瀑布模型適合於結構化方法，也就是面向過程的軟體開發方法。軟體項目或產品選擇瀑布模型必須滿足下列條件：在開發時間內需求沒有或很少變化；分析設計人員應對應用領域很熟悉；低風險項目（對目標、環境很熟悉）；用戶使用環境很穩定；用戶除提出需求以外，很少參與開發工作。

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

軟體需求包括 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行業其他職位而言，軟體測試的入行更加容易。

(8)軟體工程的需求模型擴展閱讀：

工程與科學：

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

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

Ⅸ 軟體工程的模型都有那些

都忘光了,只記得有個螺旋型的比較好