沒有需求就沒有軟體 (轉)

沒有需求就沒有軟體 (轉)[@more@]

沒有需求就沒有

金芝（轉載自世界） （轉載自軟體工程專家網）?page=/bbs/index.asp?Type=H" target=_blank>

　　需求工程無疑是當前軟體工程中的關鍵問題，從美國於1995年開始的一項調查結果就足以看出這一點。在這項調查中，他們對全國範圍內的8000個軟體專案進行跟蹤調查，結果表明，有1/3的專案沒能完成，而在完成的2/3的專案中，又有1/2的專案沒有成功實施。他們仔細分析失敗的原因後發現，與需求過程相關的原因佔了45%，而其中缺乏最終的參與以及不完整的需求又是兩大首要原因，各佔13%和12%。

　　需求工程又是軟體工程中最複雜的過程之一，其複雜性來自於客觀和主觀兩個方面。從客觀意義上說，需求工程面對的問題幾乎是沒有範圍的。由於應用領域的廣泛性，它的實施無疑與各個應用行業的特徵密切相關。其客觀上的難度還體現在非功能性需求及其與功能性需求的錯綜複雜的聯絡上，當前對非功能性需求分析建模技術的缺乏大大增加了需求工程的複雜性。從主觀意義上說，需求工程需要方方面面人員的參與（如領域專家、領域使用者、投資人、系統分析員、需求分析員等等），各方面人員有不同的著眼點和不同的知識背景，溝通上的困難給需求工程的實施增加了人為的難度。

　　最初，需求工程僅僅是軟體工程的一個組成部分，是軟體生命週期的第一個階段。雖然大家也都知道需求工程對軟體整個生命週期的重要性，但對它的研究遠遠沒有對軟體工程的其他部分的研究那麼深入。

　　在傳統軟體工程生命週期中，涉及需求的階段稱作需求分析。一般來說，需求分析的作用是：

　　● 系統工程師說明軟體的功能和，指明軟體和其他系統成分的介面，並定義軟體必須滿足的；

　　● 軟體工程師求精軟體的，建立資料模型、功能模型和行為模型；

　　● 為軟體設計者提供可用於轉換為資料設計、體系結構設計、介面設計和過程設計的模型；

　　● 提供開發人員和客戶需求規格說明，用於作為評估軟體質量的依據。

　　但從當前的研究現狀來看，需求工程的內容遠不止這些。需求工程是系統工程和軟體工程的一個交叉分支，涉及到軟體系統的目標、軟體系統提供的服務、軟體系統的約束和軟體系統執行的環境。它還涉及這些因素和系統的精確規格說明以及系統進化之間的關係。它也提供現實需要和軟體能力之間的橋樑。

　　需求工程的基本活動包括：

　　● 抽取需求；

　　● 模擬和分析需求；

　　● 傳遞需求；

　　● 認可需求；

　　● 進化需求。

　　每個活動都有它基本的動機、任務和結果，也有各自的困難所在。

　　首先，開始一個專案是因為要對現行系統進行改造。要改造一個系統是因為現行系統存在需要解決的問題。如：現行系統與當前情況不符合、出現新的商機或者可能節省時間、資金和資源等，這就是抽取需求的動機。在這個階段，需求工程師的任務是認識問題之所在，獲取足夠多的知識，最後成為問題領域的專家。需求工程師常採用W6H方法去認識問題領域，即6個以W打頭的問題，一個以H打頭的問題，如表1所示。

　　需求抽取是非常困難的，其主要原因有：

　　● 缺乏領域知識，應用領域的問題常常是模糊的、不精確的；

　　● 存在預設的知識，即難以描述的日常知識（常識問題）；

　　● 存在多個知識源，而且多知識源之間可能有衝突；

　　● 面對的客戶可能有偏見，如不能提供你需要了解什麼或不想告知你需要了解的事情。

　　需求抽取的方法一般有問卷法、面談法、資料採集法、用況法、情景例項法以及基於目標的方法等，還有知識工程方法，如：場記分析法、卡片分類法、分類表格技術和基於模型的知識獲取等。

　　需求工程的第二個階段是模擬和分析需求，目前有許多工作都以此為目標進行。需求分析和模擬的出發點在於：

　　● 指導抽取；

　　● 幫助需求工程師瞭解進展；

　　● 幫助發現問題；

　　● 幫助檢查對問題的理解。

　　需求分析和模擬又包含三個層次的工作。首先是需求建模。需求模型的表現形式有自然語言、半形式化（如圖、表、結構化英語等）和形式化表示等三種。自然語言形式具有表達能力強的特點，但它不利於捕獲模型的語義，一般只用於需求抽取或標記模型。半形式化表示可以捕獲結構和一定的語義，也可以實施一定的推理和一致性檢查。形式化表示具有精確的語義和推理能力，但要構造一個完整的形式化模型，需要較長時間和對問題領域的深層次理解。對需求概念模型的要求包括：

　　● 實現的獨立性:不模擬資料的表示和內部組織等；

　　● 足夠抽象：只抽取關於問題的本質方面；

　　● 足夠形式化：語法無二義性，並具有豐富的語義；

　　● 可構造性：簡單的模型塊，能應付不同複雜程度和規模的描述；

　　● 利於分析：能支援二義性、不完整性和不一致性分析；

　　● 可追蹤性:支援橫向交叉並能與設計或實現等建立關聯；

　　● 可性：可以動態模擬，利於與現實相比較；

　　● 最小性：沒有冗餘的概念。

　　需求模擬技術又分為企業模擬、功能需求模擬和非功能需求模擬等。

　　企業模擬是一種軟系統方法，涉及整個組織，從各個不同的視點分析問題，包括目標、組織結構、活動、過程等。有的企業模擬還建立可執行的領域模型。採用企業模擬方法產生的不僅僅是規格說明，還可以得到許多關於企業運作的狀況分析。目前代表性的工作包括：資訊模擬、組織模擬和目標模擬等。

　　功能需求模擬從不同視點為模擬軟體提供服務，包括結構視點和行為視點等，主要方法有：結構化分析、面向分析和形式化方法。結構化分析是一種面向資料的方法，以資料流為中心。其核心概念包括：程式、資料流、資料、外部實體、資料組和資料元素。有代表性的模擬工具有：資料流圖、資料字典、原始程式規格說明。物件導向分析以物件及其服務作為建模標準，比較自然，物件也具有相對的穩定性。主要模擬的元素有：物件、類、屬性、關係、方法、訊息傳遞、Use Cases等。其主要原理包括分類繼承層次、資訊隱藏、彙集關係等。形式化方法從廣義上說，是應用離散數學的手段來設計、模擬和分析，得到像數學公式那樣精確的表示。從狹義上說，就是使用一種形式語言進行語言公式的形式推理，用於檢查語法的良構性並證明某些屬性。形式化方法一般用於一致性檢查、型別檢查、有效性驗證、行為預測以及設計求精驗證。引入形式化機制的目的是：

　　● 減少二義性，提高精確性；

　　● 為驗證打下基礎；

　　● 允許對需求進行推理；

　　● 允許執行需求。

　　但是人們常常不用形式化手段，因為：

　　● 形式化涉及太多細節，分析的級別較低；

　　● 形式化的核心問題是一致性和完整性，而不是獲取需求；

　　● 沒有合適的工具；

　　● 要求更多的代價。

　　傳遞需求的主要任務是書寫軟體需求規格說明，其目的是：

　　● 傳達對需求的理解；

　　● 作為專案的一份契約；

　　● 作為評價後續工作的基線；

　　● 作為控制需求進化的基線。

　　對需求規格說明感興趣的群體包括：使用者、客戶；系統分析員、需求分析員；軟體開發者、員；測試員；者。

　　認可需求就是讓上述人員對需求規格說明達成一致，其主要任務是衝突求解，包括定義衝突和衝突求解兩方面。常用的衝突求解方法有：協商、競爭、仲裁、強制、教育等，其中有些只能用人的因素去控制。

　　進化需求的必要性是明顯的，因為客戶的需要總是不斷（連續）增長的，但是一般的軟體開發又總是落後於客戶需求的增長，如何管理需求的進化（變化）就成為軟體進化的首要問題。對傳統的變化管理過程來說，其基本成分包括軟體配置、軟體基線和變化審查小組。當前的發展是軟體家族法，即產品線方法。多視點方法也是管理需求變化的一種新方法，它可以用於管理不一致性並進行關於變化的推理。