需求分析 軟體工程第三章

2021-04-15 13:12:24 字數 3278 閱讀 1686

基本任務:對目標系統提出完整、準確、清晰、具體的要求,即準確的回答「系統必須做什麼?」這個問題。

為什麼需要需求分析:

因為在可行性研究階段,我們是以最小的**和最短的時間內確定是否存在可行的解法方法,忽略了很多細節,在這個階段需要詳細描述。

分析方法必須遵守的準則:

(1)必須理解並描述問題的資訊領域,根據這條準則應該建立資料模型。

(2)必須定義軟體完成的功能,根據這條準則應該建立功能模型。

(3)必須描述作為外部事件結果的軟體行為,要求建立行為模型。

(4)必須對描述資訊,功能和行為的模型進行分解,用層次的方式展示細節。

綜合要求:

1.

功能需求

指定系統必須完成的服務

2.

效能需求

指定系統必須滿足的定時約束或容量約束等約束。

3.

可靠性和可用性需求

定量

的指定系統的可靠性

4.

出錯處理需求

說明系統對環境錯誤應該怎樣處理

5.

介面需求

描述應用系統與它環境通訊的格式

6.

約束

描述在設計或實現應用系統時應遵守的限制條件(使用者或環境強加給專案的限制條件)

7.

逆向需求

說明系統不應該做什麼

8.

將來可能提出的要求

列出那些不屬於當前系統開發範疇,但是據分析將來很可能會提出來的要求。目的是為了對系統將來可能的擴充和修改預做準備。

資料要求:

資料可以全面準確地定義資料,資料字典的缺點是不夠形象直觀,為了提高可理解性,常加入圖形工具輔助描繪資料結構。

為了減少資料冗餘、避免出現插入異常或刪除異常,簡化修改資料的過程,通常要把資料結構規範化。

匯出系統的邏輯模型:

綜合以上兩個要求,匯出系統的詳細的邏輯模型,常用資料流圖、

er圖、狀態轉換圖、資料字典和主要的處理演算法描述這個模型。

修正系統開發計畫:

獲得更深入的了解,比較準確的估計系統的成本和進度,修正以前制定的開發計畫。

(1)訪談(包括調查表)

(2)情景分析

(3)從輸出回溯輸入,利用已有的資料流圖、資料字典和

ipo圖,然後再與使用者一步步討論資料處理流程,進一步了解詳細需求

基於團隊的需求收集法:

(1)首先進行初步的訪談(雙方都分別寫乙份產品需求),會前列乙份列表,說明系統環境組成部分的物件、系統將產生的物件以前系統為了完成功能將使用的物件。

(2)會議開始後,討論的第乙個問題是,是否需要這個新的產品,一旦大家都同意確實需要這個新產品,則可以把會前準備好的列表展示出來供大家討論。

(3)針對完每個列表之後,合併成一張組合列表,加入展示過程中產生的新想法。

(4)分組,為每張列表中的專案制定小型規模說明(對列表中包含的單詞或短語的準確說明)

(5)每個小組向全體成員展示他們制定的小型規格說明,供大家,會後做進一步精化工作。

(6)起草完整的需求說明書。

快速建立軟體原型:

最準確、最有效、最強大的需求分析技術

任務:快速地為使用者提供乙個展示其功能的目標系統的模型(可執行的軟體原型,只演示其將有的功能,而不是實現其功能)

包含三種資訊:資料物件、物件屬性和物件關係

符號:矩形代表物件,菱形代表關係,橢圓或圓角矩形代表屬性。

第一正規化:

指資料庫表的每一列都是不可分割的基本資料項,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重複的屬性

,否則不是關係資料模型

. 簡而言之,第一正規化就是無重複的列。

第二正規化:除了要滿足第一正規化,還要保證每個非關鍵字屬性值完全依賴於關鍵字。

第三正規化:符合第二正規化,同時每個非關鍵字屬性不能傳遞依賴於其他的非關鍵字屬性。

要求乙個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。

bc正規化:符合第一正規化,且每個屬性不傳遞依賴於

r的任何鍵。

第四正規化:

r,f>

∈1nf

,如果對於

r的每個非平凡多值依賴

x→→y

(y x),x

都含有候選碼

。狀態:代表任何可以被觀察到的系統的一種行為模式。

狀態有:初態、終態和中間狀態。

初態只有乙個,終態可有多個。

事件:引起系統做動作或轉換狀態的控制資訊。

符號:圓解矩形,可以用直線分格

事件表示式:事件說明

[守衛條件

]/動作表示式

事件說明的語法:事件名(參數列)

動作表示式:是乙個過程表示式,當狀態轉換開始時執行該表示式。

層次方框圖:從頂往下,一層層往下精細化,直到確定資料結構的全部細節為止。

符號:矩形框(資料子集)

warnier

圖:在乙個花括號內的所有名字都屬於同一類資訊。有點類似樹結構。

ipo

圖:是輸入、處理、輸出圖的簡稱。

從四個方面驗證:

(1)一致性:任何一條需求不能和其他需求互相矛盾。

(2)完整性:需求必須是完整的,規格說明書應該包括使用者需要的每乙個功能或效能。

(3)現實性:指定的需求應該用現有的硬體技術和軟體技術基本上可以實現的。

(4)有效性:必須證明需求是正確有效的,確實能解決使用者面對的問題。

軟體工程 第三章 需求分析

第三章 需求分析 軟體工程中包含需求 設計 編碼 測試 需求開發 需求獲取 需求分析 編寫規格說明書 需求驗證 a 需求獲取 確定需求開發過程確定如何組織需求的收集 分析 細化 核實的步驟,並編寫文件 b 需求分析 繪製關聯圖 建立開發原型 分析可行性 確定需求優先順序 為需求建立模型 編寫資料字典...

軟體工程 第三章 需求分析

1.需求分析的定義 在軟體工程中,需求分析是指在開發乙個新的或公升級乙個已有的軟體系統時描寫新系統的目的 範圍 定義和功能時所要做到工作。確定好顧客需求 2.需求分析的目的 準確地理解使用者需要什麼,反覆調查分析,做出乙個軟體需求規格說明書 3.需求分析的特點 1 使用者與開發人員很難進行交流 2 ...

《軟體工程》第三章 需求分析 作業

1 需求分析是軟體定義時期的最後乙個階段,是開發人員經過深入細緻的調研和分析,準確理解使用者和專案的功能 效能 可靠性等要求。該階段是分析系統在功能上需要實現什麼,而不考慮如何去實現。2 基本任務是準確地回答 系統必須做什麼 這個問題,確定系統必須完成哪些工作,也就是對目標系統提出完整 準確 清晰 ...