鄒楠，厲志成

摘要：需求是軟件產(chǎn)品開發(fā)的重要輸入，好的需求分析可以有效規(guī)避后期開發(fā)風(fēng)險。軟件領(lǐng)域提出了許多需求分析方法，然而隨著軟件的規(guī)模和復(fù)雜程度與日俱增，傳統(tǒng)需求分析方法的局限性日益凸顯。基于統(tǒng)一建模語言的軟件需求分析方法通過對現(xiàn)實問題做抽象映射，將需求以模型語言的方式進行可視化表達，可以有效解決傳統(tǒng)需求分析方法中存在的不足，使開發(fā)人員可以很好地理解用戶需求，從而提升產(chǎn)品開發(fā)效率和質(zhì)量。

關(guān)鍵詞：統(tǒng)一建模語言；軟件需求；需求分析

中圖分類號：TP311? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）35-0022-03

1 概述

隨著軟件工程技術(shù)的不斷發(fā)展，軟件開發(fā)關(guān)注的重點已經(jīng)逐漸從后端的編碼向前端的需求分析轉(zhuǎn)移，需求分析的好壞對軟件成功與否至關(guān)重要[1]。據(jù)權(quán)威部門統(tǒng)計，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是在需求分析階段存在問題[2]。

為了能夠有效地進行分析和設(shè)計活動，需要相應(yīng)的技術(shù)和工具支持。軟件行業(yè)經(jīng)過多年的發(fā)展，目前有許多需求分析的方法，對于普通軟件而言，用戶需求相對簡單，傳統(tǒng)的分析方法可以應(yīng)對，然而對于大型復(fù)雜系統(tǒng)如ERP等，其規(guī)模和設(shè)計都比較復(fù)雜，傳統(tǒng)的需求分析方法已經(jīng)不能滿足要求，存在開發(fā)人員不能識別業(yè)務(wù)需求書、需求反復(fù)確認等問題，影響開發(fā)效率[3]。

因此，需要研究應(yīng)用一種新的需求分析方法，促進業(yè)務(wù)人員與軟件開發(fā)人員之間一致且高效地交流，幫助開發(fā)人員深入理解用戶需求，從而實現(xiàn)系統(tǒng)設(shè)計的可讀性、可理解性和通用性。

2 傳統(tǒng)結(jié)構(gòu)化需求分析

傳統(tǒng)需求分析主要以結(jié)構(gòu)化分析方法為主，是面向過程的以功能為驅(qū)動的分析方法。其主要是根據(jù)用戶需求，確定大致業(yè)務(wù)框架以及系統(tǒng)的功能范圍，采用非開發(fā)人員也易于理解的圖形符號結(jié)合文字等形式來描述每個功能的處理邏輯和業(yè)務(wù)規(guī)則，并適當輔助一些功能分解圖和數(shù)據(jù)流圖等[4]。

這種分析方法適用于一些簡單場景，可以快速靈活地定義需求，但在復(fù)雜的業(yè)務(wù)場景下，其以功能為驅(qū)動的邏輯導(dǎo)致該方法對需求變化的適應(yīng)能力比較弱，尤其是在易變化的場景下，其面臨的問題較多，程序的可重用性和可維護性較低[5]。此外，開發(fā)人員可能無法準確識別業(yè)務(wù)需求語言，在設(shè)計階段需要重新去做分析，導(dǎo)致開發(fā)效率低下。

3 統(tǒng)一建模語言

與傳統(tǒng)結(jié)構(gòu)化方法不同，面向?qū)ο蟮男枨蠓治龇椒ㄗ⒅赜诂F(xiàn)實問題的底層邏輯，將實際問題抽象化以此來解決問題，其從類與對象的關(guān)系上出發(fā)，具備更強的通用性，可以有效支持變動的業(yè)務(wù)需求。同時，面向?qū)ο蟮男枨蠓治鋈鞒淌且詫ο笞鳛榉治雠c設(shè)計的目標，在最終編碼中也都是對象，可以有效保證從需求到分析、從分析到設(shè)計、從設(shè)計到編碼的一致性。

統(tǒng)一建模語言（Unified Modeling Language，UML）作為面向?qū)ο笮枨蠓治龇椒ǖ慕９ぞ撸哂幸?guī)則統(tǒng)一、易于表達、功能強大的優(yōu)勢，適用于各類軟件系統(tǒng)的需求建模，從一般的信息管理系統(tǒng)到大型復(fù)雜工程系統(tǒng)都可以用UML來描述、構(gòu)建需求分析模型[6]。

UML是一種可視化的建模語言而非程序設(shè)計語言，目的在于對系統(tǒng)進行抽象化并構(gòu)建可視化分析模型，包括對象模型、動態(tài)模型以及功能模型，如表1所示。功能模型是從用戶的視角來描述系統(tǒng)的功能，最常用的是用例圖；對象模型用來分析識別系統(tǒng)的對象與類，以及它們之間的靜態(tài)關(guān)系，主要用到類圖和對象圖；動態(tài)模型用來展現(xiàn)系統(tǒng)的內(nèi)部行為、時序關(guān)系及狀態(tài)變化，包括活動圖、時序圖和狀態(tài)圖[7]。

4 統(tǒng)一建模語言在軟件需求分析中的應(yīng)用

軟件需求通常分為功能性需求和非功能性需求（如可靠性、可支持性等）。在這些需求中，功能性需求是需求定義的重點。本文以某企業(yè)倉庫管理系統(tǒng)為例，利用統(tǒng)一建模語言進行功能性需求分析，分為用例建模和用例分析兩大階段。

4.1 用例建模

用例建模需要用到用例圖，用例圖為組織需求模型提供了有效手段，它通過將功能抽象為用例，進而為系統(tǒng)構(gòu)建合適的用例模型。通過用例模型完成對需求的開發(fā)和管理，同時為后續(xù)用例分析提供輸入。本節(jié)詳細介紹構(gòu)建用例模型的四個步驟：獲取原始需求、識別參與者、識別用例、繪制用例圖。

4.1.1 需求獲取

企業(yè)倉庫管理系統(tǒng)主要是解決如何合規(guī)化、精益化的管理企業(yè)庫存的問題。系統(tǒng)功能涵蓋出庫、入庫及庫存管理等，用戶涉及生產(chǎn)、銷售、倉儲、采購、財務(wù)等多個部門。通過對系統(tǒng)進行調(diào)研，將業(yè)務(wù)需求、痛點問題整理到調(diào)研表中，為接下來的UML建模分析做準備，如表2所示。

4.1.2 識別參與者

參與者是指在系統(tǒng)之外，通過系統(tǒng)邊界與系統(tǒng)進行交互的任何事物。識別模型中的參與者可以更好地去識別用例。對于倉庫管理系統(tǒng)而言，識別參與者過程如表3所示，參與者包括生產(chǎn)人員、銷售人員、倉庫管理員、采購人員、財務(wù)人員、系統(tǒng)管理員，如圖1所示。

4.1.3 識別用例

用例是參與者可以感受到的系統(tǒng)服務(wù)或功能單元，它從用戶的角度定義了系統(tǒng)要實現(xiàn)的一個目標[8]。用例不是功能分解，一個用例可能需要多個功能來實現(xiàn)，一個功能也可能被用于多個用例，所以將系統(tǒng)需求表示成用例的過程并不等同于傳統(tǒng)方法中對系統(tǒng)進行功能分解的過程。

將獲取到的需求進行總結(jié)提煉、分類，通過參與者與系統(tǒng)交互需求說明，明確業(yè)務(wù)活動，進而識別業(yè)務(wù)用例，如表4所示。

4.1.4 繪制用例圖

識別系統(tǒng)的參與者和用例后，就可以采用用例圖表示，如圖2所示。通過用例圖可以清晰地構(gòu)建需求模型。

4.2 用例分析

在用例建模階段，得到初步的需求模型。接下來的用例分析階段則需要采用另一種建模方案對用例進行精確化的描述，將以用戶視角描述的需求模型轉(zhuǎn)換為以開發(fā)團隊視角描述的分析模型，從而保證設(shè)計開發(fā)的準確性[9]。

4.2.1 識別分析類

在對象系統(tǒng)中，系統(tǒng)的所有功能都是通過相應(yīng)的類來實現(xiàn)。因此，首先需要從用例模型中抽象出這些可用的類，再將系統(tǒng)行為分配到這些類中。

為了識別分析類，UML擴展出三種不同的分析類：1）邊界類，比如UI界面；2）控制類，即控制業(yè)務(wù)流程的類，如銷售出庫業(yè)務(wù)類；3）實體類。即問題空間中的業(yè)務(wù)對象的集合，比如出庫信息類。由于邊界類和控制類比較容易確定，因此，對實體類的識別才是整個分析階段的重點。以出庫管理業(yè)務(wù)為例，抽象出的實體類包括系統(tǒng)用戶類、出庫信息類、貨品信息類、銷售信息類和生產(chǎn)信息類，通過確定類之間的關(guān)系創(chuàng)建實體類圖，如圖3所示。

4.2.2 分析交互

目前，所識別的類都是靜態(tài)的描述，而為了確認所識別的類是否達成用例實現(xiàn)的目標，必須分析由這些類所產(chǎn)生的對象的動態(tài)行為。利用UML時序圖來描述對象間的交互行為，可以表示用例實現(xiàn)是如何達成用例目標[9]。以銷售出庫業(yè)務(wù)為例，其時序圖模型如圖4所示，開發(fā)人員通過時序圖可以清晰地理解業(yè)務(wù)間各個對象交互及消息傳遞的過程。

至此，已經(jīng)建立了一套需求分析模型，系統(tǒng)用例及用例實現(xiàn)的相關(guān)交互分析以可視化的表達形式記錄在模型里。接下來，需求分析人員需要基于系統(tǒng)用戶目標、范圍和需求模型，完成用例的細化描述，并在此基礎(chǔ)上，結(jié)合非功能性需求、約束條件以及外部關(guān)聯(lián)接口等完成需求文檔的編寫。最后還需要評審審查，從而確保在開始架構(gòu)設(shè)計時需求是完整的、一致的，規(guī)避后期開發(fā)風(fēng)險。

5 結(jié)論

需求分析是整個軟件項目開發(fā)的關(guān)鍵環(huán)節(jié)，不同的分析方法各有側(cè)重，業(yè)務(wù)人員需要根據(jù)所開發(fā)的項目特點找到適合的分析方法。本文以某企業(yè)倉庫管理系統(tǒng)為例，詳細闡述了基于統(tǒng)一建模語言的軟件需求分析方法的應(yīng)用過程。通過該分析方法，能夠有效地保證需求開發(fā)的質(zhì)量，產(chǎn)出符合規(guī)范性和完整性要求的需求，大大提高溝通效率，并減少需求變更帶來的麻煩。

軟件開發(fā)實踐表明，在提高軟件工程質(zhì)量、降低軟件開發(fā)風(fēng)險、處理復(fù)雜功能需求、減少代碼開發(fā)工作量等諸多關(guān)鍵問題上，基于統(tǒng)一建模語言的需求分析方法是行之有效的。

參考文獻：

[1] Maciaszek L A.需求分析與系統(tǒng)設(shè)計[M]. 馬素霞，王素琴，謝萍，等譯.北京：機械工業(yè)出版社，2009.

[2] 吳政.軟件開發(fā)過程中的需求分析探討[J].電腦知識與技術(shù)，2008，4（32）：1125-1128.

[3] Wiegers K，Beatty J.軟件需求[M].3版. 李忠利，譯.北京：清華大學(xué)出版社，2016.

[4] 黃藍會.基于UML進行軟件需求分析的研究[J].微型電腦應(yīng)用，2016，32（7）：9-11.

[5] 李鴻君.大話軟件工程需求分析與軟件設(shè)計[M].北京：清華大學(xué)出版社，2020.

[6] 田林琳，李鶴.UML軟件建模項目教學(xué)版[M].北京：北京理工大學(xué)出版社，2018.

[7] 袁濤，孔蕾蕾.統(tǒng)一建模語言UML[M].2版.北京：清華大學(xué)出版社，2014.

[8] 趙會盼.一種基于UML的面向?qū)ο蟮能浖枨蠓治龇椒╗J].電子技術(shù)與軟件工程，2021（9）：63-65.

[9] 譚火彬.UML 2面向?qū)ο蠓治雠c設(shè)計[M].2版.北京：清華大學(xué)出版社，2019.

【通聯(lián)編輯：唐一東】