|
前面我一直在反復(fù)強(qiáng)調(diào)這樣一個(gè)觀點(diǎn)，需求分析不是一蹴而就的，是一個(gè)反復(fù)迭代的過程。它將從第一次需求分析開始，一直持續(xù)到整個(gè)項(xiàng)目生命周期。為什么這樣說呢？讓我們一起來分析分析。 在第一次的需求分析階段，我們在一段時(shí)期內(nèi)需要與客戶進(jìn)行反復(fù)地討論，這個(gè)過程往往是這樣一個(gè)反復(fù)循環(huán)的過程：需求捕獲->需求整理->需求驗(yàn)證->再需求捕獲······ 需求捕獲，就是我們與客戶在一起開研討會，討論需求的活動(dòng)?？蛻艨赡軙枋鏊麄兊臉I(yè)務(wù)流程，這時(shí)我們在紙上繪制簡單的流程草圖，及時(shí)地記錄下來；客戶在描述業(yè)務(wù)的同時(shí)，可能會反復(fù)提到一些業(yè)務(wù)名詞，詳細(xì)詢問這些名詞的含義，以及它們與其它名詞的關(guān)系，用類圖或者對象圖繪制簡單的草圖；客戶在描述業(yè)務(wù)的同時(shí)，還會提出今后的軟件希望實(shí)現(xiàn)的功能，如能夠展示某個(gè)報(bào)表、能夠?qū)С鑫募孕枨罅斜淼男问接涗浵聛?。一個(gè)功能，在需求列表中會有多個(gè)需求，而每個(gè)需求應(yīng)當(dāng)能夠用1、2句話，在20個(gè)字以內(nèi)就可以描述清楚。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設(shè)計(jì)，是我們的每項(xiàng)功能必須實(shí)現(xiàn)的內(nèi)容。需求列表是需求驗(yàn)證以及日后的用戶驗(yàn)收測試的依據(jù)，不論我們今后如何分析和設(shè)計(jì)這些功能，都要能如實(shí)地實(shí)現(xiàn)這個(gè)列表中提出的需求。（需求列表應(yīng)當(dāng)如何編寫，將在后面的章節(jié)詳細(xì)描述。） 需求整理，就是在需求研討會后，需求分析人員對研討內(nèi)容的分析和整理的過程。首先，需求分析人員應(yīng)當(dāng)通過用例模型，劃分整個(gè)系統(tǒng)的功能模塊，以及各個(gè)模塊的業(yè)務(wù)流程。用例模型分析是一個(gè)由粗到細(xì)的過程，這樣一個(gè)過程也是符合人類認(rèn)識世界的思維習(xí)慣的一個(gè)過程。最先，我們應(yīng)當(dāng)對整個(gè)系統(tǒng)繪制用例圖，設(shè)計(jì)用例場景，并依次對這些用例進(jìn)行用例描述、流程分析、角色分析等分析過程。當(dāng)然，在整體用例分析的同時(shí)，我們還應(yīng)當(dāng)進(jìn)行一個(gè)整體的角色分析，繪制一個(gè)角色分析圖，進(jìn)行一個(gè)流程分析，繪制一個(gè)流程分析圖（可以是傳統(tǒng)的流程圖、UML中的行動(dòng)圖，甚至一個(gè)簡單的示意圖，等等）。 然后，我們再在整體用例圖的基礎(chǔ)上，依次對每個(gè)用例繪制用例圖。每個(gè)用例圖中，會更細(xì)致地劃分出多個(gè)用例，并依次進(jìn)行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細(xì)化，直到我們認(rèn)為需求已經(jīng)描述清楚為止。 在一個(gè)系統(tǒng)中，用例需要細(xì)化幾次，是由這個(gè)用例的業(yè)務(wù)復(fù)雜程度決定的。對于一個(gè)簡單的用例，只需要細(xì)化一次就夠了；而對于比較復(fù)雜的用例，則需要細(xì)化2~3次，甚至更多。 用例分析的過程，之所以稱之為分析，它摻入了很多需求分析人員對業(yè)務(wù)的理解與設(shè)計(jì)：模塊如何劃分、流程如何設(shè)計(jì)、業(yè)務(wù)如何轉(zhuǎn)換，等等。用例分析，還需要讓需求分析員與架構(gòu)師、設(shè)計(jì)師等技術(shù)人員共同協(xié)作來完成，因?yàn)橛美治鲞€包含對業(yè)務(wù)需求的技術(shù)可行性分析。只有一份可行的需求分析，才能為后續(xù)的設(shè)計(jì)開發(fā)掃清障礙，有效降低項(xiàng)目風(fēng)險(xiǎn)。最后，需求分析員應(yīng)當(dāng)將需求列表中的內(nèi)容，逐一地與用例進(jìn)行核對，以避免分析人員忽略用戶的某項(xiàng)業(yè)務(wù)需求。（后面將詳細(xì)描述用例模型的搭建過程。） 在用例分析的同時(shí)，需求分析人員還需要對業(yè)務(wù)中的相關(guān)事物，制作領(lǐng)域模型。領(lǐng)域模型，是對用戶業(yè)務(wù)領(lǐng)域中相關(guān)事物、相互關(guān)系、相互行為操作的描述，它是以對象圖和類圖的形式表達(dá)的。需求人員對領(lǐng)域模型的分析，對業(yè)務(wù)理解的深度，對日后軟件的設(shè)計(jì)，以及軟件的功能擴(kuò)展、升級演化，都起到了至關(guān)重要的作用。（后面將更加詳細(xì)地講述領(lǐng)域模型。） 最后，當(dāng)我們完成了一系列的分析整理并形成文檔以后，應(yīng)當(dāng)對及時(shí)地與客戶進(jìn)行反饋，確認(rèn)我們的理解是否正確，也就是需求驗(yàn)證工作。需求驗(yàn)證工作應(yīng)當(dāng)貫穿整個(gè)研發(fā)周期，并且在不同時(shí)期表現(xiàn)出不同的形式。首先，在需求分析階段，需求驗(yàn)證工作表現(xiàn)為對需求理解是否正確的信息反饋。需求分析人員與客戶再次坐在一起，一項(xiàng)一項(xiàng)描述我們對需求的整理和理解，客戶則時(shí)不時(shí)地對一些問題進(jìn)行糾正，或者更加深入地加以描述。我們則認(rèn)真地記錄，回來整理，并等待下一次的驗(yàn)證。在需求分析后期，我們還可以制作一些簡單的原型，更加形象地描述我們對需求的理解，會使我們與客戶的溝通更加順暢。隨后的設(shè)計(jì)開發(fā)階段，我們則應(yīng)當(dāng)以迭代開發(fā)的形式進(jìn)行。每開發(fā)完一個(gè)迭代周期，將開發(fā)的成果與客戶反饋。這樣做的結(jié)果是，客戶可以及時(shí)地提出我們對需求理解的偏差，或者及時(shí)提出對我們設(shè)計(jì)不滿意的地方，使我們存在的問題得到及時(shí)地發(fā)現(xiàn)與解決。問題及時(shí)的解決，使我們修復(fù)問題的代價(jià)得以降至最小。之后，當(dāng)開發(fā)進(jìn)入到驗(yàn)收測試階段，我們則是與客戶一道，一項(xiàng)一項(xiàng)地驗(yàn)證我們的軟件是否滿足需求列表中要求的業(yè)務(wù)需求。最后，當(dāng)軟件迎來下一次升級開發(fā)時(shí)，我們將開啟另一次輪回。 因此，需求分析就是按照這樣的過程，每次多理解一些，再多理解一些，更多理解一些，逐漸深入的過程。每深入一步，我們的軟件就更接近客戶的滿意。 |
|
|
