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

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

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

3、機(jī)會(huì)的定義。問題是指企業(yè)或組織運(yùn)作過程中遇到的問題，例如物資供應(yīng)脫節(jié)、用戶投訴量大、客戶流失率較高等。機(jī)會(huì)是指抓住外部環(huán)境變化所帶來的機(jī)會(huì)，以便為企業(yè)帶來新的發(fā)展，例如電子商務(wù)、網(wǎng)上銀行、基于即時(shí)通信的工作協(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ǔ)上進(jìn)用戶訪談、調(diào)查，對用戶使用的場景進(jìn)行整理，從而建立用戶角度的需求。解決如何使用（軟

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

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

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

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

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

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

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

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

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

13、狀進(jìn)行歸納整理，同時(shí)對業(yè)務(wù)中的問題、各類期望以及優(yōu)化方案進(jìn)行記錄和整理，通過初步分析形成結(jié)構(gòu)化描述。一般需求調(diào)查報(bào)告包含目的、目標(biāo)、范圍、業(yè)務(wù)域概述、組織機(jī)構(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)域主要梳理并整理項(xiàng)目的作業(yè)范圍，同時(shí)在業(yè)務(wù)上進(jìn)行梳理了解并描述各領(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ù)流程描述（常見可以用泳道圖描述）、逐個(gè)業(yè)務(wù)場景描述、對系統(tǒng)功能需求描述、相關(guān)輸入輸

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

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

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

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

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

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

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

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

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

23、描述業(yè)務(wù)功能需求。無論采用什么方式、方法描述，那么業(yè)務(wù)功能需求的共性內(nèi)容包括:業(yè)務(wù)領(lǐng)域、組織機(jī)構(gòu)、崗位、權(quán)限、功能（用例）清單、用例說明、界面交互、數(shù)據(jù)實(shí)體、接口、規(guī)則模型等。1)       業(yè)務(wù)領(lǐng)域范圍：主要描述業(yè)務(wù)、功能的分類以及對應(yīng)的范圍。 2)       組織機(jī)構(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)限要求，往往會(huì)貫穿整

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

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

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

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

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

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

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

31、能耗下的環(huán)境需求。11)  用戶文檔及幫助系統(tǒng)需求：業(yè)務(wù)操作相關(guān)、系統(tǒng)開發(fā)相關(guān)各類學(xué)習(xí)、培訓(xùn)、實(shí)踐需求。12)  支持性/服務(wù)性需求：系統(tǒng)日志功能、系統(tǒng)配置、狀態(tài)監(jiān)控、數(shù)據(jù)異常處理（工具）等需求。 4. 約束條件約束條件一般指由其他標(biāo)準(zhǔn)、硬件局限等引發(fā)的設(shè)計(jì)約束。常見的約束條件有：網(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è)計(jì)差異）、法律法規(guī)、各類業(yè)務(wù)標(biāo)準(zhǔn)、運(yùn)行環(huán)境（比如設(shè)備能耗、內(nèi)存、CPU使用率）等等。需求分析(三)關(guān)鍵點(diǎn)4

32、.    關(guān)鍵點(diǎn)（Know-How）、運(yùn)用技巧4.1作業(yè)準(zhǔn)則以及管理準(zhǔn)則 需求分析的流程往往因項(xiàng)目規(guī)模、作業(yè)人員、系統(tǒng)類型差異很大，因此必須根據(jù)實(shí)際的情況合理的裁減。從軟件工程的角度來說，需求分析階段可以將需求開發(fā)的各種活動(dòng)，形成對應(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ì)量保證點(diǎn)、成果物等。除圍繞需求開發(fā)的各種活動(dòng)外，還有圍繞著需求變更管理、版本管理、需求跟蹤、進(jìn)度、成本管控等各種需求管理活動(dòng)。比如常見的有評審管理流程、（文

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

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

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

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

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

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

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