馮笑媚

摘 要：為了響應(yīng)綠色生產(chǎn)的號(hào)召，很多傳統(tǒng)工業(yè)也開始注重生產(chǎn)的環(huán)境，如何讓傳統(tǒng)工業(yè)更好地走上節(jié)能環(huán)保之路，這是近幾年來我們一直在探討的問題，下面我將借此篇文章講述我們進(jìn)行需求分析的過程。本文以《綠色車間檢測(cè)系統(tǒng)》項(xiàng)目為例講述了需求分析方法的選擇，及其應(yīng)用的過程。在本文中首先介紹了需求分析的主要工作，然后討論了選用面向?qū)ο蠓椒ǖ闹饕碛膳c策略，然后通過一個(gè)簡(jiǎn)單的案例說明該方法的使用過程、效果及其在軟件需求分析各階段所產(chǎn)生的可交付成果，再通過部分功能的需求分析來討論使用其他方法來進(jìn)行需求分析的好處及必要性，最后進(jìn)行簡(jiǎn)要小結(jié)說明選用多種方法進(jìn)行需求分析的意義及作用。

在項(xiàng)目開展期間，我擔(dān)任了需求分析、系統(tǒng)設(shè)計(jì)等大量工作。

正文：

綠色車間檢測(cè)系統(tǒng)是以車間為載體，融合自動(dòng)控制技術(shù)、計(jì)算機(jī)技術(shù)、物聯(lián)網(wǎng)技術(shù)，將生產(chǎn)設(shè)備控制、環(huán)境監(jiān)控、信息管理等功能有機(jī)結(jié)合，通過對(duì)生產(chǎn)環(huán)境設(shè)備的集中管理，提供更具綠色、安全、節(jié)能的工作環(huán)境。需求獲取完畢后，我們需要對(duì)需求進(jìn)行分析，因?yàn)橹挥袑?duì)需求進(jìn)行正確的分析，才能設(shè)計(jì)出用戶滿意的系統(tǒng)。需求分析里我們需求解決一下問題：

根據(jù)獲取的需求描述，解決綠色車間檢測(cè)系統(tǒng)是做什么的；

如何讓用戶清楚需求，并與用戶達(dá)成一致后簽署需求規(guī)格說明書；

如何能夠讓開發(fā)人員理解，使其能夠按照需求規(guī)格說明書的要求完成系統(tǒng)功能；

針對(duì)以上問題，經(jīng)項(xiàng)目組的討論，我們決定使用面向?qū)ο蟮姆椒ㄗ鳛楸敬雾?xiàng)目需求分析的主要方法，下面介紹一下我們做軟件需求分析的過程及各個(gè)階段的可交付成果。

第一步了解系統(tǒng)業(yè)務(wù)結(jié)構(gòu)，我們通過各種需求獲取的技術(shù)從用戶那獲取了系統(tǒng)的需求，比如設(shè)備管理模塊需要實(shí)時(shí)知道設(shè)備的狀態(tài)，從而在生產(chǎn)過程中去控制和管理設(shè)備；用戶管理模塊需要知道員工的信息，根據(jù)員工的崗位來分配權(quán)限，使其有操作設(shè)備的權(quán)限；環(huán)境管理模塊中，需要實(shí)時(shí)監(jiān)控環(huán)境中的質(zhì)量因素，從而根據(jù)空氣質(zhì)量來調(diào)整生產(chǎn)設(shè)備的使用情況，來控制生產(chǎn)等。用戶的需求除了功能性需求外，還有非功能性的需求，如果單純來用文字描述所有的需求，不但容易遺漏，而已不容易讓用戶看懂。鑒于此我們選擇采用Rational Rose（基于UML）的用例圖、類圖及其他多種圖來聯(lián)合描述需求，確保需求沒有遺漏。每當(dāng)我們分析出一個(gè)圖，我們都會(huì)向用戶進(jìn)行展示說明，讓用戶及時(shí)了解需求的詳情，也可讓用戶及時(shí)提出對(duì)需求的修改意見，促使盡早地與用戶達(dá)成需求一致的共同意識(shí)。

經(jīng)過了解系統(tǒng)業(yè)務(wù)結(jié)構(gòu)這一步后，我們能從宏觀上把握用戶的具體需求方向和趨勢(shì)，了解現(xiàn)有的組織架構(gòu)、業(yè)務(wù)流程、硬件環(huán)境、軟件環(huán)境、現(xiàn)有的運(yùn)行系統(tǒng)等等具體情況、客觀的信息。同時(shí)在每個(gè)職能部門都安排好了本次項(xiàng)目的負(fù)責(zé)人，為接下來的需求分析工作建立起良好的溝通渠道和方式。經(jīng)過一輪的了解及調(diào)研，我們編寫了調(diào)查報(bào)告，分析了客戶的組織業(yè)務(wù)概況和企業(yè)現(xiàn)狀，為接下來的需求分析工作打下了基礎(chǔ)。

第二步了解系統(tǒng)各個(gè)模塊的業(yè)務(wù)流程，在這個(gè)階段，我們需要把系統(tǒng)的各個(gè)模塊的業(yè)務(wù)流程分析出來，也要讓開發(fā)人員和用戶看的明白。因此我們?cè)谏弦浑A段的基礎(chǔ)上，跟蹤了各個(gè)模塊的業(yè)務(wù)流程，把各個(gè)業(yè)務(wù)流程根據(jù)需要使用狀態(tài)圖、活動(dòng)圖、序列圖或者協(xié)作圖來表示。每一個(gè)圖完成，我們也會(huì)讓用戶和開發(fā)人員先看一下，有問題的及時(shí)也需求分析人員溝通，這樣既可以讓用戶和開發(fā)人員明白我們的需求。然而我們以前的多個(gè)項(xiàng)目中，經(jīng)常會(huì)出現(xiàn)開發(fā)人員做出來的系統(tǒng)功能，與用戶想的功能是不一致，導(dǎo)致整個(gè)模塊，甚至是整個(gè)系統(tǒng)的編碼工作要重新編寫或者要做大量的修改。這就是在系統(tǒng)的業(yè)務(wù)流程的需求分析時(shí)，沒用讓開發(fā)人員和用戶的需求達(dá)成一致造成的，因此我們采用面向?qū)ο蟮姆椒ㄟM(jìn)行分析，將每一個(gè)用例的業(yè)務(wù)流程都以圖的形式展示出來，讓用戶和開發(fā)人員去確認(rèn)，從而讓開發(fā)人員盡早的理解和明白系統(tǒng)的業(yè)務(wù)流程，能夠盡早的避免用戶和開發(fā)人員的想法不一致導(dǎo)致開發(fā)的系統(tǒng)不符合需求的情況。面向?qū)ο蟮姆椒?，使系統(tǒng)劃分成一個(gè)個(gè)獨(dú)立的對(duì)象，即使有一個(gè)對(duì)象不符合需求，也不會(huì)對(duì)其他的對(duì)象有很大的影響，從而減少了因需求變化而導(dǎo)致全盤皆否定的情況的出現(xiàn)。

在這一階段，除了使用面向?qū)ο蟮姆治龇椒ㄍ?，我們針?duì)調(diào)查報(bào)告，做了分析，即編寫了調(diào)研分析報(bào)告，從分析報(bào)告中，把系統(tǒng)中涉及到的功能流程，做了說明；我們?yōu)榱俗屜到y(tǒng)的業(yè)務(wù)流程更合理、更準(zhǔn)確、更便易、更符合用戶的習(xí)慣，對(duì)于主要的業(yè)務(wù)流程，我們使用了原型demo展示給用戶，讓用戶提前體驗(yàn)，并讓用戶用原型反饋報(bào)告告訴我們流程有什么問題，然后我們一起討論，把不合理的流程與用戶一起想出好的辦法來解決，最后我們編寫了業(yè)務(wù)流程報(bào)告來結(jié)束本階段的工作。

第三步將業(yè)務(wù)數(shù)據(jù)變成軟件數(shù)據(jù)，這一步實(shí)際上是收集車間中各個(gè)環(huán)節(jié)中需要用到的數(shù)據(jù)，以及這些數(shù)據(jù)是如何轉(zhuǎn)換的，為了清楚的現(xiàn)實(shí)各個(gè)環(huán)節(jié)的數(shù)據(jù)變動(dòng)，我們選擇使用DFD圖（數(shù)據(jù)流圖）來展示。為了更清楚的展示系統(tǒng)中數(shù)據(jù)之間的關(guān)系，我們采用面向?qū)ο蟮姆椒ǎ瑢⑺璧臄?shù)據(jù)看做成一個(gè)實(shí)體，各個(gè)部門之間的關(guān)系，其實(shí)就是數(shù)據(jù)之間的關(guān)系，也就是實(shí)體與實(shí)體之間的關(guān)系，在UML中我們可以使用構(gòu)件圖來表示。構(gòu)件之間有組裝、分類和相連關(guān)系，反應(yīng)了現(xiàn)實(shí)世界中的業(yè)務(wù)數(shù)據(jù)之間的關(guān)系，比如車床信息與設(shè)備信息就是組裝關(guān)系，這也反應(yīng)用面向?qū)ο蟮姆治鲋械念?、繼承和封裝等概念，能更好地反映出系統(tǒng)的業(yè)務(wù)數(shù)據(jù)關(guān)系，同時(shí)也為數(shù)據(jù)庫(kù)的概念模型設(shè)計(jì)奠定了基礎(chǔ)，避免了設(shè)計(jì)與需求分析不一致的情況，從而促進(jìn)系統(tǒng)的實(shí)現(xiàn)進(jìn)程。

在這個(gè)階段是需求細(xì)化和確認(rèn)，即進(jìn)行具體的流程細(xì)化、數(shù)據(jù)項(xiàng)的確認(rèn)階段，我們?yōu)橛脩籼峁┰拖到y(tǒng)和明確的業(yè)務(wù)流程報(bào)告、數(shù)據(jù)項(xiàng)表，并能清晰地向用戶描述系統(tǒng)的業(yè)務(wù)流設(shè)計(jì)目標(biāo)，用戶對(duì)我們提交的報(bào)告、文檔都簽字確認(rèn)了。

經(jīng)過以上三個(gè)步驟，我們基本可以解決上面的三個(gè)問題，也能夠把需求規(guī)格說明書生成出來，并且能促進(jìn)用戶和開發(fā)人員對(duì)需求的理解和確認(rèn)，從而確保系統(tǒng)的正確性。系統(tǒng)開發(fā)出來后也受到用戶的認(rèn)可。由于有高質(zhì)量的需求規(guī)格說明書，后續(xù)的設(shè)計(jì)與維護(hù)工作，我們感覺輕松多了。

使用面向?qū)ο蟮姆治龇椒ǎ梢詫⑾到y(tǒng)劃分成一個(gè)個(gè)細(xì)小的功能，把問題細(xì)化便于解決，但也有不好的地方，就是很難把握到系統(tǒng)根抽象的度，也就是功能的邊界不好把握，把握不好，系統(tǒng)的劃分就好很凌亂，導(dǎo)致后面的設(shè)計(jì)及實(shí)現(xiàn)工作難以開展。因此我們還可以使用其他的方法來輔助我們進(jìn)行需求分析，比如結(jié)構(gòu)化分析方法。在做系統(tǒng)業(yè)務(wù)流程時(shí)，我們就用到了結(jié)構(gòu)化分析方法來分析，得出了系統(tǒng)的數(shù)據(jù)流圖，使我們的系統(tǒng)業(yè)務(wù)流程及數(shù)據(jù)關(guān)系更加清楚和細(xì)化，系統(tǒng)的結(jié)構(gòu)也更加清晰和明顯。

鑒于以上的經(jīng)歷，我們覺得需求分析是系統(tǒng)開發(fā)成功與否的關(guān)鍵步驟，因此要根據(jù)系統(tǒng)的需求情況、項(xiàng)目的大小等情況來綜合選擇需求分析的方法。為了保證需求分析的正確性和完整性，我們可以綜合多種分析方法，及使用多種工具來幫助需求分析的實(shí)現(xiàn)。