賈 超

(天津市科技統(tǒng)計(jì)與發(fā)展研究中心 天津300051)

軟件項(xiàng)目需求開發(fā)與管理過程方法研究

賈 超

(天津市科技統(tǒng)計(jì)與發(fā)展研究中心 天津300051)

軟件需求是軟件開發(fā)項(xiàng)目的基礎(chǔ)，與傳統(tǒng)項(xiàng)目相比，軟件開發(fā)項(xiàng)目具有抽象性和復(fù)雜性等特點(diǎn)，因此軟件開發(fā)項(xiàng)目的需求開發(fā)和管理顯得尤為重要。根據(jù)研究表明，項(xiàng)目需求的開發(fā)和管理不到位是目前大部分軟件項(xiàng)目失敗的主要原因。就軟件開發(fā)項(xiàng)目的需求開發(fā)和管理過程的方法和工具進(jìn)行研究，將需求開發(fā)和管理過程分解細(xì)化，并對(duì)各過程組的活動(dòng)進(jìn)行研究和分析，建立可用于指導(dǎo)軟件開發(fā)項(xiàng)目的工作方法。

需求開發(fā) 需求管理 需求變更控制 過程方法 管理工具

0 引 言

隨著科學(xué)技術(shù)水平的不斷提高，有關(guān)軟件開發(fā)的知識(shí)和技術(shù)也不斷豐富，可利用的工具也越來越多，但仍然存在大量軟件開發(fā)項(xiàng)目失敗的現(xiàn)象。研究發(fā)現(xiàn)，諸多項(xiàng)目失敗的最重要原因與項(xiàng)目需求有關(guān)。用戶的需求是整個(gè)軟件開發(fā)項(xiàng)目的重中之重，是軟件設(shè)計(jì)的基礎(chǔ)，決定了項(xiàng)目方向的正確與否。需求開發(fā)的不充分和需求管理的不完善，都會(huì)造成后期開發(fā)的不斷修改和變更，造成成本的超值和進(jìn)度的滯后，最終有可能導(dǎo)致項(xiàng)目失敗。

從目前軟件開發(fā)項(xiàng)目的趨勢(shì)來看，軟件開發(fā)組織機(jī)構(gòu)和項(xiàng)目經(jīng)理更加重視軟件項(xiàng)目的開發(fā)和管理。規(guī)范化的過程和管理方法成為軟件開發(fā)生命周期的重要組成部分。

1 項(xiàng)目需求開發(fā)和管理過程組

按照現(xiàn)代軟件開發(fā)項(xiàng)目的流程，所有與需求直接相關(guān)的活動(dòng)，統(tǒng)稱為需求工程。需求工程分為需求開發(fā)和需求管理兩個(gè)部分，如圖1所示。

1.1 需求開發(fā)過程組

需求開發(fā)是CMMI①中一個(gè)重要的過程域，需求開發(fā)過程的質(zhì)量決定了軟件開發(fā)產(chǎn)品的方向，如果需求開發(fā)不充分，有可能導(dǎo)致需求理解偏差，需求的任何細(xì)小偏差，都會(huì)導(dǎo)致后期無法想象的代價(jià)。

圖1 需求工程架構(gòu)圖Fig.1 Structure of Requirement Engineering

需求開發(fā)的主要目的是對(duì)尚未形成統(tǒng)一意見的需求進(jìn)行一系列的過程活動(dòng)，需求開發(fā)的過程是從需求獲取到需求分析，需求規(guī)約和需求驗(yàn)證的過程，根據(jù)CMMI的觀點(diǎn)，需求開發(fā)過程是一個(gè)循序漸進(jìn)的過程。

1.1.1 需求獲取

需求獲取是項(xiàng)目需求階段的主要工作，也是需求工程中最復(fù)雜的工作。需求獲取是一個(gè)確定和理解不同用戶類需要和限制的過程。包括需求來源和需求獲取的技術(shù)，是軟件設(shè)計(jì)的第一階段，其本質(zhì)就是人的活動(dòng)，要建立開發(fā)人員和用戶之間的有效溝通機(jī)制，采用專業(yè)的需求獲取技術(shù)來盡可能收集用戶的需求。

1.1.2 需求分析

需求分析是建立在需求獲取基礎(chǔ)上的，是對(duì)需求獲取成果的技術(shù)分析。需求分析的任務(wù)就是定義系統(tǒng)的目的、范圍和功能的過程。需求分析的具體內(nèi)容可以歸納為6個(gè)方面：軟件的功能需求、軟件與硬件或其他外部系統(tǒng)接口、軟件的非功能性需求、軟件的反向需求、軟件設(shè)計(jì)和實(shí)現(xiàn)上的限制、閱讀支持信息。

1.1.3 需求規(guī)格說明

軟件需求規(guī)約是需求分析任務(wù)的產(chǎn)物，通過建立完整的信息描述、詳細(xì)的功能和行為描述、性能需求和設(shè)計(jì)約束的說明、合適的驗(yàn)收標(biāo)準(zhǔn)，給出目標(biāo)軟件的所有功能需求。按照IEEE/ANSI 830—1993①IEEE/ANSI830—1993：中文標(biāo)準(zhǔn)名稱為：軟件要求規(guī)范推薦實(shí)施規(guī)程。標(biāo)準(zhǔn)要求，需求規(guī)約框架包括：引言、信息描述、功能描述、行為描述、檢驗(yàn)標(biāo)準(zhǔn)、參考書目和附錄。技術(shù)人員必須通過與用戶交流提煉需求，經(jīng)雙方確認(rèn)后，正式發(fā)布需求規(guī)約。

1.1.4 需求驗(yàn)證

軟件需求驗(yàn)證是為了確保軟件需求規(guī)約準(zhǔn)確、完整地表達(dá)需要的質(zhì)量特點(diǎn)。需求驗(yàn)證過程的主要內(nèi)容包括審查需求規(guī)約、需求文檔，并以需求規(guī)約為依據(jù)編寫軟件測(cè)試用例和用戶手冊(cè)，核實(shí)驗(yàn)收標(biāo)準(zhǔn)。

1.2 需求管理過程組

需求管理是完整項(xiàng)目管理模式的一環(huán)，完整的需求管理應(yīng)當(dāng)是對(duì)已知的系統(tǒng)需求的約束和管理。

項(xiàng)目需求是漸進(jìn)明晰的，隨著軟件項(xiàng)目開發(fā)的不斷深入，用戶和開發(fā)者對(duì)于變更的理解也會(huì)產(chǎn)生變化，需求的定義也會(huì)逐漸清晰。需求管理是動(dòng)態(tài)的管理過程，需要根據(jù)軟件開發(fā)的進(jìn)展，實(shí)時(shí)對(duì)開發(fā)過程中的項(xiàng)目需求進(jìn)行管理，支持系統(tǒng)的需求演進(jìn)。項(xiàng)目需求管理內(nèi)容包括需求確認(rèn)、需求變更、需求評(píng)審和需求跟蹤。

1.2.1 需求確認(rèn)

系統(tǒng)需求得到顧客和開發(fā)人員的共同認(rèn)可后，定義需求基線。

1.2.2 需求變更管理

軟件項(xiàng)目需求永遠(yuǎn)處于不停的改變狀態(tài)，應(yīng)對(duì)軟件開發(fā)項(xiàng)目過程中所提出的需求變更，建立正式的需求變更流程加以嚴(yán)格控制，防止項(xiàng)目無限制變更所導(dǎo)致的項(xiàng)目范圍蔓延。

1.2.3 需求的評(píng)審

對(duì)項(xiàng)目干系人提出的需求變更進(jìn)行評(píng)審，評(píng)估每一項(xiàng)變更的可能影響從而決定是否實(shí)施。

1.2.4 需求跟蹤

對(duì)需求變更情況和需求狀態(tài)進(jìn)行驗(yàn)證。將每項(xiàng)需求與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例等聯(lián)系起來，對(duì)項(xiàng)目變更后的執(zhí)行效果進(jìn)行評(píng)價(jià)，并對(duì)潛在的變更進(jìn)行預(yù)估。

2 需求開發(fā)和管理的過程方法

任何管理的方法和思想都是依托專業(yè)的工具、方法來實(shí)現(xiàn)的。需求開發(fā)和管理都是極其復(fù)雜的工作，使用的方法也很多，要根據(jù)不同項(xiàng)目的特點(diǎn)選擇最合適的方法來實(shí)施項(xiàng)目需求工程。

2.1 需求開發(fā)的過程方法

需求開發(fā)過程不是一個(gè)簡單的重復(fù)工作，而是建立在上一次分析基礎(chǔ)上的不斷細(xì)化和精化，在不斷的循環(huán)過程中，最大限度地理解和分析用戶需求，確保需求開發(fā)的成果最大化。

需求開發(fā)的過程方法包括但不限于以下內(nèi)容，如表1所示。

表1 需求開發(fā)過程方法Tab.1 Approaches for the requirement development process

2.2 需求管理的過程方法

需求管理的目的就是要控制和維持需求事先約定，保證項(xiàng)目開發(fā)過程的一致性。在軟件開發(fā)過程中，不可避免地還會(huì)遇到需求變更等情況。應(yīng)加強(qiáng)變更管理，建立有效的需求變更管理制度，采用專業(yè)、正式的項(xiàng)目管理方法。對(duì)變更帶來的潛在影響及可能的成本費(fèi)用進(jìn)行評(píng)估、審批和跟蹤。

2.2.1 需求確認(rèn)

建立需求基線。需求基線是需求變更的依據(jù)。在開發(fā)過程中，需求確定并經(jīng)過評(píng)審后，可以建立第一個(gè)需求基線和項(xiàng)目范圍。此后的每次變更經(jīng)評(píng)審后，都要重新確定新的需求基線。建立需求基準(zhǔn)版本和需求控制版本文檔：確定一個(gè)需求基準(zhǔn)，這是一致性需求在特定時(shí)刻的快照。之后的需求變更遵循變更控制過程即可。每個(gè)版本的需求規(guī)格說明都必須是獨(dú)立說明，以避免將底稿和基準(zhǔn)或新舊版本相混淆。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。

2.2.2 需求變更管理

建立簡單有效的需求變更控制流程，并形成正式的發(fā)布文檔。在確定需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行控制。同時(shí)這個(gè)流程應(yīng)適合組織結(jié)構(gòu)，具有通用性，適用于以后的項(xiàng)目開發(fā)和其他項(xiàng)目的借鑒；建立變更控制委員會(huì)(CCB)或類似的職能組織。由該組織審定接受哪些變更和如何執(zhí)行變更。變更控制委員會(huì)由項(xiàng)目組各方共同組成，應(yīng)包含對(duì)項(xiàng)目具有影響力的決策者。

2.2.3 需求評(píng)審

需求變更一定要進(jìn)行正式的評(píng)估，對(duì)需求變更的影響進(jìn)行分析，并根據(jù)影響程度的大小組織同等級(jí)別的變更評(píng)審。

2.2.4 需求跟蹤，應(yīng)跟蹤影響工作產(chǎn)品的每項(xiàng)變更

需求變更是一個(gè)系統(tǒng)性工作。當(dāng)進(jìn)行某項(xiàng)需求變更時(shí)，參照需求跟蹤能力矩陣找到相關(guān)的其他需求、設(shè)計(jì)模板、源代碼和測(cè)試用例，這些相關(guān)部分可能也需要修改。這樣能減少因疏忽而不得不變更產(chǎn)品的機(jī)會(huì)，這種變更在變更需求的情況下是必須進(jìn)行的。維護(hù)需求變更的歷史記錄：記錄變更需求文檔版本的日期以及所做的變更、原因，還包括由誰負(fù)責(zé)更新和更新的新版本號(hào)等。建立數(shù)據(jù)庫，記錄保存每一項(xiàng)功能需求，記錄包括功能需求的重要屬性和狀態(tài)(如已通過、已實(shí)施、已驗(yàn)證等)。衡量需求穩(wěn)定性：記錄基準(zhǔn)需求的數(shù)量和每周或每月的變更(添加、修改、刪除)數(shù)量。

2.2.5 衡量需求穩(wěn)定性

定期對(duì)需求變更數(shù)量和原始需求數(shù)量進(jìn)行比較。過多的需求變更“是一個(gè)報(bào)警信號(hào)”，意味著需求開發(fā)不完整，問題沒有真正清楚，應(yīng)重新審定項(xiàng)目需求或者取消項(xiàng)目。

2.3 需求管理的常用工具

在需求管理過程中，利用需求管理工具，可使需求管理工作更加高效。商業(yè)化的需求管理工具能幫助在數(shù)據(jù)庫中存儲(chǔ)不同類型的需求，為每項(xiàng)需求確定屬性，可跟蹤其狀態(tài)，并在需求與其他軟件開發(fā)工作中建立跟蹤能力聯(lián)系鏈。目前市場(chǎng)上比較常用的需求管理工具有Rational Requisite Pro①Requisite Pro是一個(gè)強(qiáng)大、易用、集成的需求管理產(chǎn)品。通過與Rational系列軟件產(chǎn)品的廣泛集成，大大擴(kuò)展了Requisite Pro及其他產(chǎn)品的功能。、IBM Rational DOORS②IBM Rational DOORS前身是Telelogic Doors，被IBM收購后更名為IBM Rational DOORS。、青銅器RDM③青銅器RDM是IPD+CMMI+Scrum一體化研發(fā)管理解決方案，針對(duì)需求管理，涵蓋需求的全生命周期管理。等。

3 當(dāng)前需求開發(fā)和管理存在的問題

由于軟件開發(fā)項(xiàng)目的專業(yè)性、復(fù)雜性，與一些傳統(tǒng)項(xiàng)目相比，軟件開發(fā)項(xiàng)目更模糊、不確定。軟件開發(fā)項(xiàng)目的需求開發(fā)和管理仍存在很多問題。需求開發(fā)和管理的知識(shí)和方法存在缺少實(shí)踐，管理方法的執(zhí)行不徹底。

3.1 溝通問題

由于軟件項(xiàng)目屬于專業(yè)行為，在需求收集階段，一般用戶很難清晰地理解開發(fā)人員的理念，所以在描述需求時(shí)，很難清晰地表達(dá)需求。此外，用戶對(duì)系統(tǒng)并不了解，往往在項(xiàng)目開發(fā)深入、功能雛形展現(xiàn)的時(shí)候，才真正的清楚自己所需的功能。這就需要項(xiàng)目管理人員和開發(fā)人員在項(xiàng)目需求開發(fā)階段，盡可能深入地挖掘用戶需求，在項(xiàng)目開發(fā)過程中，建立正式的溝通機(jī)制和平臺(tái)，保持與客戶的溝通協(xié)調(diào)。

3.2 需求基線的控制力不足

缺少需求基線的控制，變更執(zhí)行不是在需求基線基礎(chǔ)上進(jìn)行的，或者在需求變更后，基線調(diào)整沒有跟上。

3.3 需求管理中對(duì)需求的跟蹤和管理的變更不力

目前，國內(nèi)很多項(xiàng)目都缺少對(duì)項(xiàng)目需求的跟蹤和效果分析，對(duì)于變更的作用如何缺少評(píng)價(jià)機(jī)制，這樣就導(dǎo)致目前很多項(xiàng)目的需求變更控制不力，項(xiàng)目變更失控。

4 總 結(jié)

在軟件研發(fā)項(xiàng)目的生命周期的任何階段，需求的開發(fā)和管理都扮演著極其重要的角色，在很大程度上直接決定著項(xiàng)目的最終成敗。因此，在軟件開發(fā)項(xiàng)目研發(fā)過程中，項(xiàng)目管理者要重視需求的管理，根據(jù)所在組織的開發(fā)環(huán)境因素，結(jié)合不斷的管理實(shí)踐，摸索出適合各自不同開發(fā)環(huán)境需求管理的實(shí)施辦法和方式。

［1］ 賁可榮，何智勇. 軟件工程：基于項(xiàng)目的面向?qū)ο笱芯糠椒╗M]. 北京：機(jī)械工業(yè)出版社，2009.

［2］ 覃征，楊利英，高勇民，等. 軟件項(xiàng)目管理[M]. 北京：清華大學(xué)出版社，2004.

［3］ 周之英. 現(xiàn)代軟件工程[M]. 北京：科學(xué)出版社，2000.

［4］ 劉霞，李懷璋，王青，等. 基于ISO9000和CMMs的需求開發(fā)和需求管理平臺(tái)框架的研究[J]. 微電子學(xué)與計(jì)算機(jī)，2002(2)：50-54.

On Process Approaches for Requirement Development and Management of Software Projects

JIA Chao
(Tianjin Science and Technology Statistics and Development Research Center，Tianjin 300051，China)

The requirement is the basis of a software development project. Owing to the characteristics of abstractness and complexity requirement development and management are particularly important in a software development project. According to studies unqualified development and management of project requirements is the main cause of the most software project failures. This paper mainly studies methods and tools in the process of software project’s requirement development and management. Through decomposition of the development and management process the activities of each process group were studied and work assignments that can guide the requirement development and management were presented.

requirement development；requirement management；change control of requirements；process method；management tool

TP311.5

：A

：1006-8945(2015)12-0049-03

①CMMI：CMMI全稱是Capability Maturity Model Integration，即軟件能力成熟度模型集成。

2015-11-03