在使用你編寫的職員系統時遇到一個問題，
一個職員想把她的名字改成Sparkle Starlight，而系統不允許，你能幫幫忙嗎？”
“她嫁給了一個姓Starlight 的人嗎？” P h i l問道。
“不，她沒有結婚，而僅僅是要更改她的名字，”M a r i a回答。“就是這問題，好
像我們只能在婚姻狀況改變時才能更改姓名。”
“當然是這樣，我從沒想過誰會莫名其妙地更改自己的姓名。我不記得你曾告訴
我係統需要處理這樣的事情，這就是爲什麼你們只能在改變婚姻狀況對話框中才能
進入更改姓名的對話框。”Phil 說。
M a r i a說：“我想你當然知道每個人只要願意都可以隨時合法更改他（她）們的
姓名。但不管怎樣，我們希望在下週五之前解決這個問題，否則， S p a r k l e將不能支
付她的賬單。你能在此前修改好這個錯誤嗎？“
“這並不是我的錯！我從來不知道你需要處理這種情況。我現在正忙着做一個新
的性能檢測系統，並且還要處理職員系統的一些需求變更請求”（傳來翻閱稿紙的聲
音）。“我還有別的事。我只可能在月底前修改好，一週內不行，很抱歉。下次若有
類似情況，請早一些告訴我並把它們寫下來。”
“那我怎麼跟S p a r k l e說呢？” M a r i a追問道，“如果她不能支付賬單，那她只能掛
帳了。”
“M a r i a，你要明白，這不是我的過錯。”P h i l堅持道，“如果你一開始就告訴我，
你要能隨時改變某個人的名字，那這些都不會發生。因此你不能因我未猜出你的想
法（需求）就責備我。”
M a r i a不得不憤怒地屈從：“好吧，好吧，這種煩人的事使我恨死計算機系統了。
等你修改好了，馬上打電話告訴我，行吧？”
如果作爲客戶有過類似的經驗，你一定知道：一個不能進行一項基本操作的軟件產品是
多麼令人煩惱。儘管開發者最終會滿足你的要求，你也不會感謝他。但從開發者角度來看，
在整個系統已經完成後，用戶再提出對功能的進一步要求是多麼煩人的事。同時，修改系統
的請求迫使你放下當前的項目，而且往往修改請求還要求你優先處理，也是令人很不愉快的。
其實，在軟件開發中遇到的許多問題，都是由於收集、編寫、協商、修改產品需求過程
中的手續和作法（方法）失誤帶來的。例如上面的P h i l和M a r i a，出現的問題涉及到非正式信
息的收集，未確定的或不明確的功能，未發現或未經交流的假設，不完善的需求文檔，以及
突發的需求變更過程。
對大多數人來說，若要建一幢2 0萬美元的房子，他一定會與建房者詳細討論各種細節，
第一部分軟件需求：
是什麼和爲什麼
他們都明白完工以後的修改會造成損失，以及變更細節的危害性。然而，涉及到軟件開發，
人們卻變得“大大咧咧”起來。軟件項目中百分之四十至百分之六十的問題都是在需求分析
階段埋下的“禍根”（L e ffingwell 1997）。可許多組織仍在那些基本的項目功能上採用一些不
合規範的方法，這樣導致的後果便是一條鴻溝（期望差異）—開發者開發的與用戶所想得
到的軟件存在着巨大期望差異。
在軟件工程中，所有的風險承擔者（ s t a k e h o l d e r）都感興趣的就是需求分析階段。這些風
險承擔者包括客戶、用戶、業務或需求分析員（負責收集客戶需求並編寫文檔，以及負責客
戶與開發機構之間聯繫溝通的人）、開發人員、測試人員、用戶文檔編寫者、項目管理者和客
戶管理者。這部分工作若處理好了，能開發出很出色的產品，同時會使客戶感到滿意，開發
者也倍感滿足、充實。若處理不好，則會導致誤解、挫折、障礙以及潛在質量和業務價值上
的威脅。因爲需求分析奠定了軟件工程和項目管理的基礎，所以所有風險承擔者最好是採用
本書提供的有效的需求分析過程。
1.1 軟件需求的定義
軟件產業存在的一個問題就是缺乏統一定義的名詞術語來描述我們的工作。客戶所定義
的“需求”對開發者似乎是一個較高層次的產品概念。而開發人員所說的“需求”對用戶來
說又像是詳細設計了。實際上，軟件需求包含着多個層次，不同層次的需求從不同角度與不
同程度反映着細節問題。
I E E E軟件工程標準詞彙表（ 1 9 9 7年）中定義需求爲：
（1）用戶解決問題或達到目標所需的條件或權能（ C a p a b i l i t y）。
（2）系統或系統部件要滿足合同、標準、規範或其它正式規定文檔所需具有的
條件或權能。
（3）一種反映上面（1）或（2）所描述的條件或權能的文檔說明。
1.1.1 一些關於“需求”的解釋
I E E E公佈的定義包括從用戶角度（系統的外部行爲），以及從開發者角度（一些內部特性）
來闡述需求。
關鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發者，
客戶被迫與新的需求分析者坐到一起。分析人員說：“我們想與你談談你的需求。”客戶的第
一反應便是：“我已經將我的要求都告訴你們前任了，現在我要的就是給我編一個系統”。而
實際上，需求並未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、
貼條、會談過幾次或一些零碎的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。
另外一種定義認爲需求是“用戶所需要的並能觸發一個程序或系統開發工作的說明”
（Jones 1994）。需求分析專家Alan Davis （1 9 9 3）拓展了這個概念：“從系統外部能發現系統
2 第一部分軟件需求：是什麼和爲什麼
所具有的滿足於用戶的特點、功能及屬性等”。這些定義強調的是產品是什麼樣的，而並非產
品是怎樣設計、構造的。而下面的定義則從用戶需要進一步轉移到了系統特性（ S o m m e r v i l l e
and Sawyer 1997）：
需求是⋯⋯指明必須實現什麼的規格說明。它描述了系統的行爲、特性或屬性，
是在開發過程中對系統的約束。
從上面這些不同形式的定義不難發現：並沒有一個清晰、毫無二義性的“需求”術語存
在，真正的“需求”實際上在人們的腦海中。任何文檔形式的需求（例如：需求規格說明）
僅是一個模型，一種敘述（ Lawrence 1998）。我們需要確保所有項目風險承擔者在描述需求
的那些名詞的理解上務必達成共識。
轉摘自：ITPUT.NET