關鍵字：需求分析 原則
【IT168 技術文章】
對商業用戶來說，他們后面是成百上千個供應商，前面是成千上萬個消費顧客。怎樣利用軟件管理錯綜復雜的供應商和消費顧客，如何做好精細到一個小小調料包的進、銷、調、存的商品流通工作，這些都是商業企業需要信息管理系統的理由。軟件開發的意義也就在于此。而弄清商業用戶如此復雜需求的真面目，正是軟件開發成功的關鍵所在。
經理：“我們要建立一套完整的商業管理軟件系統，包括商品的進、銷、調、存管理，是總部-門店的連鎖經營模式。通過通信手段門店自動訂貨，供應商自動結算，賣場通過掃條碼實現銷售，管理人員能夠隨時查詢門店商品銷售和庫存情況。另外，我們也得為政府部門提供關于商品營運的報告�！�
分析員：“我已經明白這個項目的大體結構框架，這非常重要，但在制定計劃之前，我們必須收集一些需求�！�
經理覺得奇怪：“我不是剛告訴你我的需求了嗎?”
分析員：“實際上，您只說明了整個項目的概念和目標。這些高層次的業務需求不足以提供開發的內容和時間。我需要與實際將要使用系統的業務人員進行討論，然后才能真正明白達到業務目標所需功能和用戶要求，了解清楚后，才可以發現哪些是現有組件即可實現的，哪些是需要開發的，這樣可節省很多時間�！�
經理：“業務人員都在招商。他們非常忙，沒有時間與你們詳細討論各種細節。你能不能說明一下你們現有的系統?”
分析員盡量解釋從用戶處收集需求的合理性：“如果我們只是憑空猜想用戶的要求，結果不會令人滿意。我們只是軟件開發人員，而不是采購專家、營運專家或是財務專家，我們并不真正明白您這個企業內部運營需要做些什么。我曾經嘗試過，未真正明白這些問題就開始編碼，結果沒有人對產品滿意�！�
經理堅持道：“行了，行了，我們沒有那么多的時間。讓我來告訴您我們的需求。實際上我也很忙。請馬上開始開發，并隨時將你們的進展情況告訴我�！�
風險躲在需求的迷霧之后
以上我們看到的是某客戶項目經理與系統開發小組的分析人員討論業務需求。在項目開發中，所有的項目風險承擔者都對需求分析階段備感興趣。這里所指的風險承擔者包括客戶方面的項目負責人和用戶，開發方面的需求分析人員和項目管理者。這部分工作做得到位，能開發出很優秀的軟件產品，同時也會令客戶滿意。若處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。因此可見——需求分析奠定了軟件工程和項目管理的基礎。
撥開需求分析的迷霧
像這樣的對話經常出現在軟件開發的過程中�？蛻繇椖拷浝淼男枨髮Ψ治鋈藛T來講，像“霧里看花”般模糊并令開發者感到困惑。那么，我們就撥開霧影，分析一下需求的具體內容：
·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。
·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。
·功能需求——定義了開發人員必須實現的軟件功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。
·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標準、規范和約束，操作界面的具體細節和構造上的限制。
文章來源于領測軟件測試網 http://www.kjueaiud.com/