基于敏捷開發(fā)的管理信息系統(tǒng)需求分析模型構建

張保豐 徐緒堪 林潔 張驥

[摘要]國內(nèi)開發(fā)管理信息系統(tǒng)（MIS）的成功率并不高，經(jīng)過調(diào)查分析，大多是由于需求的變化性和不確定性所致。需求分析在系統(tǒng)的開發(fā)過程中有著舉足輕重的作用，因此有必要對需求分析進行深入的研究。為了應對快速變化的系統(tǒng)需求，本文采用敏捷項目管理的思想，利用增量式的迭代方法逐步明確系統(tǒng)需求，并用數(shù)值量化每一個需求的不確定性、不一致性和優(yōu)先級，在三維模型中表示每項需求，方便需求分解、細化和明確，從而使需求更加全面、清晰，有利于開發(fā)人員更好地對信息系統(tǒng)需求變更趨勢、需求變更主要原因進行掌控，有效地提高系統(tǒng)開發(fā)的成功率。

[關鍵詞] 需求分析；Scrum；業(yè)務流程；三維模型；需求變更

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2012 . 23. 028

[中圖分類號]TP391[文獻標識碼]A[文章編號]1673 - 0194（2012）23- 0045- 03

1前言

1.1 傳統(tǒng)管理信息系統(tǒng)開發(fā)方法及缺陷

管理信息系統(tǒng)（MIS）因其在創(chuàng)造有競爭力的公司、管理全球化、增加企業(yè)價值和為客戶提供有價值的產(chǎn)品與服務等方面有著重要的作用[1]，受到越來越多組織的青睞。信息技術發(fā)展的日新月異使得軟件的功能越來越強大，同時也帶來一系列的開發(fā)管理上的難題。傳統(tǒng)的瀑布模型、螺旋模型、原型模型等方法也越來越不能適應快速變化的需求和市場環(huán)境。主要表現(xiàn)在：軟件開發(fā)效率低，大量的人力、物力、財力浪費在重復開發(fā)上；軟件質(zhì)量得不到保證，后期服務費用大；技術積累困難，常常隨著技術人員的流失而消失；企業(yè)內(nèi)部、企業(yè)與外部缺乏有效、可靠、安全的信息交流方式等。

1.2 需求分析的重要性及不確定性

開發(fā)有效的信息系統(tǒng)的關鍵在于做好信息系統(tǒng)的需求分析工作，因為好的需求分析可以為信息系統(tǒng)的編寫提供任務范圍的框架，對信息系統(tǒng)的開發(fā)進行有效的控制，為信息系統(tǒng)的完成提供基線，為信息系統(tǒng)最終交付提供依據(jù)[2]。從項目管理知識體系來講，也就是要根據(jù)管理科學的理論，對需求進行科學分析和有效的規(guī)劃、管理及控制，使開發(fā)項目能夠按照預定的成本和進度順利完成，并保證信息系統(tǒng)的質(zhì)量和最終的順利實施。TTE、TRM和IBM三家公司的統(tǒng)計結果表明：發(fā)現(xiàn)錯誤的時間越晚，修改所需要花費的費用越大，如圖1所示。另外，需求定義不準確會對系統(tǒng)開發(fā)人員的積極性以及用戶實施信息系統(tǒng)的信心帶來不可忽視的影響。

由此可以看出，需求階段在系統(tǒng)開發(fā)的整個生命周期中處于最基礎、最重要的位置。許多成本分析表明，系統(tǒng)60% ～ 80%的錯誤發(fā)生來源于需求的錯誤定義[3]，這又歸結于需求分析具有很強的不確定性，表現(xiàn)為用戶本身需求的不確定性：用戶自我認識不清、員工因為利益原因故意隱藏需求、市場環(huán)境變化、業(yè)務調(diào)整等。然而更主要的原因是傳統(tǒng)開發(fā)方法的局限性，使得需求不夠明確，不能及時控制需求變更。而Scrum作為一種敏捷開發(fā)的代表，相對于傳統(tǒng)方法具有很明顯的優(yōu)勢。

2Scrum指導下的需求分析

2.1 敏捷開發(fā)Scrum

敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法。在高度協(xié)作的開發(fā)環(huán)境中，使用迭代的方式進行增量開發(fā)，經(jīng)常使用反饋進行思考、反省和總結，不停地進行自我調(diào)整和完善。采用敏捷開發(fā)不僅保證了軟件的質(zhì)量，而且開發(fā)速度也提高了3～10倍。Scrum作為一種典型的迭代式增量軟件開發(fā)過程，旨在尋求充分的發(fā)揮面向?qū)ο蠛蜆嫾夹g的開發(fā)方法，是對迭代式面向?qū)ο蠓椒ǖ母倪M，盡快讓需求者看到結果[4]。越來越多的公司，例如Google、Microsoft、IBM、Oracle等，開始采用Scrum來解決軟件開發(fā)過程中面臨的困難和挑戰(zhàn)。如果將項目開發(fā)過程視為一個黑箱，那么Scrum能更好地加強黑箱內(nèi)部的混沌性，使項目組工作在混沌的邊緣。不過，Scrum并沒有提供核心的價值觀和指導原則，也缺乏具體的實踐方法。本文借助Scrum的思想，通過具體的方法來實現(xiàn)復雜系統(tǒng)的需求分析。

2.2 需求層次

信息系統(tǒng)需求具有一定的層次和分類，一般包括業(yè)務需求、用戶需求、功能需求（包括非功能需求）3個層次。為了便于本文的研究和體現(xiàn)迭代思想的優(yōu)越性，按照需求發(fā)現(xiàn)的難易程度，從縱向上將需求分為以下3個層次。①基礎性需求：實現(xiàn)用戶需求，用戶主動提出的、顯性的、基礎的、迫切需要實現(xiàn)、必須滿足的需求。②滿意性需求：符合用戶預期，此類需求相對獨立，并且不對主要業(yè)務實現(xiàn)造成很大影響。③興奮性需求：超出用戶預期，深度隱性需求，主要為系統(tǒng)與用戶未來需求的吻合度。

2.3 需求分析建模

在關于不確定性、不一致性和優(yōu)先系數(shù)的分析中，開發(fā)團隊要根據(jù)具體情況對每一項工作制定一份比較完整的評分細則，防止評分過程中的隨意性。開發(fā)團隊需要根據(jù)需求不確定性、不一致性以及優(yōu)先級系數(shù)為坐標建立如圖2所示的三維模型。將調(diào)查得到的每個需求的屬性按（不確定性，不一致性，優(yōu)先系數(shù)），例如需求A5（30，10，1）進行繪圖定位。我們將整體分為8個象限，根據(jù)圖形情況，開發(fā)團隊和用戶可以一目了然的發(fā)現(xiàn)某一項需求的具體情況。

Ⅰ和Ⅴ區(qū)域是基本需求的集結區(qū)，是確定開發(fā)和優(yōu)先開發(fā)區(qū)域，此處的需求得到用戶和開發(fā)團隊的一致同意，在此區(qū)域的需求的成功能夠給員工工作帶來很多的方便，完成基本作業(yè)流程，增強用戶企業(yè)的市場優(yōu)勢。

Ⅶ區(qū)域是興奮性需求的集結區(qū)，也是高風險發(fā)開和爭議開發(fā)區(qū)域，因此在處理這一部分需求時要格外注意。高風險可能帶來高收益。風險主要為需求本身的變化性致使開發(fā)成功的可能性減低，或者即使成功開發(fā)也不一定能發(fā)揮作用。它的價值更多的表現(xiàn)為滿足用戶的隱性需求和應對未來的不確定性。在開發(fā)過程中，開發(fā)團隊應以戰(zhàn)略的高度把更多的注意力放在位于Ⅶ區(qū)域的需求上，通過進一步的調(diào)查將其轉(zhuǎn)化到其他區(qū)域，可以及時發(fā)現(xiàn)需求變化及其變化原因。

開發(fā)團隊要綜合考慮單個需求中三者的權重以及需求間的邏輯依賴關系來決定需求開發(fā)的先后順序。權重的確定不是任意的，必須通過科學的方法和有效的經(jīng)驗確定。我們采用主成分分析法，數(shù)據(jù)來源應為已經(jīng)公認的開發(fā)案例數(shù)據(jù)、開發(fā)團隊以往開發(fā)中的有效的成功的案例以及客戶所在公司的實際情況。

2.4 需求分析的基本流程及方法

借助Scrum的核心思想，結合需求分析自身的特殊性，我們采取如圖3所示的流程。

從一般流程我們可以看出，它是一個迭代的、逐步完善的過程，而協(xié)調(diào)關系和協(xié)同設計[5]則貫穿始終。為此，我們采取如下策略：①總體規(guī)劃，分步實施：由粗到細，有宏觀到微觀，由外到內(nèi)，逐步精深；②以部門為單位，以業(yè)務領域為主線，借助泳道圖搞清楚每個部門負責的業(yè)務以及每項業(yè)務流經(jīng)的部門。

（1）環(huán)境識別：就是把企業(yè)作為一個社會和經(jīng)濟系統(tǒng)的子系統(tǒng)，即要認識企業(yè)所處的自然環(huán)境，又要認識企業(yè)所處的政治環(huán)境、人文環(huán)境，由外到內(nèi)，由表及里地把握企業(yè)所處的地位[6]。將企業(yè)與上下游的供應商、客戶，以及合作伙伴和競爭者納入考慮范圍。企業(yè)可以利用外部競爭威脅模型和價值鏈模型等來進行戰(zhàn)略分析和選擇，識別信息系統(tǒng)能夠提供競爭優(yōu)勢的經(jīng)營領域，然后確定信息系統(tǒng)的戰(zhàn)略[7]。系統(tǒng)戰(zhàn)略必須服從服務企業(yè)戰(zhàn)略，系統(tǒng)功能必須支撐企業(yè)戰(zhàn)術要求。

（2）成立開發(fā)團隊。開發(fā)團隊領導須由資深的項目經(jīng)理擔任，由技術人員、業(yè)務分析員、管理人員組成，形成知識、技術、經(jīng)驗、溝通能力的互補。開發(fā)團隊領導沒有真正的實權，只是負責主持會議、協(xié)調(diào)成員、營造更好的交流環(huán)境，開發(fā)團隊成員都應該是全職的。開發(fā)團隊首先要對客戶的過去和現(xiàn)在進行了解，包括企業(yè)傳統(tǒng)、企業(yè)哲學、核心價值、員工價值、主營業(yè)務等，方便調(diào)查工作的順利和深入開展。

（3）理解愿景，識別目標。理解愿景，既要理解上級的意圖，又要理解下屬的愿景，上下溝通，層層協(xié)調(diào)。識別目標，既要從橫向上把握整體、要素、環(huán)境的有機聯(lián)系，在大環(huán)境下規(guī)劃企業(yè)的目標、方針、宗旨，又要正確處理企業(yè)的過去、現(xiàn)在、未來的連貫性，合理制定企業(yè)的長短期目標。

以下進入一個迭代式的增量過程，首先從每個部門入手，實現(xiàn)各個擊破，形成部門級需求，然后再通過接口進行需求整合，最終形成完整的公司級的需求文檔和需求模型。

（4）模塊分解和調(diào)查。首先根據(jù)公司現(xiàn)有組織結構和業(yè)務流程將公司劃分為界限并不明顯的職能/參謀部門，然后要對每個部門進行需求分析的時間做個排序，保持兩個相鄰部門之間具有一定的黏性，然后依次對每個部門分別進行需求分析。開發(fā)團隊首先可以對部門內(nèi)部進行問卷或者調(diào)查表調(diào)查，包括員工職務、職責以及對部門的整體描述，初步了解基本信息，這樣可以在下一步的面談中做到有針對性，節(jié)約時間。

（5）每日會議，需求發(fā)現(xiàn)。每個部門的需求分析將控制在一周內(nèi)，開發(fā)團隊會每天定時定點召集部門員工進行面談，時間控制在一個小時內(nèi)。為此我們建立一個“論戰(zhàn)室”，提供公共的會議室，以保持客戶和開發(fā)團隊能夠在協(xié)同工作下進行需求分析?？蛻魧⒅辽僖卮鹣铝袉栴}：①你對昨天的需求陳述還有什么要補充的嗎？②你今天有什么新的需求？③你明天將要做什么？有什么難度？④你認為現(xiàn)在迫切需要解決的問題是？⑤你認為你工作中的機會問題（probortunity）是什么？這一過程中要吸收頭腦風暴[8]的優(yōu)點，根據(jù)觸發(fā)器放大原理，更大程度地發(fā)現(xiàn)每個客戶個性化的理念理解和情景化的概念理解，實現(xiàn)各種需求最大化的外現(xiàn)。

（6）需求定義、編號及評審。開發(fā)團隊根據(jù)以上活動記錄總結、抽象出具體的需求文檔并形成組件，同時要給每個需求進行唯一性編碼。然后需要對此進行評審，評審會由開發(fā)團隊、部門主管、員工代表組成，各人員可以對需求文檔暢所欲言，發(fā)表自己的意見，并給需求評定優(yōu)先級別。評審主要是針對需求的合理性、粒度、完整性、價值性（商業(yè)性）等方面給與一定的評價。在此過程中我們借助用例劃分的測試方法“WAVE”，即What to do， Actors point of view， Value for the actor， Entire scenario，來檢驗每個需求的質(zhì)量[9]。在需求評審最后評審會形成最終意見，開發(fā)團隊對需求文檔和組件進行修改。

（7）需求文檔/組件集成：通過對各個部門的需求分析完畢后，通過需求間的接口進行集成。在集成中要注意是否有超出范圍的需求以及各種需求間的依賴關系。我們借助需求交互矩陣[10]來判斷任意兩個需求之間的依賴關系，并判斷是否獨立、相似、重疊或者矛盾。相似的需求要進一步細化明確，轉(zhuǎn)化為獨立需求和重疊需求；矛盾的需求需要與需求部門和更高的領導進行討論交流協(xié)商，在兩者兼顧下達到整體化更優(yōu)；重疊的需求應當消除，減少不必要的資源浪費。

在前幾輪的迭代后開發(fā)團隊會發(fā)現(xiàn)基礎性需求并設計模型和編制文檔，模型能夠給用戶更加清晰的認識，加速需求的確定，同時也可以被重復利用。隨著每輪迭代工作的進行，用戶的隱性需求和潛在需求會不斷明朗，此時要對需求進行修改、擴充，逐漸發(fā)現(xiàn)滿意性需求和興奮性需求。最后將各層次的需求文檔和模型進行整合，實現(xiàn)需求分析的成功。

3模型質(zhì)量保障措施

3.1 用戶保障

在每次的面談和評審會中要盡量保證客戶自由地、無拘束地暢談；要讓用戶認識到自己不僅僅是活動的參與人，也是變革推動者，確保每個需求優(yōu)先系數(shù)（Priority）評分、每個需求不確定性（Uncertainty）評分以及需求不一致性（Disagreement）統(tǒng)計真實可靠。

3.2 開發(fā)團隊保障

開發(fā)團隊在整個過程中應該做到以下幾個方面：每個部門作為一次增量，在劃分部門時并不具有隨意性，而是既要保證部門的獨立性，又要保持部門之間的黏性，主要依據(jù)是業(yè)務流程；為了體現(xiàn)部門劃分的連貫性和優(yōu)越性，就要使得調(diào)研過程具有連續(xù)性和繼承性；開發(fā)團隊自治，在引入基于自我組織團隊的變化驅(qū)動模式的過程中，要做到從高度個體自治、不注重團隊自治向高度個體自治并且注重團隊自治的轉(zhuǎn)變[11-12]；開發(fā)團隊中的每個人都沒有專門的職責。開發(fā)團隊是一個自組織、自管理的團隊，項目的每個成員都具有項目中所有方面的參與權，不存在單一成員劃分部門、問卷調(diào)查、構建需求模型的情況[3]，這樣保證了不會因為開發(fā)團隊成員的減少而影響需求分析的進度。

4結語

需求及需求變更對信息系統(tǒng)開發(fā)過程影響較大， 是影響信息系統(tǒng)質(zhì)量的重要因素[14]。本文在敏捷開發(fā)思想的指導下，重在從實踐的角度，以部門模塊為單位，以業(yè)務流程為主線，數(shù)字量化已發(fā)現(xiàn)的需求后建立三維需求模型，有效的說明各種需求的關系以及其優(yōu)先情況，有利于開發(fā)人員更好對信息系統(tǒng)需求變更趨勢、需求變更主要原因進行掌控，方便后期開發(fā)工作的進行，有效的提高系統(tǒng)開發(fā)的成功率。

主要參考文獻

[1][美] Kenneth C Laudon， Jane P Laudon.管理信息系統(tǒng)：管理數(shù)字化[M].第8版.周宣光，譯.北京：清華大學出版社，2005.

[2]董紅贊.中小企業(yè)信息管理系統(tǒng)需求分析流程研究[D].上海：上海交通大學，2009.

[3]羅曉沛，姜同強，等. 全國計算機等級考試三級教程——信息管理技術[M]. 北京：高等教育出版社，2011.

[4]張智海，周國祥.Scrum方法的研究與分析[J].合肥工業(yè)大學學報：自然科學版，2010，33（2）：198-200.

[5]陳麗. 基于共同價值的多維度組織協(xié)同機理和方法[D]. 天津：天津大學，2010.

[6]彭本紅，呂永成，黎軍.運用WSR方法探討國有企業(yè)BPR的有效實施[C]//顧基發(fā).西部開發(fā)與系統(tǒng)工程——中國系統(tǒng)工程學會第12屆年會論文集，2002.

[7]杜棟.新編管理信息系統(tǒng)[M].北京：中國人民大學出版社，2005.

[8] 潘綿臻，毛基業(yè).ERP實施中用戶的有效參與——頭腦風暴會議的作用[J].管理學報，2010，7（7）：1052-1063.

[9]Eric J Naibug，Robert A Maksimchuk.UML for Database Design[M]. Boston，MA：Addison-Wesley，2001.

[10]G Kotonya，I Sommerville.Requirements Engineering：Processes and Techniques[M].New York，NY：John Wiley& Sons，1998.

[11]Meo NB， Dingsoyr T.Understanding Self-Organizing Teaming Agile Software Development[C]//19th Australian Conference on Software Engineering，2008：76-85.

[12]楊帆，徐俊剛.一種改進的Scrum敏捷軟件開發(fā)方法[J].電子技術，2011（9）：22-23.

[13]Robert C Martin.敏捷軟件開發(fā)——原則、模式與實踐[M].鄧輝，譯.北京：清華大學出版社，2003：7.

[14]張獻國，劉鐵英，徐智文.信息系統(tǒng)需求變更統(tǒng)計分析度量方法[J].內(nèi)蒙古大學學報：自然科學版，2006（1）：89-94.