李俊煒

摘 要：文章通過分析軟件開發(fā)中的用戶需求和需求變更管理來探討軟件開發(fā)團(tuán)隊(duì)?wèi)?yīng)該如何應(yīng)對(duì)這些問題，軟件開發(fā)團(tuán)隊(duì)?wèi)?yīng)該采取哪些對(duì)策來解決用戶復(fù)雜多變的需求。

關(guān)鍵詞：軟件需求工程；需求分析；需求管理；需求變更管理

1 軟件需求分析

軟件需求是指用戶對(duì)新系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望。包括業(yè)務(wù)需求、用戶需求、系統(tǒng)需求3個(gè)不同層次。

在需求獲取階段所得到的需求是雜亂的而不明確的，很多需求既重復(fù)又矛盾，而一個(gè)合格的需求描述應(yīng)該具備完整性、可測(cè)試性、確定性、無歧義、可跟蹤性、正確性、必要性等特性，而需求分析就是把這些雜亂的用戶要求和期望轉(zhuǎn)化有效而合格的需求描述的過程。

首先，系統(tǒng)分析師通過對(duì)所獲取的需求進(jìn)行分類，創(chuàng)建出不同的業(yè)務(wù)模型：通過由領(lǐng)域?qū)＜遥ó?dāng)系統(tǒng)分析師具有足夠的領(lǐng)域經(jīng)驗(yàn)時(shí)，可泛化為領(lǐng)域?qū)＜遥┩緩降玫綐I(yè)務(wù)類模型，制作出被領(lǐng)域廣泛認(rèn)可的需求模型；通過與客戶/用戶溝通得到業(yè)務(wù)用例模型，獲得當(dāng)前業(yè)務(wù)的獨(dú)有特征，再將兩個(gè)需求集合統(tǒng)一，構(gòu)成業(yè)務(wù)模型。

1.1 需求分析的方法

在軟件工程的研究中，人們提出了多種需求分析的方法，其中主要有結(jié)構(gòu)化分析法（Structure Analysis，SA）、面向?qū)ο蠓治龇ǎ∣bject-Oriented Analysis，OOA）和面向問題域的方法。另外，還有一些形式化方法，但由于實(shí)用性不強(qiáng)，一般只用在學(xué)術(shù)研究中。

1.1.1 SA方法

SA方法主要關(guān)注于功能的分層和分解。這非常符合人們自上而下，逐步分解問題直到可解決的自然思考方式。但通過細(xì)分系統(tǒng)模塊的功能來描述整個(gè)系統(tǒng)做法，很容易混淆需求和設(shè)計(jì)的界限，使系統(tǒng)分析師感到迷惑，不知道系統(tǒng)需求應(yīng)該詳細(xì)到何種程度。并且從用戶的角度來看，他們并不想了解系統(tǒng)內(nèi)部結(jié)構(gòu)和設(shè)計(jì)，他們所關(guān)心的是系統(tǒng)所能提供的服務(wù)。SA方法模型的核心是數(shù)據(jù)字典（Data Dictionary，DD），圍繞這個(gè)核心分3個(gè)層次的模型，分別是：數(shù)據(jù)模型、功能模型和行為模型（也稱狀態(tài)模型）。

1.1.2 OOA方法

OOA方法主要是運(yùn)用面向?qū)ο蟮姆椒ǎ瑢?duì)問題域進(jìn)行分析和理解。OOA模型獨(dú)立于具體實(shí)現(xiàn)，即不考慮與系統(tǒng)具體實(shí)現(xiàn)有關(guān)的因素。僅思考“做什么”的問題。OOA使用統(tǒng)一建模語言進(jìn)行需求的分析，利用用例模型獲取需求，進(jìn)而由分析模型描述系統(tǒng)的基本邏輯結(jié)構(gòu)等。統(tǒng)一建模語言（Unified Modeling Language，UML）通過邏輯視圖、進(jìn)程視圖、實(shí)現(xiàn)視圖、部署視圖以及用例視圖來體現(xiàn)系統(tǒng)架構(gòu)。其中又包含了多種不同的圖來對(duì)所開發(fā)系統(tǒng)的某一特定方面進(jìn)行分析。

1.1.3 PODA方法

面向問題域的分析方法（Problem Oriented Domain Analysis，PODA）是一項(xiàng)很新的技術(shù)，目前還處于研究階段，它主要關(guān)注問題域，并關(guān)注系統(tǒng)實(shí)現(xiàn)的待求行為，用一個(gè)文檔對(duì)解系統(tǒng)的待求行為進(jìn)行描述。

1.2 結(jié)構(gòu)化分析方法實(shí)例

下面以一個(gè)嵌入式接口處理軟件為例，介紹結(jié)構(gòu)化分析方法的實(shí)例。該軟件使用串口1與控制器進(jìn)行交互：要求具備串口升級(jí)功能，要求具備由控制器進(jìn)行啟動(dòng)模式設(shè)置完成重啟、保存控制器發(fā)送的重要配置數(shù)據(jù)以及將常規(guī)指令通過串口2轉(zhuǎn)發(fā)至一個(gè)外部模塊。下面用狀態(tài)轉(zhuǎn)換圖（State Transition Diagram，STD）以及數(shù)據(jù)流圖（Data Flow Diagram，DFD）舉例說明結(jié)構(gòu)化分析方法。

根據(jù)以上需求可分析出當(dāng)程序正常啟動(dòng)后進(jìn)入就緒狀態(tài)，等待串口語句指令：若接收到升級(jí)指令則進(jìn)入升級(jí)狀態(tài)，升級(jí)過程中等待升級(jí)數(shù)據(jù)包，升級(jí)完成程序結(jié)束等待重啟；若接收到啟動(dòng)指令，則進(jìn)入重啟狀態(tài)；若接收到配置及常規(guī)轉(zhuǎn)發(fā)指令則完成不同狀態(tài)處理后重新進(jìn)入就緒狀態(tài)。

數(shù)據(jù)流圖按照自頂向下的分解方法，首先繪制一張頂層圖，將整個(gè)待開發(fā)系統(tǒng)表示為一個(gè)加工。系統(tǒng)頂層如圖1所示，頂層用來描述系統(tǒng)有什么輸入輸出的數(shù)據(jù)流，與哪些外部實(shí)體直接相關(guān)。

完成頂層圖建模之后，在此基礎(chǔ)上進(jìn)一步分解，得到圖2的1層圖示例，1層圖將系統(tǒng)細(xì)化為3個(gè)加工。

繼續(xù)對(duì)1層圖中的加工1進(jìn)行分解，并將所分解的加工命名為1.1，1.2……，可以看到在細(xì)化的2層圖中引入了數(shù)據(jù)存儲(chǔ)，看到對(duì)于配置參數(shù)、啟動(dòng)設(shè)置數(shù)據(jù)等需要進(jìn)行存儲(chǔ)操作。就這樣在不斷細(xì)化的過程中完成分析工作。

1.3 面向?qū)ο蠓治龇椒▽?shí)例

同樣根據(jù)上述需求的例子，利用面向?qū)ο蟮姆治龇椒ㄟM(jìn)行分析，通過分析不同參與者所關(guān)注的不同需求，得到以下的用例圖示例，如圖4所示。

在獲取用例后，還需要繼續(xù)深入分析，對(duì)用例間的活動(dòng)關(guān)系進(jìn)行研究，同時(shí)對(duì)升級(jí)用例進(jìn)行了細(xì)化分析，便得到了以下的活動(dòng)圖示例。在后續(xù)分析中可使用該方法進(jìn)行進(jìn)一步的活動(dòng)細(xì)化。

2 軟件需求管理

需求是軟件項(xiàng)目成功的核心所在，它是后續(xù)軟件工作開展的基礎(chǔ)和基石。在軟件需求工程中，需求管理貫穿于整個(gè)過程。

首先，最重要的是系統(tǒng)分析師應(yīng)充分思考客戶的需求，制定計(jì)劃前要有充分的溝通，若這點(diǎn)沒有實(shí)現(xiàn)，繼續(xù)展開下一步制作，只會(huì)使得雙方的理念偏離越來越大，最終做出來的軟件也很有可能不符合用戶的商業(yè)用途。

編寫需求文檔，確定需求的范圍和標(biāo)準(zhǔn)，加以約束限制，然后對(duì)需求進(jìn)行細(xì)化，在具體實(shí)施過程中還需進(jìn)行不斷地調(diào)整。有時(shí)計(jì)劃趕不上變化，受許多非確定因素影響，若不能及時(shí)有效處理這些改變，將會(huì)拖延工期，面臨很大的風(fēng)險(xiǎn)。

系統(tǒng)設(shè)計(jì)師對(duì)系統(tǒng)自身需求、客戶需求都要有深刻認(rèn)識(shí)，要充分了解各個(gè)階段的計(jì)劃，預(yù)測(cè)軟件開發(fā)的進(jìn)程，軟件生產(chǎn)做到有目的性、階段性、可行性，才能保證項(xiàng)目開發(fā)的順利進(jìn)行。

在需求管理中，應(yīng)該認(rèn)識(shí)到整個(gè)需求開發(fā)過程的各個(gè)階段并不是瀑布式發(fā)展的，而是應(yīng)該采用迭代方式。由這一思想去進(jìn)行需求管理及控制，保證項(xiàng)目的順利進(jìn)行是非常有必要的。需求管理涉及3個(gè)主要問題：將需求進(jìn)行標(biāo)識(shí)、分類以及組織，并為需求建立文檔；管理需求的變更，說明不可避免的需要變更是如何被提出、協(xié)商、確認(rèn)的，并且將整個(gè)變更過程記錄在案；對(duì)需求進(jìn)行跟蹤，保持需求和軟件產(chǎn)品之間的一致性，及相互關(guān)聯(lián)性。

2.1 需求變更的原因分析

需求變化問題是一直存在的，也是不可避免的，需求不可能一開始就做到百分之百完善，往往都需要在后續(xù)階段不斷地改進(jìn)，對(duì)于項(xiàng)目團(tuán)隊(duì)而言，必須要正確對(duì)待變更，按照既定流程管理變更，盡量降低由于變更帶來的成本、進(jìn)度及質(zhì)量的負(fù)面影響。

需求變更的原因常見有：（1）最初對(duì)用戶需求缺乏認(rèn)識(shí)，產(chǎn)生了錯(cuò)誤，需要改變；（2）用戶產(chǎn)業(yè)有了變化，軟件開發(fā)概念也要隨之改變；（3）需求了解不夠全面，需求要增加；（4）系統(tǒng)的升級(jí)換代使軟件的運(yùn)行環(huán)境發(fā)生改變，軟件的兼容性必須滿足，安全性也必須提高。

無論是哪種情況所導(dǎo)致的需求變更通常都意味著新需求的增加和原有需求的修改，對(duì)于較少發(fā)生的減少需求的情況，則比較容易處理。無論對(duì)何種變更，都必須采取規(guī)范的流程去管理，以保證變更后不會(huì)帶來新的問題。

2.2 需求變更的管理控制

為保證需求變更不對(duì)軟件質(zhì)量產(chǎn)生負(fù)面影響，必須規(guī)范軟件開發(fā)過程，開發(fā)出標(biāo)準(zhǔn)的管理流程。近些年，軟件大量生產(chǎn)，若沒有一個(gè)規(guī)范統(tǒng)一的開發(fā)流程模式，軟件開發(fā)過程中由于需求的變更，增加了生產(chǎn)工期，生產(chǎn)成本提高，擴(kuò)大了風(fēng)險(xiǎn)，很可能導(dǎo)致項(xiàng)目失敗。需求變更動(dòng)機(jī)往往是為了滿足用戶需要，順應(yīng)市場(chǎng)的動(dòng)態(tài)變化，但是為了能使整個(gè)工程能夠如期完成，必須制定一個(gè)合理有效的變更機(jī)制，確定一個(gè)變化范圍，考慮到軟件制作的合理性，不能一味地聽從用戶的體驗(yàn)需求，而不思考項(xiàng)目組能否在不違背完整性約束的條件下開發(fā)出軟件。對(duì)以往的需求變更進(jìn)行收集、整理、分類，將變更方案的檔案記錄下來，在下次遇到需求變更時(shí)能夠快速應(yīng)對(duì)，迅速制作出處理方案。

軟件開發(fā)做到嚴(yán)格按照流程實(shí)施，對(duì)需求變更流程路線做到統(tǒng)一規(guī)范。首先是對(duì)各種需求變更的詳細(xì)原因進(jìn)行收集，并寫成需求變更請(qǐng)求報(bào)告，提交評(píng)審小組進(jìn)行變更評(píng)審。在需求評(píng)審過程中，對(duì)需求變更項(xiàng)目進(jìn)行審查，將可執(zhí)行的需求挑選出來，不合理的需求進(jìn)行排除，還有一部分尚不確定的還需要和用戶進(jìn)行下一階段的溝通處理，再次通過審核，直到通過評(píng)審才能到下一步的流程。而當(dāng)變更周期完成后，還需要對(duì)變更情況進(jìn)行測(cè)試及跟蹤。在中途有新的變更時(shí)，需要通重新進(jìn)行這一流程處理。因此看似簡(jiǎn)單的變更，實(shí)施過程中卻并不簡(jiǎn)單。只有嚴(yán)格按照規(guī)定流程進(jìn)行管理，才能得到質(zhì)量保證與質(zhì)量的控制。

初步的需求變更完成后，為了加強(qiáng)需求變更后的準(zhǔn)確性，技術(shù)人員必須對(duì)軟件進(jìn)行測(cè)試，檢查該階段的性能，保證與其他方面的合理銜接，預(yù)測(cè)軟件的整體運(yùn)行情況，做到一致和統(tǒng)一，而質(zhì)量控制部門也必須有質(zhì)量保證人員執(zhí)行測(cè)試，保證得到高質(zhì)量的最終產(chǎn)品。

3 結(jié)語

一個(gè)軟件的生產(chǎn)周期中，各個(gè)環(huán)節(jié)都不可以忽視，需求更是軟件開發(fā)的基礎(chǔ)與成功的關(guān)鍵。軟件企業(yè)應(yīng)該在軟件開發(fā)過程中不斷地總結(jié)問題，提高需求分析及需求管理水平，過程中必須嚴(yán)格按照流程實(shí)施。只有在遇到問題積極面對(duì)，保證管理者與被管理者的良好關(guān)系，才能在確保生產(chǎn)效率的情況下提高軟件的質(zhì)量。

[參考文獻(xiàn)]

[1]雷斯?jié)煽?，馬克扎克.需求分析與系統(tǒng)設(shè)計(jì)[M].馬素霞，王素琴，謝萍，譯.北京：機(jī)械工業(yè)出版社，2009.

[2]張友生.系統(tǒng)分析師教程[M].北京：清華大學(xué)出版社，2010.

[3]李超，謝坤武.軟件需求分析方法研究進(jìn)展[J].湖北民族學(xué)院學(xué)報(bào)（自然科學(xué)版），2013（2）：204-211.