本文將通過介紹關于軟件需求的基本知識和個人在實際工作中總結的一些經驗，幫助讀者了解軟件需求，學習需求開發的一些基本方法，避免因需求原因而導致的項目失敗。
1 什么是軟件需求和需求工程
1.1 軟件需求的定義
在IEEE軟件工程標準詞匯表(1997年)中定義軟件需求為：
（1）用戶解決問題或達到目標所需的條件或能力。
（2）系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力。
（3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 實通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程序或系統開發工作的說明，表現形式一般為文檔形式。
1.2 需求工程的定義
需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反復的。需求管理是軟件項目開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。
2 需求分析的風險
由于需求分析的參與人員、業務模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風險。這些風險主要表現在：
（1）用戶不能正確表達自身的需求。在實際開發過程中，常常碰到用戶對自己真正的需求并不是十分明確的情況，他們認為計算機是萬能的，只要簡單的說說自己想干什么就是把需求說明白了，而對業務的規則、工作流程卻不愿多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花費更多的時間和精力與用戶交流，幫助他們梳理思路，搞清用戶的真實需求。
（2）業務人員配合力度不夠。有的用戶日常工作繁忙，他們不愿意付出更多的時間和精力向分析人員講解業務，這樣會加大分析人員的工作難度和工作量，也可能導致因業務需求不足而使系統無法使用。
（3）用戶需求的不斷變更。由于需求識別不全、業務發生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發生變化，因此，我們要認識到，軟件開發的過程實際上是同變化做斗爭的過程，需求變化是每個開發人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發生了需求變化，就不得不修改設計、重寫代碼、修改測試用例、調整項目計劃等等，需求的變化就像是萬惡之源，為項目的正常的進展帶來不盡的麻煩。
（4）需求的完整程度。需求如何做到沒有遺漏？這是一個大問題，大的系統要想窮舉需求幾乎是不可能的，即使小的系統，新的需求也總會不時地冒出來。一個系統很難確定明確的范圍并把所有需求一次性提出來，這會導致開發人員在項目進展中去不斷完善需求，先建立系統結構再完成需求說明，造成返工的可能性很大，會給開發人員帶來挫折感，降低他們完成項目的信心。
（5）需求的細化程度。需求到底描述到多細，才算可以結束了？雖然國家標準有需求說明的編寫規范，但具體到某一個需求上，很難給出一個具體的指標，可謂仁者見仁，智者見智，并沒有定論。需求越細，周期越長，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求也越高，相反，需求越粗，開發人員在技術設計時不清楚的地方就越多，影響技術設計。
（6）需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說明產生了不同的理解；另一方面是指同一讀者能用不同的方式來解釋某個需求說明。多義性會使用戶和開發人員等項目參與者產生不同的期望，也會使開發、測試人員為不同的理解而浪費時間，帶來不可避免的后果便是返工重做。
（7）忽略了用戶的特點分析。分析人員往往容易忽略了系統用戶的特點，系統是由不同的人使用其不同的特性，使用頻繁程度有所差異，使用者受教育程度和經驗水平不盡相同。如果忽略這些的話，將會導致有的用戶對產品感到失望。
（8）需求開發的時間保障。為了確保需求的正確性和完整性，項目負責人往往堅持要在需求階段花費較多的時間，但用戶和開發部門的領導卻會因為項目遲遲看不到實際成果而焦慮，他們往往會強迫項目盡快往前推進，需求開發人員也會被需求的復雜和善變折騰的筋疲力盡，他們也希望盡快結束需求階段。
文章來源于領測軟件測試網 http://www.kjueaiud.com/