需求分析20條法則
posted by ucpm on 2008-3-26 17:04:45 view 6039 comments 46
【摘要】對商業使用者來說，他們後面是成百上千個供貨商，前面是成千上萬個消費顧客。怎樣利用軟體管理錯綜複雜的供貨商和消費顧客，如何做好精細到乙個小小調料包的進、銷、調、存的商品流通工作，這些都是商業企業需要資訊管理系統的理由。軟體開發的意義也就在於此。
而弄清商業使用者如此複雜需求的真面目，正是軟體開發成功的關鍵所在。
經理：「我們要建立一套完整的商業管理軟體系統，包括商品的進、銷、調、存管理，是總部-門店的連鎖經營模式。通過通訊手段門店自動訂貨，供貨商自動結算，賣場通過掃條形碼實現銷售，管理人員能夠隨時查詢門店商品銷售和庫存情況。
另外，我們也得為**部門提供關於商品營運的報告。」
分析員：「我已經明白這個專案的大體結構框架，這非常重要，但在制定計畫之前，我們必須收集一些需求。」
經理覺得奇怪：「我不是剛告訴你我的需求了嗎？」
分析員：「實際上，您只說明了整個專案的概念和目標。這些高層次的業務需求不足以提供開發的內容和時間。
我需要與實際將要使用系統的業務人員進行討論，然後才能真正明白達到業務目標所需功能和使用者要求，了解清楚後，才可以發現哪些是現有元件即可實現的，哪些是需要開發的，這樣可節省很多時間。」
經理：「業務人員都在招商。他們非常忙，沒有時間與你們詳細討論各種細節。你能不能說明一下你們現有的系統？」
分析員盡量解釋從使用者處收集需求的合理性：「如果我們只是憑空猜想使用者的要求，結果不會令人滿意。我們只是軟體開發人員，而不是採購專家、營運專家或是財務專家，我們並不真正明白您這個企業內部運營需要做些什麼。
我曾經嘗試過，未真正明白這些問題就開始編碼，結果沒有人對產品滿意。」
經理堅持道：「行了，行了，我們沒有那麼多的時間。讓我來告訴您我們的需求。實際上我也很忙。請馬上開始開發，並隨時將你們的進展情況告訴我。」
風險躲在需求的迷霧之後
以上我們看到的是某客戶專案經理與系統開發小組的分析人員討論業務需求。在專案開發中，所有的專案風險承擔者都對需求分析階段備感興趣。這裡所指的風險承擔者包括客戶方面的專案負責人和使用者，開發方面的需求分析人員和專案管理者。
這部分工作做得到位，能開發出很優秀的軟體產品，同時也會令客戶滿意。若處理不好，則會導致誤解、挫折、障礙以及潛在的質量和業務價值上的威脅。因此可見——需求分析奠定了軟體工程和專案管理的基礎。
撥開需求分析的迷霧
像這樣的對話經常出現在軟體開發的過程中。客戶專案經理的需求對分析人員來講，像「霧裡看花」般模糊並令開發者感到困惑。那麼，我們就撥開霧影，分析一下需求的具體內容：
·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在專案定義與範圍文件中予以說明。
·使用者需求——描述了使用者使用產品必須要完成的任務，這在使用例項或方案指令碼中予以說明。
·功能需求——定義了開發人員必須實現的軟體功能，使使用者利用系統能夠完成他們的任務，從而滿足了業務需求。
·非功能性的需求——描述了系統展現給使用者的行為和執行的操作等，它包括產品必須遵從的標準、規範和約束，操作介面的具體細節和構造上的限制。
·需求分析報告——報告所說明的功能需求充分描述了軟體系統所應具有的外部行為。「需求分析報告」在開發、測試、質量保證、專案管理以及相關專案功能中起著重要作用。
前面提到的客戶專案經理通常闡明產品的高層次概念和主要業務內容，為後繼工作建立了乙個指導性的框架。其它任何說明都應遵循「業務需求」的規定，然而「業務需求」並不能為開發人員提供開發所需的許多細節說明。
下一層次需求——使用者需求，必須從使用產品的使用者處收集。因此，這些使用者構成了另一種軟體客戶，他們清楚要使用該產品完成什麼任務和一些非功能性的特性需求。例如：
程式的易用性、健壯性和可靠性，而這些特性將會使使用者很好地接受具有該特點的軟體產品。
經理層有時試圖代替實際使用者說話，但通常他們無法準確說明「使用者需求」。使用者需求來自產品的真正使用者，必須讓實際使用者參與到收集需求的過程中。如果不這樣做，產品很可能會因缺乏足夠的資訊而遺留不少隱患。
在實際需求分析過程中，以上兩種客戶可能都覺得沒有時間與需求分析人員討論，有時客戶還希望分析人員無須討論和編寫需求說明就能說出使用者的需求。除非遇到的需求極為簡單；否則不能這樣做。如果您的組織希望軟體成功，那麼必須要花上數天時間來消除需求中模糊不清的地方和一些使開發者感到困惑的方面。
優秀的軟體產品建立在優秀的需求基礎之上，而優秀的需求源於客戶與開發人員之間有效的交流和合作。只有雙方參與者都明白自己需要什麼、成功的合作需要什麼時，才能建立起一種良好的合作關係。
由於專案的壓力與日俱增，所有專案風險承擔者有著乙個共同目標，那就是大家都想開發出乙個既能實現商業價值又能滿足使用者要求，還能使開發者感到滿足的優秀軟體產品。
客戶的需求觀
客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦（如一方要求而另一方不願意或不能夠滿足要求）。
1、 分析人員要使用符合客戶語言習慣的表達
需求討論集中於業務需求和任務，因此要使用術語。客戶應將有關術語（例如：採價、印花商品等採購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。
2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。
如果是切換新系統，那麼開發和分析人員應使用一下目前的舊系統，有利於他們明白目前系統是怎樣工作的，其流程情況以及可供改進之處。`
3、 分析人員必須編寫軟體需求報告
分析人員應將從客戶那裡獲得的所有資訊進行整理，以區分業務需求及規範、功能需求、質量目標、解決方法和其它資訊。通過這些分析，客戶就能得到乙份「需求分析報告」，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。
客戶要評審此報告，以確保報告內容準確完整地表達其需求。乙份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。
4、 要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文本性「需求分析報告」的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難於理解，但是客戶可能對此並不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。
5、 開發人員要尊重客戶的意見
如果使用者與開發人員之間不能相互理解，那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為專案成功所付出的時間，同樣，客戶也應對開發人員為專案成功這一共同目標所做出的努力表示尊重。
員工需求分析
員工需求之一 基本薪資和收入成長空間 基本薪資是員工普遍關注的需求。通過基本工資可以反映出以下問題 崗位高低及重要程度 一般企業在設定基本薪資的時候都會考慮職位 技術難度和崗位的重要程度等，因此基本薪資能夠反映崗位高低和重要程度，通過基本薪酬的區別員工可以找到自己的定位，同時也能通過這一點感受企業對...
需求分析報告
1.2.目錄需求分析的目的5 專案簡介5 1 2 3 4 專案商業目標5 專案所開發的系統的定義和用途5 專案的成本計畫5 開發期限5 3.專案可交付資料5 1 2 3 專案結束時客戶應接收到的資料5 專案結束時客戶不應接收到的資料5 滿足可交付資料所必需的產品6 4.系統使用者分析6 1 2 3 ...
需求分析報告
文件編號 no.001 版本號 1.0 文件名稱 需求規格說明書 專案名稱 c語言貪吃蛇 專案負責人 王阿海 編寫 王阿海 校對 車進輝 審核 車進輝 批准 車進輝 開發單位 北華大學計算機學院軟體工程 12 1 通過與多位軟體使用者進行全面深入地 和分析，並完成 貪吃蛇遊戲 市場的前期調查後，提出...