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

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

關鍵詞： 軟件工程; 需求分析; 架構設計; 敏捷開發

中圖分類號：TP311????????? 文獻標識碼：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 引言

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

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

1 方法概述

對于軟件開發團隊而言，軟件開發的全過程是：做什么->怎么做->做->成果檢驗->交付部署;其中，“做什么”對應的是需求分析過程，“怎么做”對應于軟件架構設計過程，“做”對應于開發過程，“成果檢驗”對應于測試，部署由運維團隊執行后，如果達到用戶的要求，則軟件上線后進入軟件的運行生命周期[1]。

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

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

2 原始需求分析

原始需求是從用戶及業務的角度可見或必須的需求，或項目團隊經過初步挖掘后整理出來的、未經進一步提煉的需求。

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

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

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

⑴ 前臺子系統

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

⑵ 后臺子系統

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

原始需求分析的目標是需求的收集、整理和簡單分析，為業務架構分析奠定基礎。

3 面向應用的業務架構分析

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

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

4 面向開發的業務架構分析

業務架構為軟件系統的開發奠定了基礎，在實際的軟件開發項目中，通?？梢栽诖嘶A上讓需求分析再往前邁一步，將“做什么”和“怎么做”緊密聯系起來，承上啟下，這個階段的需求分析可以稱之為“面向開發的業務架構分析”，下文簡稱開發架構。

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

開發架構作為需求分析的最后一步，能有效減少因為沒有“向后看”帶來的需求分析不充分問題，能夠把需求和實現更緊密的結合在一起，它在一定程度上對業務架構做了進一步的細化，也在一定程度上影響了業務架構的最終成果。

開發架構不必刻意設計的與業務架構不同，但其關注點已經是為“怎么做”和“做”這兩階段鋪路了，“怎么做”是架構師負責的，本階段的需求分析也由架構師來牽頭和落實更合適。

開發架構分析的主要內容有兩點：①再次提煉和抽象業務功能;②確認和完善非功能需求。

⑴ 再次提煉和抽象業務功能

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

OA系統中，可能還存在一些功能模塊，涉及到上傳附件、預覽或下載附件等功能，我們可以把“文件存儲管理”獨立出來作為基礎功能模塊來實現;架構師還會進一步分析，文件有大有小，大文件存儲、管理和消費的業務邏輯和零散小文件類似業務邏輯的實現及性能上可能會有很大差別，導致不同的應用場景對應不同的實現方案，文件存儲管理要可能會設計為多個模塊。

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

⑵ 確認和完善非功能需求

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

5 結束語

工程項目的軟件開發，需求分析由架構師牽頭，按照原始需求分析、面向應用的業務架構分析和面向開發的業務架構分析三步走，是一種可應用于實踐的需求分析方法，能有效解決業務方和開發方難以準確溝通業務、難以深入分析和實現業務的問題。

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

參考文獻（References）：

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

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

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

[4] 孫昌愛，金茂忠，劉超，田麗從.一種基于UML的面向對象需求分析方法[J].航空學報，2003.1：75-78

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

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

收稿日期：2020-09-04

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