需求調(diào)研報(bào)告

　- -

　工商財(cái)稅

　- -

　 業(yè)務(wù)需求調(diào)研大綱

　版權(quán)所有不得復(fù)制

　 Copyright ? BroadenGate Technologies, Co., Ltd.

　 All Rights Reserved

　Revision Record 修訂記錄

　 Catalog

　 目錄

　 1 需求調(diào)研流程 (4)

　 1.1 調(diào)研整體流程 (4)

　 1.2 組成部分關(guān)系 (6)

　 1.3 分析過(guò)程 (7)

　 2 需求調(diào)研和分析的方法、策略和步驟 (8)

　 2.1 如何調(diào)研 (8)

　 2.2 如何分析 (8)

　 2.3 調(diào)研方法 (9)

　 2.4 基本策略 (9)

　 2.5 結(jié)構(gòu)化方法分析步驟 (10)

　 2.6UML 方法分析步驟 (10)

　 3 需求調(diào)研相關(guān)要求 (11)

　 3.1xx 規(guī)范 (11)

　 3.2 需求管理 (13)

　 3.3 調(diào)研成果 (13)

　1.1 調(diào)研整體流程

　●問(wèn)題識(shí)別：解決目標(biāo)系統(tǒng)做什么，做到什么程度。需求包括：功能、性能、環(huán)境、

　 可靠性、安全性、保密性、用戶界面、資源使用、成本、進(jìn)度。同時(shí)建立需求調(diào)查分析所需的通信途徑。

　 ●分析與綜合：從數(shù)據(jù)流和數(shù)據(jù)結(jié)構(gòu)出發(fā)，逐步細(xì)化所有的軟件功能，找出各元素之

　 間的聯(lián)系、接口特性和設(shè)計(jì)上的限制，分析它們是否滿足

　功能要求并剔除不合理部分，綜合成系統(tǒng)解決方案，給出目標(biāo)系統(tǒng)的詳細(xì)邏輯模型。[常用的分析方法有面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法 SA（數(shù)據(jù)流圖 DFD、數(shù)據(jù)詞典 DD、加工邏輯說(shuō)明）、描繪系統(tǒng)數(shù)據(jù)關(guān)系的實(shí)體關(guān)系圖 ERD、面向數(shù)據(jù)結(jié)構(gòu)的 Jackson 方法 JSD、面向?qū)ο蠓治龇椒?OOA（主要用 UML）、對(duì)于有動(dòng)態(tài)時(shí)序問(wèn)題的軟件可以用形式化技術(shù)，包括有窮狀態(tài)機(jī) FSM 的狀態(tài)遷移（轉(zhuǎn)換）圖 STD、時(shí)序圖、Petri 網(wǎng)。每一種分析建模方法都有其優(yōu)勢(shì)和局限性，可以兼而有之以不同角度分析，應(yīng)該避免陷入在軟件需求方法和模型中發(fā)生教條的思維模式和派系斗爭(zhēng)，一般來(lái)說(shuō)結(jié)構(gòu)化方法用于中小規(guī)模軟件、面向?qū)ο蠓椒ㄓ糜诖笮蛙浖�。]

　 ●編制需求分析 xx

　 ●需求評(píng)審

　 1.2 組成部分關(guān)系

　 需求分析可分為問(wèn)題識(shí)別、分析與綜合、編制需求分析 xx、需求評(píng)審等四個(gè)階段，包括以下幾個(gè)方面：確定軟件所期望的用戶類；獲取每個(gè)用戶的需求；了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求；分析員與用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息；將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將

　需求中的一部分分配給軟件組件；了解相關(guān)質(zhì)量屬性的重要性；討論得出實(shí)施優(yōu)先級(jí)；將所收集的用戶需求編寫成需求規(guī)格說(shuō)明和模型；評(píng)審需求規(guī)格說(shuō)明，確保與用戶達(dá)成共識(shí)。

　 1.3 分析過(guò)程

　 需求分析的任務(wù)是借助于當(dāng)前系統(tǒng)的物理模型（待開發(fā)系統(tǒng)的系統(tǒng)元素）導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型（只描述系統(tǒng)要完成的功能和要處理的數(shù)據(jù)），解決目標(biāo)系統(tǒng)“做什么”的問(wèn)題，所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的限制和軟件同其他系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其他有效性需求，通過(guò)逐步細(xì)化對(duì)軟件的要求描述軟件要處理的數(shù)據(jù)，并給軟件開發(fā)提供一種可以轉(zhuǎn)化為數(shù)據(jù)設(shè)計(jì)、結(jié)構(gòu)設(shè)計(jì)和過(guò)程設(shè)計(jì)的數(shù)據(jù)與功能表示。必須全面理解用戶的各項(xiàng)要求，但不能全盤接受，只能接受合理的要求；對(duì)其中模糊的要求要進(jìn)一步澄清，然后決定是否采納；對(duì)于無(wú)法實(shí)現(xiàn)的要求要向用戶作充分的解釋。最后將軟件的需求準(zhǔn)確地表達(dá)出來(lái)，形成軟件需求說(shuō)明書 SRS。

　●獲得當(dāng)前系統(tǒng)的物理模型：首先分析、理解當(dāng)前系統(tǒng)是如何運(yùn)行的，了解當(dāng)前系統(tǒng)

　 的組織機(jī)構(gòu)、輸入輸出、資源利用情況和日常數(shù)據(jù)處理過(guò)程，并用一個(gè)具體的模型

　 來(lái)反映自己對(duì)當(dāng)前系統(tǒng)的理解。此步驟也可以稱為“業(yè)務(wù)

　建模”，其主要任務(wù)是對(duì)

　 用戶的組織機(jī)構(gòu)或企業(yè)進(jìn)行評(píng)估理解他們的需要及未來(lái)系統(tǒng)要解決的問(wèn)題，然后建

　 立一個(gè)業(yè)務(wù) USECASE 模型和業(yè)務(wù)對(duì)象模型。當(dāng)然如果系統(tǒng)相對(duì)簡(jiǎn)單，也沒(méi)必要大動(dòng)

　 干戈區(qū)進(jìn)行業(yè)務(wù)建模，只要做一些簡(jiǎn)單的業(yè)務(wù)分析即可。

　 ●抽象出當(dāng)前系統(tǒng)的邏輯模型：在理解當(dāng)前系統(tǒng)“怎樣做”的基礎(chǔ)上，取出非本質(zhì)因

　 素，抽取出“做什么”的本質(zhì)。

　 ●建立目標(biāo)系統(tǒng)的邏輯模型：明確目標(biāo)系統(tǒng)要“做什么”。

　 ●對(duì)邏輯模型的補(bǔ)充，如用戶界面、啟動(dòng)和結(jié)束、出錯(cuò)處理、系統(tǒng)輸入輸出、系統(tǒng)性

　 能、其他限制等等。

　2 需求調(diào)研和分析的方法、策略和步驟

　 2.1 如何調(diào)研

　 需求調(diào)研涉及三個(gè)問(wèn)題：

　 一是如何確定調(diào)研對(duì)象；

　 二是如何確定被調(diào)研對(duì)象；

　 三是采用何種調(diào)研方法；

　 調(diào)研對(duì)象的組成應(yīng)以互補(bǔ)為原則，至少要由三類人員組成：技術(shù)人員、業(yè)務(wù)專家和管理者。被調(diào)研對(duì)象主要是人員和業(yè)

　務(wù)兩類，其間主要涉及人與人、人與事物、事物與事物等三種關(guān)系。

　 其中，關(guān)鍵是確定調(diào)研范圍。調(diào)研范圍包括關(guān)鍵域和關(guān)鍵活動(dòng)。而關(guān)鍵活動(dòng)又由關(guān)鍵流程加關(guān)鍵點(diǎn)構(gòu)成。

　 找到關(guān)鍵域，明確關(guān)鍵流程和關(guān)鍵點(diǎn)，對(duì)需求調(diào)研至關(guān)重要，需要專家或咨詢顧問(wèn)介入。而能否把握這一時(shí)機(jī)并找準(zhǔn)需求提煉的關(guān)鍵點(diǎn)，是考驗(yàn)需求調(diào)研人員的重要方面。優(yōu)秀的需求調(diào)研人員不僅能認(rèn)識(shí)問(wèn)題之所在，還能藉此獲取足夠多的知識(shí)，最后成為問(wèn)題領(lǐng)域的專家。

　 需求調(diào)研非常困難，必須引起重視。因?yàn)椋?/p>

　 ● 缺乏專門領(lǐng)域的知識(shí)，同時(shí)應(yīng)用領(lǐng)域中的許多問(wèn)題通常模糊，很難界定；

　 ● 機(jī)構(gòu)實(shí)踐存在默認(rèn)知識(shí)，難以描述；

　 ● 多個(gè)知識(shí)源或信息源既有沖突又有重合；

　 ● 被調(diào)研對(duì)象可能有認(rèn)知偏見或者欠缺或有時(shí)不愿提供確切信息。

　 這些都會(huì)給需求調(diào)研人員帶來(lái)障礙和困難。在這種情況下，掌握必要的方法與技巧非常重要。

　 2.2 如何分析

　需求工程是繼軟件工程之后的又一熱點(diǎn)工程。從理論上說(shuō)，包括調(diào)研需求、模擬和分析需求、需求描述、需求認(rèn)可、需

　求演進(jìn)這五個(gè)層次，并且逐層遞進(jìn)、螺旋式上升。需求分析是需求工程的核心，貫穿于系統(tǒng)整個(gè)生命周期。

　 需求分析的出發(fā)點(diǎn)在于：對(duì)調(diào)研的需求進(jìn)行進(jìn)一步提煉并指導(dǎo)需求的抽�。粠椭�需求分析人員發(fā)現(xiàn)問(wèn)題。需求模擬則幫助檢查驗(yàn)證對(duì)問(wèn)題的理解。需求分析和模擬又包含三個(gè)層次的工作：需求定義、需求建模、需求模擬。

　 需求定義，是對(duì)經(jīng)調(diào)研獲取的需求進(jìn)行初步整理，抽取其中基本需求和關(guān)鍵需求予以界定，并為需求建模提供必要的需求元素。

　 需求建模，是把抽象的需求通過(guò)概念、符號(hào)、數(shù)學(xué)模型及邏輯結(jié)構(gòu)表現(xiàn)出來(lái)。表現(xiàn)形式有自然語(yǔ)言、半形式化（如圖、表、結(jié)構(gòu)化英語(yǔ)等）和形式化表示等三種。自然語(yǔ)言形式具有表達(dá)能力強(qiáng)的優(yōu)點(diǎn)，但不利于捕獲模型語(yǔ)義；半形式化表示可捕獲結(jié)構(gòu)和一定的語(yǔ)義，也可進(jìn)行一定的推理和一致性檢查；形式化表示具有精確的語(yǔ)義和推理能力，但構(gòu)造一個(gè)完整的形式化模型，需要較長(zhǎng)時(shí)間和對(duì)問(wèn)題領(lǐng)域的深層次理解。相對(duì)而言，圖表形式的需求模型直觀常用，比如組織結(jié)構(gòu)圖、系統(tǒng)流程圖、網(wǎng)絡(luò)拓?fù)鋱D等。

　 良好的需求概念模型應(yīng)包括以下幾個(gè)特點(diǎn)：實(shí)現(xiàn)的獨(dú)立性、足夠抽象、足夠形式化、可構(gòu)造性、利于分析、可追蹤性、可執(zhí)行性、最小冗余性。

　 2.3 調(diào)研方法

　 1、會(huì)談、詢問(wèn)：圍繞軟件目標(biāo)提出具體問(wèn)題；

　 2、調(diào)查表：經(jīng)過(guò)仔細(xì)考慮的書面回答可能比會(huì)談中的回答更加準(zhǔn)確；

　 3、收集分析客戶使用的各種表格、有關(guān)工作責(zé)任、工作流程、工作規(guī)范、相關(guān)數(shù)據(jù)標(biāo)準(zhǔn)、業(yè)務(wù)標(biāo)準(zhǔn)的各種文字資料；

　 4、收集同類相關(guān)產(chǎn)品的宣傳資料、技術(shù)資料、演示程序或軟件程序；

　 5、情景分析：利用情景分析誘導(dǎo)用戶能夠把它們的需求告知分析員（可以描述當(dāng)前一項(xiàng)業(yè)務(wù)怎么做、也可以描述設(shè)想的系統(tǒng)中此項(xiàng)業(yè)務(wù)怎么做）；

　 6、可視化方法：結(jié)和情景分析，利用畫用戶界面圖、業(yè)務(wù)流程圖、功能結(jié)構(gòu)圖、時(shí)序圖等圖形與客戶進(jìn)行討論；

　 2.4 基本策略

　1、首先確定用戶的軟件開發(fā)目標(biāo)，確定系統(tǒng)基本范圍，然后圍繞這一目標(biāo)，確定要訪問(wèn)的部門和人員，要了解的業(yè)務(wù)，在基本范圍內(nèi)展開調(diào)研；

　 2、以部門職責(zé)為基礎(chǔ)搞清各種現(xiàn)有業(yè)務(wù)、要填寫的表簿冊(cè)xx 報(bào)表等，其數(shù)據(jù)來(lái)源及去向；

　 3、以業(yè)務(wù)為主線，搞清每個(gè)業(yè)務(wù)的每個(gè)環(huán)節(jié)的流程關(guān)系、涉及部門、輸入輸出項(xiàng)；

　 4、以數(shù)據(jù)為主線，搞清數(shù)據(jù)采集方式、數(shù)據(jù)流向、數(shù)據(jù)之

　間的內(nèi)在聯(lián)系；

　 5、搞清哪些業(yè)務(wù)或數(shù)據(jù)是已建系統(tǒng)的，它們和新系統(tǒng)的關(guān)系是銜接還是替換；

　 6、應(yīng)思考是否有新技術(shù)可以改進(jìn)現(xiàn)有工作，用戶提出的需求用現(xiàn)有技術(shù)能否實(shí)現(xiàn)。

　 2.5 結(jié)構(gòu)化方法分析步驟

　 1、畫出數(shù)據(jù)流圖。設(shè)計(jì)數(shù)據(jù)流圖必須逐步求精；

　 2、決定哪些部分需要計(jì)算機(jī)化和怎樣計(jì)算機(jī)化（取決于用戶投資限制和自身技術(shù)限制）；

　 3、描述數(shù)據(jù)流細(xì)節(jié)，大型軟件可以使用數(shù)據(jù)字典描述所有數(shù)據(jù)元素；

　 4、定義處理邏輯（加工邏輯：每個(gè)加工處理做什么）；

　 5、定義數(shù)據(jù)存儲(chǔ)，即定義每個(gè)存儲(chǔ)的確切內(nèi)容及其表示法（格式）；

　 6、定義物理資源：如是文件需指定：文件名、組織結(jié)構(gòu)（排序、索引等）、存儲(chǔ)介質(zhì)和記錄；如是數(shù)據(jù)庫(kù)需指定每個(gè)表的相關(guān)信息；

　 7、確定輸入輸出規(guī)格說(shuō)明，如輸入內(nèi)容、輸入屏幕、打印輸出格式、輸出長(zhǎng)度等等；

　 8、確定硬件所需有關(guān)數(shù)值，如輸入量、打印頻率、CPU、記錄大小、數(shù)據(jù)量大小、文件大小等等；

　 9、確定軟硬件接口和環(huán)境需求。

　 2.6 UML 方法分析步驟

　 一般的應(yīng)用系統(tǒng)又是各組成部分：?jiǎn)栴}論域、人機(jī)界面、數(shù)據(jù)管理、任務(wù)管理，在 OOA 階段重點(diǎn)對(duì)問(wèn)題論域進(jìn)行分析，對(duì)人機(jī)界面、數(shù)據(jù)管理、任務(wù)管理等問(wèn)題，OOA 一般較少或

　沒(méi)有分析，而是留待 OOD 階段解決。

　 1、調(diào)研、識(shí)別系統(tǒng)需求；

　 2、分析問(wèn)題領(lǐng)域：主要任務(wù)是充分理解領(lǐng)域問(wèn)題和項(xiàng)目投資者及用戶的需求，對(duì)需求進(jìn)行抽象，提出高層次的解決方案）；

　 （1）確定系統(tǒng)范圍和系統(tǒng)邊界；

　 （2）確定系統(tǒng)的約束（環(huán)境和條件）；

　 （3）定義活動(dòng)者；

　 （4）確定系統(tǒng)的綜合要求（功能、性能、運(yùn)行）；

　 （5）確定系統(tǒng)的數(shù)據(jù)要求（名稱、范圍、類型、數(shù)量、特點(diǎn)）；

　 （6）建立 USE CASE 模型、繪制 USE CASE 圖；

　 （7）繪制主要交互圖；

　 3、建立靜態(tài)結(jié)構(gòu)模型（對(duì)象類圖、數(shù)據(jù)庫(kù)模型、包圖）；

　 4、建立動(dòng)態(tài)行為模型（順序圖、協(xié)同圖、狀態(tài)圖、活動(dòng)圖）；

　 5、建立系統(tǒng)物理模型（組件圖、配置圖）；

　 3 需求調(diào)研相關(guān)要求

　 3.1 xx 規(guī)范

　 A、三種編寫方法

　 1、用好的結(jié)構(gòu)化和自然語(yǔ)言編寫文本型 xx；

　 2、建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過(guò)程、系統(tǒng)狀態(tài)、和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退麄兊年P(guān)系；

　 3、編寫形式化規(guī)格說(shuō)明，這可以通過(guò)使用數(shù)學(xué)上精確的形式化邏輯語(yǔ)言來(lái)定義需求。

　多種編寫方法可在同一個(gè) xx 使用，根據(jù)需要選擇，或互為補(bǔ)充，以能夠把需求說(shuō)明白為目的。

　 B、應(yīng)有成果

　 1、各業(yè)務(wù)手工辦理流程文字說(shuō)明；

　 2、各業(yè)務(wù)手工辦理流程圖；

　 3、各業(yè)務(wù)手工辦理各環(huán)節(jié)輸入輸出表單、數(shù)據(jù)來(lái)源；

　 4、目標(biāo)軟件系統(tǒng)功能劃分（示意圖及文字說(shuō)明）；

　 5、目標(biāo)軟件系統(tǒng)中各業(yè)務(wù)辦理流程文字說(shuō)明；

　 6、目標(biāo)軟件系統(tǒng)中各業(yè)務(wù)辦理流程圖（模型）；

　 7、目標(biāo)軟件系統(tǒng)中各業(yè)務(wù)辦理各環(huán)節(jié)數(shù)據(jù)、數(shù)據(jù)采集方式、數(shù)據(jù)間的內(nèi)在聯(lián)系分析。

　 8、目標(biāo)軟件系統(tǒng)用戶界面圖、各式系統(tǒng)邏輯模型圖及說(shuō)明

　 C、xx 工具推薦

　 1、調(diào)研結(jié)果《需求分析說(shuō)明書》格式參照開發(fā) xx 模板；

　 2、單位組織結(jié)構(gòu)圖、功能模塊分解圖用 VISIO 繪制，或直接用 WORD 中的畫圖工具；

　 3、業(yè)務(wù)流程圖用 VISIO 中的 FLOWCHART 模板繪制；

　 4、系統(tǒng)邏輯模型使用 ROSE 繪制活用 VISIO 中的 UML 模板繪制；

　 5、軟件用戶界面用 VISIO 中的 WIN95 USER INTERFACE 模板繪制；

　 6、數(shù)據(jù)物理模型用 POWERDESINER 繪制；

　 D、需求 xx 編寫原則

　 1、句子簡(jiǎn)短完整，具有正確的語(yǔ)法、拼寫和標(biāo)點(diǎn)；

　 2、使用的術(shù)語(yǔ)與詞匯表中所定義的一致；

　 3、需求陳述應(yīng)該有一致的樣式，例如“系統(tǒng)必須..”或者“用戶必須..”，并緊跟

　一個(gè)行為動(dòng)作和可觀察的結(jié)果。；

　 4、避免使用模糊、主觀的術(shù)語(yǔ)，減少不確定性，如“界面友好、操作方便”；

　 5、避免使用比較性詞語(yǔ)，如“提高”，應(yīng)定量說(shuō)明提高程度。

　 3.2 需求管理

　 需求調(diào)研分析過(guò)程是一個(gè)由粗到細(xì)、漸進(jìn)明晰、持續(xù)完善

　的過(guò)程。在指導(dǎo)后面系統(tǒng)設(shè)計(jì)，編碼階段時(shí)都應(yīng)當(dāng)不斷完善修改需求 xx，因此需求管理非常重要。需求管理包括在工程進(jìn)展過(guò)程中維持需求約定集成型和精確性的所有活動(dòng)，它是CMM 模型二級(jí)中的首要 KPA（關(guān)鍵過(guò)程域），這些活動(dòng)包括：

　 （1）定義需求基線（需求 xx 的主體）；

　 （2）評(píng)審提出的需求變更申請(qǐng)、評(píng)估每項(xiàng)變更可能的影響，從而決定是否實(shí)施變更；

　 （3）以一種可控的方式將需求變更融入到項(xiàng)目中；

　 （4）使當(dāng)前的項(xiàng)目計(jì)劃與需求保持一致；

　 （5）分析變更所產(chǎn)生的影響并在此基礎(chǔ)上協(xié)商出新的約定；

　 （6）使每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來(lái)以實(shí)現(xiàn)跟蹤；

　 （7）在整個(gè)項(xiàng)目過(guò)程中跟蹤需求狀態(tài)及其變更情況。

　3.3 調(diào)研成果

相關(guān)熱詞搜索：財(cái)稅 調(diào)研報(bào)告 需求