對大多數人來說，若要建一幢數百萬元的房子，他一定會與建房者詳細討論各種細節，他們都明白完工以后的修改會造成損失，以及變更細節的危害性。然而，涉及到軟件開發，人們卻變得“大大咧咧”起來。軟件項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”(Leffingwell 1997)�？稍S多組織仍在那些基本的項目功能上采用一些不合規范的方法，這樣導致的后果便是一條鴻溝(期望差異)—開發者開發的與用戶所想得到的軟件存在著巨大期望差異。
在軟件工程中，所有的風險承擔者(stakeholder)(這個詞很有意思，原義是賭金保管者。我看過很多的翻譯，有翻譯成涉眾的，也有的翻譯成參與者的，但是我想他的主要意思就是和這個項目有密切相關利益的人)都感興趣的就是需求分析階段。這些風險承擔者包括客戶、用戶、業務或需求分析員(負責收集客戶需求并編寫文檔，以及負責客戶與開發機構之間聯系溝通的人)、開發人員、測試人員、用戶文檔編寫者、項目管理者和客戶管理者。這部分工作若處理好了，能開發出很出色的產品，同時會使客戶感到滿意，開發者也倍感滿足、充實。若處理不好，則會導致誤解、挫折、障礙以及潛在質量和業務價值上的威脅。因為需求分析奠定了軟件工程和項目管理的基礎，所以所有風險承擔者最好是采用有效的需求分析過程。
軟件需求的定義
IEEE軟件工程標準詞匯表(1997年)中定義需求為：
(1)用戶解決問題或達到目標所需的條件或權能(Capability)。
(2)系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或權能。
(3)一種反映上面(1)或(2)所描述的條件或權能的文檔說明。
需求的層次
下面這些定義是需求工程領域中常見術語的定義說明。
軟件需求包括三個不同的層次—業務需求、用戶需求和功能需求—也包括非功能需求。業務需求( business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務，這在使用實例(use case)文檔或方案腳本(scenario)說明中予以說明。功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。軟件需求各組成部分之間的關系如圖所示。
作為補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對用戶和開發人員都極為重要。
值得注意的一點是，需求并未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發什么。
Frederick Brooks在他1987年的經典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分說明了需求過程在軟件項目中扮演的重要角色：
開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統的接口。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，并且以后再對它進行修改也極為困難。
為什么這么說呢，因為在大多數的軟件系統中，最終用戶可能都不清楚他的需求是什么，這是千真萬確的。如果你的用戶告訴你需求就是這些了，不要相信他，繼續刨根問底，直到你們都筋疲力盡了。
雖然聽上去有些不可思議，但這是教訓之談，在我從事的項目之中，沒有一個用戶在軟件接近完成的時候打電話對我說，我看了你們的軟件，我想我必須改動一些地方。在那些日子中，我甚至得了一種電話鈴音恐懼癥。
需求風險
下面列出了在做需求分析時一些很危險的做法，如果你發現你的一些做法與之相似，那么，給自己一些時間，好好思考一下，這些做法會對你的軟件產生致命的影響。
1. 無足夠用戶參與
客戶經常不明白為什么收集需求和確保需求質量需花費那么多功夫，開發人員可能也不重視用戶的參與。究其原因：一是因為與用戶合作不如編寫代碼有意思；二是因為開發人員覺得已經明白用戶的需求了。在某些情況下，與實際使用產品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中，并一同經歷整個開發過程。
最重要的就是用戶必須要重視他的軟件，必須讓他明白：如果失敗，他的損失最大(當然你的損失也不小，但這時候你必須讓他重視這項工作)。如果用戶不夠重視，想辦法解決，否則你就不用再繼續了。
2. 用戶需求的不斷增加
在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發者對新需求所作的修改。要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。
產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內聚、松耦合的設計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，并能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利于減少因變更導致質量的下降。
最糟糕的莫過于用戶覺得如果不再加點什么功能就對不起自己。我曾經看過一個數據倉庫的一期工程，在設計階段沒有很好的定義范圍，當我向項目管理者提出這個問題的時候，他認為都已經說好了，合同上也寫清楚了，并沒有加以重視�？墒亲詈�，用戶提出的修改意見已經遠遠超出了范圍，項目時間也延長了一倍。整個的項目組成員疲憊不堪，可是卻不斷的接到用戶投訴說項目失敗。
3. 模棱兩可的需求
模棱兩可是需求規格說明中最為可怕的問題(Lawrence 1996)。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
