1. 程式人生 > >《需求工程——軟件建模與分析》閱讀筆記03

《需求工程——軟件建模與分析》閱讀筆記03

bsp 模擬 大致 表達式 排序 標識 修改 能夠 產生

一、需求工程過程概念介紹

(一)概述

1.規格說明

需求工程過程是系統開發中需求開發活動的集成,它以用戶所面臨的業務問題為出發點進行分析和各種轉換,最終產生一個能在用戶環境下解決用戶業務問題的系統方案,並將其文檔化為明確的規格說明。

2.生命周期

需求工程也有屬於它自己的生命周期模型,即存在針對需求開發的需求工程過程,這個過程又作為系統工程和軟件工程的一個子過程部署在系統開發的初期階段。

3.活動分類

需求獲取、需求分析、需求規格說明、需求驗證為需求開發活動,需求管理為項目管理活動。

(二)需求開發活動成果文檔類型簡述

1.項目前景和範圍文檔

定義系統業務需求,明確系統開發的努力方向和工作範圍。

2.用戶需求文檔

定義系統用戶需求,以用戶立場表達行為期望。例如,用例文檔就屬於用戶需求文檔中的一種。

3.需求規格說明文檔

定義系統的系統級需求,指出開發者應該完成的任務。需求規格說明文檔按照需求範圍大致可以分為以下兩類:

(1)系統規格說明文檔

定義軟、硬件需求、其他需求。

(2)軟件規格說明文檔

僅僅用於描述軟件需求。

(三)系統開發後續階段

在所有的系統開發活動結束之後,定義良好的需求被轉入系統開發的後續階段——設計、實現和測試等,這時往往會面對一個重要問題——需求變化。因此,在需求開發結束之後,在後續階段中采取有效的方法統一管理開發的需求和需求變化,進行需求管理和變化控制。

二、需求工程過程分步介紹

(一)需求獲取

需求獲取主要包含五個步驟:

收集背景材料->獲取問題與目標,定義項目前景與範圍->識別涉眾,選擇信息的來源->選擇獲取方法,執行獲取,獲取功能與非功能要求->記錄獲取結果。

下面對每個過程的註意事項進行簡要介紹:

1.收集背景材料

此階段主要是通過與用戶交流,發現用戶的問題,經過需求分析步驟轉化為用戶的需求。

2.獲取問題與目標,定義項目前景與範圍

需求獲取中面對的信息比較廣泛,因此,為保證獲取信息的有效性需要保證:

(1)不在無關內容上花費太多時間。

(2)不遺漏應該獲取的重要內容。

3.識別涉眾,選擇信息的來源

此過程將涉及眾多用戶的需求采集,但是為了便於實現和收集信息的準確性,需要將用戶按角色不同進行大致分類,分類後選擇用戶代表盡可能采集到全面的信息。這個過程叫做“涉眾分析”。

4.選擇獲取方法,執行獲取,獲取功能與非功能要求

需求獲取有許多技巧與方法,利用表單、報表、備忘錄等硬數據進行需求獲取,常用的獲取方法還有面談、調查表、觀察和原型等。應該根據實際場景和業務類型選擇合適的采集方法。

5.記錄獲取結果

對以上獲取到的信息,需要對每個階段進行記錄,以便後期進行分析和處理,因此,獲取筆錄記錄的內容往往具有淩亂、模糊、冗余和遺漏等諸多問題。

(二)需求分析

其主要工作為通過建模來整合各種信息、檢查需求中存在的錯誤、遺漏和不一致等各種缺陷,並加以修正。這其中主要包含了六個方面的內容:

背景分析->問題分析、目標分析、業務分析,確定系統邊界->軟件需求建模->細化需求->確定優化級->需求協商。

1.背景分析

主要適用於大規模的系統中,因為系統環境難以梳理,此時就需要進行背景分析。例如,領域分析、企業建模等。

這個步驟在一般的項目中被省略,以免花費太多不必要的精力。

2.問題分析、目標分析、業務分析,確定系統邊界

系統邊界需要保證系統能夠和周圍環境形成有效互,並且在互動中解決用戶問題,滿足業務需求,這些都將依賴於分析技術與方法的使用。例如,系統用例圖和上下文圖。

3.軟件需求建模

為了展現和解釋信息而進行的抽象描述活動,常用技術包括數據流圖、實體關系圖、狀態轉換圖、類圖等半形式化建模技術。需要註意的是,對於一些要求嚴格的項目(醫療器械控制),還需要利用嚴格形式化的技術進行建模。例如,Z模型。

4.細化需求

對於有模糊、有歧義的用戶需求,通過系統建模,轉化為一些有良好粒度和特性的需求細節,即“系統型需求”。

5.確定優化級

對於用戶眾多的需求,需求工程師需要對需求進行排序。

6.需求協商

當用戶需求出現沖突時,需要與用戶進行協商,對沖突的需求進行選擇。

(三)需求規格說明

1.定制文檔模板

通常組織會參考[IEEE 1998]推薦的規格說明文檔,再根據自己的特點和需要進行調整,建立組織的參考模板。

2.編寫文檔

一般會同時使用模型語言(圖形、表達式等)和自然語言(文本)兩種表達方式,以確保文檔內容準確、易讀。

(四)需求驗證

驗證需求說明文檔是否滿足以下標準:

l 真實反映用戶意圖

l 記錄的需求整體上具有完整性和一致性

l 組織方式和書寫方式具有可讀性和可修改性

需求驗證主要包含以下任務:

1.執行驗證

最好采取同級評審,如果必要的話,可采取原型或模擬但代價較高。

2.問題修正

對發現的問題,在驗證之後需要及時修正。並對修正進行跟蹤,以保證修正的落實。

(五)需求管理

在需求開發建立需求基線,在設計、實現等後續活動中處理來自客戶、管理層、營銷部門及其他涉眾群體的變更需求。需求管理在項目的各項管理活動中具有非常重要的作用,CMMI(capability Maturity Model Integration,軟件能力成熟度模型集成)將其作為所有二級成熟度企業都應該具備的一個關鍵過程域。

主要包含以下任務:

1.建立和維護需求基線集

建立良好的配置管理,對需求基線進行版本控制。首先要標識每項需求,記錄相關屬性。基線的版本控制工作可以使用版本管理工具來進行。

2.建立需求跟蹤信息

系統的可跟蹤性要求以系統級需求為出發點進行雙向跟蹤。

(1)後向跟蹤

跟蹤系統級需求被設計、實現為什麽制品,並回溯到每個設計、實現制品是為何而存在。

(2)前向跟蹤

回溯每個系統級需求是為支持哪些用戶需求及業務需求存在。

3.進行變更控制

需求基線建立之後,仍應該積極接受來自外界的需求變化請求,並作出及時調整與反饋。

《需求工程——軟件建模與分析》閱讀筆記03