張保豐 徐緒堪 林潔 張?bào)K

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

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

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

[中圖分類號(hào)]TP391[文獻(xiàn)標(biāo)識(shí)碼]A[文章編號(hào)]1673 - 0194（2012）23- 0045- 03

1前言

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

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

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

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

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

2Scrum指導(dǎo)下的需求分析

2.1 敏捷開發(fā)Scrum

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

2.2 需求層次

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

2.3 需求分析建模

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 用戶保障

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

3.2 開發(fā)團(tuán)隊(duì)保障

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

4結(jié)語(yǔ)

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

主要參考文獻(xiàn)

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

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

[3]羅曉沛，姜同強(qiáng)，等. 全國(guó)計(jì)算機(jī)等級(jí)考試三級(jí)教程——信息管理技術(shù)[M]. 北京：高等教育出版社，2011.

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

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

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

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

[8] 潘綿臻，毛基業(yè).ERP實(shí)施中用戶的有效參與——頭腦風(fēng)暴會(huì)議的作用[J].管理學(xué)報(bào)，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]楊帆，徐俊剛.一種改進(jìn)的Scrum敏捷軟件開發(fā)方法[J].電子技術(shù)，2011（9）：22-23.

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

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