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

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

2、通過形成制作規(guī)格說明書（或 SRS）使業(yè)務(wù)系統(tǒng)化， 項目團隊同客戶、用戶逐步達成共識對需求得以最終確認(rèn)，其間可以通過系統(tǒng)建模、POC等方式評估需求的可實現(xiàn)性。需求管理在需求開發(fā)過程中，通過需求范圍認(rèn)定、需求形式化記錄、需求數(shù)據(jù)庫建立、需求狀態(tài)跟蹤、 需求變更分析和波動評估、需求評審控制等活動，通過使用需求管理工具等手段， 實現(xiàn)對系統(tǒng)需求按基線進行控制和管理。 其核心內(nèi)容變更管理、 版本管理以及需求跟蹤。1.2需求開發(fā)的主要概念以及核心步驟業(yè)務(wù)需求反映了企業(yè)或組織對（軟件）系統(tǒng)的業(yè)務(wù)要求， 通常也包含問題或機會的定義。問題是指企業(yè)或組織運作過程中遇到的問題，例如物資供應(yīng)脫節(jié)、用戶投訴量大、 客戶

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

4、、分析、提煉，從而指導(dǎo)開發(fā)的、更精確的、規(guī)格化的需求。一般來說，軟件需求可以作為軟件驗收依據(jù)與合同契約。軟件系統(tǒng)需求可以分為業(yè)務(wù)功能需求、系統(tǒng)功能需求、設(shè)計約束等方面的內(nèi)容。業(yè)務(wù)功能需求： （軟件） 系統(tǒng)必須完成的業(yè)務(wù)功能，即為了向它的用戶提供有用的功能，產(chǎn)品必須執(zhí)行的動作。 這部分工作將分散的用戶零散的需求采用結(jié)構(gòu)化的方法去定義，以便支撐后續(xù)的設(shè)計、開發(fā)、測試。系統(tǒng)功能需求 ：（軟件）系統(tǒng)必須具備的功能、性能、屬性。包括系統(tǒng)性能（功能速度、響應(yīng)時間、恢復(fù)時間等等）、可靠性、易用性、安全性、移植、部署等方面的內(nèi)容需求。設(shè)計約束的需求： 影響系統(tǒng)實現(xiàn)的各種設(shè)計約束， 包括開發(fā)語言、 數(shù)據(jù)完整性方

5、針、資源的限制、運行的環(huán)境的要求等等。2.主要流程需求分析階段的主要活動圍繞需求開發(fā)進行，包括 制定及修改需求開發(fā)計劃、開展需求調(diào)查以及分析、需求驗證、需求規(guī)則說明制作、需求確認(rèn)幾個步驟。1制定及修改需求開發(fā)計劃包括建立需求團隊的組織并授權(quán)、對需求分析階段的WBS進行分解、 協(xié)商并制定調(diào)查分析以及評審計劃、 評估工作量等等方面的內(nèi)容， 其目的是保證各項活動有序、可控的進行。2需求調(diào)查以及分析的過程，主要活動通過溝通、收集項目中的各級關(guān)系人的需求，形成需求調(diào)查報告。需求調(diào)查通過現(xiàn)場參觀、開調(diào)查會、業(yè)務(wù)專家培訓(xùn)、詢問溝通、設(shè)計調(diào)查表并調(diào)查、收集查閱記錄等方式獲取客戶、用戶各級組織對（軟件）系統(tǒng)需求

6、，分析并識別客戶以及用戶的需要、期望、業(yè)務(wù)要求，歸納整理后形成需求調(diào)查報告。3需求驗證環(huán)節(jié)主要通過原型（ Prototype ）、 POC（ Proof of Concept ）、用例（ Use Case）或簡單的功能列表的方式同客戶、 用戶溝通逐步將業(yè)務(wù)需求、 用戶需求等轉(zhuǎn)化為軟件系統(tǒng)需求。? 原型（ Prototype ）模擬最終軟件的屏幕顯示，這樣用戶可以看到最終軟件將是什么樣， 有些原型可以模擬實際的操作， 對關(guān)鍵的輸入輸出數(shù)據(jù)也可以一定程度的模擬。對于用戶體驗為主的系統(tǒng)往往可以起到很好的效果。? POC（Proof Of Concept ）原意是“為觀點提供證據(jù)”。對于關(guān)鍵的技術(shù)或者

7、業(yè)務(wù)模型，論證需求、設(shè)計的可實施性, 評估和確認(rèn)概念設(shè)計方案， POC的評價可能引起需求和設(shè)計的調(diào)整。一般來說，進行POC的條件： 1.論證業(yè)務(wù)中涉及到的模型或者算法的可行性。2.論證技術(shù)模型實現(xiàn)的可行性、成本等。? 用例（ Use Case）：對（軟件）系統(tǒng)如何反應(yīng)外界請求的描述，是一種通過用戶的使用場景來獲取需求的技術(shù)。 每個用例提供了一個或多個場景， 該場景說;.明了系統(tǒng)是如何同最終用戶或其它系統(tǒng)交互(interact)的，也就是誰可以用系統(tǒng)做什么，從而獲得一個明確的業(yè)務(wù)目標(biāo)。4. 需求規(guī)則說明 (SRS)制作：通過需求調(diào)查和初步的需求驗證后，可以建立需求制作的準(zhǔn)則，包括確認(rèn)需求規(guī)則說明

8、 (SRS) 的內(nèi)容、制作方法、制作工具、質(zhì)量標(biāo)準(zhǔn)等等。根據(jù)需求制作的準(zhǔn)則制作需求規(guī)格說明（ SRS） , 好的需求規(guī)格說明（ SRS）應(yīng)該遵循正確、無歧義、完備、一致、分級（重要性或穩(wěn)定性）、可驗證、可修改、可追蹤的原則。5.需求確認(rèn)： 通過組織各級評審對需求分析階段的產(chǎn)物，尤其最重要的結(jié)果產(chǎn)物需求規(guī)格說明（ SRS）進行確認(rèn)，以確保相關(guān)人員理解一致。從評審方法來說，可以根據(jù)情況分為需求開發(fā)組組內(nèi)評審、客戶外部評審、關(guān)鍵關(guān)系人評審等等。需求分析的流程往往因項目規(guī)模、 作業(yè)人員、 系統(tǒng)類型差異很大， 因此必須根據(jù)實際的情況合理的裁減，以下舉例幾種不同情況下的具體流程：例：簡明的需求開發(fā)的流程第

9、 1 步: 確定實現(xiàn)的目的、目標(biāo)，基本業(yè)務(wù)需求、業(yè)務(wù)定義以及相關(guān)的評審。從達到目的、目標(biāo)的角度，重新評審業(yè)務(wù)定義，總結(jié)業(yè)務(wù)需求。 （確認(rèn)客戶實施的業(yè)務(wù)要求 ）第 2 步: 使業(yè)務(wù)具體化，進行軟件系統(tǒng)的定義（系統(tǒng)需求定義）。從目的的角度，進行業(yè)務(wù)定義（功能，步驟），對系統(tǒng)結(jié)構(gòu)進行討論、對所要進行系統(tǒng)化或計算機化的功能、流程進行定義。第 3 步: 一邊定義業(yè)務(wù)需求、系統(tǒng)需求、一邊對運行上的相關(guān)要求（非功能需求）進行總結(jié)運行時間， 安全應(yīng)對、 訪問權(quán)限等系統(tǒng)需求以及設(shè)計約束在業(yè)務(wù)需求的基礎(chǔ)之上、考慮系統(tǒng)上的限制條件之后逐步形成。例：軟件工程類的典型流程;.主要特征：強調(diào)客戶協(xié)同、提高運作效率、屏蔽技

10、術(shù)風(fēng)險、加強邊界管控? 強調(diào)同客戶協(xié)同，比如確定各種約定，包括截至?xí)r間、交流方式、成果物；? 強調(diào)計劃管控，起目的確保進度和成本，人力資源合理使用；? 采用問題回答管理票的方式加強需求團隊以及客戶的協(xié)同作業(yè)，提高生產(chǎn)效率，確保質(zhì)量；? 加強需求邊界管理，控制項目整體成本；? 提前對技術(shù)關(guān)鍵環(huán)節(jié)（技術(shù)解決方案、技術(shù)構(gòu)架）進行論證，控制技術(shù)風(fēng)險，減少技術(shù)帶來的成本損失；? 強調(diào)需求最終確認(rèn)；案例 3：軟件產(chǎn)品類的典型流程主要特征：縮減開發(fā)周期、支撐跨部門運作、提高創(chuàng)造性、強調(diào)用戶體驗設(shè)計。? 強調(diào)計劃性以加快研發(fā)進程，縮減產(chǎn)品開發(fā)周期。? 強調(diào)跨部門協(xié)調(diào)組織，建立統(tǒng)一的需求團隊。? 強調(diào)行業(yè)學(xué)習(xí)、

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

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

13、的期望等幾個方面進行描述。 如果原業(yè)務(wù)有對應(yīng)的 （軟件）系統(tǒng)， 也可以收集原系統(tǒng)的對應(yīng)的資料進行整理。1) 業(yè)務(wù)場景描述 : 對業(yè)務(wù)工作中的每個處理進行對應(yīng)的描述， 并通過記錄和整理形成結(jié)構(gòu)化的場景描述。 場景描述一般包括定義場景的名稱、 場景相關(guān)的角色、 場景的詳細描述、 結(jié)果產(chǎn)出以及當(dāng)前的存在的問題以及對應(yīng)的期望。需要注意的是任何系統(tǒng)的引入都會一定程度地改變當(dāng)前的工作模式和工作方法，所以對當(dāng)前的存在的問題以及對應(yīng)的期望的支撐程度往往決定了系統(tǒng)的價值，也必然是今后 （軟件）系統(tǒng)的焦點。當(dāng)然這些問題以及期望可以采用多種方式解決，比如通過管理制度的建設(shè)、人員能力的加強、計算模型的優(yōu)化、系統(tǒng)化（計

14、算機化）等等。其實需求分析階段的主要工作就是識別、分析那些工作是可以系統(tǒng)化或計算機化的工作，并輔助制度化管理流程、提高人員能力等工作提高作業(yè)的效率和質(zhì)量。例，一個移動終端希望提高購物的便利;.性，哪些是可以系統(tǒng)化的呢？比如支付可以系統(tǒng)化做到移動支付，同時第 3 方支付還需要法律的支撐等等。2) 業(yè)務(wù)功能需求描述：結(jié)合業(yè)務(wù)場景對系統(tǒng)的業(yè)務(wù)功能進行描述。一般包括前置條件、輸入、輸出、業(yè)務(wù)規(guī)則、典型動作等。業(yè)務(wù)功能需求描述著眼于使業(yè)務(wù)具體化，進行（軟件）系統(tǒng)的需求調(diào)查或定義，描述方法也更加的結(jié)構(gòu)化。這一步驟中，業(yè)務(wù)規(guī)則是重要的核心，是 業(yè)務(wù)場景中具體處理的細節(jié)要求，一般包括處理的詳細流程、關(guān)鍵數(shù)據(jù)的

15、計算方法、樣式要求等等內(nèi)容。3) 業(yè)務(wù)數(shù)據(jù)描述：對業(yè)務(wù)場景、業(yè)務(wù)功能需求中的輸入和輸出數(shù)據(jù)進行結(jié)構(gòu)化整理的過程。 多數(shù)新建系統(tǒng)， 業(yè)務(wù)數(shù)據(jù)往往是分散和凌亂的， 通過這個過程需要對相關(guān)的數(shù)據(jù)進行結(jié)構(gòu)化的整理，并為后續(xù)的規(guī)格定義提供基礎(chǔ)。4) 其他：對業(yè)務(wù)現(xiàn)狀整理過程，對一些過程性的資料比如原始的單據(jù)、表單通過掃描等方式進行收集匯總。 對原系統(tǒng)可以通過收集設(shè)計資料、 屏幕截圖等方式匯集整理。3.2軟件規(guī)格說明書 (SRS)通過需求調(diào)查以及分析、需求驗證環(huán)節(jié)等步驟，需求 規(guī)格說明書 使業(yè)務(wù)具體化， 最終對軟件以及硬件系統(tǒng)的功能進行明確定義。需求規(guī)格說明（SRS）對功能進行結(jié)構(gòu)化的描述，以指導(dǎo)后續(xù)設(shè)計

16、、開發(fā)、測試工作的開展。需求規(guī)格說明定義系統(tǒng)愿景、系統(tǒng)范圍、業(yè)務(wù)功能、系統(tǒng)功能、約束條件等方面的需求。主要描述系統(tǒng)“What to do”，而后續(xù)的設(shè)計要描述系統(tǒng)“ How to do ”。;.1. 項目目標(biāo) &系統(tǒng)范圍項目目標(biāo) &系統(tǒng)范圍描述項目發(fā)起的背景、希望解決的問題、系統(tǒng)的目的和目標(biāo)以及核定項目的范圍。一般可以包含以下內(nèi)容項目背景（Project Background）、現(xiàn)狀（ CurrentSituation）、當(dāng)前面臨的問題（The issues we are facing now）、項目目的以及目標(biāo)（ Objectives & Goals ）、項目范圍（

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

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

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

20、聯(lián)機事務(wù)處理系統(tǒng)：主要的本質(zhì)是流程的電子化，所以固化流程是主要工作，需求的描述也圍繞著流程進行。管理分析信息系統(tǒng)： 主要的本質(zhì)是數(shù)據(jù)信息化， 需求的描述圍繞著信息數(shù)據(jù)加工， 即數(shù)據(jù)的輸入、 變換、處理、輸出，報表往往需求的關(guān)鍵線索。;.監(jiān)控系統(tǒng)：主要的本質(zhì)是數(shù)據(jù)收集、狀態(tài)控制等方面的內(nèi)容，其本質(zhì)往往是狀態(tài)的管理、接口標(biāo)準(zhǔn)的處理。這也是為什么在通過需求調(diào)查和初步的需求驗證后，需要討論并建立需求制作的準(zhǔn)則，針對不同類型的系統(tǒng)，采用適合的方式、方法、工具來更有效的描述業(yè)務(wù)功能需求。無論采用什么方式、方法描述，那么業(yè)務(wù)功能需求的共性內(nèi)容包括: 業(yè)務(wù)領(lǐng)域、組織機構(gòu)、崗位、權(quán)限、功能（用例）清單、用例說明

21、、界面交互、數(shù)據(jù)實體、接口、規(guī)則模型等。1) 業(yè)務(wù)領(lǐng)域范圍：主要描述業(yè)務(wù)、功能的分類以及對應(yīng)的范圍。2) 組織機構(gòu)、崗位、權(quán)限：主要包含系統(tǒng)涉及的組織、崗位、權(quán)限的要求。一般內(nèi)容包括組織體系圖、崗位說明、業(yè)務(wù)以及系統(tǒng)相關(guān)的權(quán)限要求。系統(tǒng)功能以及數(shù)據(jù)相關(guān)的權(quán)限要求，往往會貫穿整個需求規(guī)格書的各個章節(jié)。這種情況下，我們可以將權(quán)限要求匯集在一個單獨的章節(jié)中，以便其他章節(jié)引用。另外，權(quán)限相關(guān)的內(nèi)容在系統(tǒng)實際導(dǎo)入的時候，還需要更具體的需求，比如哪些人、哪些功能等等。3) 功能（用例）清單：根據(jù)需求分析的結(jié)果，對業(yè)務(wù)逐步進行分類，對每個分類進行細化梳理功能，形成用例清單。功能（用例）清單一般包括分類、功能

22、概要說明、功能編號等等方面的內(nèi)容。4) 用例說明 : 一般包含用例對應(yīng)的編號、名稱、場景概要描述、前置條件、流程、前置條件、業(yè)務(wù)規(guī)則等內(nèi)容。對于復(fù)雜的流程，也可以用流程圖的方式描述對應(yīng)的流程5) 界面交互： 界面交互往往是關(guān)注的重點， 在需求分析階段可以通過原型的方法同客戶溝通并驗證業(yè)務(wù)需求。對于界面交互比較重要的項目，可以詳細描述頁面的需求，一般包括以下內(nèi)容：界面的遷移、界面原型或式樣（可以采用高保真圖或線框圖）、界面元素（輸入、輸出）、界面動作等等。例 , 界面的遷移：描述畫面以及處理間的關(guān)系。例，界面線框圖：用來描述界面的式樣, 一般可以用一些簡單快捷的工具制作。6) 數(shù)據(jù)實體：記錄業(yè)務(wù)

23、過程中的輸入、輸出數(shù)據(jù)的詳細內(nèi)容。7) 接口說明：本系統(tǒng)內(nèi)部以及其他系統(tǒng)間的接口，接口需求因不同業(yè)務(wù)功能差異很大，通常接口需求涉及模塊對象、 處理流程（時序） 、性能以及容量、 數(shù)據(jù)傳輸、 數(shù)據(jù)格式、安全等方面的內(nèi)容。8)規(guī)則模型： 在業(yè)務(wù)處理中的專用的規(guī)則模型，比如核心的預(yù)算預(yù)估模型、各類精算模型、成本歸集模型、 圖像處理識別模型、溫度控制模型、 GIS 中犯罪軌跡追蹤模型等等。規(guī)則模型往往建立在一定的專業(yè)基礎(chǔ)上，在理論模型的基礎(chǔ)根據(jù)實際情況進行修正優(yōu)化。;.規(guī)則模型的需求內(nèi)容要根據(jù)實際的情況進行確定。常見的內(nèi)容有基本模型、優(yōu)化模型、配置調(diào)優(yōu)等方面的內(nèi)容。3. 系統(tǒng)功能需求系統(tǒng)功能需求指除了

24、業(yè)務(wù)功能外， 系統(tǒng)本身根據(jù)項目目標(biāo)、 目的以及支撐業(yè)務(wù)功能的實現(xiàn)，（軟件）系統(tǒng)本身應(yīng)該具有的功能需求，一般來說系統(tǒng)功能包含質(zhì)量、性能等方面的屬性。一般有性能 （運行速度、 響應(yīng)性、 在線用戶量等） 、安全和保密、 可靠性、 運行、移植、維護、部署、數(shù)據(jù)容量等方面的系統(tǒng)功能需求。常見的系統(tǒng)功能需求種類有：常見的系統(tǒng)功能需求種類經(jīng)驗匯總1) 系統(tǒng)功能性需求：工作流功能、系統(tǒng)離線功能、版本發(fā)布管理功能、搜索功能、日志管理、配置管理、系統(tǒng)異常處理以及通知機制、報表生成以及定制機制等等。2) 易用性需求 : 多設(shè)備支持、多語言支持、多瀏覽器支持、自適應(yīng)界面調(diào)整、系統(tǒng)超時數(shù)據(jù)自動保存、用戶操作易用性（包括

25、易理解性、易學(xué)習(xí)性、易操作性）。3) 可靠性需求：架構(gòu)可靠性、數(shù)據(jù)及操作可靠性、操作以及數(shù)據(jù)容錯處理需求（比如系統(tǒng)應(yīng)有全面、完善的檢驗和明確的錯誤提示信息， 系統(tǒng)界面被破壞或系統(tǒng)發(fā)生故障， 系統(tǒng)仍能給予操作者必要的提示，使其按照相關(guān)提示退出系統(tǒng)，并最大程度保留用戶的工作成果。）4) 性能需求 : 用戶數(shù)量、頁面（接口）訪問性能要求、數(shù)據(jù)同步性能要求、各應(yīng)用場景（比如模塊、網(wǎng)絡(luò)、數(shù)據(jù)庫、 Web、應(yīng)用、接口及業(yè)務(wù)場景）的性能以及容量要求、超長時間操作處理需求。5) 可擴展性、兼容性需求：系統(tǒng)在技術(shù)架構(gòu)上、各類功能、接口、標(biāo)準(zhǔn)以及系統(tǒng)部署上支持可擴展性需求。對軟件、硬件等環(huán)境的兼容性。6) 安全性

26、需求：多重組織架構(gòu)體系安全支撐、權(quán)限控制（用戶組、用戶、角色）及設(shè)置、安全構(gòu)架集成、應(yīng)用安全控制、數(shù)據(jù)以及傳輸安全、數(shù)據(jù)備份安全、數(shù)據(jù)操作安全等7) 維護需求：系統(tǒng)上線以及更新需求、數(shù)據(jù)管理/ 數(shù)據(jù)遷移 / 數(shù)據(jù)維護需求，包括數(shù)據(jù)同步、數(shù)據(jù)管理工具、數(shù)據(jù)清洗、數(shù)據(jù)補采、數(shù)據(jù)補錄等方面的需求。8) 災(zāi)難備份需求：硬件、軟件、數(shù)據(jù)、網(wǎng)絡(luò)等對應(yīng)自然、病毒等災(zāi)難的處理需求。9) 可配置性需：用戶界面及系統(tǒng)功能配置需求、系統(tǒng)基礎(chǔ)數(shù)據(jù)配置需求、系統(tǒng)后臺配置需求等。10) 系統(tǒng)環(huán)境需求：在開發(fā)、測試、生產(chǎn)、培訓(xùn)等環(huán)境的數(shù)據(jù)以及應(yīng)用多種環(huán)境應(yīng)用需求，服務(wù)器在各種溫度、濕度、磁場、能耗下的環(huán)境需求。11) 用戶

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

28、分析的流程往往因項目規(guī)模、作業(yè)人員、系統(tǒng)類型差異很大，因此必須根據(jù)實際的情況合理的裁減。從軟件工程的角度來說， 需求分析階段可以將需求開發(fā)的各種活動，形成對應(yīng)的“作業(yè)準(zhǔn)則”比如定義階段控制目標(biāo)（過程目標(biāo)、質(zhì)量目標(biāo)、生產(chǎn)效率目標(biāo)）、階段入口準(zhǔn)則、階段執(zhí)行的相關(guān)準(zhǔn)則、階段過程定義（輸入、執(zhí)行步驟、出口準(zhǔn)則、輸出）、定義質(zhì)量保證點、成果物等。除圍繞需求開發(fā)的各種活動外，還有圍繞著需求變更管理、版本管理、需求跟蹤、進度、成本管控等各種需求管理活動。 比如常見的有評審管理流程、（文件）版本管理、需求變更管理、問題跟蹤管理、（需求）跟蹤矩陣管理、決策管理、風(fēng)險管理、會議管理、工作匯報管理、考勤請假管理、非

29、正式交付物管理、正式交付物管理、需求調(diào)查準(zhǔn)入標(biāo)準(zhǔn)等等多方面的流程，這些可以形成需求分析階段的“管理準(zhǔn)則”。通過“作業(yè)準(zhǔn)則”以及“管理準(zhǔn)則”可以控制整個需求開發(fā)階段的進程、質(zhì)量以及成本。4.2需求驗證1. Q&A 管理軟件開發(fā)的過程實際上是個學(xué)習(xí)的過程，在學(xué)習(xí)中每個人（包括客戶、用戶、設(shè)計、開發(fā)、測試人員）理解以及學(xué)習(xí)的速度是不同的，軟件工程的過程從某種意義上就是協(xié)同團隊中的每個人學(xué)習(xí)進度。既然是學(xué)習(xí)那么就會有多種多樣的問題，快速解答問題顯然是非常重要的環(huán)節(jié)。 Q&A(問題 &回答 ) 的管理實際貫穿整個工程的生命周期，在需求分析階段， Q&A(問題 &回

30、答 ) 的管理可以加快項目團隊內(nèi)部的學(xué)習(xí)以及加速項目團隊同客戶、用戶的溝通。 Q&A(問題 &回答 ) 的管理過程并不復(fù)雜，主要就是提出問題、內(nèi)部知識共享解決、外部確認(rèn)解決、監(jiān)控并管理整個過程。 Q&A(問題 &回答 ) 經(jīng)常可以簡單地采用 EXCEL表的形式（也可以項目組、客戶、 用戶共同使用專門的系統(tǒng)來共享）， 定期發(fā)送給相關(guān)人員，這樣可以非實時的處理，不影響正常的工作。另外， Q&A(問題 &回答 ) 可以在固定的時期，集中的進行處理，以加快確認(rèn)的過程。2. 原型原型模型本身是一個迭代的模型，是為了解決在產(chǎn)品或系統(tǒng)開發(fā)的早期階段存在的不確定

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

32、情況制定一些策略，一般考慮的要點如下：1) 原型是拋棄型還是進化型。原型中哪些內(nèi)容可以在后續(xù)工程中復(fù)用。;.2) 原型設(shè)計、開發(fā)過程中是否要驗證技術(shù)的可行性、 是否要驗證工作效率以及工作方法的可用性。3) 設(shè)計團隊中是否配置了原型的開發(fā)所需要的設(shè)計、開發(fā)、測試人員。4) 系統(tǒng)中哪些部分需要采用原型的方式， 加強同客戶、 用戶的驗證。 比如關(guān)鍵或復(fù)雜的部分功能進行原型制作， 或?qū)I(yè)務(wù)歸納成幾種模式， 對不同的模式制作對應(yīng)的原型等等。5) 制作原型所需要的預(yù)算、 時間、成本等。有些原型的制作也需要不少的工作量，有些情況下原型制作本身就是一個單獨的項目。 比如，有些方案供應(yīng)商就預(yù)先開發(fā)原型， 以便爭

33、取項目的合同。 同時有些項目在招標(biāo)的時候， 就要求必須對核心功能提供必要的原型等等。6) 制作原型的所采用的快速工具， 比如 WEB站點的原型，如何有開發(fā)人員的參與的情況下，可以直接用 HTML制作原型，不然也可以用 PPT或其他工具“畫”出原型。7) 原型除能確認(rèn)系統(tǒng)的操作、畫面的遷移、畫面（風(fēng)格外觀、動作、要素等）等方面的內(nèi)容外，也可以對關(guān)鍵數(shù)據(jù)進行確認(rèn)，所以有些情況下，還需要考慮對原型所涉及的數(shù)據(jù)（尤其業(yè)務(wù)數(shù)據(jù)）進行專門的制作。從工作實踐中經(jīng)驗證明， 對于一些較為業(yè)務(wù)復(fù)雜或更關(guān)注交互的系統(tǒng)來說， 需求分析階段在規(guī)劃的時候，就應(yīng)考慮制作原型并配置對應(yīng)的原型開發(fā)隊伍（設(shè)計、開發(fā)、測試），對原

34、型的目標(biāo)建立、功能選擇、構(gòu)造確認(rèn)、評價等過程進行合理管理，可以降低整理項目的技術(shù)、業(yè)務(wù)、人員、過程中的風(fēng)險。3. POC 驗證POC（Proof Of Concept）原意是“為觀點提供證據(jù)”，本質(zhì)上是一種重要的評估技術(shù)。 對于系統(tǒng)中的關(guān)鍵技術(shù)或者業(yè)務(wù)模型， 論證團隊和客戶的設(shè)計，評估和確認(rèn)概念設(shè)計方案， POC的評價可能引起需求和設(shè)計的調(diào)整。為屏蔽系統(tǒng)存在的業(yè)務(wù)或技術(shù)風(fēng)險， 在系統(tǒng)需求、 設(shè)計的早期， 我們可以設(shè)定 POC來評估和確認(rèn)這些業(yè)務(wù)或技術(shù)的模型，以減少項目的風(fēng)險。對軟件系統(tǒng)的研發(fā)而言，POC的目的是為系統(tǒng)確定合適的業(yè)務(wù)模型（流程、方法等）、核心功能對應(yīng)的實現(xiàn)方法、系統(tǒng)構(gòu)架、 系統(tǒng)或軟件產(chǎn)品版本、 有效技術(shù)方案以及運行維護等服務(wù)的方案等內(nèi)容，或者驗證建議的方案可行性。 POC的最大價值在于在正式設(shè)計或規(guī)模實施以前，選擇最優(yōu)的方案。比如 POC在核心技術(shù)上的驗證內(nèi)容可以有：消息中間件、工作流、數(shù)據(jù)庫、瀏覽器、跨設(shè)備、 UI 控件、報表、共通組件、系統(tǒng)集成等等方面的內(nèi)容。POC作為一種重要的評估技術(shù)，過程上可以歸納為以下幾步：1.收集并識別來自業(yè)務(wù)、技術(shù)等方面的風(fēng)險。2.評估、決策那些內(nèi)容實施POC。POC的實施往往需要花費不少的時間