淺談軟件開(kāi)發(fā)項(xiàng)目中的需求變更

摘要:軟件開(kāi)發(fā)項(xiàng)目中的需求變更是一個(gè)令軟件開(kāi)發(fā)人員感到頭痛的問(wèn)題，但同時(shí)需求變更又是不可避免的。本文將探討需求變更產(chǎn)生的原因以及如何正確對(duì)待需求變更。

關(guān)鍵詞:軟件開(kāi)發(fā) 需求變更

一、需求變更的涵義

需求變更是因?yàn)橛脩舻男枨蟀l(fā)生了變化。如果在需求說(shuō)明書(shū)經(jīng)過(guò)論證以后，需要在原有需求基礎(chǔ)上追加和補(bǔ)充新的需求或?qū)υ行枨筮M(jìn)行修改和削減，均屬于需求變更。

在項(xiàng)目開(kāi)發(fā)進(jìn)程中，軟件開(kāi)發(fā)人員經(jīng)常要面對(duì)用戶的需求變更，有時(shí)甚至是客戶的一個(gè)電話，就推翻了之前經(jīng)過(guò)再三討論而確定下來(lái)的需求。由于用戶通常對(duì)需求變更認(rèn)識(shí)不足，因而他們提出需求變更往往比較隨意，有些用戶的需求變更甚至?xí)铋_(kāi)發(fā)人員無(wú)所適從。一旦發(fā)生了需求變更，就意味著軟件開(kāi)發(fā)人員有可能需要修改設(shè)計(jì)，重寫(xiě)代碼，調(diào)整項(xiàng)目計(jì)劃等等。更為嚴(yán)重的是:如果不能有效地處理需求變更，會(huì)導(dǎo)致項(xiàng)目計(jì)劃一再調(diào)整，項(xiàng)目多次延期，用戶的耐性漸漸消逝，研發(fā)人員的士氣也越來(lái)越低落。

總之，需求變更給項(xiàng)目的正常進(jìn)展帶來(lái)了不小的麻煩。

二、需求變更產(chǎn)生的原因

雖然一般情況下，軟件開(kāi)發(fā)人員花費(fèi)了大量的氣力去避免需求變更，可最后需求變更仍然會(huì)出現(xiàn)。產(chǎn)生需求變更的原因也有很多。

在項(xiàng)目的需求確定階段，用戶往往不能確切地定義自己需要什么，而隨著研發(fā)工作的不斷進(jìn)展，用戶對(duì)系統(tǒng)的了解也逐步深入，于是，他們可能會(huì)想到各種新的功能和特色，或?qū)σ郧疤岢龅男枨筮M(jìn)行改動(dòng)。用戶了解得越多，新的需求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)了。另外，有時(shí)候由于需求分析人員理解有誤，也可能引起需求變更。在軟件開(kāi)發(fā)項(xiàng)目中，需求變更可能來(lái)自于很多方面，如:方案服務(wù)商、用戶或產(chǎn)品供應(yīng)商等，還可能來(lái)源于項(xiàng)目組內(nèi)部。

發(fā)生需要變更可能是因?yàn)樾枨蠹?xì)化過(guò)早。細(xì)化工作是由需求分析人員完成的，一般是根據(jù)用戶提出的描述性的、總結(jié)性的短短幾句話去細(xì)化的，提取其中的一個(gè)個(gè)功能，并給出描述。然而，需求的變化是永恒的，并非對(duì)需求定義得越細(xì)，就越能避免需求的變更。太細(xì)的需求定義對(duì)需求變更沒(méi)有任何效果。當(dāng)細(xì)化到一定程度并開(kāi)始系統(tǒng)設(shè)計(jì)時(shí)，范圍會(huì)發(fā)生變化，那細(xì)節(jié)的描述可能就有很多要改動(dòng)。

需求分析的最終成果是:在客戶和開(kāi)發(fā)人員對(duì)所要開(kāi)發(fā)的產(chǎn)品達(dá)成共識(shí)后，形成具體的文檔。筆者認(rèn)為，在項(xiàng)目初期對(duì)于需求文檔可以寫(xiě)個(gè)大概，具體開(kāi)發(fā)的時(shí)候再進(jìn)行不斷的探討。文檔的工作是不斷積累的，是越來(lái)越明確的一個(gè)過(guò)程。在工作分解結(jié)構(gòu)之前，文檔工作應(yīng)該明細(xì)到每個(gè)模塊的功能要求、界面要求，驗(yàn)收標(biāo)準(zhǔn)等內(nèi)容。文檔寫(xiě)出來(lái)后，拿它來(lái)和客戶周旋。當(dāng)文檔得到客戶或項(xiàng)目干系人簽字后，就按照文檔嚴(yán)格執(zhí)行。只有把所有與項(xiàng)目有關(guān)的需求組織起來(lái)，編寫(xiě)成易于閱讀的文檔，并由項(xiàng)目的主要相關(guān)人員對(duì)這些需求進(jìn)行評(píng)審后，人們才能確定這些需求。

另外，沒(méi)有指定需求的基線也容易引起需求變更。需求的基線是指是否容許需求變更的分界線。隨著項(xiàng)目的進(jìn)展，需求的基線也在變化。是否容許變更的依據(jù)是合同以及對(duì)成本的影響。隨著項(xiàng)目的進(jìn)展，基線將越定越高，也就是說(shuō)容許的變更將越來(lái)越少。需求在通過(guò)正式的評(píng)審和批準(zhǔn)之后，就應(yīng)該確定需求基線，進(jìn)一步的需求變更將在此基線的基礎(chǔ)上，依照項(xiàng)目定義的變更流程進(jìn)行。設(shè)置需求基線可以將變更引起的麻煩減至最小。

三、如何對(duì)待需求變更

需求變更是不可避免的，項(xiàng)目開(kāi)發(fā)人員切忌在項(xiàng)目設(shè)計(jì)之前試圖消除需求變更，這樣做往往費(fèi)力不討好。項(xiàng)目開(kāi)發(fā)人員應(yīng)該做的是:在需求變更發(fā)生之前盡量減少需求變更，以將需求變更帶來(lái)的風(fēng)險(xiǎn)降到最低。在進(jìn)行需求分析時(shí)要懂得防患于未然，盡可能地分析清楚哪些是穩(wěn)定的需求，哪些是易變的需求，以便在進(jìn)行設(shè)計(jì)時(shí)，將軟件的核心建筑在穩(wěn)定的需求上，同時(shí)留出變更空間。

在討論需求時(shí)，開(kāi)發(fā)人員與用戶應(yīng)該采取相互理解、相互協(xié)作的態(tài)度，對(duì)能解決的問(wèn)題盡量解決。開(kāi)發(fā)人員必須學(xué)會(huì)認(rèn)真聽(tīng)取用戶的要求、考慮和設(shè)想，并加以分析和整理，要幫助客戶在需求分析之前就盡量對(duì)他們所需要的功能有個(gè)整體的了解和確定的思路，而不是等到程序員開(kāi)始編碼了，才提出以前原本在需求分析時(shí)就可以提出的需求。同時(shí)，軟件開(kāi)發(fā)人員應(yīng)該向用戶說(shuō)明，進(jìn)入設(shè)計(jì)階段以后，再提出需求變更會(huì)給整個(gè)開(kāi)發(fā)工作帶來(lái)什么樣的沖擊和不良后果，讓他們清楚需求隨意變更所帶來(lái)的風(fēng)險(xiǎn)，清楚這種風(fēng)險(xiǎn)應(yīng)該由客戶和項(xiàng)目開(kāi)發(fā)者共同承擔(dān)，除此之外，還應(yīng)該安排專(zhuān)職人員負(fù)責(zé)需求變更管理，保持與用戶的及時(shí)交流。另外，需求變更給軟件開(kāi)發(fā)帶來(lái)的影響有目共睹，所以在與用戶簽訂合同時(shí)，可以增加一些相關(guān)條款，如限定用戶提出需求變更的時(shí)間，規(guī)定何種情況的變更可以接受、部分接受或拒絕接受，還可以規(guī)定發(fā)生需求變更時(shí)必須執(zhí)行變更控制流程。

用戶參與需求評(píng)審也有利于減少需求變更。作為需求的提出者，用戶理所當(dāng)然是最具權(quán)威的發(fā)言人之一，在需求評(píng)審過(guò)程中，用戶往往能提出許多有價(jià)值的意見(jiàn)。同時(shí)，這也是用戶對(duì)需求進(jìn)行最后確認(rèn)的機(jī)會(huì)，可以有效減少需求變更的發(fā)生。

進(jìn)入項(xiàng)目實(shí)施階段以后，如果發(fā)生需求變更，則要分析變更請(qǐng)求，評(píng)估需求變更可能帶來(lái)的問(wèn)題和修改基準(zhǔn)文件。要讓用戶明確:任何軟件開(kāi)發(fā)項(xiàng)目中的需求變更除了影響項(xiàng)目的正常進(jìn)行以外，還會(huì)影響到客戶的投入收益。

要對(duì)需求變更進(jìn)行有效控制和管理，以便更好地處理發(fā)生的變更，確保變更有序地進(jìn)行。控制需求變更并不是控制變更的發(fā)生，而是對(duì)其進(jìn)行管理，從而減少因?yàn)樾枨笞兏鴰?lái)的損失，加快項(xiàng)目的開(kāi)發(fā)速度。需求變更的控制和管理貫穿于整個(gè)項(xiàng)目生命周期的全過(guò)程中。需求變更管理的過(guò)程很大程度上就是用戶與開(kāi)發(fā)人員的交流過(guò)程。實(shí)施需求變更管理需要遵循如下原則:

1. 建立需求基線

需求基線是需求變更的依據(jù)。在開(kāi)發(fā)過(guò)程中，需求確定并經(jīng)過(guò)評(píng)審后(用戶參與評(píng)審)，可以建立第一個(gè)需求基線。此后每次變更并經(jīng)過(guò)評(píng)審后，都要重新確定新的需求基線。

2.妥善保存需求變更產(chǎn)生的相關(guān)文檔

3.制訂簡(jiǎn)單有效的需求變更控制流程

需求變更一定要先申請(qǐng)然后再評(píng)估，最后經(jīng)過(guò)與變更大小相當(dāng)級(jí)別的評(píng)審確認(rèn)，評(píng)估如果實(shí)現(xiàn)該需求，需要的時(shí)間以及人力成本是多少，并評(píng)估對(duì)項(xiàng)目工期影響有多大，判斷哪些需求能夠目前解決，哪些需要留到下一版本解決，最后輸出一份審核確認(rèn)表反饋給用戶，和用戶進(jìn)行商討。如果需求變更被接受，還要增加實(shí)施和驗(yàn)證兩個(gè)步驟。也就是說(shuō)，需求變更控制一般要經(jīng)過(guò)變更申請(qǐng)、變更評(píng)估、決策、回復(fù)這四大步驟。在建立了需求基線后提出的所有變更都必須遵循這個(gè)控制流程進(jìn)行。

需求變更的管理和控制對(duì)項(xiàng)目成敗有重要影響，項(xiàng)目開(kāi)發(fā)之前要明確定義，開(kāi)發(fā)過(guò)程中要嚴(yán)格執(zhí)行。