陳 垚，劉 奎，高 峰

(1.河北東軟軟件有限公司，河北 秦皇島 066004；2.秦皇島市政務數(shù)據(jù)治理及社會化應用工程技術(shù)研究中心，河北 秦皇島 066004)

chenyao@neusoft.com;liuk@neusoft.com;gao-f@neusoft.com

1 引言(Introduction)

當前在大型信息系統(tǒng)開發(fā)中，大多數(shù)軟件公司都能遵從軟件工程的軟件生命周期各階段的劃分，也能在實際工作中按照階段執(zhí)行，但實際成本與預估成本還是存在較大差異。通過實際工作發(fā)現(xiàn)，造成實際成本高的原因不是發(fā)生在內(nèi)部開發(fā)階段，而是發(fā)生在系統(tǒng)上線釋放后。系統(tǒng)上線釋放后，客戶需求不斷調(diào)整，系統(tǒng)反復修改，導致成本不斷增加。

系統(tǒng)上線釋放后的需求調(diào)整，可能有兩種情況：一種情況是需求確實在上線后發(fā)生變化，造成較大規(guī)模的修改，一般這種情況可以通過商務談判進行緩解。還有一種情況，就是前期的需求分析成果不能描述出業(yè)務的實際需求，不能滿足客戶的實際意愿，導致系統(tǒng)上線釋放后發(fā)生大規(guī)模調(diào)整。通常第二種情況是造成實際成本與預估成本偏差較大的主要原因。

結(jié)合上述問題，建立一種功能需求分析方法，提高需求分析的成果質(zhì)量，客觀反映客戶的實際意愿，避免系統(tǒng)上線釋放后的大規(guī)模調(diào)整，有效控制開發(fā)成本。

2 需求過程中的問題(Issues in the requirement process)

軟件系統(tǒng)需求常常分為功能需求、非功能需求和領(lǐng)域需求。功能需求包括對系統(tǒng)應該提供的服務、如何對輸入做出反應以及系統(tǒng)在特定條件下的行為的描述。在某些情況下，功能需求可能還需明確聲明系統(tǒng)不應該做什么。需求過程是建立客戶與軟件開發(fā)工程師的橋梁，一方面使客戶能夠理解和確認，通過收集、溝通及匯總分析出的真實需求，另一方面為后續(xù)系統(tǒng)設計和開發(fā)提供依據(jù)，是未來系統(tǒng)設計的工作輸入。在信息系統(tǒng)的功能需求分析時，主要存在以下幾類問題。

一是需求分析僅是對現(xiàn)有業(yè)務流程的“翻譯”。沒有結(jié)合信息技術(shù)將現(xiàn)有業(yè)務流程進行重新構(gòu)造，也沒有發(fā)揮出信息技術(shù)便捷、高效的作用。

二是采用的基本方法難以清晰描述需求。采用基本流程圖或基本框圖將實際業(yè)務分解為功能模塊，圍繞功能模塊開展需求調(diào)研，客戶難以與實際業(yè)務相結(jié)合，不能反映真實需求。

三是需求分析不完整。需求分析僅描述正向業(yè)務流程，業(yè)務流程不完整，系統(tǒng)上線后的逆向業(yè)務難以應對。

結(jié)合上述問題，通過對需求工程中需求分析方法的研究，建立一種功能需求分析方法，提高需求分析的成果質(zhì)量，使需求過程能夠切實反映客戶的實際意愿，避免軟件系統(tǒng)上線釋放后大規(guī)模調(diào)整，有效控制開發(fā)成本。

3 功能需求分析方法(Functional requirement analysis method)

信息系統(tǒng)實際是對信息的管理，信息也就是數(shù)據(jù)，是對業(yè)務流轉(zhuǎn)過程中產(chǎn)生數(shù)據(jù)的管理。采用5W1H分析法能夠易于客戶對于需求的理解，明確反映出真實需求。5W1H指從原因(何因，Why)、目標(何事，What)、時間(何時，When)、地點(何地，Where)、角色(何人，Who)、方法(何法，How)等六個方面提出問題進行思考。首先明確解決什么問題或為什么要做，然后明確誰在什么時間、什么地點、做什么，最后明確如何去做。只要圍繞以上幾個要素來描述需求，獲取真實的需求應該不是問題。

Why：為什么要做，是原因；

What：做什么，做成什么，是目標；

When：什么時候做，是時間；

Where：在哪兒做，是地點；

Who：誰來做，是角色；

How：怎么做，是方法。

功能需求分析方法主要由目的和范圍表示方法、業(yè)務改變表示方法、業(yè)務流程表示方法、業(yè)務單據(jù)表示方法及接口需求表示方法五部分組成。

3.1 目的及范圍表示方法

對于大型信息系統(tǒng)，可能由許多功能模塊構(gòu)成，功能需求圍繞功能模塊構(gòu)建。功能需求不僅描述信息系統(tǒng)的建設目的，重點關(guān)注業(yè)務目標或解決的問題。對于業(yè)務目的，組織結(jié)構(gòu)中不同的角色關(guān)注點可能也不一樣。對于管理者來說，更關(guān)注管理過程的改變或業(yè)務流程的重構(gòu)，由此帶來的可能是相關(guān)政策、管理辦法或組織結(jié)構(gòu)的改變。對于最終用戶來說，更關(guān)注業(yè)務流程的簡便性或?qū)嶋H操作的便捷性。在業(yè)務目標中，需要關(guān)注組織結(jié)構(gòu)中不同角色的期望。

功能需求的范圍通常包括兩部分：業(yè)務范圍和實施范圍。業(yè)務范圍需要描述功能模塊覆蓋的業(yè)務或流程，例如：本次業(yè)務范圍為采購模塊中的采購接收業(yè)務。實施范圍需要描述系統(tǒng)上線后的使用范圍或組織范圍，包括組織、地點、角色等。通過實施范圍的識別，可以界定功能需求覆蓋的完整性，也為系統(tǒng)上線前的測試提供依據(jù)。實施范圍也是容易遺漏或模糊的。

在必要時，為了使甲乙雙方對功能需求的范圍更加明確，可以補充不包含的業(yè)務范圍和實施范圍。例如：本次業(yè)務范圍為采購模塊中的采購接收業(yè)務，但不包含鋼材類物料。

3.2 業(yè)務改變表示方法

首先，需要明確系統(tǒng)建設的相關(guān)原則。系統(tǒng)建設的相關(guān)原則指的是現(xiàn)有相關(guān)政策或管理辦法，可以是業(yè)務管理要求、技術(shù)要求或?qū)嵤┮?，這些都是系統(tǒng)建設的依據(jù)，需要被獲取及提及的。

其次，需要明確系統(tǒng)建設的業(yè)務改變。信息系統(tǒng)建設，如果只是業(yè)務流程的簡單電子化，不能帶來足夠的經(jīng)濟效益或社會效益。在目的及范圍表示方法中，我們提到對于管理者而言，更關(guān)注于管理過程的改變或業(yè)務流程的重構(gòu)，希望通過新技術(shù)的引入帶來現(xiàn)有業(yè)務流程的改變。需求分析需要結(jié)合信息技術(shù)手段，討論并提出業(yè)務流程的重新設計及改善，使信息技術(shù)發(fā)揮出便捷、高效的作用。

再次，需要明確對組織結(jié)構(gòu)改變的建議。為了達到業(yè)務目標，信息技術(shù)的引入帶來管理過程的改變或業(yè)務流程的重構(gòu)，有可能對現(xiàn)有組織結(jié)構(gòu)、崗位和人員產(chǎn)生調(diào)整。那么在需求分析過程中，除了對業(yè)務流程重新設計，還需要提出組織結(jié)構(gòu)、崗位和人員調(diào)整的必要建議與要求。這些很可能會構(gòu)成未來系統(tǒng)上線釋放后的依賴。

在現(xiàn)有業(yè)務原則下，通過需求分析和信息技術(shù)的引入，對管理過程或業(yè)務流程重構(gòu)，對組織結(jié)構(gòu)、崗位和人員進行優(yōu)化，使信息系統(tǒng)建設切實帶來經(jīng)濟效益或社會效益。

3.3 業(yè)務流程表示方法

通常業(yè)務流程分為正向業(yè)務流程、逆向業(yè)務流程、特殊業(yè)務流程。滿足正向業(yè)務流程和逆向業(yè)務流程，操作場景就可以形成閉環(huán)，可以初步認為需求是完整的。正向業(yè)務流程指順序發(fā)生或正常情況下發(fā)生的業(yè)務流程，多數(shù)情況都只發(fā)生正向業(yè)務流程。如：訂單付款流程。逆向業(yè)務流程指當正向業(yè)務流程發(fā)生問題而產(chǎn)生的業(yè)務回退或反沖流程。如：訂單退款流程。特殊業(yè)務流程指偶然或特例情況下的業(yè)務流程，與正向業(yè)務流程又不完全一致，為了滿足系統(tǒng)上線后的業(yè)務符合，單獨規(guī)劃和設計的業(yè)務流程。如：訂單付款流程中可能有內(nèi)部付款業(yè)務。通常情況下，為了保證需求的完整性，正向業(yè)務流程、逆向業(yè)務流程是必須存在的，特殊業(yè)務流程只有當需要時才會出現(xiàn)。

業(yè)務流程采用泳道圖的表示方法更容易理解。將業(yè)務流程中的角色劃分為一個個泳道，每個角色對應的活動節(jié)點散落在各個角色對應的泳道里。泳道圖是將模型中的活動按照角色組織起來，不同的角色通過不同的泳道區(qū)域來表示。當然，為了便于閱讀和理解，泳道圖的編制需要遵從流程圖的基本規(guī)則要求，如：流程必須有開始節(jié)點和結(jié)束節(jié)點；流程結(jié)束必須連接結(jié)束節(jié)點；一個節(jié)點可以有多條輸入，但只能有一條輸出等。泳道代表的角色解決了Who的問題，業(yè)務流程中的先后順序解決了When的問題。

業(yè)務流程需要描述業(yè)務的全貌，包括流程中的所有活動節(jié)點。通過業(yè)務流程圖中的活動節(jié)點，解決What的問題，也就是做什么的問題。對于活動節(jié)點，通常采用“動詞”加“名詞”的命名方式，可以快速描述活動節(jié)點所完成的活動。比如：生成訂單，核對庫存等。為了便于客戶及軟件工程師的理解，需要建立一套活動節(jié)點示例，以區(qū)分不同節(jié)點代表的含義。活動節(jié)點示例如圖1所示。

圖1 活動節(jié)點示例Fig.1 Active node example

活動節(jié)點示例的描述如下。

開始：描述流程的開始；

結(jié)束：描述流程的結(jié)束；

系統(tǒng)內(nèi)：本系統(tǒng)內(nèi)的活動節(jié)點；

系統(tǒng)外：系統(tǒng)外的活動節(jié)點；

系統(tǒng)內(nèi)單據(jù)：本系統(tǒng)內(nèi)產(chǎn)生的業(yè)務單據(jù)；

系統(tǒng)外單據(jù)：系統(tǒng)外使用的業(yè)務單據(jù)；

子流程：系統(tǒng)的其他業(yè)務流程；

其他系統(tǒng)：其他系統(tǒng)的活動節(jié)點；

判斷：系統(tǒng)多輸出的判斷分支。

在業(yè)務流程表示時，除了系統(tǒng)內(nèi)的活動節(jié)點，同樣需要關(guān)注系統(tǒng)外的活動節(jié)點或其他系統(tǒng)的活動節(jié)點。很多情況，需求工程師只描述系統(tǒng)內(nèi)所涉及的活動節(jié)點，忽略了系統(tǒng)外的活動及其他系統(tǒng)中的活動，認為系統(tǒng)內(nèi)的活動節(jié)點才是需要關(guān)注的。這種描述方式的問題在于難以將完整的業(yè)務流程連貫起來，或不能反映真實業(yè)務，也不利于客戶的閱讀與理解，對于系統(tǒng)的業(yè)務測試及系統(tǒng)上線后的業(yè)務難以起到指導作用。

在表示業(yè)務流程時，除了建立活動節(jié)點外，還需要描述活動節(jié)點的IPO，即數(shù)據(jù)輸入(Input)、數(shù)據(jù)處理(Process)、數(shù)據(jù)輸出(Output)。通過在業(yè)務流程中的活動節(jié)點上帶入數(shù)據(jù)輸入和數(shù)據(jù)輸出，完成活動節(jié)點的完整描述。在信息系統(tǒng)中，信息通過活動節(jié)點的加工，進行信息的處理和存儲，在這里的信息通常也稱為“單據(jù)”。通常約定，在活動節(jié)點上方標注的“單據(jù)”作為該活動節(jié)點的數(shù)據(jù)輸入，在活動節(jié)點下方標注的“單據(jù)”作為該活動節(jié)點的數(shù)據(jù)輸出。上一活動節(jié)點的輸出“單據(jù)”通常為下一活動節(jié)點的輸入“單據(jù)”，這一原則也通常作為需求流程的完整性驗證。業(yè)務流程圖示例如圖2所示。

圖2 業(yè)務流程圖示例Fig.2 Business process diagram example

由于業(yè)務流程圖上的活動節(jié)點表示有限，需要在業(yè)務流程圖后，針對每一個活動節(jié)點進行詳細描述。詳細描述重點從業(yè)務描述、數(shù)據(jù)輸入、數(shù)據(jù)處理、數(shù)據(jù)輸出和業(yè)務約束五個方面進行表示。業(yè)務描述是指從實際業(yè)務的角度描述該活動節(jié)點是何種角色，在何時、何地完成何種工作。數(shù)據(jù)輸入指完成工作的輸入數(shù)據(jù)或輸入“單據(jù)”，數(shù)據(jù)輸入可以是一張單據(jù)也可以是多張單據(jù)。數(shù)據(jù)處理是指如何完成工作，重點描述的是數(shù)據(jù)加工邏輯或加工算法，解決How的問題，就是怎么做的問題。如：單據(jù)編號的產(chǎn)生邏輯、數(shù)據(jù)的計算算法等。數(shù)據(jù)輸出是指完成工作的輸出結(jié)果或輸出“單據(jù)”，數(shù)據(jù)輸出可以是一張單據(jù)也可以是多張單據(jù)。業(yè)務約束是指在哪些限制或約束下可以完成工作，如：單據(jù)狀態(tài)、數(shù)據(jù)權(quán)限、特殊業(yè)務約束等。

相對基本框圖的表示方法，采用5W1H分析法及泳道圖表示業(yè)務流程，能夠更清晰地描述Why、When、Where、Who、What和How六個核心要素，明確反映出真實需求。

3.4 業(yè)務單據(jù)表示方法

業(yè)務單據(jù)指的是我們在業(yè)務流程圖中用到輸入“單據(jù)”和輸出“單據(jù)”。在需求分析中，重點描述本業(yè)務流程產(chǎn)生的單據(jù)或輸出“單據(jù)”。業(yè)務單據(jù)主要從單據(jù)樣式、單據(jù)數(shù)據(jù)項、單據(jù)狀態(tài)方面進行表示。通?，F(xiàn)有業(yè)務規(guī)則中已經(jīng)具有業(yè)務單據(jù)，通過信息技術(shù)的引入，可能對現(xiàn)有單據(jù)的樣式產(chǎn)生變化或影響，通常需要重新設計單據(jù)樣式、規(guī)劃單據(jù)數(shù)據(jù)項及單據(jù)狀態(tài)，以保證業(yè)務流程的正常流轉(zhuǎn)。如：增加單據(jù)編號、各項小計與合計等。

3.5 接口需求表示方法

當前的信息系統(tǒng)建設，很少是建設一個孤立的系統(tǒng)，通常會與已建系統(tǒng)產(chǎn)生聯(lián)系，接口是系統(tǒng)間交互方式，可能是使用其他系統(tǒng)的數(shù)據(jù)，也可能是產(chǎn)生的數(shù)據(jù)被其他系統(tǒng)使用，那么就需要進行接口需求分析。通常接口需求也為數(shù)據(jù)接口，分為數(shù)據(jù)輸入的接口和數(shù)據(jù)輸出的接口。在進行需求表示時，接口需求基于業(yè)務流程中的某個活動節(jié)點進行表示，同樣需要對接口進行詳細描述，接口需求的描述包括編號、名稱、描述、類型、調(diào)用參數(shù)及回傳參數(shù)等。

4 功能需求驗證方法(Verification method of functional requirement)

功能需求的驗證包括有效性驗證、完整性驗證、一致性驗證。有效性主要驗證是否清晰描述了業(yè)務需求的目的、業(yè)務范圍及實施范圍，識別由于信息技術(shù)的引入是否對現(xiàn)有業(yè)務流程進行重新設計等；完整性主要驗證是否覆蓋正向業(yè)務及逆向業(yè)務，活動節(jié)點的輸入是否為前面活動節(jié)點的輸出，業(yè)務流程的接口需求是否體現(xiàn)等；一致性主要驗證需求的前后是否存在二義性，如：活動節(jié)點的輸出單據(jù)與定義是否一致，活動節(jié)點中的單據(jù)狀態(tài)與定義是否一致等。功能需求驗證項如表1所示。

表1 功能需求驗證項Tab.1 Functional requirement verification items

功能需求驗證的審查方式主要采用人工審查的方式，討論審查后形成需求成果基線，作為系統(tǒng)設計的輸入。

5 方法應用(Method application)

5.1 項目背景

以某企業(yè)費用控制系統(tǒng)為具體場景，將該功能需求分析方法在差旅報銷審批模塊中加以應用。該企業(yè)的情況是，差旅報銷審批沒有使用系統(tǒng)管理，審批過程以紙質(zhì)單據(jù)流轉(zhuǎn)。問題主要在兩個層面：一是審批周期長。審批人經(jīng)常出差，難以及時審批；過程中存在票據(jù)異地郵寄審批的情況，也會增加審批周期。二是費用核算有待進一步提高。通過紙質(zhì)單據(jù)填寫的項目編號，可以將費用歸集至項目，但不能明確至差旅出行和差旅借款。報銷費用依據(jù)紙質(zhì)單據(jù)手工計算，難免存在錯誤。希望通過信息系統(tǒng)建設解決以上問題。

5.2 需求分析

對于差旅報銷審批模塊的建設目的，針對管理者和最終用戶給予清晰描述。對于企業(yè)管理者，希望進一步提升報銷過程中的合規(guī)性，加強費用發(fā)生的成本中心與項目的歸集。對于最終用戶，更關(guān)注優(yōu)化報銷流程，提升報銷效率。由于差旅費用審批只是費用控制系統(tǒng)中差旅報銷的一個模塊，在業(yè)務范圍中需要清晰描述差旅報銷審批業(yè)務，實施范圍需要明確企業(yè)的組織機構(gòu)及分支機構(gòu)。

從前期的需求調(diào)研中了解到，該企業(yè)制定及發(fā)布了《差旅費借款與報銷專項管理制度》，并且當前的業(yè)務流程也是按照該管理辦法執(zhí)行，系統(tǒng)建設也需要遵從該管理辦法作為建設原則或建設依據(jù)。之前已經(jīng)提到信息系統(tǒng)的建設不僅是業(yè)務流程的翻譯或簡單電子化，對于管理者和最終用戶均有一定的改善期望。經(jīng)過對管理辦法分析，其中的部分內(nèi)容已不適用，基于此提出以下業(yè)務改變：采用電子票據(jù)作為報銷審批依據(jù)；審批結(jié)束后打印并粘貼紙質(zhì)報銷單據(jù)提交報銷會計；為報銷借款沖賬，建議補充差旅出行申請流程和差旅借款流程等。在差旅報銷審批模塊，并未涉及對組織結(jié)構(gòu)改變的調(diào)整。

經(jīng)過需求調(diào)研分析，差旅報銷審批模塊的業(yè)務流程涉及報銷人員、初級審批人、報銷會計、費用審批人四個崗位角色，那么在業(yè)務流程圖中建立四個泳道。結(jié)合建設目標和關(guān)鍵用戶期望，新業(yè)務流程的改造思路是，審批過程中不再使用紙質(zhì)票據(jù)，以電子單據(jù)及電子票據(jù)在系統(tǒng)中流轉(zhuǎn)；審批結(jié)束后，由報銷人員打印報銷單據(jù)并粘貼紙質(zhì)報銷單據(jù)，提交報銷會計。差旅報銷審批業(yè)務流程如圖3所示。

圖3 差旅報銷審批業(yè)務流程圖Fig.3 Business flow chart of travel reimbursement approval

在圖3差旅報銷審批業(yè)務流程中，以CCS-AP-TV-1-01填寫差旅報銷單的活動節(jié)點為例，數(shù)據(jù)輸入(Input)是旅費發(fā)票、住宿發(fā)票、差旅出行申請單，數(shù)據(jù)處理(Process)是填寫差旅報銷單，數(shù)據(jù)輸出(Output)是差旅報銷單。在業(yè)務流程圖后還針對每個活動節(jié)點的數(shù)據(jù)輸入、數(shù)據(jù)處理和數(shù)據(jù)輸出進行了詳細描述。該業(yè)務流程產(chǎn)生的單據(jù)是差旅報銷單，結(jié)合紙質(zhì)差旅報銷單樣式和系統(tǒng)需要重新進行規(guī)劃設計。該業(yè)務流程會與郵件系統(tǒng)對接，發(fā)送審批通過郵件、發(fā)送審批不通過郵件，在接口需求中對郵件系統(tǒng)對接進行了詳細描述。

5.3 需求驗證

在需求分析成果完成后，組織關(guān)鍵用戶、需求人員、開發(fā)人員和測試人員，依據(jù)表1功能需求驗證項，以會議的方式對需求成果的有效性、完整性、一致性進行驗證和審查。經(jīng)過多次反復討論和修改，最終形成需求成果基線版本。該基線版本作為系統(tǒng)設計和開發(fā)的工作輸入。

5.4 應用效果

在某企業(yè)費用控制系統(tǒng)中引入該功能需求分析方法，對差旅報銷審批流程進行了重新規(guī)劃，解決了審批流程中傳統(tǒng)紙質(zhì)單據(jù)效率低的問題，提出的相關(guān)業(yè)務改變意見也被客戶接受。結(jié)合5W1H分析法及泳道圖方法的業(yè)務流程表示方法，易于客戶理解，清晰反映實際需求。在需求驗證和審查過程中，通過有效性、完整性、一致性驗證，提高了需求分析的成果質(zhì)量。該系統(tǒng)上線釋放后運行平穩(wěn)，未發(fā)生大規(guī)模調(diào)整，有效控制了開發(fā)成本。

6 結(jié)論(Conclusion)

結(jié)合5W1H分析法及泳道圖方法，從需求分析、需求驗證提出的這種功能需求分析方法，有效緩解需求分析過程中的實際問題，提升需求分析的成果質(zhì)量，實現(xiàn)信息系統(tǒng)開發(fā)的質(zhì)量控制前置。經(jīng)過多個實際大型信息系統(tǒng)應用，該方法能夠有效避免或減少軟件系統(tǒng)上線釋放后大規(guī)模調(diào)整，控制開發(fā)成本，尤其適合業(yè)務邏輯復雜的信息系統(tǒng)。