--- 經理：“我們要建立一套完整的商業管理軟件系統，包括商品的進、銷、調、存管理，是總部-門店的連鎖經營模式。通過通信手段門店自動訂貨，供應商自動結算，賣場通過掃條碼實現銷售，管理人員能夠隨時查詢門店商品銷售和庫存情況。另外，我們也得為政府部門提供關于商品營運的報告�！�
-- -分析員：“我已經明白這個項目的大體結構框架，這非常重要，但在制定計劃之前，我們必須收集一些需求�！�
-- -經理覺得奇怪：“我不是剛告訴你我的需求了嗎？”
-- -分析員：“實際上，您只說明了整個項目的概念和目標。這些高層次的業務需求不足以提供開發的內容和時間。我需要與實際將要使用系統的業務人員進行討論，然后才能真正明白達到業務目標所需功能和用戶要求，了解清楚后，才可以發現哪些是現有組件即可實現的，哪些是需要開發的，這樣可節省很多時間�！�
-- -經理：“業務人員都在招商。他們非常忙，沒有時間與你們詳細討論各種細節。你能不能說明一下你們現有的系統？”
--- 分析員盡量解釋從用戶處收集需求的合理性：“如果我們只是憑空猜想用戶的要求，結果不會令人滿意。我們只是軟件開發人員，而不是采購專家、營運專家或是財務專家，我們并不真正明白您這個企業內部運營需要做些什么。我曾經嘗試過，未真正明白這些問題就開始編碼，結果沒有人對產品滿意�！�
--- 經理堅持道：“行了，行了，我們沒有那么多的時間。讓我來告訴您我們的需求。實際上我也很忙。請馬上開始開發，并隨時將你們的進展情況告訴我�！�
--- 風險躲在需求的迷霧之后
- --以上我們看到的是某客戶項目經理與系統開發小組的分析人員討論業務需求。在項目開發中，所有的項目風險承擔者都對需求分析階段備感興趣。這里所指的風險承擔者包括客戶方面的項目負責人和用戶，開發方面的需求分析人員和項目管理者。這部分工作做得到位，能開發出很優秀的軟件產品，同時也會令客戶滿意。若處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。因此可見——需求分析奠定了軟件工程和項目管理的基礎。
-- -撥開需求分析的迷霧
--- 像這樣的對話經常出現在軟件開發的過程中�？蛻繇椖拷浝淼男枨髮Ψ治鋈藛T來講，像“霧里看花”般模糊并令開發者感到困惑。那么，我們就撥開霧影，分析一下需求的具體內容：
-- -·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。
--- ·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。
--- ·功能需求——定義了開發人員必須實現的軟件功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。
-- -·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標準、規范和約束，操作界面的具體細節和構造上的限制。
--- ·需求分析報告——報告所說明的功能需求充分描述了軟件系統所應具有的外部行為�！靶枨蠓治鰣蟾妗痹陂_發、測試、質量保證、項目管理以及相關項目功能中起著重要作用。
--- 前面提到的客戶項目經理通常闡明產品的高層次概念和主要業務內容，為后繼工作建立了一個指導性的框架。其他任何說明都應遵循“業務需求”的規定，然而“業務需求”并不能為開發人員提供開發所需的許多細節說明。
--- 下一層次需求——用戶需求，必須從使用產品的用戶處收集。因此，這些用戶構成了另一種軟件客戶，他們清楚要使用該產品完成什么任務和一些非功能性的特性需求。例如：程序的易用性、健壯性和可靠性，而這些特性將會使用戶很好地接受具有該特點的軟件產品。
--- 經理層有時試圖代替實際用戶說話，但通常他們無法準確說明“用戶需求”。用戶需求來自產品的真正使用者，必須讓實際用戶參與到收集需求的過程中。如果不這樣做，產品很可能會因缺乏足夠的信息而遺留不少隱患。
--- 在實際需求分析過程中，以上兩種客戶可能都覺得沒有時間與需求分析人員討論，有時客戶還希望分析人員無須討論和編寫需求說明就能說出用戶的需求。除非遇到的需求極為簡單；否則不能這樣做。如果您的組織希望軟件成功，那么必須要花上數天時間來消除需求中模糊不清的地方和一些使開發者感到困惑的方面。
--- 優秀的軟件產品建立在優秀的需求基礎之上，而優秀的需求源于客戶與開發人員之間有效的交流和合作。只有雙方參與者都明白自己需要什么、成功的合作需要什么時，才能建立起一種良好的合作關系。
--- 由于項目的壓力與日俱增，所有項目風險承擔者有著一個共同目標，那就是大家都想開發出一個既能實現商業價值又能滿足用戶要求，還能使開發者感到滿足的優秀軟件產品。
-- -客戶的需求觀
-- -客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容并達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以后的磨擦（如一方要求而另一方不愿意或不能夠滿足要求）。
--- 1、 分析人員要使用符合客戶語言習慣的表達
--- 需求討論集中于業務需求和任務，因此要使用術語�？蛻魬獙⒂嘘P術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。
--- 2、分析人員要了解客戶的業務及目標
--- 只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助于開發人員設計出真正滿足客戶需要并達到期望的優秀軟件。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那么開發和分析人員應使用一下目前的舊系統，有利于他們明白目前系統是怎樣工作的，其流程情況以及可供改進之處。s
--- 3、 分析人員必須編寫軟件需求報告
--- 分析人員應將從客戶那里獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份“需求分析報告”，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易于翻閱和理解的方式組織編寫�？蛻粢u審此報告，以確保報告內容準確完整地表達其需求。一份高質量的“需求分析報告”有助于開發人員開發出真正需要的產品。
--- 4、 要求得到需求工作結果的解釋說明
--- 分析人員可能采用了多種圖表作為文字性“需求分析報告”的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難于理解，但是客戶可能對此并不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。
--- 5、 開發人員要尊重客戶的意見
--- 如果用戶與開發人員之間不能相互理解，那關于需求的討論將會有障礙。共同合作能使大家“兼聽則明”。參與需求開發過程的客戶有權要求開發人員尊重他們并珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。
--- 6、 開發人員要對需求及產品實施提出建議和解決方案
--- 通�？蛻羲f的“需求”已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情后，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/