第三章 需求分析

2022-08-31 19:36:29 字數 2508 閱讀 3530

軟體需求分析的任務:深入描述軟體的功能和效能

確認軟體設計的約束和軟體同其他系統元素的介面問題

定義軟體的其他有效性需求

軟體需求分析的任務就是借助於當前系統的邏輯模型匯出目標系統的邏輯模型,解決目標系統的「做什麼」的問題。

需求分析的過程

問題識別

分析與綜合(面向資料流的結構化分析方法sa,面向資料結構的jackson方法jsd,結構化資料系統開發方法dssd,物件導向的分析方

法ooa等)

編制需求分析階段文件(軟體需求說明書,資料要求說明書,初步的使用者手冊,修改、完善與確定軟體開發實施計畫)

需求分析評審

需求分析的原則:需要能夠表達和理解問題的資訊域和功能域

要能以層次化的方式對問題進行分解和不斷細化

指導性原則

在開始建立分析模型前,先理解問題

開發原型使得使用者能夠了解將如何發生人機互動

記錄每個需求的起源及原因

使用多個需求檢視

給需求賦予優先順序

努力刪除含糊性

需求分析的方法

大多數的需求分析方法是由資料驅動的,資料域具有三種屬性:資料流、資料內容和資料結構。通常,一種需求分析方法總要利用一種或

幾種屬性。

需求分析方法具有一下的共性

支援資料域分析的機制

功能表示的方法

介面的定義

問題分解的機制以及對抽象的支援

邏輯檢視和物理檢視

系統抽象模型

問題分解的兩種方式

橫向分解 縱向分解

軟體需求規格說明的原則

從現實中分離功能,即描述要做什麼而不是怎樣實現

要求使用面向處理的規格說明語言(或稱系統定義語言)

結構化分析方法

面向資料流進行後需求分析的方法

結構化分析方法適合與資料處理型別軟體的需求分析

資料流圖:dfd

定義:從資料傳遞和加工的角度,以圖形的方式刻畫資料流從輸入到輸出的傳輸交換過程。資料流圖是結構化系統分析的主要工具,他表示了系統內部資訊的流向,並表示了系統的邏輯處理功能。

特性:抽象性  概括性  層次性

基本符號;

用途:系統分析員用這種工具可以自頂向下分析系統資訊流程

可在圖上畫出需要計算機處理的部分

根據資料儲存,進一步作資料分析,向資料庫設計過渡

根據資料流向,定出訪問方式

對應乙個處理過程,用相應的語言、判定表等工具表達處理方法

優缺點:總體概念強,每一層都明確強調「幹什麼」,「需要什麼」,「給出什麼」

可以反應出資料的流向和處理過程

由於自頂向下分析,容易及早發現系統各部分的邏輯錯誤,也容易修正

不直觀,一般都要在作業流程分析的基礎上加以概括、抽象、修正來得到

如果沒有計算機系統幫助的話,人工繪製太麻煩,工作量較大

與繪製其他流程圖(系統流程圖,程式流程圖,程式結構圖,控制流程圖)的區別

資料流與資料加工之間的關係

資料流圖層次結構

為了表達資料處理過程的資料加工情況,需要採用層次結構的資料流圖

檢查和修改資料流圖的原則

不允許檔案到檔案,也不允許檔案到資料來源

資料流不是從加工出發,就是流向加工

不允許畫控制流

不允許交叉、重疊

資料字典是關於資料的資訊的集合,對資料流程圖中的各個元素做完整的定義與說明,是資料流程圖的補充工具。資料流圖和資料字典共同

構成系統的邏輯模型

資料詞典與資料流圖配合,能清楚的表達資料處理的要求

資料字典內容:(資料流  資料項 資料結構 資料儲存  處理邏輯  外部實體  )

用於書寫加工邏輯說明的工具

結構化英語  判定表  判定樹 

從機器可讀性來講,判定表與結構化英語優於判定樹

從描述的直觀性來講,判定樹優於判定表和結構化英語

從邏輯驗證和優化能力來講,結構化英語優於判定表與判定樹

原型化方法:

分類:探索型,實驗型,進化型

使用策略:廢棄策略,追加策略

開發優缺點:使用者和設計人員接觸比較密切。

提供了一種開發軟體的方法

各個階段的層次分得不是很清楚

可以容易的確定系統的效能

原型開發模型

模型的細化過程

最常用的動態分析方法

狀態遷移圖

優點:狀態之間的關係能夠直觀的捕捉到

由於狀態遷移圖的單純性,能夠機械的分析許多情況,可很容易的建立分析工具

時序圖petri網

需求規格說明書

1、引言

編寫目的 專案背景  定義  參考資料

2、任務概述

目標  執行環境  條件與限制

3、資料描述

靜態資料  動態資料  資料庫介紹  資料詞典  資料採集

4、功能需求

功能劃分  功能描述 

5、效能需求

資料精確度  時間特性  適應性

6、執行需求

使用者介面  硬體介面  軟體介面  故障處理

7、其他需求

第三章 需求分析

涉眾的重要程度是不同的。準確的識別出來,並確定其優先順序。需要斡旋和協調,讓目標系統滿足大多數涉眾的要求 常見涉眾 終端使用者 投資者 業務提出者 業務管理者 業務執行者 第三方 開發方 法律法規。考慮在業務系統中進行管理和處理的關鍵業務實體。考慮業務相關的過程資料,即圍繞基本業務實體的加工和組合而...

需求分析 軟體工程第三章

基本任務 對目標系統提出完整 準確 清晰 具體的要求,即準確的回答 系統必須做什麼?這個問題。為什麼需要需求分析 因為在可行性研究階段,我們是以最小的 和最短的時間內確定是否存在可行的解法方法,忽略了很多細節,在這個階段需要詳細描述。分析方法必須遵守的準則 1 必須理解並描述問題的資訊領域,根據這條...

軟體工程 第三章 需求分析

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