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 需求管理
需求管理是一組用於幫助項目組在項目進展中的任何時候去標識,控制和跟蹤需求的活動.在需求管理中,每個需求被賦予唯一的標識符,一旦標示出需求,就可以爲需求建立跟蹤表,每個跟蹤表標示需求與其他需求或設計文檔,代碼,測試用例的不同版本間的關係.這些跟蹤表可以用於需求跟蹤,在整個開發過程中,進行需求跟蹤的目的是爲了建立和維護從用戶需求開始到測試之間的一致性與完整性.確保所有的實現是以用戶需求爲基礎,所有的輸出符合用戶需求,並且全面覆蓋了用戶需求.