信息系統的功能需求分析方法研究

陳 垚，劉 奎，高 峰

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

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

1 引言(Introduction)

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

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

結合上述問題，建立一種功能需求分析方法，提高需求分析的成果質量，客觀反映客戶的實際意愿，避免系統上線釋放后的大規模調整，有效控制開發成本。

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

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

一是需求分析僅是對現有業務流程的“翻譯”。沒有結合信息技術將現有業務流程進行重新構造，也沒有發揮出信息技術便捷、高效的作用。

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

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

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

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

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

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

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

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

Where：在哪兒做，是地點；

Who：誰來做，是角色；

How：怎么做，是方法。

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

3.1 目的及范圍表示方法

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

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

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

3.2 業務改變表示方法

首先，需要明確系統建設的相關原則。系統建設的相關原則指的是現有相關政策或管理辦法，可以是業務管理要求、技術要求或實施要求，這些都是系統建設的依據，需要被獲取及提及的。

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

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

在現有業務原則下，通過需求分析和信息技術的引入，對管理過程或業務流程重構，對組織結構、崗位和人員進行優化，使信息系統建設切實帶來經濟效益或社會效益。

3.3 業務流程表示方法

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

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

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

圖1 活動節點示例Fig.1 Active node example

活動節點示例的描述如下。

開始：描述流程的開始；

結束：描述流程的結束；

系統內：本系統內的活動節點；

系統外：系統外的活動節點；

系統內單據：本系統內產生的業務單據；

系統外單據：系統外使用的業務單據；

子流程：系統的其他業務流程；

其他系統：其他系統的活動節點；

判斷：系統多輸出的判斷分支。

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

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

圖2 業務流程圖示例Fig.2 Business process diagram example

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

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

3.4 業務單據表示方法

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

3.5 接口需求表示方法

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

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

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

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

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

5 方法應用(Method application)

5.1 項目背景

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

5.2 需求分析

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

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

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

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

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

5.3 需求驗證

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

5.4 應用效果

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

6 結論(Conclusion)

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