ChatModeler：基于大語言模型的人機協作迭代式需求獲取和建模方法

靳東明 金 芝 陳小紅 王春暉

1 （北京大學計算機學院 北京 100871）

2 （高可信軟件技術教育部重點實驗室（北京大學） 北京 100871）

3 （上海高可信計算重點實驗室（華東師范大學） 上海 200050）

4 （內蒙古師范大學計算機科學與技術學院 內蒙古 010011）

（jindm@stu.pku.edu.cn）

需求獲取和建模是指需求分析師從需求提供者獲取需求，并據此構建需求模型的過程. 傳統的需求獲取方法需要需求分析師和需求提供者不斷地溝通，直到需求提供者確認所有的需求，這是一個迭代的過程[1]. 隨著軟件系統的規模和復雜度的不斷增大，涉及的干系人（即角色）和需求的數量越來越多，許多項目的需求文檔通常有數百頁. 在這樣的背景下，傳統的需求獲取方法由于需要干系人之間不斷地溝通和持續地迭代，給需求提供者和需求分析師造成巨大的負擔. 因此如何提高需求獲取和建模的效率成為亟待解決的問題.

很多研究者提出了自動化需求獲取與建模的方法[2-4]，主要包括2 種：一種是基于知識庫的方法，即將需求工程中的領域知識和經驗封裝在知識庫中，利用知識庫中的相關知識引導進行需求獲取[5-7]. 另一種是基于機器學習的方法，即設計神經網絡從自然語言需求描述中提取相應的建模元素，并人工或者設計規則組裝成需求模型[8-10]. 然而，這2 種方法僅能自動化需求獲取和建模過程中的部分步驟，并不能替代需求干系人，尤其是需求提供者的大部分工作. 如何進一步減輕需求提供者和需求分析師的工作負擔，提高獲取與建模效率，仍是一個待解決的問題.

最近，由于以ChatGPT 為代表的大語言模型（large language models，LLMs ）在軟件工程的一系列任務上取得了優異的性能[11]. 大語言模型匯聚了豐富的人類知識，不僅具有強大的自然語言生成和對話能力，而且可以通過指令學習[12]轉變成領域“專家”，具有扮演需求提供者、需求分析員等多類干系人的潛力. 因此，有可能使用大語言模型（部分）替代需求提供者和需求分析師的工作，加速迭代式需求獲取和建模的過程. 其中要解決的主要問題是如何通過人機交互引導大語言模型生成對需求獲取和建模有幫助的信息[13].

受現實世界需求分析流程[14]和團隊合作方法[15-16]的啟發，我們提出了利用大語言模型進行需求獲取和建模的人機協作迭代框架ChatModeler.具體而言，首先明確需求獲取和建模過程中參與交互的干系人，如收集者、建模師和檢測員；然后利用大語言模型指令學習的能力設計不同角色的提示詞以扮演需求團隊中的不同角色，組建虛擬的需求團隊. 這種方法只要求需求提供者進行確認或者少量輸入，可以極大地減輕需求提供者和需求分析師的負擔，達成通過多次人機交互進行高效需求獲取和建模的目的.

為了驗證ChatModeler 的效果，我們使用2 種大語言模型在7 個公開用于需求建模的案例上與3 種需求模型，如用例圖、序列圖和問題圖[17]的先進自動建模方法，如IT4RE 方法、GSQ 方法和GPD 方法進行了對比實驗. 評估結果顯示ChatModeler 能夠有效降低需求提供者的交互負擔，能夠生成質量更高的需求模型. 最后，我們用一個真實的案例，即太陽搜索控制系統進行了案例研究，證明了其可行性.

本文的主要貢獻包括3 個方面：

1）提出了一個用于需求獲取和建模的人機協作迭代框架，該框架使用多個大語言模型進行角色扮演，能替代需求提供者和需求分析師的大部分工作，提高了需求獲取和建模的效率.

2）設計了一種基于大語言模型和需求元模型的協作機制，通過提示詞定義了團隊角色及其之間的協作過程，支持需求的獲取和多種需求模型的構建.

3）進行了方法評估和案例研究，方法評估證明了ChatModeler 能降低需求提供者的負擔，并能生成效果更好的需求模型，案例研究證明了其可行性.

本文其余部分的組織如下. 第一節對相關工作進行了比較. 第二節介紹了大語言模型和需求模型等預備知識. 第三節說明了我們提出的框架和設計細節. 第四節報告了我們的研究問題和實驗結果. 第五節展示了我們的案例研究結果. 第六節討論了我們工作的意義和具有的局限性. 第七節對本文進行了總結，并說明了未來的工作內容.

1 相關工作

相關工作主要體現在迭代式需求獲取和需求建模中部分步驟的自動化，主要包括基于機器學習的自動化以及基于知識庫和大語言模型的自動化.

1.1 基于機器學習的自動化建模

根據設計方法的不同，該研究工作又可以分為兩大類別：基于自然語言處理的統計方法和基于神經網絡的深度學習方法.

1）基于自然語言處理的統計方法主要是借助已有的自然語言處理工具對軟件需求文檔進行語義或者語法方面的計算，進而設計規則對建模元素進行提取. 例如，Elbendak 等人[8]基于文本的預處理技術設計了需求提取工具Class-Gen，該工具能夠從自然語言需求文檔中提取類和對象，進而生成用例圖模型. Jahan 等人[3]基于詞性和依存關系提出了一種從英語用例描述中自動生成序列圖的方法. 文獻[3, 11]所提方法的設計過程繁瑣且領域遷移能力弱.

2）基于神經網絡的深度學習方法主要是使用深度學習技術設計網絡模型，以從需求文本中提取相應的建模元素. 例如，Pudlitz 等人[9]使用基于雙向長短時記憶網絡和卷積神經網絡的命名實體識別模型從軟件需求文本中提取目標對象的狀態信息. Qian等人[10]設計了一種層次神經網絡方法，從需求描述中提取過程模型中的動作、控制流等建模元素. 文獻[9?10]所提方法可以提高領域遷移能力.

盡管文獻[3, 11, 12?13]所提方法都達成了較好的效果，能夠輔助建模者進行需求建模，但是它們都是以需求文檔或者需求描述為輸入，一次性產生各種建模元素，且在過程中無法修改和迭代系統需求.如果自動化提取過程中遺漏了部分建模元素，建模者只能人工檢查需求文檔進行修改，迭代修改的過程也需要花費大量時間人工手動來完成.

1.2 基于知識庫和大語言模型的自動化獲取和建模

基于知識庫的方法是通過用軟件開發者積累的經驗或者領域分析的結果，輔助需求的獲取和建模.例如，Dardenne 等人[5]提出了KAOS 項目的元模型制導下的需求獲取方法. 金芝[6]以企業信息系統為研究背景，提出了一種基于本體的需求獲取方法，有利于保證需求獲取的完整性. 文獻[7, 18?19]以問題框架方法中的元模型——問題框架本體，引導需求提供者進行問題圖的建模以及需求規約的獲取.

隨著大語言模型能力的不斷增強，引發了需求工程領域社區越來越多的興趣. White 等人[2]探究了將大語言模型用于需求獲取、原型設計、自動設計等各項任務的提示詞，但是該模型處理各項任務時相互獨立，沒有考慮到不同任務在不同階段會相互反饋、相互影響. Xing 等人[17]利用大語言模型在軟件工程的各項任務中創建了思維鏈，但是對需求任務考慮較少.

在文獻[5?7, 18?20]方法中，基于知識庫的方法僅僅是檢索知識，并不具備生成知識庫外新需求的能力. 這類方法依賴于檢索知識庫中積累的有限的經驗，不支持迭代式獲取. 此外，雖然研究者已經開始探索大語言模型在需求工程方面的應用，但目前僅限于設計單個任務的提示詞，沒有考慮利用其生成能力進行不同角色間交互式協作迭代.

2 預備知識

在本節中，我們主要介紹大語言模型、提示工程以及需求元模型3 個方面的預備知識.

2.1 大語言模型和提示工程

大語言模型的興起可以追溯到Transformer[21]模型以及BERT[22]模型的發布. 之后，隨著GPT 系列模型的出現（如GPT-3[23]），大語言模型在一系列任務上取得了優異的性能[24-26]. 最近，以ChatGPT 為代表的大語言模型能夠通過指令或者提示詞[27]來完成用戶的各種文本處理任務[28].

大語言模型聚集了豐富的人類知識，具有強大的自然語言生成能力和對話能力，它可以生成與用戶進行自然對話的響應，因此大語言模型可以模擬人類對話過程，與人類進行交互. 大語言模型還具有上下文感知能力，能夠根據當前的回答記錄引導用戶提供更加詳細的需求信息.

使用大語言模型的關鍵是設計提示詞. 提示詞的質量是大語言模型在處理下游任務上性能好壞的重要因素[25]. 因此，需要為大語言模型設計高質量的提示詞以獲得預期的模型輸出.

2.2 需求元模型

需求建模方法有很多種，如結構化分析方法[29]、面向對象方法[30]、問題框架方法[17]、面向目標的方法[5]等. 每種建模方法都有其需求元模型，即建模概念及其之間的關聯關系. 下面以問題框架方法中的問題圖為例來說明需求元模型. 圖1 展示了問題框架方法的需求元模型.

Fig. 1 Requirement meta-model of problem frame圖1 問題框架方法的需求元模型

如圖1 所示，問題框架方法中的概念包括機器領域（MD）、需求領域（RD）、外部實體（OE）、物理設備（PD）和共享現象（SP）. 表1 給出了這些概念的定義及舉例說明. 其中，機器領域為待開發的軟件；外部實體是不能直接與機器領域交互的實體；物理設備則是可以與機器領域直接交互的實體，機器領域通過物理設備與外部實體進行交互；機器領域與物理設備之間存在共享現象，而物理設備與外部實體之間存在共享現象. 需求領域則是需求的希求式表達，它引用或者約束外部實體.

Table 1 Entity Modeling Elements in Problem Frame Method表1 問題框架方法中的實體建模元素

在需求元模型的基礎上，問題框架方法定義了需求模型——問題圖，它是需求元模型的實例. 圖2展示了太陽搜索控制系統的一個問題圖. 該系統主要是通過采集各種硬件設備的數據以確定衛星當前的姿態，進而實現追蹤太陽.

Fig. 2 Part problem diagram of the sun search control system圖2 太陽搜索控制系統的部分問題圖

從圖2 可以看出，問題圖中的節點表示需求元模型中的實體概念，包括機器領域、物理設備、外部實體和需求領域等. 邊表示了實體概念之間的關聯關系. 實體概念間的關系可以分為兩類，一類是需求引用關系，另一類是現象共享關系. 需求引用關系被建模成二元關系，多存在于需求領域與外部實體之間，表示期望在問題領域上出現的效果. 本文用二元組（e1，e2）表達這種關系，其含義是指為了實現e2的需求效果，系統需要涉及e1這個外部實體. 現象共享關系被建模為三元關系，多存在于機器領域與物理設備或者物理設備與外部實體之間，表示2 個領域實體之間接收或者發送某些數據或者指令. 本文使用三元組（e1，e2，data）來表示這種關系，其含義是指e1實體和e2實體之間存在數據data的傳遞.

3 人機協作的需求獲取和建模框架

本節給出基于大語言模型的人機協作迭代式需求獲取和建模框架. 首先給出該框架的角色組成和迭代關系，然后介紹了協作框架中不同角色之間的協作流程.

3.1 ChatModeler 整體框架

現實世界中，需求團隊進行需求獲取和建模的一般流程為：首先需求收集者與需求提供者進行對話以交談待開發系統的需求；然后將對話記錄整理成需求片段；接下來需求建模者閱讀整理后的需求片段，從中提取建模元素進行需求建模；最后需求檢測員閱讀建立的需求模型以檢測需求的完備性. 如果發現缺少某項需求建模元素，則給需求收集者反饋缺失信息. 需求收集者需要根據反饋的信息再次與需求提供者進行訪談，補充更多的需求信息.

受上述現實世界中需求團隊工作流的啟發，本文提出了基于大語言模型的人機協作迭代式需求獲取和建模框架ChatModeler，如圖3 所示. 其中需求提供者依然是現實世界中的需求提供者，但是他/她的重要職責由原來的提供需求轉換為確認需求，而提供需求的職責大部分轉交給了大語言模型扮演的需求收集者. 同時，原來需求工程師（包括需求收集者、建模師、檢測員）的工作則由3 個大語言模型組成的需求分析團隊負責.

Fig. 3 Human-machine collaborative framework for requirement elicitation and modeling圖3 人機協作的需求獲取與建模框架

在該協作框架中，3 個大語言模型分別扮演不同的角色，即收集者、建模師和檢測員. 它們之間相互協作，與需求提供者一起迭代式進行需求獲取和建模. 在該框架中，我們設計了這4 種角色之間的協作流程，如圖4 所示.

Fig. 4 Sequence diagram of collaboration relationships among four roles圖4 4 種角色之間的協作關系序列圖

在該協作流程中，首先是需求提供者和收集者進行n次對話以收集需求提供者對待開發系統的需求；其次收集者將本輪的n次對話內容整理成一個需求片段，并將該需求片段發送給建模師；然后建模師從該需求片段中提取目標需求模型的建模元素，并將提取的建模元素發送給檢測員；隨后檢測員根據當前提取的建模元素檢測需求的完整性，并將本輪檢測的缺失信息發送給收集者；最后收集者根據收到的缺失信息，進入下一輪需求迭代過程，再次與需求提供者進行對話.

迭代多輪后，收集者收到檢測員發送的需求檢測通過的信息時，收集者將整理與需求提供者的對話記錄，按照設定的需求文檔模板自動生成需求文檔. 建模師會輸出在多輪迭代過程中提取的全部目標需求建模元素.

3.2 基于大語言模型的協作團隊定義

這一步的目標是根據提出的需求獲取和建模框架定義協作團隊，為大語言模型設計提示詞以實現大語言模型承擔不同角色的分工和具備協作關系.主要任務包括團隊任務定義與角色定義2 方面.

3.2.1 團隊任務定義

根據3.1 節設計的角色之間的協作流程，我們定義了用于協作式需求獲取和建模任務的團隊提示詞模版. 具體來說，設計的團隊提示詞（Prompt）模版由4 部分組成，分別是團隊說明（Team）、職能說明（Role）、行為說明（Action）和交互信息（Message）. 其中，團隊說明是用來闡述團隊的構成以及提示不同角色之間需要相互協作；職能說明是提示大語言模型需要扮演的角色以及這個角色的職責和分工；行為說明是提示大語言模型具備的交互行為，即要扮演的這個角色會收到來自哪些角色的信息以及收到這個信息后需要執行怎樣的行為；交互消息是提示大語言模型當前來自其他角色的具體交互信息. 這4部分提示詞的設計具體如表2 所示.

Table 2 Prompt Template for Different Roles in the Requirements Elicitation and Modeling Team表2 需求獲取和建模團隊中不同角色的提示詞模板

3.2.2 角色定義

從3.1 節設計的角色之間的協作過程中，我們首先得到大語言模型扮演的3 種角色的職責和行為，再進一步進行提示詞設計，由此定義角色.

1）收集者角色的定義

根據我們設計的協作框架，收集者使用大語言模型的對話能力引導需求提供者，輸入更加詳細的需求描述，負責與需求提供者進行多輪對話，收集需求提供者對系統的期望，并據此生成需求片段.收集者也會收到來自檢測員反饋的待補充的需求信息，并根據反饋信息向需求提供者執行下一次對話以溝通需求，循環往復，逐步完善需求. 因此，根據上述收集者的角色和行為定義，可以將表2 提示詞模版中的參數進行實例化以獲得收集者的提示詞. 收集者實例化的提示詞模版參數具體如表3 所示. 其中MissingReq 表示需求檢測員反饋的缺失需求信息.

Table 3 Parameter Values of Collector Prompt表3 收集者提示詞的參數取值

此外，當需求收集完成后，收集者需要梳理當前所有的會話記錄，并將其整理成一個完整規范的需求文檔. 但是大語言模型輸出的需求文檔的格式具有一定的隨機性，每次輸出的需求文檔遵循的規范不同，不利于人工閱讀. 因此，本文設計了一個需求文檔的統一規范格式，然后以提示詞的形式將需求文檔模版知識輸入給大語言模型. 具體的提示詞如表4 所示.

Table 4 The Prompt for Requirements Documents Generation表4 需求文檔生成的提示詞

該需求模版包括概述、系統組成和功能需求3部分. 概述部分介紹系統的基本情況，包括目標等；系統組成部分介紹系統包含的物理設備；功能需求部分介紹為了達成每個功能需求的動作序列. 表4 的提示詞中包含了每部分推薦的句型.

2） 建模師定義

根據我們設計的協作過程，建模師的職責是理解需求提供者整理的需求片段，并從中提取需求元模型中的需求建模元素. 建模師會將提取出來的建模元素發給檢測員. 考慮到需求建模元素中存在各種專有名詞，大語言模型不能準確理解其含義. 因此，本文在提示詞中添加了需求元模型中對應的各種建模元素的含義說明，輔助大語言模型理解這些專有名詞和需求建模元素的概念.

由于需求建模與具體的需求模型密切相關，提示詞的設計就需要考慮到目標建模的需求模型，即建模師的提示詞是由目標建模的需求元模型制導產生的. 下面以2.2 節列出的問題框架方法[28]中問題圖的需求元模型作為建模師設計提示詞來說明如何基于需求元模型進行建模師提示詞的設計. 構建的建模師的提示詞如表5 所示.

在表5 中，建模師的提示詞包含了圖1 問題圖需求元模型中的各種建模元素以及含義說明. 如果對其他需求模型進行建模，如面向結構的方法、面向對象的方法等，只需要根據目標建模的需求元模型修改該提示詞中建模元素的含義說明即可.

3）檢測員定義

檢測員的職責主要是基于建模師提取出的建模元素和需求元模型檢測缺失的需求信息，反饋缺失信息以指導下一輪需求收集者的需求獲取過程. 需求元模型對需求完整性的檢查具有一定的指導作用.我們以圖1 的需求元模型為例，為扮演檢測員的大語言模型設計了10 條需求完整性的檢查規則.

我們將這10 條規則按照檢測員檢查的順序進行了編號，并按照編號順序寫到提示詞中，提示大語言模型按照編號從上往下檢查需求. 具體的提示詞如表6 所示. 這10 條檢查規則與圖1 密切相關. 前7 條規則是按照需求元模型中需要包含的建模實體元素如機器領域、需求領域、外部實體、物理設備和共享現象的順序排列. 因為問題框架需求元模型的需求獲取邏輯依次是要開發怎樣的系統、開發這個系統的意圖是什么、為了實現這樣的意圖需要監測哪些外部實體、這些外部實體是通過哪些物理設備監測的、物理設備需要采集這些外部實體的什么數據或者指令. 后3 條規則是需求元模型中需要包含的建模關系元素，并按照先需求引用、后現象共享排序.

Table 6 The Prompt for the Checker表6 檢測員的提示詞

4 實驗設計與結果分析

本文利用大語言模型的語義理解和生成能力提出了需求獲取和建模協作框架ChatModeler. 與其他方法相比，該方法能與需求提供者發生較少的交互，并生成質量較高的需求模型. 為了證明這個效果，設計了2 個研究問題：

問題1：ChatModeler 在獲取需求時能否減輕需求提供者的負擔，降低與需求提供者的交互. 問題1旨在證明ChatModeler 在獲取需求方面降低了與需求提供者的溝通負擔. 我們在7 個案例上計算了2 種大語言模型下的ChatModeler 與需求提供者發生交互的次數，并與3 種需求模型的自動化方法進行了對比實驗.

問題2：與其他自動建模方法相比，ChatModeler生成的需求模型的質量怎么樣. 問題2 旨在驗證ChatModeler 生成需求模型上的效果. 我們在7 個案例上計算了2 種大語言模型下的ChatModeler 生成需求模型的準確率（P）、召回率（R）和F1 得分，并與3種需求模型的自動化方法進行了對比實驗.

4.1 實驗配置

1）評估案例. 我們在8 個公開用于需求建模的案例上評估ChatModeler，這些案例分別是：ATM 系統需求案例（ATM）[31]；圖書館管理系統案例（TLS）[32]；自助點餐系統案例（COS）[33]；裝配系統案例（TSS）[34]；時間監控系統（TMS）[35]；售貨員系統（SSS）[3]；智能家居控制系統（HCS）[36]；鎖鏈控制系統（CCS）[37].

2）基線方法. 我們選擇了3 種需求模型的需求自動化建模方法與ChatModeler 進行對比實驗. 下面對這3 種方法進行說明.

①IT4RE 方法[38]從需求描述中提取“參與者”和“動作”2 種建模元素，自動建模用例圖.

②GSQ 方法[3]從需求描述中提取“發起者”“接收者”和“消息”3 種建模元素，自動建模序列圖.

③GPD 方法[18]是從需求描述中提取“問題領域”“需求領域”等多種建模元素，自動建模問題圖.

3）大語言模型的選取. 本文實驗使用了2 個大語言模型，一個是閉源模型GPT-3.5，另一個是開源模型ChatGLM-6B.GPT-3.5 模型是OpenAI 公司開發的，該模型能夠遵循提示指令提供詳細的響應信息. 本文實驗是通過LangChain 框架[39]提供的API 訪問模型. 考慮到模型的回答具有一定的隨機性，為了保證實驗結果的穩定性，我們使用gpt-3.5-turbo 作為我們的基本模型，同時也將gpt-3.5-turbo 模型的解碼溫度設置為0. ChatGLM-6B 模型是清華大學開源的、支持中英雙語的對話模型，能夠生成符合人類偏好的回答[40]. 本文實驗是將開源的模型通過API 的方式進行本地部署，然后利用LangChain 提供的自定義大語言模型的方式將模型進行本地部署和API 封裝.

4）評價指標. 為了驗證ChatModeler 協作框架能夠降低需求提供者的負擔，提高需求獲取和建模的效率，本文選擇在需求獲取過程中與需求提供者發生的交互次數作為衡量指標. 為了衡量ChatModeler生成的需求模型的質量，本文選擇生成需求模型元素的準確率、召回率和F1 得分作為衡量指標. 準確率是指正確生成的需求模型元素數量與生成的全部需求模型元素數量之比. 召回率是指正確生成的需求模型元素數量與應該被生成的需求模型元素數量之比.F1 是平衡準確率和召回率的綜合評價指標.

4.2 問題1 的設計和結果

1）實驗設計

為了評估ChatModeler 能否降低與需求提供者發生交互的次數，本文選擇將其與3 種先進的需求自動建模方法IT4RE、GSQ 和GPD 在7 個案例上進行對比實驗，分別計算與需求提供者的交互次數. 對比的3 種自動化需求建模方法的選取涉及了多種需求建模原型，以驗證ChatModeler 在各種需求模型中均適用.

2）實驗過程

對于傳統方法與需求提供者交互次數的計算，考慮到這些方法對需求的輸入是一次性的且輸入的是整理好的需求文檔，無法直接計算得到此需求時與提供者發生交互的次數. 因此，本文選擇將傳統方法處理的需求描述的句子數目視為交互的次數. 因為我們認為這些案例中的需求描述是簡潔完備的.對于ChatModeler 與需求提供者交互次數的計算，是在人工理解需求描述后，與ChatModeler 進行人機對話，將需求提供者輸入需求的次數視為產生交互的次數.

首先，使用IT4RE 和ChatModeler 分別處理4.2節中的前5 個案例以獲取和建模用例圖，并分別計算和對比這2 種方法的交互次數. 其次，使用GSQ 和ChatModeler 處理SSS 案例以獲取和建模序列圖. 最后，使用GPD 和ChatModeler 處理HCS 案例以獲取和建模問題圖.

3）實驗結果及分析

各種方法在獲取需求時與需求提供者產生交互的次數如表7 所示. 從表7 可以看出，ChatModeler能夠進一步降低與需求提供者交互的次數.ChatModeler 在處理7 個案例上均低于現有3 種先進需求建模方法. 與IT4RE 相比，ChatModeler 在處理前5 個案例時，與需求提供者交互的次數平均降低了34%. 與GSQ 相比，ChatModeler 在SSS 案例上，與需求提供者交互的次數降低了21.4%. 與GPD 相比，ChatModeler 在HCS 案例上，與需求提供者交互的次數降低了20%.

Table 7 Numbers Interacted with Requirement Providers表7 與需求提供者發生交互的次數

ChatModeler 適用于多種需求模型的需求獲取.ChatModeler 與用例圖、序列圖和問題圖的先進需求建模方法相比，與需求提供者交互的次數均有所下降. 對于建模用例圖、序列圖和問題圖，使用GPT-3.5大語言模型的ChatModeler 與需求提供者交互的次數分別降低了38%、14.3%和20%.

ChatModeler 在多個大語言模型上都能降低與需求提供者交互的次數. 在7 個案例上，GPT-3.5 和ChatGLM-6B 這2 種大語言模型實現的ChatModeler，與需求提供者產生交互的次數分別平均降低了31.1%和29.7%. 由此可以看出，這2 種大語言模型下交互次數均有減少，而且GPT-3.5 大語言模型實現的ChatModeler 的效果略好. 因此，ChatModeler 是一種協作框架，適用于多種大語言模型，但是我們建議使用最新的大語言模型.

4.3 問題2 的設計和結果

1）實驗設計

為了評估ChatModeler 生成的需求模型的質量，本文同樣選擇將其與4.2 節中的3 種先進需求自動建模方法IT4RE、GSQ 和GPD 對7 個案例進行對比實驗，分別計算從需求描述中產生需求建模元素的準確率、召回率和F1 值.

2）實驗過程

對于4.2 節中的每一個案例，首先由人工理解需求描述；其次與ChatModeler 進行對話交互，生成人工與ChatModeler 的對話記錄；然后對建模師每個迭代周期產生的需求建模元素合并；最后計算ChatModeler產生的需求建模元素與的準確率、召回率和F1 值.

3）實驗結果及分析

ChatModeler 與3 種傳統方法生成的需求模型的質量評估結果如表8 所示. 從表8 可以看出，ChatModeler協作框架在多個案例上的效果均高于傳統方法. 與IT4RE 相比，ChatModeler 在前5 個案例上的召回率均保持或提升，準確率在TAS 案例上略有下降，但在其他4 個案例上分別相對提升了18.1 個百分點、12.6 個百分點、8.3 個百分點、22.8 個百分點. 與GSQ相比，ChatModeler 在SSS 案例上的準確率有所下降，但是召回率相對提升了18.9 個百分點，綜合評價指標F1 值相對提升了5.1 個百分點. 與GPD 相比，ChatModeler 在HCS 案例上的準確率、召回率和F1值分別相對提升了9.6 個百分點、49.3 個百分點和26 個百分點.

Table 8 Evaluation Results of ChatModeler on Modeling Quality表8 ChatModeler 在建模質量上的評估結果

ChatModeler 協作框架相對于多種需求模型生成質量均有所提升. 對于用例圖建模，ChatModeler 處理前5 個案例上的平均準確率、召回率和F1 值分別相對提升13.2 個百分點、8.5 個百分點和11.9 個百分點.對于序列圖和問題圖建模，ChatModeler 在處理SSS案例和HCS 案例時，召回率和F1 得分均有所增加.

ChatModeler 協作框架在多個大語言模型上都能提高生成需求模型的質量. 對于GPT-3.5 大語言模型，ChatModeler 在7 個案例上的平均準確率、召回率和F1值分別相對提升17.9 個百分點、19.2 個百分點和20.8個百分點. 對于ChatGLM-6B 大語言模型，ChatModeler在7 個案例上的平均準確率相對降低了1.9 個百分點，但是召回率和F1 值分別相對提升9.8 個百分點和1.7 個百分點.

5 案例研究

在本節，我們使用一個實際的開發系統進行了案例分析和研究，以證明本文設計方法的實用性. 我們選擇的案例是來自航空航天控制領域的一個真實開發系統，即太陽搜索控制系統[41-42]. 該系統主要是通過采集各種硬件設備的數據以確定衛星當前的姿態，進而實現捕獲太陽. 我們選定該案例，一方面是因為該案例真實面臨著需求獲取和建模的任務，另一方面是因為它屬于嵌入式系統，需求相對復雜，而且需要與現實世界中的實體緊密聯系，適合采用問題框架方法建模.

5.1 案例研究過程

本文案例研究過程中使用的大語言模型是gpt-3.5-turbo，模型的設置和本文實驗環節相同，具體設置如4.1 節所述. 在案例研究過程中，我們首先閱讀了太陽搜索控制系統的系統需求文檔，然后人工與ChatModeler 進行多輪迭代式對話交互. 完整的人機對話記錄以及由大語言模型扮演的3 種角色生成的需求片段、需求模型和需求草稿可以在鏈接中訪問①https://github.com/publicsubmission/chatmodeler-result..

對話結束后，將建模師生成的建模元素人工組裝成問題圖，并將表4 的提示詞輸入給收集者以根據對話記錄生成相應的需求文檔.

5.2 案例結果

1）生成的問題圖

圖5 展示了從對話記錄中生成的問題圖. 我們讓專業的需求建模工程師人工閱讀了人機對話記錄，然后評估建模師生成的問題圖. 經過人工評估發現，ChatModeler 能夠正確提取太陽、衛星等外部實體，也能夠正確識別出追蹤太陽、接收操作員的指令2個需求領域，同時也能識別出監測外部實體的物理設備以及它們之間互相的數據傳送信息，如太陽敏感器需要感知太陽的可見標志，推力器需要采集衛星的角度等.

Fig. 5 Final generated problem diagram of the sun search control system圖5 最終生成的太陽搜索控制系統的問題圖

2）生成的需求文檔

表9 展示了ChatModeler 生成的太陽搜索控制系統的需求文檔.

Table 9 Final Generated Requirement Document for the Sun Search Control System表9 最終生成的太陽搜索控制系統需求文檔

對生成的需求文檔人工評估發現，概述部分描述出了太陽搜索控制系統的目的，但是對意圖描述不夠充分；系統組成部分準確描述了系統包含的4種設備；功能需求部分準確描述了實現2 個功能的操作序列. 所以，我們認為大語言模型產生的需求必須由需求提供者進一步確認和修改.

6 討 論

我們提出了利用大語言模型進行角色扮演，人機相互協作迭代式需求獲取和建模框架ChatModeler.這種框架不僅能夠降低需求提供者的負擔，提高需求獲取和建模的效率，而且能夠生成質量更高的需求建模，提升自動化需求建模的效果. 同時，ChatModeler框架具備良好的可擴展性，可以適用于多種需求模型的建模任務，不再局限于一種方法只能建模一種需求模型. 我們認為，ChatModeler 提供的角色扮演協同方案，也為軟件工程中的其他任務提供了一種可以探索的思路.

但是，由于大語言模型本身存在幻覺問題，大語言模型可能會生成含有錯誤的需求文檔和需求模型，且大語言模型自動化生成的需求文檔和模型的質量難以保障. 本文提出的ChatModeler 是一種半自動化的人機交互方法，大模型生成的需求草稿和模型的每個迭代階段會由人工驗證生成的內容. 如果存在錯誤的需求內容，會輸入給大語言模型人工反饋信息.

另一方面，由于大模型上一種黑盒模型，我們目前設計的用于構建需求分析團隊的提示詞不可避免地會受到一些限制. 我們的協作方式也受到傳統需求工程方法論的限制，沒有考慮大模型時代下需求獲取和建模任務下的重新分工，或許存在更加適合的虛擬需求分析團隊.

7 結 論

本文提出了一種基于大語言模型的人機協作迭代式需求獲取和建模框架ChatModeler，旨在降低需求提供者的負擔和生成質量更高的需求模型. 具體而言，受現實世界中需求分析團隊工作流的啟發，本文分析了需求分析團隊中的協作流程和角色職責，進而設計提示詞實現了由大語言模型扮演需求獲取和建模團隊. 在該團隊中，大語言模型扮演的3 種角色相互協作、不斷迭代和細化需求，最終生成需求文檔和需求模型. 我們進行了廣泛的對比實驗證明了ChatModeler 的優越性，并在航空航天領域系統中的太陽搜索控制系統上進行了案例研究，證明了ChatModeler 的可行性.

我們認為，多個大語言各司其職，相互協作的框架對處理需求工程中復雜分析任務具備很大的發展潛力，我們將繼續在這個方向進行探索. 未來的工作主要是2 個方面：一方面是探索更多大模型之間的分工和協作機制來處理需求工程中的獲取和建模等任務；另一方面是探索如何進一步保障大模型的模型生成質量.

作者貢獻聲明：靳東明提出了論文思路并完成了實驗；金芝對研究問題和實驗方案的設計以及論文的撰寫提供了幫助；陳小紅和王春暉修改論文，并提出方案改進意見.