怎樣做需求分析（之二）

撥開需求分析的迷霧

---像這樣的對話經常出現在軟體開發的過程中。客戶

專案經理的需求對分析人員來講，像「霧裡看

花」般模糊並令開發者感到困惑。那麼，我們就撥開霧影，分析一下需求的具體內容：

---·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在專案定義與範圍文件中予以說明。

---·使用者需求——描述了使用者使用產品必須要完成的任務，這在使用例項或方案指令碼中予以說明。

---·功能需求——定義了開發人員必須實現的軟體功能，使使用者利用系統能夠完成他們的任務，從而滿足了業務需求。

---·非功能性的需求——描述了系統展現給使用者的行為和執行的操作等，它包括產品必須遵從的標準、規範和約束，操作介面的具體細節和構造上的限制。

---·需求分析報告——報告所說明的功能需求充分描述了軟體系統所應具有的外部行為。「需求分析報告」在開發、測試、質量保證、專案

管理以及相關專案功能中起著重要作用。

---前面提到的客戶專案經理通常闡明產品的高層次概念和主要業務內容，為後繼

工作建立了乙個指導性的框架。其他任何說明都應遵循「業務需求」的規定，然而「業務需求」並不能為開發人員提供開發所需的許多細節說明。

---下一層次需求——使用者需求，必須從使用產品的使用者處收集。因此，這些使用者構成了另一種軟體客戶，他們清楚要使用該產品完成什麼任務和一些非功能性的特性需求。例如：程式的易用性、健壯性和可靠性，而這些特性將會使使用者很好地接受具有該特點的軟體產品。

---經理層有時試圖代替實際使用者說話，但通常他們無法準確說明「使用者需求」。使用者需求來自產品的真正使用者，必須讓實際使用者參與到收集需求的過程中。如果不這樣做，產品很可能會因缺乏足夠的資訊而遺留不少隱患。

---在實際需求分析過程中，以上兩種客戶可能都覺得沒有

時間與需求分析人員討論，有時客戶還希望分析人員無須討論和編寫需求說明就能說出使用者的需求。除非遇到的需求極為簡單；否則不能這樣做。如果您的組織希望軟體成功，那麼必須要花上數天時間來消除需求中模糊不清的地方和一些使開發者感到困惑的方面。

---優秀的軟體產品建立在優秀的需求基礎之上，而優秀的需求源於客戶與開發人員之間有效的交流和合作。只有雙方參與者都明白自己需要什麼、成功的合作需要什麼時，才能建立起一種良好的合作關係。

---由於專案的壓力與日俱增，所有專案風險承擔者有著乙個共同目標，那就是大家都想開發出乙個既能實現商業價值又能滿足使用者要求，還能使開發者感到滿足的優秀軟體產品。

該文件來自於：http://mfg.kingdee.com/pages/bhdxyjg/blog/archive/2008/01/12/270517.aspx

如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求獲取使用者需求分析使用者需求編寫需求文件評審需求文件管理需求。下面我們先來討論前兩個步驟獲取使用者需求分析使用者需求的做法。獲取使用者需求這是該階段...