軟件工程學習筆記(三):需求工程

1 概述

需求工程是應用已證明有效的技術與方法開展需求分析,肯定客戶需求,幫助分析人員理解問題,評估可行性,協商合理的解決方案,無歧義地規約方案,確認規約以及將規約轉換到可運行系統時的需求管理.需求工程是一個不斷反覆的需求定義,文檔記錄,需求演進的過程,並最終在驗證的基礎上凍結需求.需求工程能夠分爲六個階段:需求獲取,需求分析與協商,系統建模,需求規約,需求驗證,需求管理.

2 需求獲取

需求獲取階段分析人員經過與用戶的交流,對現有系統的觀察以及對任務進行分析,肯定系統或產品範圍的限制性描述,與系統或產品有關的人員及特徵列表,系統的技術環境的描述,系統功能列表及應用於每一個需求的領域限制,描述不一樣運行條件下系統或產品使用情況的應用場景等,爲需求分析打下基礎.

2.1 軟件需求

軟件需求是指用戶對目標軟件系統在功能,行爲,性能,設計約束等方面的指望,包括:

2.1.1 功能需求

考慮系統要作什麼,在什麼時候作,在什麼時候及如何修改或升級等.

2.1.2 性能需求

考慮軟件開發的技術性指標,例如,存儲容量限制,執行速度,響應時間以及吞吐量.

2.1.3 用戶或人的因素

考慮用戶的類型,例如用戶對使用計算機的熟練程度,須要接受的訓練,用戶理解,使用系統的難度,用戶錯誤操縱系統的可能性等.

2.1.4 環境需求

考慮將來軟件應用的環境,包括硬件和軟件,對硬件設備的需求包括機型,外設,接口,地點,分佈,溫度,溼度,磁場干擾等.對軟件的需求包括操做系統,網絡,數據庫等.

2.1.5 界面需求

考慮來自其餘系統的輸入,到其餘系統的輸出,對數據格式的特殊規定,對數據存儲介質的規定.

2.1.6 文檔需求

考慮須要哪些文檔,文檔針對的讀者.

2.1.7 數據需求

考慮輸入,輸出數據的格式,接受,發送數據的頻率,數據的準確度與精度,數據流量,數據需保持的時間等.

2.1.8 資源使用需求

考慮軟件運行時所須要的數據,其餘軟件,內存空間等資源.軟件開發,維護所需的人力,支撐軟件,開發設備等.

2.1.9 安全保密需求

考慮是否須要對訪問系統或系統信息加以控制,隔離用戶數據與方法,用戶程序如何與其餘程序和操做系統隔離以及系統備份要求等等.

2.1.10 可靠性需求

考慮系統的可靠性技術,系統是否必須監測和隔離錯誤,出錯後重啓系統容許的時間等.

2.1.11 軟件成本消耗與開發進度需求

考慮開發是否有規定的時間表,軟硬件投資有無限制等.

2.1.12 其餘非功能性需求

如採用某種開發模式,肯定質量控制標準,里程碑和評審,驗收標準,各類質量要求的優先級等,以及可維護性方面的需求.

2.2 需求獲取的方法即策略

2.2.1 創建順暢的通訊途徑

在用戶,系統分析人員,軟件開發小組,管理人員之間創建良好的溝通方式,以保證能順利地對問題進行分析.

2.2.2 訪談與調查

分析人員要從分析已經存在的同類的軟件產品,或從行業標準,規則中提取初步需求,而後以個別訪談的形式或小組會議的形式開始與用戶進行初步的溝通.除了進行面談外,能夠進行市場調查,瞭解市場對將開發的軟件有什麼樣的要求,能夠採起多種調查方式,指定調查提綱,向不一樣層次的用戶發調查表,或訪問用戶和領域專家.

2.2.3 觀察用戶操做流程

到用戶的實際工做環境中對用戶的工做流程進行觀察,瞭解用戶的實際操做環境,操做過程與操做要求,對照用戶提交的問題陳述,對用戶需求能夠有更全面細緻的認識.

2.2.4 成立聯合小組

採用一種叫FAST(facilitated application sepcification techniques)的技術用戶與開發方成立一個聯合小組,發揮各自的長處,共同負責項目的推動.FAST鼓勵創建用戶與開發者隊伍之間的合做,共同工做來標識問題,提出解決方法的要素,商議不一樣的方法以及刻畫初步的解決方案.

它已經成爲信息系統使用的主流技術,該技術爲改善各類應用中的相互通訊提供了潛在的可能.FAST團隊由來自市場,軟件與硬件工程以及製造方的表明組成,並選擇外來人員做爲協調者.該方法有一下基本原則:

• 在中立的地點舉行由開發者和用戶出席的會議
• 創建準備和參與會議的規則
• 創建一個足夠正式的議程以即可以進行自由的交流
• 由一個"協調者"(用戶,開發者,或其餘人)來控制會議
• 使用一種"定義機制"(工做表,圖標等)
• 目標是標識問題,提出解決方案的要素,商議不一樣的方法以及在有利於完成目標的氛圍中刻畫出初步的需求

2.2.5 用況

用況常被稱爲用例,應該包含:

• 執行者完成的主要任務或功能
• 執行者將獲取,生產或改變什麼信息
• 執行者是否必須通知系統關於外部環境的變化
• 執行者但願從系統得到什麼信息
• 執行者是否但願被通知未預期的變化

3 需求分析

3.1 原則

• 必須可以表示和理解問題的信息域
• 必須可以定義軟件將完成的功能
• 必須可以表示軟件的行爲
• 必須劃分描述的數據,功能和行爲的模型
• 分析過程應該從要素信息移向細節信息

3.2 信息域

信息域包括信息內容,信息流以及信息結構.

3.2.1 信息內容

信息內容表示了單個數據和控制對象,目標軟件全部處理的信息集合由它們構成.

3.2.2 信息流

信息流表示了數據和控制在系統中流動時的變化方式,輸入對象被變換爲中間信息,而後進一步被變換爲輸出.

3.2.3 信息結構

信息結構表示了各類數據和控制項的內部組織形式.

3.3 需求協商

需求很容易出現衝突,這就須要進行協商,討論需求衝突,一般會議是解決衝突最快的方式.

3.4 需求建模

建立模型是需求分析的重要活動.模型以一種簡潔,準確,結構清晰的方式系統地描述了軟件需求,從而幫助分析員理解系統的信息,功能與行爲,模型還將成爲軟件設計的基礎,爲設計者提供軟件要素的表示視圖.

4 需求規約

需求規約是分析任務的最終產物,經過創建完整的信息描述,詳細的功能和行爲描述,性能需求和設計約束的說明,合適的驗收標準,給出對目標軟件的各類需求.軟件需求規約的框架主要分爲5部分:

4.1 引言

引言陳述軟件目標,在基於計算機的系統語境內進行描述,包括系統參考文獻,總體描述,軟件項目約束等.

4.2 信息描述

信息描述給出軟件必須解決的問題的詳細描述,記錄信息內容,信息流,信息結構.

4.3 功能描述

功能描述用以描述解決問題所須要的每一個功能,其中包括爲每一個功能說明一個處理過程,敘述設計約束,敘述性能特徵,用一個或多個圖形來形象地表示軟件的總體結構和軟件功能與其餘元素間的相互影響.

4.4 行爲描述

行爲描述用以描述做爲外部事件和內部產生的控制特徵的軟件操做.

4.5 檢驗標準

檢驗標準描述檢驗系統成功的標誌,即對系統進行什麼樣的測試,獲得什麼樣的結果,就表示系統已經成功實現了.檢驗標準是確認測試的基礎.

4.6 參考書目

對全部和該軟件相關文檔的引用,包括其餘的軟件工程的文檔,技術參考文獻,廠商文獻和標準.

4.7 附錄

包含了規約的補充信息,表格數據,算法的詳細描述,圖表和其餘材料.

5 需求驗證

需求驗證的目的是檢驗是否可以反映用戶的意願,須要對需求文檔中定義的需求執行多種檢查,評審團隊應該檢查需求的有效性,一致性和做爲一個總體的完備性.包括系統定義的目標是否與用戶的要求一致,系統需求分析階段提供的文檔資料是否齊全,被開發的數據流與數據結構是否肯定且充足,主要功能是否已包括在規定的軟件範圍以內,是否都已充分說明,設計的約束條件或限制條件是否符合實際,開發的技術風險是什麼,是否詳細制定了檢驗標準,它們可否對系統定義進行確認.

6 需求管理

需求管理是一組用於幫助項目組在項目進展中的任什麼時候候去標識,控制和跟蹤需求的活動.在需求管理中,每一個需求被賦予惟一的標識符,一旦標示出需求,就能夠爲需求創建跟蹤表,每一個跟蹤表標示需求與其餘需求或設計文檔,代碼,測試用例的不一樣版本間的關係.這些跟蹤表能夠用於需求跟蹤,在整個開發過程當中,進行需求跟蹤的目的是爲了創建和維護從用戶需求開始到測試之間的一致性與完整性.確保全部的實現是以用戶需求爲基礎,全部的輸出符合用戶需求,而且全面覆蓋了用戶需求.