論需求分析方法及應用

馮笑媚

摘 要：為了響應綠色生產的號召，很多傳統工業也開始注重生產的環境，如何讓傳統工業更好地走上節能環保之路，這是近幾年來我們一直在探討的問題，下面我將借此篇文章講述我們進行需求分析的過程。本文以《綠色車間檢測系統》項目為例講述了需求分析方法的選擇，及其應用的過程。在本文中首先介紹了需求分析的主要工作，然后討論了選用面向對象方法的主要理由與策略，然后通過一個簡單的案例說明該方法的使用過程、效果及其在軟件需求分析各階段所產生的可交付成果，再通過部分功能的需求分析來討論使用其他方法來進行需求分析的好處及必要性，最后進行簡要小結說明選用多種方法進行需求分析的意義及作用。

在項目開展期間，我擔任了需求分析、系統設計等大量工作。

正文：

綠色車間檢測系統是以車間為載體，融合自動控制技術、計算機技術、物聯網技術，將生產設備控制、環境監控、信息管理等功能有機結合，通過對生產環境設備的集中管理，提供更具綠色、安全、節能的工作環境。需求獲取完畢后，我們需要對需求進行分析，因為只有對需求進行正確的分析，才能設計出用戶滿意的系統。需求分析里我們需求解決一下問題：

根據獲取的需求描述，解決綠色車間檢測系統是做什么的；

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

如何能夠讓開發人員理解，使其能夠按照需求規格說明書的要求完成系統功能；

針對以上問題，經項目組的討論，我們決定使用面向對象的方法作為本次項目需求分析的主要方法，下面介紹一下我們做軟件需求分析的過程及各個階段的可交付成果。

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

經過了解系統業務結構這一步后，我們能從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬件環境、軟件環境、現有的運行系統等等具體情況、客觀的信息。同時在每個職能部門都安排好了本次項目的負責人，為接下來的需求分析工作建立起良好的溝通渠道和方式。經過一輪的了解及調研，我們編寫了調查報告，分析了客戶的組織業務概況和企業現狀，為接下來的需求分析工作打下了基礎。

第二步了解系統各個模塊的業務流程，在這個階段，我們需要把系統的各個模塊的業務流程分析出來，也要讓開發人員和用戶看的明白。因此我們在上一階段的基礎上，跟蹤了各個模塊的業務流程，把各個業務流程根據需要使用狀態圖、活動圖、序列圖或者協作圖來表示。每一個圖完成，我們也會讓用戶和開發人員先看一下，有問題的及時也需求分析人員溝通，這樣既可以讓用戶和開發人員明白我們的需求。然而我們以前的多個項目中，經常會出現開發人員做出來的系統功能，與用戶想的功能是不一致，導致整個模塊，甚至是整個系統的編碼工作要重新編寫或者要做大量的修改。這就是在系統的業務流程的需求分析時，沒用讓開發人員和用戶的需求達成一致造成的，因此我們采用面向對象的方法進行分析，將每一個用例的業務流程都以圖的形式展示出來，讓用戶和開發人員去確認，從而讓開發人員盡早的理解和明白系統的業務流程，能夠盡早的避免用戶和開發人員的想法不一致導致開發的系統不符合需求的情況。面向對象的方法，使系統劃分成一個個獨立的對象，即使有一個對象不符合需求，也不會對其他的對象有很大的影響，從而減少了因需求變化而導致全盤皆否定的情況的出現。

在這一階段，除了使用面向對象的分析方法外，我們針對調查報告，做了分析，即編寫了調研分析報告，從分析報告中，把系統中涉及到的功能流程，做了說明；我們為了讓系統的業務流程更合理、更準確、更便易、更符合用戶的習慣，對于主要的業務流程，我們使用了原型demo展示給用戶，讓用戶提前體驗，并讓用戶用原型反饋報告告訴我們流程有什么問題，然后我們一起討論，把不合理的流程與用戶一起想出好的辦法來解決，最后我們編寫了業務流程報告來結束本階段的工作。

第三步將業務數據變成軟件數據，這一步實際上是收集車間中各個環節中需要用到的數據，以及這些數據是如何轉換的，為了清楚的現實各個環節的數據變動，我們選擇使用DFD圖（數據流圖）來展示。為了更清楚的展示系統中數據之間的關系，我們采用面向對象的方法，將所需的數據看做成一個實體，各個部門之間的關系，其實就是數據之間的關系，也就是實體與實體之間的關系，在UML中我們可以使用構件圖來表示。構件之間有組裝、分類和相連關系，反應了現實世界中的業務數據之間的關系，比如車床信息與設備信息就是組裝關系，這也反應用面向對象的分析中的類、繼承和封裝等概念，能更好地反映出系統的業務數據關系，同時也為數據庫的概念模型設計奠定了基礎，避免了設計與需求分析不一致的情況，從而促進系統的實現進程。

在這個階段是需求細化和確認，即進行具體的流程細化、數據項的確認階段，我們為用戶提供原型系統和明確的業務流程報告、數據項表，并能清晰地向用戶描述系統的業務流設計目標，用戶對我們提交的報告、文檔都簽字確認了。

經過以上三個步驟，我們基本可以解決上面的三個問題，也能夠把需求規格說明書生成出來，并且能促進用戶和開發人員對需求的理解和確認，從而確保系統的正確性。系統開發出來后也受到用戶的認可。由于有高質量的需求規格說明書，后續的設計與維護工作，我們感覺輕松多了。

使用面向對象的分析方法，可以將系統劃分成一個個細小的功能，把問題細化便于解決，但也有不好的地方，就是很難把握到系統根抽象的度，也就是功能的邊界不好把握，把握不好，系統的劃分就好很凌亂，導致后面的設計及實現工作難以開展。因此我們還可以使用其他的方法來輔助我們進行需求分析，比如結構化分析方法。在做系統業務流程時，我們就用到了結構化分析方法來分析，得出了系統的數據流圖，使我們的系統業務流程及數據關系更加清楚和細化，系統的結構也更加清晰和明顯。

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