軟體開發中的需求定義，是軟體產生過程中的重要階段，也是軟體開發管理中的難題。
先來看看K.E.維格斯在《軟體需求》中的一個例子：
Contoso 製藥公司的高階管理長官Gerhard ,會見C o n t o s o公司的資訊系統開發小組的專案負責人C y n t h i a。“我們需要建立一套化學制品跟蹤資訊系統”，G e r h a r d說道。“該系統可以記錄庫房或某個實驗室中已有的化學藥品，這樣，化學專家可以直接從樓下的某人那裡拿到所需的藥品，而不必再買一瓶新的。另外，衛生保健部門也得為聯邦政府寫些關於化學藥品的使用報告。你們小組能在五個月內開發出該系統嗎？”
“我已經明白這個專案的重要性了， G e r h a r d”C y n t h i a說，“但在我制定計劃前，我們必須收集一些系統的需求。”
G e r h a r d覺得很奇怪“你的意思是什麼？我不是剛告訴你我的需求了嗎？”
“實際上，你只說明瞭整個專案的概念與目標，”C y n t h i a解釋道，“這些高層次的業務需求並不能為我們提供足夠的詳細資訊以確定究竟要開發什麼樣的軟體，以及需要多長時間。我需要一些分析人員與一些知道系統使用要求的化學專家進行討論，然後才能真正明白達到業務目標所需的各種功能和使用者的要求。我們甚至並不需要開發一個新的軟體系統，這樣可節省許多錢。”
“那些化學專家都非常忙” G e r h a r d說道，“他們沒有時間與你們詳細討論各種細節，你不能讓你的手下的人說明要做的系統嗎？”
C y n t h i a盡力解釋從使用新系統的使用者處收集需求的合理性。“如果我們只是憑空猜想使用者要求，結果不會令人滿意。我們只是軟體開發人員，而並非化學專家。我們並不能真正明白化學專家們需要這個化學制品跟蹤系統做些什麼。未真正明白這些問題就匆忙開始編碼，結果會很難讓人對產品滿意。”
“行了，行了，我們沒有那麼多時間” G e r h a r d堅持道。“我來告訴你需求，請馬上開始開發系統。隨時將你們的進展情況告訴我。”
這樣的情況，估計會經常出現在企業的資訊化系統開發、實施過程中。這叫“上面一張嘴，下面累斷腿。”
由於不同行業、不同規模、不同應用深度的企業的資訊化需求不同，很多現成的產品實際上是根本無法完全滿足企業的個性化需求。企業的IT部門（計算機中心）免不了要對採購的資訊化系統進行二次開發或是自己針對某些應用進行開發，或是對某些產品進行整合開發。
此時，開發需求的定義就成了一個讓CIO很棘手的問題。企業老闆往往會把自己的個人想法作為軟體目標，把簡單的概念作為軟體需求，甚至也可能把個人喜好作為需要實現的使用者體驗，希望IT部門能夠在很短的時間按他想法把系統給他“變”出來。這個時候，其他的業務主管領導或業務部門負責人往往會附和大老闆的意見，反正“資訊化是一把手工程”。
其實，從這個角度來說，資訊化不能是一把手工程。資訊化是一把手工程，既意味著資訊化需要獲得一把手的支援才能取得成功，但也意味著資訊化完全由一把手說了算存在著巨大的風險。強調資訊化是一把手工程，是由於企業的資訊化規劃、選型、實施都缺乏科學的理論作為指導，缺乏有效的方法去付諸實施，在不得已的情況下由領導直接拍板，反正責任由領導負，領導說了大家都不會反對。這實際上是資訊化主管推卸責任，讓一把手承擔隨意與盲目的資訊化帶來的風險。
因為一把手不是超人，對於很多業務的具體細節未必就瞭解得很清楚。一把手其實更多的是關心最終的資料，他並不關心流程或者並不一定熟悉流程。
再看看另外一組調查資料：在企業中，85%的CIO把自己定位為部門經理級，只有15%的CIO自認是企業副總級。與之匹配的是，只有4.17%的CIO在戰略決策中擁有決策權，大多數的CIO在戰略決策中只擁有建議權。即使在CIO工作範疇內的IT投資權上，也只有7.65%的CIO擁有決策權，更多的CIO只擁有建議權。
前幾天參加了e-works組織的武漢製造企業CIO沙龍。會上，很多來自於製造企業第一線的CIO紛紛介紹了企業在資訊化應用、資訊化管理、資訊化實施等各方面的經驗。其中，有一家企業CIO在介紹經驗時提出，為了更好的瞭解企業的業務流程，他們資訊中心把技術人員派到各個部門去上班，完全作為每個部門的員工，與其他員工一樣工作，去熟悉每個部門的具體運作。
從企業需求獲取的角度來講，這算是最直接、也可能是最有效的需求獲取、需求驗證模式了。不管怎麼樣，這至少還能保證所獲取的需求是來自於資訊化第一線的。只有把來自於生產、管理第一線的要求，與技術人員、開發人員的專業經驗相結合，進行科學、合理的論證，才可能真正形成為能夠滿足企業實際業務的軟體需求。
確實，對任何企業而言，談需求不能只看一把手或領導們的臉色，而應該更多地聽聽來自基層員工的聲音。在軟體需求定義問題上，要做到民主與集中的統一。