大型軟件項目中的需求管理及控制

徐 龍

(重慶市公安局交通管理局科研所，重慶 400074)

1 論文概述

本文通過作者多年從事大型軟件項目管理的經(jīng)驗，從甲方的角度定義和論述大型軟件在需求過程中的一些過程及規(guī)范，并通過規(guī)范需求過程的步驟及方法來達(dá)到縮短開發(fā)周期、降低軟件開發(fā)成本和提高軟件質(zhì)量的目的，并且通過需求分析工作，定義分析方法把《用戶需求》轉(zhuǎn)化為《軟件需求》，同時利用科學(xué)的方法評審需求的正確性，避免需求的隨意性，在項目初期即獲得需求雙方的承諾；控制需求的變更，并確保軟件系統(tǒng)項目工作產(chǎn)品與需求的一致性.

2 術(shù)語解釋

軟件需求:在IEEE軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中定義軟件需求為:(1)用戶解決問題或達(dá)到目標(biāo)所需的條件或能力.(2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或能力.(3)一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說明.通俗地講，“需求”就是用戶的需要，它包括用戶要解決的問題、達(dá)到的目標(biāo)以及實現(xiàn)這些目標(biāo)所需要的條件，它是一個程序或系統(tǒng)開發(fā)工作的說明，表現(xiàn)形式一般為文檔形式.

用例:是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成對特定參與者可見的價值結(jié)果，一個用例定義了一組用例實例.

需求分析:是指在需求開發(fā)過程中，對所獲取的需求信息進(jìn)行分析，及時排除錯誤和彌補(bǔ)不足，確保需求文檔正確地反映用戶的真實意圖.需求分析的關(guān)鍵就是對問題域的研究與理解.為了便于理解問題域，現(xiàn)代軟件工程方法所推薦的做法就是對問題域進(jìn)行抽象，將其分解為若干基本元素，然后對元素之間的關(guān)系進(jìn)行建模.

3 需求過程參與人員角色及職責(zé)

在大型軟件項目中的需求過程中，明確角色及職責(zé)，界定在需求過程中各角色人員的具體工作和范圍是非常重要的，根據(jù)作者本人所在單位的軟件建設(shè)過程和系統(tǒng)特點，在軟件需求過程中按照單位的職責(zé)劃分分為如下角色及職責(zé):

項目總負(fù)責(zé)人:負(fù)責(zé)項目的需求評審及確認(rèn)，并擔(dān)任需求評審小組的組長；

項目經(jīng)理:負(fù)責(zé)組織單位各部門配合項目進(jìn)行需求調(diào)研，并對項目進(jìn)行需求分析和管理工作；

需求分析師:負(fù)責(zé)需求的獲取，分析以及定義

評審小組:接受需求評審申請，組織進(jìn)行需求的評審CM工程師:負(fù)責(zé)需求基線變更的維護(hù).

4 需求開發(fā)與管理流程

大型軟件項目的需求管理階段的主要活動包括:需求確認(rèn)，需求變更和需求跟蹤控制三大部分，下面作者結(jié)合本單位軟件項目需求管理及控制階段，詳細(xì)的論述需求獲取、變更和控制這三大部分理論與實際的結(jié)合應(yīng)用.

圖1 需求開發(fā)與管理過程活動示意圖

4.1 需求獲取

作為甲方的項目管理人員必須做好需求獲取前的計劃審核及協(xié)調(diào)工作，良好的開端是項目成功的基礎(chǔ)，編制需求計劃具有以下幾個要素.

1)明確需要獲取的信息是什么(What)

2)明確需要獲取信息來自于什么地方(Where)

3)明確獲取需求的方法(How)

需求獲取的方法主要有以下幾種，各有利弊.

A.調(diào)查問卷

需求獲取方根據(jù)對甲方業(yè)務(wù)學(xué)習(xí)情況和具體工作情況的學(xué)習(xí)結(jié)合實際情況設(shè)計需求問題形成調(diào)查問卷，然后下發(fā)到具體的被調(diào)研人員手中，填寫答案來進(jìn)行需求獲取.

B.訪談

訪談分為兩種形式，問題列表訪談，即有提前準(zhǔn)備好訪談的問題，有問有答式的進(jìn)行訪談，并記錄好訪談結(jié)果，形成訪談問答式的訪談記錄.提綱開放式訪談，即準(zhǔn)備一個大致的訪談提綱和粗略的方向，根據(jù)被訪談人的具體情況進(jìn)行調(diào)整.但是在實際的情況中，往往是這兩種訪談模式相結(jié)合才能更加靈活、有效地進(jìn)行需求的有效訪談.

C.現(xiàn)場觀摩工作流程，觀察實際操作

對于一些較為復(fù)雜的流程和操作，是比較難以用語言和文字進(jìn)行表達(dá)的，可以有針對性的采用到系統(tǒng)預(yù)期使用者及管理者的工作現(xiàn)場，一邊觀察，一邊聽其講解，從而更直觀的了解其需求.

D.從法律法規(guī)、行業(yè)標(biāo)準(zhǔn)、業(yè)務(wù)規(guī)則中提取需求

這種方法要求需求分析師有一定的行業(yè)從業(yè)經(jīng)驗及法律法規(guī)知識，能夠了解行業(yè)的發(fā)展動向，可以聘請業(yè)務(wù)專家、相關(guān)法律專家和業(yè)務(wù)骨干對需求分析師進(jìn)行集中培訓(xùn)和講解，使之縮短提取需求時間，提高需求獲取的準(zhǔn)確性和效率.

E.文檔追溯(文檔考古)

需求獲取人員通過對甲方業(yè)務(wù)和工作中已經(jīng)歸檔的歷史文檔進(jìn)行研究，其主要的工作是對已經(jīng)歸檔的攜帶了大量真實數(shù)據(jù)的文件、表單、報告和電子文檔進(jìn)行分析，獲取需要調(diào)研的信息.

F.需求討論會

需求討論會作為需求獲取階段的重要手段，一直都是在需求的中期后期來進(jìn)行，需要在獲取到一定量的系統(tǒng)需求后，在召集甲方的關(guān)鍵業(yè)務(wù)人員和開發(fā)方的需求分析人員、項目開發(fā)人員來進(jìn)行需求討論，并最終確定.

G.原型法

需要在很短的時間內(nèi)完成的中小型軟件系統(tǒng)，針對實際情況經(jīng)常采用的是原型法(prototype)，即把系統(tǒng)主要功能、流程和數(shù)據(jù)項通過快速開發(fā)制作形成可視的操作頁面展示給系統(tǒng)預(yù)期使用者，并征求預(yù)期使用者意見，通過可視化的界面和數(shù)據(jù)項快速的確定項目的實際需求.

4)需求獲取資料的保管

根據(jù)所采用的需求獲取方法，在需求獲取過程中將產(chǎn)生不同的記錄和原始資料，項目組應(yīng)將這些記錄納入開發(fā)庫進(jìn)行配置管理.需求獲取的記錄與資料包括但不限于:用戶編寫的原始需求文檔、用戶填寫的需求調(diào)查表、用戶訪談的訪談紀(jì)要、需求研討會的會議紀(jì)要、相關(guān)的政策法規(guī)文件，業(yè)務(wù)規(guī)則文件以及行業(yè)標(biāo)準(zhǔn)文件、需求原型.

4.2 編寫用戶需求規(guī)格說明書

需求獲取人員在通過需求獲取的各種方法獲取的項目需求進(jìn)行整理、分析和記錄，結(jié)合實際情況編寫《用戶需求規(guī)格說明書》，《用戶需求規(guī)格說明書》作為開發(fā)方與甲方的溝通性文檔，需要具有以下特性:編寫語言必須采用通俗易懂的語言；術(shù)語性字眼必須加以解釋；結(jié)構(gòu)清晰，條理清楚，主次分明；需進(jìn)行廣泛的意見征集.

主要內(nèi)容應(yīng)該包括但不局限于:系統(tǒng)總體介紹(背景、用途、用戶群和系統(tǒng)特征)；系統(tǒng)應(yīng)遵循的業(yè)務(wù)規(guī)范和行業(yè)標(biāo)準(zhǔn)；業(yè)務(wù)流程；產(chǎn)品的功能性需求；產(chǎn)品的非功能性需求.

建議針對工作量小于5人月的小型項目、使用了原型法獲取需求的項目、沒有明確的目標(biāo)使用者的項目、直接引用預(yù)期使用者提供的需求說明書的項目，可以不用編制《用戶需求規(guī)格說明書》.

4.3 需求分析

在需求獲取后，對獲取到的業(yè)務(wù)資料、訪談記錄、意見匯總表和各討論會會議紀(jì)要進(jìn)行整理和分析，并由甲乙雙方的骨干人員進(jìn)行需求分析工作，對其分散獲取的各項具體建立邏輯關(guān)系，明確軟件類的需求，并對其進(jìn)行分類，確定其需求的優(yōu)先級和重要程度等.

主要的需求分析方法如下:

1)結(jié)構(gòu)化分析方法

結(jié)構(gòu)化分析方法的主要特點是“自頂向下、逐層分解”，利用圖形、表格等描述方式表達(dá)需求，對需求問題進(jìn)行分析，具體采用的工具有:Data Flow Diagram、Data Dictionary、E-R圖、判定表和判定樹、結(jié)構(gòu)化語言.

結(jié)構(gòu)化分析方法從總體上看是一種強(qiáng)烈依賴數(shù)據(jù)流圖的自上而下的建模方法，在具體的項目中，結(jié)構(gòu)化分析方法的具體操作方式如下:

A.建立系統(tǒng)的物理模型；B.建立系統(tǒng)的邏輯模型；C.劃清人機(jī)界限

2)基于用例的分析方法

基于用例的分析方法，主要是成熟度高，規(guī)模大和分工明確的開發(fā)公司進(jìn)行采用，針對大型的軟件項目，開發(fā)方會根據(jù)獲取的需求來形成可視化的程序?qū)嵗M出系統(tǒng)的各項功能、使用流程和數(shù)據(jù)項，建立可供需求分析的用例模型.

使用用例分析方法時可遵循以下步驟:

A.界定系統(tǒng)使用者；B.分析整理需求形成用例；C.形成用例圖；D.對用例進(jìn)行詳細(xì)描述.

4.4 需求定義

需求獲取、分析完成后，項目組需要做的就是進(jìn)行需求定義，需求定義主要是根據(jù)需求獲取和分析的結(jié)果，定義軟件需求，形成《軟件需求規(guī)格說明書》.

1)定義需求優(yōu)先級

需求定義首先需要確認(rèn)的是定義需求的優(yōu)先級，在需求分析完成后，需要對需求的優(yōu)先級進(jìn)行分析和定義，并預(yù)先制定優(yōu)先級評價標(biāo)準(zhǔn)，在作者參與的項目中，需求優(yōu)先級的評價標(biāo)準(zhǔn)如下:

2)編寫《軟件需求規(guī)格說明書》

需求分析師在組織甲乙雙方的項目骨干人員進(jìn)行需求分析過程后形成《軟件需求規(guī)格說明書》(其中包含《產(chǎn)品功能列表》).編寫需求規(guī)格說明書應(yīng)遵循以下規(guī)則，確保需求的完整性、確保需求的一致性、確保需求的正確性、確保需求無二義性、確保需求易于追溯、確保需求的可測試性、確保需求的可行性.

4.5 需求確認(rèn)

《軟件需求規(guī)格說明書》編寫完成后，需要項目的甲乙雙方的項目骨干人員及外部的業(yè)務(wù)專家共同進(jìn)行需求確認(rèn)，對《軟件需求規(guī)格說明書》進(jìn)行評審.需求確認(rèn)是需求階段最重要的一個環(huán)節(jié)，但是往往又被項目的建設(shè)方所忽視，做好需求的確認(rèn)工作對整個項目的后續(xù)開發(fā)和順利進(jìn)行都覺有非常重大的意義，需求確認(rèn)的主要工作如下:

1)需求評審

需求評審即對前面產(chǎn)生的《用戶需求規(guī)格說明書和》、《軟件需求規(guī)格說明書》進(jìn)行評審，召開技術(shù)評審會議，組建評審小組，召集項目干系人、業(yè)務(wù)專家和外部技術(shù)專家進(jìn)行討論，并對評審意見和結(jié)果進(jìn)行記錄，把評審意見和結(jié)果性的東西合并到文檔中，需指定嚴(yán)格的評審規(guī)范和流程.

大型的軟件項目也可采用分段評審的方式來進(jìn)行需求評審，即針對性的邀請專家、業(yè)務(wù)骨干和系統(tǒng)預(yù)期使用者參加進(jìn)行小規(guī)模的評審，降低需求返工的風(fēng)險，縮短需求評審的周期和事件，提高需求評審質(zhì)量.

2)需求承諾

需求承諾作為需求確認(rèn)的手段，開發(fā)方項目經(jīng)理把評審?fù)ㄟ^的《軟件需求規(guī)格說明書》提交給甲方進(jìn)行確認(rèn)，主要包含以下確認(rèn)方式:

直接簽字:由甲方在《軟件需求確認(rèn)書》上直接簽字或蓋章確認(rèn)，附件為《軟件需求規(guī)格說明書》.

郵件方式:由項目經(jīng)理將《軟件需求規(guī)格說明書》與評審報告通過郵件發(fā)送給接收方，并明確確認(rèn)通過的準(zhǔn)則.

發(fā)送會議紀(jì)要函:如果甲方參加了評審會議并在會上達(dá)成了共識，則可以通過編制會議紀(jì)要，在紀(jì)要中寫明參加評審的人員、評審的結(jié)論等，并讓甲方簽字蓋章確認(rèn).

不過作者根據(jù)多年的項目管理經(jīng)驗，強(qiáng)烈建議采用直接簽字的方法進(jìn)行需求承諾確認(rèn).

3)建立需求基線

項目的《軟件需求規(guī)格說明書》經(jīng)過評審與確認(rèn)后，應(yīng)建立需求基線，并上傳到配置管理服務(wù)器保留版本以便后續(xù)需求變更后進(jìn)行跟蹤.

4.6 需求變更

一個大型的軟件項目，具有周期長、功能復(fù)雜的特性，無論前期開發(fā)方和建設(shè)方的需求多么明確，實際開發(fā)過程中的需求變更也是不可避免的.需求變更產(chǎn)生的主要原因，作者分析如下:

(1)系統(tǒng)開發(fā)過程中甲方的工作及業(yè)務(wù)流程發(fā)生變化；(2)前期需求獲取時發(fā)生了偏差及錯誤；(3)使用者提出新的需求；(4)被調(diào)研者無法準(zhǔn)確描述其所需要的系統(tǒng)功能；(5)法律法規(guī)或行業(yè)標(biāo)準(zhǔn)發(fā)生變化；(6)使用范圍變化，對性能的要求重新進(jìn)行界定.

需求變更在項目中的標(biāo)準(zhǔn)流程如下:

(1)變更提出，變更申請人填寫《需求變更申請單》；(2)項目經(jīng)理召集項目相關(guān)人員進(jìn)行討論，決定是否接受變更；(3)通過變更管理規(guī)范來實施變更；(4)發(fā)布新的需求基線；(5)通知相關(guān)的人員.

4.7 需求跟蹤

在大型的軟件項目中必須建立一種需求跟蹤機(jī)制，這種機(jī)制必須是雙向的，可追溯的.目前作者所接觸到的根據(jù)需求的最有效和最普遍的需求跟蹤方法是通過映射的方法建立需求跟蹤矩陣來實現(xiàn)。當(dāng)需求通過評審并確認(rèn)下來之后，項目開發(fā)方需根據(jù)具體的系統(tǒng)需求編制《需求跟蹤矩陣》，并指定需求負(fù)責(zé)人對需求跟蹤矩陣核查，保證需求跟蹤矩陣的正確性、完整性.隨著軟件開發(fā)的進(jìn)行，項目組應(yīng)專門指定專人維護(hù)需求跟蹤矩陣，對已經(jīng)變更了的需求進(jìn)行及時更新，修改需求跟蹤矩陣各模塊的對應(yīng)關(guān)系，保證其完整性，正確性和一致性.

[1]邱苑華.現(xiàn)代項目管理導(dǎo)論[M].北京:機(jī)械工業(yè)出版社，2002.

[2]巴迪魯.項目管理原理[M].北京:清華大學(xué)出版社，2003.

[3][美]羅伯特.K.威索基拉德.麥加里.有效的項目管理[M].費(fèi)琳，李盛萍，等.譯.北京:電子工業(yè)出版社，2004.

[4]張家浩.軟件項目管理[M].北京:機(jī)械工業(yè)出版社，2005.

[7]施瓦爾貝.IT項日管理[M].北京:機(jī)械工業(yè)出版社，2004.

[5]羅運(yùn)模，謝志敏.CMMI軟件過程改進(jìn)與評估[M].北京:電子工業(yè)出版社，2004.

[6][美]Dennis M.Ahern，Aaron Clouse，Richard Turner.CMMI精粹—集成化過程改進(jìn)實用導(dǎo)論[M].北京:清華大學(xué)出版社，2005.

[7]吳明珠，徐俊.基于CMMI的需求工程實施方法研究[J].軟件導(dǎo)刊，2009(1).

[8]李世蓉，黃福珠.淺議工程建設(shè)項目中的采購信息管理[J].重慶工學(xué)院學(xué)報:自然科學(xué)版，2006(9).