對商業使用者來說，他們後面是成百上千個**商，前面是成千上萬個消費顧客。怎樣利用軟體管理錯綜複雜的**商和消費顧客，如何做好精細到乙個小小調料包的進、銷、調、存的商品流通工作，這些都是商業企業需要資訊管理系統的理由。軟體開發的意義也就在於此。而弄清商業使用者如此複雜需求的真面目，正是軟體開發成功的關鍵所在。
經理：「我們要建立一套完整的商業管理軟體系統，包括商品的進、銷、調、存管理，是總部-門店的連鎖經營模式。通過通訊手段門店自動訂貨，**商自動結算，賣場通過掃條碼實現銷售，管理人員能夠隨時查詢門店商品銷售和庫存情況。另外，我們也得為**部門提供關於商品營運的報告。」
分析員：「我已經明白這個專案的大體結構框架，這非常重要，但在制定計畫之前，我們必須收集一些需求。」
經理覺得奇怪：「我不是剛告訴你我的需求了嗎？」
分析員：「實際上，您只說明了整個專案的概念和目標。這些高層次的業務需求不足以提供開發的內容和時間。我需要與實際將要使用系統的業務人員進行討論，然後才能真正明白達到業務目標所需功能和使用者要求，了解清楚後，才可以發現哪些是現有元件即可實現的，哪些是需要開發的，這樣可節省很多時間。」
經理：「業務人員都在招商。他們非常忙，沒有時間與你們詳細討論各種細節。你能不能說明一下你們現有的系統？」
分析員盡量解釋從使用者處收集需求的合理性：「如果我們只是憑空猜想使用者的要求，結果不會令人滿意。我們只是軟體開發人員，而不是採購專家、營運專家或是財務專家，我們並不真正明白您這個企業內部運營需要做些什麼。我曾經嘗試過，未真正明白這些問題就開始編碼，結果沒有人對產品滿意。」
經理堅持道：「行了，行了，我們沒有那麼多的時間。讓我來告訴您我們的需求。實際上我也很忙。請馬上開始開發，並隨時將你們的進展情況告訴我。」
風險躲在需求的迷霧之後
以上我們看到的是某客戶專案經理與系統開發小組的分析人員討論業務需求。在專案開發中，所有的專案風險承擔者都對需求分析階段備感興趣。這裡所指的風險承擔者包括客戶方面的專案負責人和使用者，開發方面的需求分析人員和專案管理者。這部分工作做得到位，能開發出很優秀的軟體產品，同時也會令客戶滿意。若處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。因此可見——需求分析奠定了軟體工程和專案管理的基礎。
撥開需求分析的迷霧
像這樣的對話經常出現在軟體開發的過程中。客戶專案經理的需求對分析人員來講，像「霧裡看花」般模糊並令開發者感到困惑。那麼，我們就撥開霧影，分析一下需求的具體內容：
•業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在專案定義與範圍文件中予以說明。
•使用者需求——描述了使用者使用產品必須要完成的任務，這在使用例項或方案指令碼中予以說明。
•功能需求——定義了開發人員必須實現的軟體功能，使使用者利用系統能夠完成他們的任務，從而滿足了業務需求。
•非功能性的需求——描述了系統展現給使用者的行為和執行的操作等，它包括產品必須遵從的標準、規範和約束，操作介面的具體細節和構造上的限制。
•需求分析報告——報告所說明的功能需求充分描述了軟體系統所應具有的外部行為。「需求分析報告」在開發、測試、質量保證、專案管理以及相關專案功能中起著重要作用。
前面提到的客戶專案經理通常闡明產品的高層次概念和主要業務內容，為後繼工作建立了乙個指導性的框架。其他任何說明都應遵循「業務需求」的規定，然而「業務需求」並不能為開發人員提供開發所需的許多細節說明。
下一層次需求——使用者需求，必須從使用產品的使用者處收集。因此，這些使用者構成了另一種軟體客戶，他們清楚要使用該產品完成什麼任務和一些非功能性的特性需求。例如：程式的易用性、健壯性和可靠性，而這些特性將會使使用者很好地接受具有該特點的軟體產品。
經理層有時試圖代替實際使用者說話，但通常他們無法準確說明「使用者需求」。使用者需求來自產品的真正使用者，必須讓實際使用者參與到收集需求的過程中。如果不這樣做，產品很可能會因缺乏足夠的資訊而遺留不少隱患。
在實際需求分析過程中，以上兩種客戶可能都覺得沒有時間與需求分析人員討論，有時客戶還希望分析人員無須討論和編寫需求說明就能說出使用者的需求。除非遇到的需求極為簡單；否則不能這樣做。如果您的組織希望軟體成功，那麼必須要花上數天時間來消除需求中模糊不清的地方和一些使開發者感到困惑的方面。
優秀的軟體產品建立在優秀的需求基礎之上，而優秀的需求源於客戶與開發人員之間有效的交流和合作。只有雙方參與者都明白自己需要什麼、成功的合作需要什麼時，才能建立起一種良好的合作關係。
由於專案的壓力與日俱增，所有專案風險承擔者有著乙個共同目標，那就是大家都想開發出乙個既能實現商業價值又能滿足使用者要求，還能使開發者感到滿足的優秀軟體產品。
客戶的需求觀
「需求確認」意味著什麼
在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標誌行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文件的最後一行下面簽名，於是我就籤了，否則這些開發人員不開始編碼。」
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上籤了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」
同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」
這兩種態度都是不對的。因為不可能在專案的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。
對「需求分析報告」的簽名是建立在乙個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文件表述了我們對專案軟體需求的了解，進一步的變更可在此基線上通過專案定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和專案階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦**於專案的改進和需求的誤差或市場和業務的新要求等。
需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成乙個持續良好的客戶與開發人員的關係，為專案的成功奠定了堅實的基礎。
需求分析的20條法則
需求分析的20條法則 節摘自軟體工程專家網 客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦 如一方要求而另一方不願意或不能夠滿足要求 1 分析人員要使用符合客戶語言習慣的表達 需求...
需求分析的20條法則
客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦 如一方要求而另一方不願意或不能夠滿足要求 1 分析人員要使用符合客戶語言習慣的表達 需求討論集中於業務需求和任務，因此要使用術語。客...
需求分析的20條法則
1 分析人員要使用符合客戶語言習慣的表達 2 分析人員要了解客戶的業務及目標 3 分析人員必須編寫軟體需求報告 4 要求得到需求工作結果的解釋說明 5 開發人員要尊重客戶的意見 6 開發人員要對需求及產品實施提出建議和解決方案 7 描述產品使用特性 8 允許重用已有的軟體元件 9 要求對變更的代價提...