工程項目需求分析方法研究

摘? 要： 傳統(tǒng)工程項目的信息化和數(shù)字化日益成為軟件開發(fā)行業(yè)的主要業(yè)務(wù)，而這類軟件工程項目的開發(fā)和實施，由于業(yè)務(wù)方和開發(fā)方缺乏有效的溝通方法，其成果經(jīng)常會有所欠缺。文章提出一套由架構(gòu)師牽頭，以架構(gòu)設(shè)計思想和敏捷開發(fā)方法為基礎(chǔ)，實戰(zhàn)可行的需求分析方法，有效解決工程項目中業(yè)務(wù)難以溝通、難以深入的問題。

關(guān)鍵詞： 軟件工程; 需求分析; 架構(gòu)設(shè)計; 敏捷開發(fā)

中圖分類號：TP311????????? 文獻(xiàn)標(biāo)識碼：A???? 文章編號：1006-8228（2021）01-51-03

Research on requirements analysis of engineering project

Yu Yang

（Power China Huadong Engineering Corporation Limited， Hangzhou， Zhejiang 310014， China）

Abstract： The informatization and digitization in traditional engineering project have become the main business in software development industry. However， as a result of the in effective communication between business and developing aside， the achievement is always not very satisfying. In this paper， a practical method of requirements analysis is proposed， which is led by the architect and complies with the architecture design idea and agile development method， to effectively solve the problem that the business is difficult to communicate in-depth in engineering projects.

Key words： software engineering; requirements analysis; architecture design; agile development

0 引言

近年來，傳統(tǒng)工程項目的信息化和數(shù)字化日益成為軟件開發(fā)行業(yè)的一個主流方向，而這類軟件工程項目的開發(fā)和實施，經(jīng)常會差強人意。造成這一現(xiàn)象的原因，通常歸結(jié)為兩個方面：一方面是由于工程背景的甲方用戶，普遍缺乏軟件系統(tǒng)開發(fā)的通識，較難把自己的需求準(zhǔn)確傳達(dá)給乙方開發(fā)者;另一方面，乙方開發(fā)者普遍缺乏準(zhǔn)確理解甲方需求的專業(yè)知識，導(dǎo)致在接收甲方需求的過程中產(chǎn)生偏差。在近年來的開發(fā)實踐中，雖然甲乙雙方越來越多的認(rèn)識到這兩方面原因，并投入了較多的力量來緩解這個問題，然而成效依然良莠不齊。究其原因，問題依然出現(xiàn)在需求分析環(huán)節(jié)，僅讓甲乙雙方互相加強對方的專業(yè)知識，并未帶來顯著和穩(wěn)定的成效，需求分析方法依然存在較大的研究空間。

本文在這一背景下，結(jié)合作者自身軟件開發(fā)經(jīng)驗和項目執(zhí)行經(jīng)驗，提出了一種深入的需求分析方法，并在實際項目中取得了顯著成效。

1 方法概述

對于軟件開發(fā)團(tuán)隊而言，軟件開發(fā)的全過程是：做什么->怎么做->做->成果檢驗->交付部署;其中，“做什么”對應(yīng)的是需求分析過程，“怎么做”對應(yīng)于軟件架構(gòu)設(shè)計過程，“做”對應(yīng)于開發(fā)過程，“成果檢驗”對應(yīng)于測試，部署由運維團(tuán)隊執(zhí)行后，如果達(dá)到用戶的要求，則軟件上線后進(jìn)入軟件的運行生命周期[1]。

在實際的軟件項目開發(fā)中，“做什么”，“怎么做”和“做”這三個環(huán)節(jié)是緊密結(jié)合在一起的。“做”、“成果檢驗”和“交付部署”通常也會是一個持續(xù)交付過程。“成果檢驗”的內(nèi)容一定會受到“做什么”的影響，在“做什么”階段，也要考慮到如何部署和交付[2]。所以，軟件開發(fā)的全過程，都是緊密結(jié)合在一起的[3]，也都離不開需求，如果刻意劃分為獨立的幾個階段，忽視其作為一個整理的綜合影響，每個環(huán)節(jié)的實施過程必然會遇到因上一階段考慮不周全帶來的問題，造成工作的反復(fù)，影響整體開發(fā)效率。

基于此，需求分析的實施，圍繞架構(gòu)師這一角色開展[4]，基于架構(gòu)師的視角和能力，將上述軟件開發(fā)的全過程打造為有機的一體。相應(yīng)的，以需求深度劃分[5]，可以把需求分析分為三個層次：原始需求分析、面向應(yīng)用的業(yè)務(wù)架構(gòu)分析和面向開發(fā)的架構(gòu)分析，經(jīng)過這三個層次的需求分析后，其成果可以貫穿通用于軟件開發(fā)的全過程，提供綜合研發(fā)效能。

2 原始需求分析

原始需求是從用戶及業(yè)務(wù)的角度可見或必須的需求，或項目團(tuán)隊經(jīng)過初步挖掘后整理出來的、未經(jīng)進(jìn)一步提煉的需求。

如果拿做項目與做產(chǎn)品類比，原始需求類似于產(chǎn)品設(shè)計中的“用戶故事”，由于原始需求既可以是開發(fā)者分析出來的，也可以是行業(yè)專家或目標(biāo)客戶/用戶提出來的，原始需求可以不止步于“用戶故事”，在該階段做一定的業(yè)務(wù)邏輯的抽取和提煉，對接下來“業(yè)務(wù)架構(gòu)”階段的需求分析也有幫助，這兩個階段沒必要確立一個嚴(yán)格的界限。

以多人博客系統(tǒng)為例，原始需求可以梳理如下：①要有所有文章列表;②能點擊查閱文章;③能評論文章;④能創(chuàng)建新文章;⑤能編輯刪除文章;⑥要有權(quán)限機制。

而對于更有經(jīng)驗的人而言，原始需求可能更加體系化：多人博客系統(tǒng)由前臺展示子系統(tǒng)和后臺管理子系統(tǒng)構(gòu)成，兩個子系統(tǒng)的功能分別分析。

⑴ 前臺子系統(tǒng)

前臺子系統(tǒng)對任何人可見，該子系統(tǒng)至少包含以下頁面或功能：①文章列表+概要頁面;②文章詳情頁面;③作者主頁;④文章評論功能;⑤文章搜索功能;⑥側(cè)邊欄的目錄、tag等博客經(jīng)典功能。

⑵ 后臺子系統(tǒng)

后臺子系統(tǒng)只對登錄用戶開放，對多人博客而言，該子系統(tǒng)應(yīng)該分用戶組，為不同類型用戶分配不同的權(quán)限，該子系統(tǒng)至少包含以下頁面或功能：①用戶登錄或注冊功能;②根據(jù)不同用戶的權(quán)限，登錄后看到不同的頁面或功能;③創(chuàng)建新文章;④修改或刪除文章;⑤維護(hù)博客名稱描述等內(nèi)容的功能。

原始需求分析的目標(biāo)是需求的收集、整理和簡單分析，為業(yè)務(wù)架構(gòu)分析奠定基礎(chǔ)。

3 面向應(yīng)用的業(yè)務(wù)架構(gòu)分析

面向應(yīng)用的業(yè)務(wù)架構(gòu)（下文簡稱業(yè)務(wù)架構(gòu)）分析，是對原始需求的抽象和再提煉，在形成業(yè)務(wù)架構(gòu)之前，首先要梳理清楚非功能需求和功能需求。非功能需求可以為接下來的面向開發(fā)的業(yè)務(wù)架構(gòu)分析和軟件架構(gòu)設(shè)計鋪路。功能需求又分為“顯式的功能需求”和“潛在的功能需求”。如上一節(jié)列出的需求，均為顯式功能需求;潛在的功能需求要從多個角度去考慮，如整理出用戶組、權(quán)限對應(yīng)的完整業(yè)務(wù)邏輯，屬于可以推測并進(jìn)一步開展工作的潛在功能需求，修改密碼、個人信息、用戶管理和忘記密碼等功能，是上面漏掉的、但又會影響到系統(tǒng)完整性的潛在需求，而提供一個系統(tǒng)初始化接口的功能需求，是站在運維實施角度提出來的潛在需求。

做好業(yè)務(wù)架構(gòu)，是為整個軟件項目邁出堅實的第一步。業(yè)務(wù)架構(gòu)是需求分析中最重要的階段，經(jīng)歷了業(yè)務(wù)架構(gòu)分析的過程，系統(tǒng)需求才能完成初步梳理。業(yè)務(wù)架構(gòu)對軟件系統(tǒng)開發(fā)也有重要影響。開發(fā)軟件系統(tǒng)，通常要求具備充分的可擴展性[6]，而可擴展性，在需求分析階段就奠定了基礎(chǔ)，需求分析做的充分，系統(tǒng)可擴展性在很大程度上就確定了，當(dāng)增加新功能時，系統(tǒng)能否擴展功能，還是系統(tǒng)的某些功能要打破重來，業(yè)務(wù)架構(gòu)階段就能看出端倪。比如，若要在多人博客系統(tǒng)中增加用戶社交功能，可以把該功能插入到用戶模塊和個人模塊中去，也可以新增社交模塊，前者會打破原有業(yè)務(wù)邏輯，從而改變已有功能的代碼實現(xiàn)，而后者更多是在新的模塊中梳理業(yè)務(wù)邏輯，開發(fā)新功能，前者重構(gòu)多于擴展，而后者擴展多于重構(gòu)。所以如果業(yè)務(wù)架構(gòu)設(shè)計的具有擴展性，相當(dāng)于軟件系統(tǒng)先天具備較強的可擴展能力。

4 面向開發(fā)的業(yè)務(wù)架構(gòu)分析

業(yè)務(wù)架構(gòu)為軟件系統(tǒng)的開發(fā)奠定了基礎(chǔ)，在實際的軟件開發(fā)項目中，通常可以在此基礎(chǔ)上讓需求分析再往前邁一步，將“做什么”和“怎么做”緊密聯(lián)系起來，承上啟下，這個階段的需求分析可以稱之為“面向開發(fā)的業(yè)務(wù)架構(gòu)分析”，下文簡稱開發(fā)架構(gòu)。

開發(fā)架構(gòu)也可以納入“怎么做”的環(huán)節(jié)，但筆者認(rèn)為把它作為需求分析的最后階段，對整個項目過程而言更有效率。這部分工作依然是圍繞需求分析展開的，前文所述的需求分析工作通常開發(fā)者也會參與，面向應(yīng)用和開發(fā)這兩階段的需求分析本身就是銜接在一起的連續(xù)過程，如果把這一步工作從需求分析中拋離，項目進(jìn)行到“怎么做”或“做”的階段時，發(fā)現(xiàn)現(xiàn)實（代碼邏輯和系統(tǒng)實施）和理想（業(yè)務(wù)邏輯）不一致的概率會更大，開發(fā)過程中可能會有更多關(guān)于“需求分析沒做到位”的扯皮，甚至不得不重新返回需求分析階段再次梳理需求，這都會帶來本可避免的項目進(jìn)度延誤。

開發(fā)架構(gòu)作為需求分析的最后一步，能有效減少因為沒有“向后看”帶來的需求分析不充分問題，能夠把需求和實現(xiàn)更緊密的結(jié)合在一起，它在一定程度上對業(yè)務(wù)架構(gòu)做了進(jìn)一步的細(xì)化，也在一定程度上影響了業(yè)務(wù)架構(gòu)的最終成果。

開發(fā)架構(gòu)不必刻意設(shè)計的與業(yè)務(wù)架構(gòu)不同，但其關(guān)注點已經(jīng)是為“怎么做”和“做”這兩階段鋪路了，“怎么做”是架構(gòu)師負(fù)責(zé)的，本階段的需求分析也由架構(gòu)師來牽頭和落實更合適。

開發(fā)架構(gòu)分析的主要內(nèi)容有兩點：①再次提煉和抽象業(yè)務(wù)功能;②確認(rèn)和完善非功能需求。

⑴ 再次提煉和抽象業(yè)務(wù)功能

簡單的系統(tǒng)，業(yè)務(wù)架構(gòu)和開發(fā)架構(gòu)可能基本上是一致的，而復(fù)雜系統(tǒng)，業(yè)務(wù)架構(gòu)分析所提煉的業(yè)務(wù)功能，是有可能被再次提煉的，如OA系統(tǒng)中，我們從業(yè)務(wù)架構(gòu)的視角看，可以整理出如“計劃管理”、“任務(wù)管理”和“表單管理”等模塊，這些模塊的業(yè)務(wù)流程都會包含“審批流程”、“短信通知”、“郵件通知”等基礎(chǔ)功能，這些功能在每個業(yè)務(wù)模塊中，功效類似，但在業(yè)務(wù)架構(gòu)的視角和顆粒度上，不一定能清晰的表達(dá)出來，但梳理功能架構(gòu)的時候，可以將此作為從相關(guān)業(yè)務(wù)模塊的核心業(yè)務(wù)邏輯中剝離的非核心業(yè)務(wù)邏輯，作為基礎(chǔ)功能模塊放到功能架構(gòu)的恰當(dāng)位置。

OA系統(tǒng)中，可能還存在一些功能模塊，涉及到上傳附件、預(yù)覽或下載附件等功能，我們可以把“文件存儲管理”獨立出來作為基礎(chǔ)功能模塊來實現(xiàn);架構(gòu)師還會進(jìn)一步分析，文件有大有小，大文件存儲、管理和消費的業(yè)務(wù)邏輯和零散小文件類似業(yè)務(wù)邏輯的實現(xiàn)及性能上可能會有很大差別，導(dǎo)致不同的應(yīng)用場景對應(yīng)不同的實現(xiàn)方案，文件存儲管理要可能會設(shè)計為多個模塊。

因此，面向應(yīng)用的業(yè)務(wù)架構(gòu)分析階段，雖然能夠做到把業(yè)務(wù)需求和邏輯完整的整理出來，但不一定能把構(gòu)成每個業(yè)務(wù)邏輯的單位功能一一提煉和組織起來，也可能會因為缺乏功能開發(fā)和系統(tǒng)性能上的背景知識，忽視某些需要單獨處理的功能或模塊的特殊性，為系統(tǒng)的穩(wěn)定性和可擴展性埋下隱患，所以，在面向應(yīng)用的業(yè)務(wù)架構(gòu)分析之后，在開發(fā)之前，一定要做“面向開發(fā)的業(yè)務(wù)架構(gòu)分析”。

⑵ 確認(rèn)和完善非功能需求

非功能需求，通常要考慮系統(tǒng)的存儲能力、吞吐能力和容錯能力等，最常見的就是我們常說的“日活”或“并發(fā)”，這些性能指標(biāo)會影響到我們的軟件架構(gòu)。確立非功能需求，一方面是為了保證我們的軟件架構(gòu)能夠支撐起我們的業(yè)務(wù)量，另一方面也是為了防止我們對軟件架構(gòu)做過度設(shè)計，為系統(tǒng)開發(fā)帶來不必要的復(fù)雜度。另外，這也為系統(tǒng)的性能測試提供了依據(jù)。

5 結(jié)束語

工程項目的軟件開發(fā)，需求分析由架構(gòu)師牽頭，按照原始需求分析、面向應(yīng)用的業(yè)務(wù)架構(gòu)分析和面向開發(fā)的業(yè)務(wù)架構(gòu)分析三步走，是一種可應(yīng)用于實踐的需求分析方法，能有效解決業(yè)務(wù)方和開發(fā)方難以準(zhǔn)確溝通業(yè)務(wù)、難以深入分析和實現(xiàn)業(yè)務(wù)的問題。

該方法已應(yīng)用于筆者的軟件工程實踐中，相比于筆者以往的工程項目開發(fā)經(jīng)歷，應(yīng)用該方法后，需求分析成果能切實深入到位，既能滿足業(yè)主的預(yù)期，也讓研發(fā)更容易理解到位，很大程度上避免了甲乙雙方在需求認(rèn)知上的偏差，有效提高了軟件交付物的實際成效。

參考文獻(xiàn)（References）：

[1] 張祎.軟件生命周期中的需求分析方法論建構(gòu)[J].電子科學(xué)技術(shù)，2017.4（3）：37-40

[2] 吳爭榮，包新曄，尹立彬，梁耀文.基于敏捷開發(fā)理念的軟件系統(tǒng)持續(xù)交付研究[J].電子世界，2020.7：80-81

[3] 謝鵬飛.敏捷開發(fā)在項目開發(fā)和管理中的實踐和應(yīng)用[J].電子世界，2020.7：80-81

[4] 孫昌愛，金茂忠，劉超，田麗從.一種基于UML的面向?qū)ο笮枨蠓治龇椒╗J].航空學(xué)報，2003.1：75-78

[5] 周紹景，唐艷，邱發(fā)林.淺談軟件需求分析方法[J].科技信息，2007.2：37-37，119

[6] 趙承乾.軟件需求分析方法創(chuàng)新分析[J].計算機光盤軟件與應(yīng)用，2013.3：61-61

收稿日期：2020-09-04

作者簡介：于洋（1987-），男，山東泰安人，碩士研究生，工程師，主要研究方向：計算機軟件開發(fā)，系統(tǒng)架構(gòu)。