淺談信息系統之需求管理

摘要：過去的軟件開發更多的是作坊式、游擊隊式的做法，沒有過程管理，更別提需求管理，大家基本上按照團隊內某個相對權威的人士進行系統開發，這對于過去的單機版系統尚且可以。但是隨著信息系統規模的增大、產品生命周期時間的延長、產品開發團隊的擴大以及環境的復雜化，信息系統的建設越來越強調過程的規范化及文檔化，信息系統項目的成敗在很大程度上已經取決于對其軟件過程的控制，特別是需求管理的控制，因為需求是整個系統的入口，需求開發及管理的好壞決定著整個信息系統的成敗，決定著客戶最終是否對系統認可，需求工程正是在這樣的背景下產生的。

關鍵詞：信息系統需求開發需求管理

1 需求工程概述

需求工程隸屬于軟件工程，是軟件工程的一根分支。利用工程的結構化思想管理需求，進行需求分析及需求管理，確定客戶需求。

所有與需求相關的活動通稱為需求工程。

需求工程一般分為兩個過程，分別是需求開發和需求管理。

1.1 需求開發的目的是通過調查與分析，獲取用戶需求并定義產品需求。

1.2 需求管理的目的是保證需求基準在一條準線上，保證客戶與開發方雙方對需求的共同理解，控制需求的變更，維護需求與其他工作成果的一致性。

需求工程的結構圖如下:

2 需求開發

需求開發包括的過程元素有：需求獲取、需求分析、需求定義，包括了需求收集、分析、編寫文檔、驗證等所有的活動。

需求是整個應用系統建設中最首要的內容，需求開發也是整個項目中至關重要的管理內容。完整準確的業務需求定義是整體項目實施的基準，也是最后檢驗項目是否達到預期業務目標的基準。

什么是需求？需求是用戶為了達到某個目標而解決某個問題時所必需的一種軟件能力，是系統或系統組件為滿足某個合約、標準、規格說明或其他正式文檔所必需達到或擁有的軟件能力。需求并不包括設計細節、實現細節、項目計劃信息或測試信息，它所關注的是究竟要開發什么。需求獲取階段、需求分析階段及需求定義階段在邏輯上存在先后關系，以界限分明、相互獨立的形式出現，但在實踐中它們可能相互交疊、相互作用，實際工作中三個階段通常是迭代進行的。

2.1 需求獲取 需求獲取是通過一定的活動或方式從客戶、業務部門及管理部門收集到他們對系統所能提供的業務支持和功能支持的要求。進行需求收集，首先需要明確需求的四個不同的層次：業務需求、用戶需求、功能需求和非功能需求。不同層次的需求，在項目中它們在不同階段有著不同的來源，也有著不同的目標和對象，需要采取不同的方式獲取。

2.2 需求的層次

2.2.1 業務需求：反應了客戶對產品的高層次的目標要求，定義了產品的方向和商業（市場）目標。是最高層的抽象：它們為項目定義了視圖和范圍。

2.2.3 用戶需求：描述了用戶使用產品必須要完成的任務。

2.2.4 功能需求：是應用軟件所必須實現的軟件功能，使操作者（用戶）能夠通過操作應用系統完成他們必須完成的任務，從而滿足業務需求。

2.2.5 非功能需求：描述系統展現給用戶的行為和執行的操作等，包括應用系統必須遵從的標準、規范、協議，以及容量、性能、安全性、易用性、可維護性、可擴展性要求等。需求調查時通常會采用如下一些形式：①訪談。②觀察。③向用戶群體發調查問卷。④需求專題討論會。⑤焦點小組會議。⑥引導式研討會。⑦原型法。

2.3 需求分析 在做需求分析的時候，采用適當的方法和技術，可以更好地表達和定義用戶的需求，挖掘用戶潛在的需求。常用的需求分析方法：面向對象分析法、原型法和結構化分析法，可以根據實際情況選用。由于表達方式的不同，在需求分析中采用的分析法與后續過程的設計和實現方法有一定的關聯關系，通常應該保持所選用的表達方法一致。需求分析是對獲取的需求進行進一步細化描述，通過與用戶的不斷交互，并得到用戶的確認，最終形成需求規格說明書的過程。在實際執行過程中，可以根據項目的實際情況，按照業務需求、功能需求、非功能需求分層次、漸進式進行細化、確認工作。

2.4 需求定義 經過需求整理和對需求的進一步的分類、細化、描述說明以及與用戶的確認，最終形成一份完整的需求規格說明書。所以，需求規格說明書的編寫是一個逐步細化的過程。在需求規格說明書編寫完成之后，需要進行評審，評審通過后的需求規格說明書將作為應用系統實現的依據，即需求基線。

3 需求管理

需求管理包括的過程元素有：需求確認、需求跟蹤、需求變更控制，是對需求進行一些維護活動，以保證在客戶和開發方之間能夠建立并保持對需求理解的一致性，同時維護需求與后續工作產品的一致性，并對需求的變更進行控制。需求管理是監督需求狀態以更新項目狀態、管理需求基準變更的過程。

3.1 需求確認 需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。需求確認是評估需求文檔、模型和屬性，以判斷它們是否滿足業務需求和足夠完善的過程，以便技術團隊能夠在其上開展系統設計與開發工作。

3.2 需求跟蹤 軟件開發的基本目標是構造能夠滿足客戶基本需求的軟件系統，因此需要一種檢測手段來檢驗軟件是否滿足所有的需求。需求跟蹤是一種有效的檢測手段，它要求對每一項需求都可以追蹤到實現該需求的設計、編碼及測試用例。通過需求追蹤，可以檢驗軟件是否實現了所有需求以及軟件是否對所有的需求都經過了測試。有兩種類型的跟蹤：前向跟蹤和后向跟蹤。前向追蹤意味著看需求是否在生命周期的后續階段（如設計和編碼階段）的工作成果中得到體現。后向追蹤則意味著看生命周期后期的各個階段的工作成果滿足何種需求。前向追蹤保證了軟件能夠滿足需求。后向追蹤則在變更、回歸測試等情況下更有用。

3.3 需求變更控制 需求變更一般由變更控制委員會進行決策管理，作出決定是否可以將建議的需求變更付諸應用。變更控制委員會一般由客戶、專家、項目經理等人員組成。變更控制委員會可以授權，由項目經理對一些影響較小的需求變更作出決策。在信息系統建設過程中，變更是不可避免的。從某種角度上講，信息系統的開發過程就是一個變更過程。因此，如何進行變更管理是一個信息系統建設成功的關鍵。換言之，配置管理就是管理變更的過程，它貫穿著幾乎軟件的整個生命周期，可以說，變更伴隨著軟件開發的各個階段。

變更管理將信息系統的建設變成一個可控的過程，從而降低軟件開發所面臨的風險，從而提高軟件的質量和開發效率。

變更管理是配置管理的重要內容，其目的是為了在動態中保證基線化后配置項的完整性、一致性和可追溯性，保證配置項的變更過程規范、受控、有完整記錄，受影響的各方均能及時了解情況，并相互協調一致。