淺談需求工程問題

摘要：需求工程是軟件工程的初始階段，是整個軟件開發過程的基礎，也是項目成敗的關鍵階段之一。近些年來，隨著軟件規模的不斷增大和在各個領域的廣泛應用，使軟件工程研究越來越重視對需求工程的研究。眾所周知，60%的軟件產品的錯誤來源于不正確的需求，但是大部分的軟件開發組織仍然沒有一個正式的需求過程。許多組織看上去愿意花費巨資用于修改或調整沒有很好規定需求的產品，但卻不愿意投資相對很少的費用來使需求從一開始就正確。

關鍵詞：需求工程；功能性需求；非功能性需求；需求變更

一、研究需求工程的必要性

需求就是那些您必須在開始構建產品之前發現的東西。如果在構建的過程中才發現需求，或者更糟糕，直到客戶已經開始使用您的產品才發現需求，那么代價將是很大的，并且效率將極其低下。在試圖構造產品之前，必須明確需求。如果您沒有正確的需求，就不能設計或構造正確的產品，進而產品也就不能幫助用戶完成他們的工作。

二、需求工程的兩個主要活動

需求是系統必須具有的特征，或者為了使客戶接受該系統而必須滿足的約束。需求工程的目標就是定義所構建系統的需求。需求工程包含兩個主要活動：需求的提出（產生客戶理解的系統規格說明）和分析（產生開發人員可以清楚解釋的分析模型）。

第一部分：需求提出（或需求獲取）

需求包含功能性需求和非功能性需求。功能性需求是產品必須完成的那些事，即為了向它的用戶提供有用的功能，產品必須執行的動作，功能性需求源于產品存在的最基本理由。非功能性需求是產品必須具備的屬性或品質。在某些情況下，非功能性需求對于產品的成功是至關重要的，有時它們作為需求的原因是為了增強產品，非功能性需求通常跟在產品功能的后面。也就是說，一旦我們知道了產品要做的事情，就可以確定它的行為方式，它需要具備什么品質以及它應該多大和多快。

◆功能性需求———產品的功能

·產品的范圍———定義產品的邊界，以及它與相鄰系統的連接情況。

·功能與數據需求———產品必須做的事情和功能進行的數據操作。◆非功能性需求———產品的品質

·觀感需求———預期的外觀。

·易用性需求———基于預期用戶的操作水平作出。

·性能需求———多快、多大、多精確、多安全、多可靠等等。

·操作需求———產品預期的操作環境。

·可維護性和可移植性需求———產品的可改動性必須達到什么水平。

·安全性需求———產品 的安全性、保密性和完整性。

·文化與政策需求———人的因素。

·法律需求———滿足適用的法律。

非功能性需求是您的產品必須具備的屬性。這些屬性可以看作是一些特征或屬性，它們使產品有吸引力、易用、快速或可靠。例如，您可能希望您的產品在指定的時間內作出響應，或者在計算時達到指定的精度。類似地，您可能希望您的產品有某種特定的外觀，或者能被無法閱讀的人士使用，或者遵守適用于您的這類業務的法律。

需求的獲取主要通過下面兩個途徑：

◆◆做用戶的學徒

這一點是基于師傅和學徒的想法。系統分析師成為用戶的學徒，與用戶坐在一起，通過觀察和問問題來學習該工作。不太可能做到許多用戶都能以足夠詳細的方式解釋清楚他們在做什么，讓分析師能捕獲所有的需求。但是，當人們正在做某事時，總是很善于解釋他們正在做什么。如果用戶正在他日常的位置上做他的工作，他就能提供一份動態的意見和建議，這樣能提供一些細節，不這樣做的話很可能漏掉這些細節。可能僅當用戶在工作時，他才能精確地描述他的任務，告訴您他為什么在做這些事。

◆用戶訪談

用戶訪談是需求收集的傳統方法。然而，僅使用這種方法可能并不是最有效率的。我們強烈建議不要把訪談作為唯一的需求收集方法，而是將它與其他方法一起使用，有時其他方法能產生更好的效果。

第二部分：需求分析

分析的結果是產生準確、完整、一致并且可檢驗的系統模型。需求提出階段產生了系統規格說明，開發人員在分析階段將該系統規格說明形式化，并詳細檢查邊界條件和異常情況。如果發現有任何錯誤或二義性，開發人員就糾正并澄清系統規格說明。該活動通常涉及客戶及用戶，特別是當需要改變系統規格說明，以及需要收集附加信息時。

由于項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟件需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本上是由于以下情況造成的：

1）客戶說不清楚需求。

2）需求自身經常變動。

3）分析人員或客戶理解有誤。

面向對象的需求分析的基本步驟如下：

1）與用戶廣泛接觸，收集和查看相關資料，對問題域有一個大致的了解。在此基礎上，提煉和標識對象。

2）描述對象（類）的屬性。

3）描述對象之間的關系，如整體關系和從屬關系等。

4））描述問題域的“劇情”，即描述問題域中完成每個任務需要的對象間的協作關系。

以上四個步驟不是孤立進行，而是相互聯系的。通過這四個步驟的反復執行，就可以建立一個基于對象的問題域模型。

三、需求存在變化

需求也會更改。通常它們的更改有個很好的理由：業務改變了，或者新的技術優勢使得進行改動是值得的。這類改動常常被視為需求蔓延。需求蔓延指的是在大家認為需求過程已經結束以后又進入規格說明書的需求。但是，如果改動導致了在正式需求過程結束后產生新的需求――它們不能事先預見――那么這類需求蔓延就是不可避免的。很自然，需求過程永遠不會結束（產品不斷地演進），但是總存在一個項目階段，在這個階段您打算要開始構建產品的工作。在這個階段之后發生的需求被視為需要蔓延。

（一）統一的方法

統一軟件開發過程是通過在項目的前期盡可能準確，全面地捕獲需求，然后對需求的變化加以控制和管理，來避免范圍的蔓延，并通過迭代和遞增的開發方式，來應對變化。從軟件工程發展的歷史，我們說在項目前期全面地捕獲需求一直是一個做好軟件的不二法則。

對業務邏輯相對穩定的項目，在項目實施之前做好需求的捕獲絕對是受益匪淺的，因為軟件的問題在生命周期的后期發現需要的成本要比在初期發現高得多。

迭代和遞增式開發也降低了項目的風險，他允許在項目進行過程中對需求進行校正，它通過遞增的版本發布使得客戶能在軟件開發生命周期過程中就對軟件有了更全面的認識，因此也能及時的提出改進意見。

從團隊的角度看，迭代的開發更符合人類學習的曲線-一個漸進的過程。在項目開發的初期，開發人員對業務邏輯和技術的掌握可能并不全面，隨著項目的進展，認識會不斷加深，這對于后期的迭代周期的成功是很好的保障。

（二）敏捷方法（XP）

以XP為例，他提出以擁抱變化來應對需求的變化，他并沒有強調在項目的初期確定能確定的需求的重要意義。這與傳統的軟件工程觀點和統一軟件開發過程有差異，他不主張預防需求變化，因此也就沒有強調盡可能在早期確定需求。

擁抱變化與其說是一種方法，不如說是一種心態的調整，XP方法希望開發人員能有良好的面對變化的心態，不討厭變化，積極面對變化。

擁抱變化的確是一種非常優良的品質，這不僅僅對于軟件需求如此，對于日新月異的軟件行業不也如此嗎，不跟上技術潮流就會被淘汰，作技術的人員都是深有體會的。同樣，面對飛速發展的社會，如果沒有積極的心態來應對各種變化，改變固有的觀念，也一樣會被時代所拋棄。

XP同樣采用迭代的開發方法，小版本交付，來使得客戶對軟件盡早有更多的認識和了解，這和統一軟件過程是相同的。

縱觀統一軟件開發過程和敏捷方法對于需求變化的解決方法，我們可以得出結論：

◆預防變化，做到在軟件開發的初期就盡可能確定可以確定的需求；

◆控制需求變更，避免范圍蔓延；

◆以積極的心態來擁抱變化；

◆采用迭代和遞增的開發方法，是解決需求變化的最佳方法。

四、總結

需求工程的發展，使人們認識到，只有最終用戶的直接參與并發揮主導作用，才能真正解決問題空間與求解空間的一致性問題，消除計算機領域和應用領域之間的鴻溝，并自動適應系統需求的不斷變化。針對傳統分析方式的弊端，一種新的被稱為“用戶主導、面向領域的需求分析方法”被提了出來。需求工程研究現狀中一個明顯的不足是研究理論與實踐的脫節，理論解決方案通常是在對實際問題簡化的基礎上得到的。要獲得需求突破，改善需求工程的開發質量和效率，需要探索一條有效的解決途徑，縮小理論與應用之間的距離，使開發出來的系統和模型切實滿足應用領域的需要。目前我們正在嘗試研制一種有實用價值的面向某一行業領域的用戶主導式的應用軟件輔助開發工具及原型系統，建立面向領域的用戶框架，繼續完善用戶驅動的需求分析理論和方法，推動用戶工程理論的形成。

參考文獻：

[1] Suzanne Robertson and James Robertson. Mastering the Requirements Process. Addison-Wesley ，2006

[2] B.Bruegge and A.H.Dutoit. Object-Oriented Software Engineering—Conquering Complex and Changing Systems. Pearson Education， 2002