需求分析(一)概念、方法、實踐步驟

1、需求分析(一)概念、方法、實踐步驟 1.    概念、方法、實踐步驟需求分析階段主要通過收集、分析、導出的方法，將客戶、業(yè)務、用戶的需求轉換為對應的（軟件）系統(tǒng)需求的過程。典型的工作產品：軟件需求說明（Software Requirements Specifications，以下簡稱SRS）其主要包括系統(tǒng)基本概要、業(yè)務功能、系統(tǒng)功能（性能、安全性、信賴性、擴充性、移植性、多語言對應性等要求）、接口功能要求等內容。1.1 需求分析階段的主要活動需求分析階段的主要活動可以分為需求開發(fā)、需求管理2類：需求開發(fā)通過對客戶、業(yè)務、用戶、原系統(tǒng)等

2、調查獲取原始的需求，經過需求分析逐步識別并使業(yè)務具體化，通過形成制作規(guī)格說明書（或SRS）使業(yè)務系統(tǒng)化，項目團隊同客戶、用戶逐步達成共識對需求得以最終確認，其間可以通過系統(tǒng)建模、POC等方式評估需求的可實現性。需求管理在需求開發(fā)過程中，通過需求范圍認定、需求形式化記錄、需求數據庫建立、需求狀態(tài)跟蹤、需求變更分析和波動評估、需求評審控制等活動，通過使用需求管理工具等手段，實現對系統(tǒng)需求按基線進行控制和管理。其核心內容變更管理、版本管理以及需求跟蹤。1.2 需求開發(fā)的主要概念以及核心步驟   業(yè)務需求反映了企業(yè)或組織對（軟件）系統(tǒng)的業(yè)務要求，通常也包含問題或

3、機會的定義。問題是指企業(yè)或組織運作過程中遇到的問題，例如物資供應脫節(jié)、用戶投訴量大、客戶流失率較高等。機會是指抓住外部環(huán)境變化所帶來的機會，以便為企業(yè)帶來新的發(fā)展，例如電子商務、網上銀行、基于即時通信的工作協(xié)同系統(tǒng)等。業(yè)務需求通常由管理人員提出，業(yè)務需求的解決往往要結合制度、（人員）能力、系統(tǒng)功能等多方面綜合解決。另外,業(yè)務需求也反映了企業(yè)或組織對（軟件）系統(tǒng)的高層次目標要求，就是系統(tǒng)的建設的目的以及目標。用戶需求是指描述用戶使用（軟件）系統(tǒng)需要完成什么任務，怎么完成的需求，通常是在問題定義（業(yè)務需求）的基礎上進用戶訪談、調查，對用戶使用的場景進行整理，從而建立用戶角度的需求。解決如何使用（軟

4、件）系統(tǒng)完成具體工作。軟件系統(tǒng)需求是在業(yè)務需求的指導下，對用戶需求進行整理、分析、提煉，從而指導開發(fā)的、更精確的、規(guī)格化的需求。一般來說，軟件需求可以作為軟件驗收依據與合同契約。軟件系統(tǒng)需求可以分為業(yè)務功能需求、系統(tǒng)功能需求、設計約束等方面的內容。n  業(yè)務功能需求：（軟件）系統(tǒng)必須完成的業(yè)務功能，即為了向它的用戶提供有用的功能，產品必須執(zhí)行的動作。這部分工作將分散的用戶零散的需求采用結構化的方法去定義，以便支撐后續(xù)的設計、開發(fā)、測試。n  系統(tǒng)功能需求：（軟件）系統(tǒng)必須具備的功能、性能、屬性。包括系統(tǒng)性能（功能速度、響應時間、恢復時間等等）、可靠性、易

5、用性、安全性、移植、部署等方面的內容需求。n  設計約束的需求：影響系統(tǒng)實現的各種設計約束，包括開發(fā)語言、數據完整性方針、資源的限制、運行的環(huán)境的要求等等。 2.    主要流程需求分析階段的主要活動圍繞需求開發(fā)進行，包括制定及修改需求開發(fā)計劃、開展需求調查以及分析、需求驗證、需求規(guī)則說明制作、需求確認幾個步驟。1制定及修改需求開發(fā)計劃包括建立需求團隊的組織并授權、對需求分析階段的WBS進行分解、協(xié)商并制定調查分析以及評審計劃、評估工作量等等方面的內容，其目的是保證各項活動有序、可控的進行。2需求調查以及分析的過程，主要活動

6、通過溝通、收集項目中的各級關系人的需求，形成需求調查報告。需求調查通過現場參觀、開調查會、業(yè)務專家培訓、詢問溝通、設計調查表并調查、收集查閱記錄等方式獲取客戶、用戶各級組織對（軟件）系統(tǒng)需求，分析并識別客戶以及用戶的需要、期望、業(yè)務要求，歸納整理后形成需求調查報告。3需求驗證環(huán)節(jié)主要通過原型（Prototype）、POC（Proof of Concept）、用例（Use Case）或簡單的功能列表的方式同客戶、用戶溝通逐步將業(yè)務需求、用戶需求等轉化為軟件系統(tǒng)需求。· 原型（Prototype）模擬最終軟件的屏幕顯示，這樣用戶可以看到最終軟件將是什么樣，有些原型可以模擬實際的操作，對關

7、鍵的輸入輸出數據也可以一定程度的模擬。對于用戶體驗為主的系統(tǒng)往往可以起到很好的效果。· POC（Proof Of Concept）原意是“為觀點提供證據”。對于關鍵的技術或者業(yè)務模型，論證需求、設計的可實施性,評估和確認概念設計方案，POC的評價可能引起需求和設計的調整。一般來說，進行POC的條件：1. 論證業(yè)務中涉及到的模型或者算法的可行性。2. 論證技術模型實現的可行性、成本等。· 用例（Use Case）：對（軟件）系統(tǒng)如何反應外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術。每個用例提供了一個或多個場景，該場景說明了系統(tǒng)是如何同最終用戶或

8、其它系統(tǒng)交互(interact)的，也就是誰可以用系統(tǒng)做什么，從而獲得一個明確的業(yè)務目標。4. 需求規(guī)則說明(SRS)制作：通過需求調查和初步的需求驗證后，可以建立需求制作的準則，包括確認需求規(guī)則說明(SRS)的內容、制作方法、制作工具、質量標準等等。根據需求制作的準則制作需求規(guī)格說明（SRS）,好的需求規(guī)格說明（SRS）應該遵循正確、無歧義、完備、一致、分級（重要性或穩(wěn)定性）、可驗證、可修改、可追蹤的原則。5. 需求確認：通過組織各級評審對需求分析階段的產物，尤其最重要的結果產物需求規(guī)格說明（SRS）進行確認，以確保相關人員理解一致。從評審方法來說，可以根據情況分為需求開

9、發(fā)組組內評審、客戶外部評審、關鍵關系人評審等等。需求分析的流程往往因項目規(guī)模、作業(yè)人員、系統(tǒng)類型差異很大，因此必須根據實際的情況合理的裁減，以下舉例幾種不同情況下的具體流程：例：簡明的需求開發(fā)的流程 第1步:確定實現的目的、目標，基本業(yè)務需求、業(yè)務定義以及相關的評審。從達到目的、目標的角度，重新評審業(yè)務定義，總結業(yè)務需求。（確認客戶實施的業(yè)務要求 ）第2步:使業(yè)務具體化，進行軟件系統(tǒng)的定義（系統(tǒng)需求定義）。從目的的角度，進行業(yè)務定義（功能，步驟），對系統(tǒng)結構進行討論、對所要進行系統(tǒng)化或計算機化的功能、流程進行定義。第3步:一邊定義業(yè)務需求、系統(tǒng)需求、一邊對運行上的相關要求（

10、非功能需求）進行總結運行時間，安全應對、訪問權限等系統(tǒng)需求以及設計約束在業(yè)務需求的基礎之上、考慮系統(tǒng)上的限制條件之后逐步形成。  例：軟件工程類的典型流程主要特征：強調客戶協(xié)同、提高運作效率、屏蔽技術風險、加強邊界管控ü  強調同客戶協(xié)同，比如確定各種約定，包括截至時間、交流方式、成果物；ü  強調計劃管控，起目的確保進度和成本，人力資源合理使用；ü  采用問題回答管理票的方式加強需求團隊以及客戶的協(xié)同作業(yè)，提高生產效率，確保質量；ü  加強需求邊界管理，

11、控制項目整體成本；ü  提前對技術關鍵環(huán)節(jié)（技術解決方案、技術構架）進行論證，控制技術風險，減少技術帶來的成本損失；ü  強調需求最終確認；案例3：軟件產品類的典型流程主要特征：縮減開發(fā)周期、支撐跨部門運作、提高創(chuàng)造性、強調用戶體驗設計。ü  強調計劃性以加快研發(fā)進程，縮減產品開發(fā)周期。ü  強調跨部門協(xié)調組織，建立統(tǒng)一的需求團隊。ü  強調行業(yè)學習、創(chuàng)新以及交流。ü  分版本制作以適應產品的創(chuàng)造、快速變化、市場需求

12、的適應性、進程以及成本控制。ü  強調交互原型的重要性，加強用戶體驗性設計。 需求分析(二)內容 需求分析階段產物可以包括需求調查報告、需求規(guī)格說明、可行性報告等多方面的內容，但是一般來說需求規(guī)格說明（硬件、軟件）是最終的產物。過程中的關鍵產物還包括需求調查報告。3.1 需求調查報告通過現場參觀、開調查會、業(yè)務專家培訓、詢問溝通、設計調查表并調查、收集查閱記錄等方式獲取客戶、用戶各級組織對（軟件）系統(tǒng)需求，分析并識別客戶以及用戶的需要、期望、業(yè)務要求，歸納整理后形成需求調查報告。需求調查常作為一個中間過程成果，主要強調對業(yè)務、系統(tǒng)的現

13、狀進行歸納整理，同時對業(yè)務中的問題、各類期望以及優(yōu)化方案進行記錄和整理，通過初步分析形成結構化描述。一般需求調查報告包含目的、目標、范圍、業(yè)務域概述、組織機構以及對應的崗位權限、業(yè)務現狀、業(yè)務優(yōu)化的期望、業(yè)務規(guī)則（算法、邏輯）、輸入輸出數據、其他系統(tǒng)的交互（如果有）等內容。 1.業(yè)務領域業(yè)務領域主要梳理并整理項目的作業(yè)范圍，同時在業(yè)務上進行梳理了解并描述各領域間的關聯。 例 業(yè)務領域以及關聯關系  2.業(yè)務現狀業(yè)務現狀主要描述當前業(yè)務工作中的各種處理，可以通過業(yè)務流程描述（常見可以用泳道圖描述）、逐個業(yè)務場景描述、對系統(tǒng)功能需求描述、相關輸入輸

14、出信息以及優(yōu)化分析的期望等幾個方面進行描述。如果原業(yè)務有對應的（軟件）系統(tǒng)，也可以收集原系統(tǒng)的對應的資料進行整理。1)         業(yè)務場景描述: 對業(yè)務工作中的每個處理進行對應的描述，并通過記錄和整理形成結構化的場景描述。場景描述一般包括定義場景的名稱、場景相關的角色、場景的詳細描述、結果產出以及當前的存在的問題以及對應的期望。需要注意的是任何系統(tǒng)的引入都會一定程度地改變當前的工作模式和工作方法，所以對當前的存在的問題以及對應的期望的支撐程度往往決定了系統(tǒng)的價值，也必然是今后（軟件）系統(tǒng)的

15、焦點。當然這些問題以及期望可以采用多種方式解決，比如通過管理制度的建設、人員能力的加強、計算模型的優(yōu)化、系統(tǒng)化（計算機化）等等。其實需求分析階段的主要工作就是識別、分析那些工作是可以系統(tǒng)化或計算機化的工作，并輔助制度化管理流程、提高人員能力等工作提高作業(yè)的效率和質量。例，一個移動終端希望提高購物的便利性，哪些是可以系統(tǒng)化的呢？比如支付可以系統(tǒng)化做到移動支付，同時第3方支付還需要法律的支撐等等。  2)         業(yè)務功能需求描述：結合業(yè)務場景對系統(tǒng)的業(yè)務功能進行描述。一般包括前置

16、條件、輸入、輸出、業(yè)務規(guī)則、典型動作等。業(yè)務功能需求描述著眼于使業(yè)務具體化，進行（軟件）系統(tǒng)的需求調查或定義，描述方法也更加的結構化。這一步驟中，業(yè)務規(guī)則是重要的核心，是業(yè)務場景中具體處理的細節(jié)要求，一般包括處理的詳細流程、關鍵數據的計算方法、樣式要求等等內容。  3)         業(yè)務數據描述：對業(yè)務場景、業(yè)務功能需求中的輸入和輸出數據進行結構化整理的過程。多數新建系統(tǒng)，業(yè)務數據往往是分散和凌亂的，通過這個過程需要對相關的數據進行結構化的整理，并為后續(xù)的規(guī)格定義提供基礎。4)&#

17、160;        其他：對業(yè)務現狀整理過程，對一些過程性的資料比如原始的單據、表單通過掃描等方式進行收集匯總。對原系統(tǒng)可以通過收集設計資料、屏幕截圖等方式匯集整理。  3.2 軟件規(guī)格說明書(SRS)通過需求調查以及分析、需求驗證環(huán)節(jié)等步驟，需求規(guī)格說明書使業(yè)務具體化，最終對軟件以及硬件系統(tǒng)的功能進行明確定義。需求規(guī)格說明（SRS）對功能進行結構化的描述，以指導后續(xù)設計、開發(fā)、測試工作的開展。需求規(guī)格說明定義系統(tǒng)愿景、系統(tǒng)范圍、業(yè)務功能、系統(tǒng)功能、約束條件等方面的需求。主要描述系

18、統(tǒng)“What to do”，而后續(xù)的設計要描述系統(tǒng)“How to do”。 1. 項目目標&系統(tǒng)范圍項目目標&系統(tǒng)范圍描述項目發(fā)起的背景、希望解決的問題、系統(tǒng)的目的和目標以及核定項目的范圍。一般可以包含以下內容項目背景（Project Background）、現狀（Current Situation ）、當前面臨的問題（The issues we are facing now）、項目目的以及目標（Objectives & Goals）、項目范圍（Project Scope）、業(yè)務流程/功能范圍（Business Process/Functi

19、on Scope）、涉及組織范圍（Organization Scope）。1)       項目目的以及目標（Objectives & Goals）應著眼于（系統(tǒng)）未來的價值，它應該是可以量化、可評價、可實現、有價值的。系統(tǒng)的設計、開發(fā)、測試、驗證、發(fā)布、運行等工作都圍繞項目目的以及目標而進行。需要注意：項目目的以及目標應該細化分解成一些核心的指標，這些指標今后是可以量化或評定。比如“節(jié)省人力和物理的投入同時提升客戶滿意度”可以設定為“原有維護人員規(guī)?？梢钥s減75%，物理投入減少80%”等。設定明確的指標可以更加有效

20、的推動（軟件）系統(tǒng)、人員、制度的有效的結合，這個也是項目成功的必要條件。很多軟件項目到后期往往為了上線而上線，往往不能取得實際的效用，這個和前期目標不明確有關。實際上，當一個項目經過數人或數百人的數月或數年辛勤工作，經過了設計、開發(fā)、測試、反復的缺陷修正、上線以及運行后，也許值得欣慰的就是達成了項目目的以及目標。最悲劇的故事就是“不知道原來的目標是什么？”。項目目的以及目標也可以是多方面的，比如對用戶、操作員、管理人員、決策人員分別設定不同的目標，這些也是今后系統(tǒng)化以及設計的指導原則。制定項目目的以及目標需要多方面的反復討論和確認，尤其是項目的關鍵決策者。通過這些目的和目標，起碼我們可以明確這

21、個系統(tǒng)未來的價值。有些情況下，決策人員并不是這些方面的專家，需求開發(fā)人員應對需求及目標提出建議和解決方案，然后耐心等待決策環(huán)境的成熟，決策慢的一個好處就是可以減少決策失誤。2)       范圍可以包括項目范圍、業(yè)務范圍、功能范圍、組織范圍等等方面的內容，界定了那些工作是需要做的，那些不需要做。在項目中對于預算、成本、WBS、計劃等方面起決定性作用。  2. 業(yè)務功能需求業(yè)務功能需求往往主體描述系統(tǒng)"What to do"，不同類型的系統(tǒng)業(yè)務功能需求的側重點也不太相同，那么描

22、述的方法和內容也有差異。 不同類型系統(tǒng)業(yè)務功能需求的側重點不同n  聯機事務處理系統(tǒng)：主要的本質是流程的電子化，所以固化流程是主要工作，需求的描述也圍繞著流程進行。n  管理分析信息系統(tǒng)：主要的本質是數據信息化，需求的描述圍繞著信息數據加工，即數據的輸入、變換、處理、輸出，報表往往需求的關鍵線索。n  監(jiān)控系統(tǒng)：主要的本質是數據收集、狀態(tài)控制等方面的內容，其本質往往是狀態(tài)的管理、接口標準的處理。這也是為什么在通過需求調查和初步的需求驗證后，需要討論并建立需求制作的準則，針對不同類型的系統(tǒng)，采用適合的方式、方法、工具來更有效的

23、描述業(yè)務功能需求。無論采用什么方式、方法描述，那么業(yè)務功能需求的共性內容包括:業(yè)務領域、組織機構、崗位、權限、功能（用例）清單、用例說明、界面交互、數據實體、接口、規(guī)則模型等。1)       業(yè)務領域范圍：主要描述業(yè)務、功能的分類以及對應的范圍。 2)       組織機構、崗位、權限：主要包含系統(tǒng)涉及的組織、崗位、權限的要求。一般內容包括組織體系圖、崗位說明、業(yè)務以及系統(tǒng)相關的權限要求。 系統(tǒng)功能以及數據相關的權限要求，往往會貫穿整

24、個需求規(guī)格書的各個章節(jié)。這種情況下，我們可以將權限要求匯集在一個單獨的章節(jié)中，以便其他章節(jié)引用。另外，權限相關的內容在系統(tǒng)實際導入的時候，還需要更具體的需求，比如哪些人、哪些功能等等。 3)       功能（用例）清單：根據需求分析的結果，對業(yè)務逐步進行分類，對每個分類進行細化梳理功能，形成用例清單。功能（用例）清單一般包括分類、功能概要說明、功能編號等等方面的內容。   4)       用例說明: 一

25、般包含用例對應的編號、名稱、場景概要描述、前置條件、流程、前置條件、業(yè)務規(guī)則等內容。對于復雜的流程，也可以用流程圖的方式描述對應的流程 5)       界面交互：界面交互往往是關注的重點，在需求分析階段可以通過原型的方法同客戶溝通并驗證業(yè)務需求。對于界面交互比較重要的項目，可以詳細描述頁面的需求，一般包括以下內容：界面的遷移、界面原型或式樣（可以采用高保真圖或線框圖）、界面元素（輸入、輸出）、界面動作等等。例, 界面的遷移：描述畫面以及處理間的關系。  例，界面線框圖：用來描述界面的

26、式樣,一般可以用一些簡單快捷的工具制作。 6)       數據實體：記錄業(yè)務過程中的輸入、輸出數據的詳細內容。7)       接口說明：本系統(tǒng)內部以及其他系統(tǒng)間的接口，接口需求因不同業(yè)務功能差異很大，通常接口需求涉及模塊對象、處理流程（時序）、性能以及容量、數據傳輸、數據格式、安全等方面的內容。8)       規(guī)則模型：在業(yè)務處理中的專用的規(guī)則模型，比如核心的預算預估模型

27、、各類精算模型、成本歸集模型、圖像處理識別模型、溫度控制模型、GIS中犯罪軌跡追蹤模型等等。規(guī)則模型往往建立在一定的專業(yè)基礎上，在理論模型的基礎根據實際情況進行修正優(yōu)化。規(guī)則模型的需求內容要根據實際的情況進行確定。常見的內容有基本模型、優(yōu)化模型、配置調優(yōu)等方面的內容。 3. 系統(tǒng)功能需求系統(tǒng)功能需求指除了業(yè)務功能外，系統(tǒng)本身根據項目目標、目的以及支撐業(yè)務功能的實現，（軟件）系統(tǒng)本身應該具有的功能需求，一般來說系統(tǒng)功能包含質量、性能等方面的屬性。一般有性能（運行速度、響應性、在線用戶量等）、安全和保密、可靠性、運行、移植、維護、部署、數據容量等方面的系統(tǒng)功能需求。常見的系統(tǒng)功

28、能需求種類有： 常見的系統(tǒng)功能需求種類經驗匯總1)   系統(tǒng)功能性需求：工作流功能、系統(tǒng)離線功能、版本發(fā)布管理功能、搜索功能、日志管理、配置管理、系統(tǒng)異常處理以及通知機制、報表生成以及定制機制等等。2)   易用性需求:多設備支持、多語言支持、多瀏覽器支持、自適應界面調整、系統(tǒng)超時數據自動保存、用戶操作易用性（包括易理解性、易學習性、易操作性）。3)   可靠性需求：架構可靠性、數據及操作可靠性、操作以及數據容錯處理需求（比如系統(tǒng)應有全面、完善的檢驗和明確的錯誤提示信息，系統(tǒng)界面被破壞或系統(tǒng)發(fā)生

29、故障，系統(tǒng)仍能給予操作者必要的提示，使其按照相關提示退出系統(tǒng)，并最大程度保留用戶的工作成果。）4)   性能需求:用戶數量、頁面（接口）訪問性能要求、數據同步性能要求、各應用場景（比如模塊、網絡、數據庫、Web、應用、接口及業(yè)務場景）的性能以及容量要求、超長時間操作處理需求。5)   可擴展性、兼容性需求：系統(tǒng)在技術架構上、各類功能、接口、標準以及系統(tǒng)部署上支持可擴展性需求。對軟件、硬件等環(huán)境的兼容性。6)   安全性需求：多重組織架構體系安全支撐、權限控制（用戶組、用戶、角色）及設置、安全構架集成、應用

30、安全控制、數據以及傳輸安全、數據備份安全、數據操作安全等7)   維護需求：系統(tǒng)上線以及更新需求、數據管理/數據遷移/數據維護需求，包括數據同步、數據管理工具、數據清洗、數據補采、數據補錄等方面的需求。8)   災難備份需求：硬件、軟件、數據、網絡等對應自然、病毒等災難的處理需求。9)   可配置性需：用戶界面及系統(tǒng)功能配置需求、系統(tǒng)基礎數據配置需求、系統(tǒng)后臺配置需求等。10)  系統(tǒng)環(huán)境需求：在開發(fā)、測試、生產、培訓等環(huán)境的數據以及應用多種環(huán)境應用需求，服務器在各種溫度、濕度、磁場、

31、能耗下的環(huán)境需求。11)  用戶文檔及幫助系統(tǒng)需求：業(yè)務操作相關、系統(tǒng)開發(fā)相關各類學習、培訓、實踐需求。12)  支持性/服務性需求：系統(tǒng)日志功能、系統(tǒng)配置、狀態(tài)監(jiān)控、數據異常處理（工具）等需求。 4. 約束條件約束條件一般指由其他標準、硬件局限等引發(fā)的設計約束。常見的約束條件有：網絡帶寬以及環(huán)境約束、客戶端選型約束、服務器端操作系統(tǒng)約束、數據庫選型約束、開發(fā)環(huán)境選型約束（比如開發(fā)語言）、開發(fā)的結構（比如B/S,C/S結構導致的設計差異）、法律法規(guī)、各類業(yè)務標準、運行環(huán)境（比如設備能耗、內存、CPU使用率）等等。需求分析(三)關鍵點4

32、.    關鍵點（Know-How）、運用技巧4.1作業(yè)準則以及管理準則 需求分析的流程往往因項目規(guī)模、作業(yè)人員、系統(tǒng)類型差異很大，因此必須根據實際的情況合理的裁減。從軟件工程的角度來說，需求分析階段可以將需求開發(fā)的各種活動，形成對應的“作業(yè)準則”比如定義階段控制目標（過程目標、質量目標、生產效率目標）、階段入口準則、階段執(zhí)行的相關準則、階段過程定義（輸入、執(zhí)行步驟、出口準則、輸出）、定義質量保證點、成果物等。除圍繞需求開發(fā)的各種活動外，還有圍繞著需求變更管理、版本管理、需求跟蹤、進度、成本管控等各種需求管理活動。比如常見的有評審管理流程、（文

33、件）版本管理、需求變更管理、問題跟蹤管理、（需求）跟蹤矩陣管理、決策管理、風險管理、會議管理、工作匯報管理、考勤請假管理、非正式交付物管理、正式交付物管理、需求調查準入標準等等多方面的流程，這些可以形成需求分析階段的“管理準則”。通過“作業(yè)準則”以及“管理準則”可以控制整個需求開發(fā)階段的進程、質量以及成本。4.2 需求驗證1. Q&A管理軟件開發(fā)的過程實際上是個學習的過程，在學習中每個人（包括客戶、用戶、設計、開發(fā)、測試人員）理解以及學習的速度是不同的，軟件工程的過程從某種意義上就是協(xié)同團隊中的每個人學習進度。既然是學習那么就會有多種多樣的問題，快速解答問題顯然是非常重要的環(huán)節(jié)。Q&a

34、mp;A(問題&回答)的管理實際貫穿整個工程的生命周期，在需求分析階段， Q&A(問題&回答)的管理可以加快項目團隊內部的學習以及加速項目團隊同客戶、用戶的溝通。Q&A(問題&回答)的管理過程并不復雜，主要就是提出問題、內部知識共享解決、外部確認解決、監(jiān)控并管理整個過程。Q&A(問題&回答)經?？梢院唵蔚夭捎肊XCEL表的形式（也可以項目組、客戶、用戶共同使用專門的系統(tǒng)來共享），定期發(fā)送給相關人員，這樣可以非實時的處理，不影響正常的工作。另外，Q&A(問題&回答)可以在固定的時期，集中的進行處理，以加快確認的過程。2.&#

35、160;原型原型模型本身是一個迭代的模型，是為了解決在產品或系統(tǒng)開發(fā)的早期階段存在的不確定性、二義性和不完整性等問題。原型是（軟件）系統(tǒng)一個早期可以運行的版本，它反映了系統(tǒng)的部分重要的特性，用于試驗和評價，以指導后續(xù)的設計、開發(fā)、測試等工作。通過建立產品原型使相關人員更易理解系統(tǒng)未來的功能。原型只是真實系統(tǒng)的一部分或一個模型，部分實現了產品或系統(tǒng)的功能。比如，在一些交互性系統(tǒng)中，可以模擬實際的操作，甚至對關鍵的輸入輸出數據也可以一定程度的模擬。這樣用戶可以感受到今后系統(tǒng)的功能。一般通過原型可以更快的確認系統(tǒng)的交互部分，比如系統(tǒng)的操作、畫面的遷移、畫面（風格外觀、動作、要素等）等多方面的內容，所

36、以在以交互為主的系統(tǒng)需求開發(fā)的早期就可以開展原型制作的工作。原型的開發(fā)要根據情況制定一些策略，一般考慮的要點如下：1)   原型是拋棄型還是進化型。原型中哪些內容可以在后續(xù)工程中復用。2)   原型設計、開發(fā)過程中是否要驗證技術的可行性、是否要驗證工作效率以及工作方法的可用性。3)   設計團隊中是否配置了原型的開發(fā)所需要的設計、開發(fā)、測試人員。4)   系統(tǒng)中哪些部分需要采用原型的方式，加強同客戶、用戶的驗證。比如關鍵或復雜的部分功能進行原型制作，或將業(yè)務歸納成幾種模式，對

37、不同的模式制作對應的原型等等。5)   制作原型所需要的預算、時間、成本等。有些原型的制作也需要不少的工作量，有些情況下原型制作本身就是一個單獨的項目。比如，有些方案供應商就預先開發(fā)原型，以便爭取項目的合同。同時有些項目在招標的時候，就要求必須對核心功能提供必要的原型等等。6)   制作原型的所采用的快速工具，比如WEB站點的原型，如何有開發(fā)人員的參與的情況下，可以直接用HTML制作原型，不然也可以用PPT或其他工具“畫”出原型。7)   原型除能確認系統(tǒng)的操作、畫面的遷移、畫面（風格外觀、動作、要素等）

38、等方面的內容外，也可以對關鍵數據進行確認，所以有些情況下，還需要考慮對原型所涉及的數據（尤其業(yè)務數據）進行專門的制作。從工作實踐中經驗證明，對于一些較為業(yè)務復雜或更關注交互的系統(tǒng)來說，需求分析階段在規(guī)劃的時候，就應考慮制作原型并配置對應的原型開發(fā)隊伍（設計、開發(fā)、測試），對原型的目標建立、功能選擇、構造確認、評價等過程進行合理管理，可以降低整理項目的技術、業(yè)務、人員、過程中的風險。3. POC驗證n     POC（Proof Of Concept）原意是“為觀點提供證據”，本質上是一種重要的評估技術。對于系統(tǒng)中的關鍵技術或者業(yè)務模型，論證團隊

39、和客戶的設計，評估和確認概念設計方案，POC的評價可能引起需求和設計的調整。為屏蔽系統(tǒng)存在的業(yè)務或技術風險，在系統(tǒng)需求、設計的早期，我們可以設定POC來評估和確認這些業(yè)務或技術的模型，以減少項目的風險。對軟件系統(tǒng)的研發(fā)而言，POC 的目的是為系統(tǒng)確定合適的業(yè)務模型（流程、方法等）、核心功能對應的實現方法、系統(tǒng)構架、系統(tǒng)或軟件產品版本、有效技術方案以及運行維護等服務的方案等內容，或者驗證建議的方案可行性。POC的最大價值在于在正式設計或規(guī)模實施以前，選擇最優(yōu)的方案。比如POC 在核心技術上的驗證內容可以有：消息中間件、工作流、數據庫、瀏覽器、跨設備、UI控件、報表、共通組件、系統(tǒng)集成等等方面的內容。         POC作為一種重要的評估技術，過程上可以歸納為以下幾步：1.         收集并識別來自業(yè)務、技術等方面的風險。2.         評估、決策那些內容實施POC。POC的實施往往需要花費不少的時間和資源，應合理控制PO