生成AIによる要求工学の進歩：LLMs-driven 要求工学 Process

タグ

SoftwareEngneering

AIBoom

AIDB X

Github

URL

https://arxiv.org/abs/2310.13976

公開日

November 21, 2023

概要

著者リスト

Chetan Arora, John Grundy, Mohamed Abdelrazek

著者所属機関

Monash University, Deakin University

視点

サマリ

どういう論文？

生成AIを活用して要件工学を進化させる方法について探求しています。

先行研究と比べてどこがすごい？

LLM（大規模言語モデル）を要件工程プロセスに統合する新しいアプローチを提案しています。

技術や方法のポイントはどこ？

要件の連続的な洗練、ソフトウェア開発環境への統合、ステークホルダーの共同作業の促進がポイントです。

どうやって有効と検証した？

要件の検証を通じて、ステークホルダーのニーズを正確に表現するための様々なタスクについて検証しました。

議論の内容は？

詳細な議論の内容は特定できませんでしたが、LLMの利用に関する潜在的なリスクと機会について検討していると推測されます。

アブスト- GPT要約

生成AIを通じて要件工学を進化させる：LLMの役割の評価

主要機能

要件の連続的な洗練
ソフトウェア開発環境への統合
ステークホルダーの共同作業の促進

利点

論文から直接的な利点の記述は見つかりませんでしたが、一般的にLLMの利用は要件工程の効率化に寄与すると考えられます。

実験結果

ステークホルダーのニーズを正確に表現するための要件検証タスクの実施

評価と結論

具体的な評価と結論の部分は特定できませんでしたが、LLMの利用は要件工程における新たな可能性を示していると評価されています。

和訳

こちらは大規模言語モデル（LLMs）を駆使した要件工学（RE）プロセスの概観を示した図です。このプロセスは、以下のステップで構成されています。

1.要件の引き出し（Requirements Elicitation）: この段階では、要件エンジニアが利害関係者やドメイン専門家からニーズや特定のドメイン情報を収集し、要件の初草案を作成します。

2.要件の仕様化（Requirements Specification）: 草案は、要件ドキュメントの形式で正式化され、レビューと改訂のサイクルを経て、詳細化されます。

3.要件の分析（Requirements Analysis）: 分析ヒューリスティックを使用して、要件ドキュメントが分析され、矛盾や漏れがないか検証します。

4.プロンプトエンジニアリング（Prompt Engineering）: LLMsを活用したREエージェントが導入され、要件に基づいて適切なプロンプトを生成します。

5.要件の検証（Requirements Validation）: 検証ヒューリスティックを使用して、分析された要件が受け入れ基準やテストシナリオに沿っているか確認します。

2. LLMs-driven RE Process

このセクションでは、LLMs（大規模言語モデル）を活用した要件工学（RE）プロセスについて述べています。このプロセスは、Van LamsweerdeのREプロセスに基づいて適応されており、要件の引き出し、仕様化、分析、検証の4つの段階に大別されます。LLMsをREに具体的に適用する方法は、問題のドメインやプロジェクトによって異なることに注意しています。例えば、ActAppにLARREフレームワークを実装することは、安全性が重視されるシステムとは異なる可能性があります。この章では、さまざまなプロジェクトに適用可能なREにおけるLLMsの役割について広い視野を提供しています。議論されているREの各段階は共通しており、ドメインやシステム全体で一般化可能ですが、場合によってはより細かい調整が必要になります。

LLMsは、曖昧性の管理など、REタスクを自動化するために異なる方法で使用できます。

この章では、要件分析者や他の利害関係者が、ChatGPTやこれらに基づいて構築された調整されたLLMs REエージェントなどの生成型AIエージェントに直接プロンプトを提供することに特に焦点を当てています。複数のLLMsベースのエージェントを生成し、利害関係者（例えば、ドメイン専門家、エンジニアリングチーム、クライアント、要件エンジニア、エンドユーザー）とのやり取り（プロンプトを介して）を行い、要件の引き出し、仕様化、交渉、分析、検証を行い、品質保証のための他のアーティファクトを生成することができます。プロンプトは、LLMsを使用して生成タスクを実行するための技術です。プロンプトは、LLMsに求められているタスクに関する情報を提供する短いテキスト入力です。プロンプトエンジニアリングとは、LLMsのパフォーマンスを向上させ、望ましい出力品質を得るためにプロンプトを設計しテストすることです。プロンプトエンジニアは、言語の知識、手がかりのタスク、LLMsの能力を使用して、望ましい出力を生成するのに効果的なプロンプトを作成します。プロンプトエンジニアリングには、適切なプロンプトパターンとプロンプト技術の選択が含まれます。プロンプトパターンとは、特定の目標に対応する異なるテンプレートを指し、例えば、Output Customizationパターンは、LLMsによる出力の形式や構造をカスタマイズすることに焦点を当てています。他の一般的なテンプレートには、「Context, Task and Expected Output」形式でプロンプトを一貫してフォーマットするものが含まれます。例えば、出力カスタマイズのためにペルソナを使用することができます。

3 要件の引き出し

3.1 引き出しタスク

要件の引き出しは、前段階の作業（現状分析と利害関係者分析）と利害関係者とのコアな引き出し活動（インタビューと観察）を包含しています。主な目的は、開発中のソリューションのプロジェクト情報、システムのニーズ、期待、および制約を特定し文書化することです。引き出しにおける主要なタスクには、ドメイン分析、現状分析、利害関係者分析、実現可能性分析、そして特定された利害関係者とのインタビューや観察といった技法を用いた引き出しセッションの実施が含まれます。引き出しプロセスは方法的ですが、本質的に動的であり、要件が進化し新たな洞察が利害関係者から生まれるにつれて反復的なセッションがしばしば必要となります。要件の引き出しはまた、明確さと一致を確保するために多様な利害関係者からの絶え間ないフィードバックと検証を要求する、非常に協力的な活動でもあります。要件引き出しに関連する一般的な課題には、ドメイン理解の欠如、未知（すなわち、既知の未知と未知の未知）、言語障壁や専門用語によるコミュニケーション問題、初期段階で何を構築する必要があるのかの明確な理解の欠如などがあります。さらに、現在の引き出し技法は、人間中心のソフトウェア開発において不足しています。つまり、年齢、性別、文化、言語、感情、好み、アクセシビリティ、能力などの人間中心の要因に基づいて、すべての潜在的なユーザーグループから適切な代表を確保することです。進化する法的規定や法的コンプライアンスなどの外部影響も、引き出しプロセスを形成する上で重要な役割を果たしています。さらに、急速に進化する技術的環境では、既存の引き出しプロセスはしばしばシステム要件を正確に捉えることができません。例えば、AIシステムの場合、バイアス、倫理的考慮、大規模ソフトウェアシステム内での非決定論的AIコンポーネントの統合などです。

3.2 LLMsの役割

LLMsは、ドメイン分析を含む引き出しフェーズの多くの重要な課題に対処できます。LLMsは、膨大な量のドメイン固有の文献を迅速に吸収し、基礎的な構造を提供し、ドメイン知識源の代理として機能することができます。これらは、既存の文献に基づいて接続を描き、ギャップを特定し、洞察を提供し、現状分析、ドメイン分析、規制コンプライアンスなどの自動化されたタスクに基づいて支援することができます。LLMsは、利害関係者とのコミュニケーションを支援するために、既存のドメインやプロジェクト固有の文書（例えば、LLMsのファインチューニング）や規制（例えば、GDPR）などの他の入力を必要とします。LLMsはドメイン知識にアクセスできますが、ドメイン専門家の直感、経験、専門知識を置き換えることは困難です。例えば、ActAppでは、特定の運動が患者の血糖やホルモンレベルにどのような影響を与えるかという微妙な理解は、代替不可能な内分泌学者などの医療専門家にあります。

LLMsは、既存の文書を分析し、曖昧さや不確実性のある領域を強調することによって未知を特定するのに役立ちます。LLMsは、要件分析者が見落としていたかもしれない完成品や代替案を提案することができ、その大規模なトレーニングデータと接続に基づいて描き出します。LLMsは、複雑な技術用語を平易な言葉に翻訳し、異なる言語背景を持つ利害関係者を支援することができます。例えば、ActAppで要件分析者に医療用語を翻訳したり、ドメイン情報をある言語から別の言語に翻訳したりします。

LLMsは人間中心のREにおいて重要な役割を果たします。彼らは、アプリのレビューなど、多様なユーザーのフィードバックを分析し、すべてのユーザーのニーズが対応されていることを確認できます。LLMsはまた、人間中心の要因を考慮してユーザージャーニーをシミュレートすることもできますが、これにはアプリレビュー、ペルソナベースのユースケース、アクセシビリティガイドラインなどのリソースが必要です。新興技術の場合、LLMsは定期的な更新が必要であり、自動化されたソリューションはこれらの更新によって影響を受ける可能性があります。要件引き出しでのLLMsの使用は、倫理的な精査も必要とされます。LLMsは、インターネットの膨大なデータに基づいてトレーニングされているため、バイアスを導入したり、維持したりする可能性があります。LLMsの倫理的な使用を確実にするためには、バイアスを避け、利害関係者の入力がデータプライバシーとセキュリティガイドラインに従って管理されていることを保証することが必要です。LLMsの出力は、人間の努力を補完するものとして見るべきです。要件分析者は、ドメインの専門知識、文化的な認識、繊細な理解、共感的な相互作用を提供し、ソフトウェア要件がエンドユーザーの多様で進化するニーズに応えることを確実にします。人間と生成型AIのこの相乗効果は、人間中心のソフトウェア開発において重要です。

要件生成のプロンプト例
私はActAppというアプリを開発しています。 ActAppはT2D患者がアクティブなライフスタイルを確保するためのリアルタイムアプリケーションです。このアプリは、ワークアウト、健康、病気管理のためのタイムリーなリマインダーを提供します。以下にJSON形式で提供されるペルソナを使用して、ActAppユーザーとして行動し、応答してください。主な目的は、あなたの視点から要件を引き出すことです。生成された要件は、それぞれ一意のIDと根拠に関連付けられている必要があります。 {"persona":{ "name"： "Jane Doe", "age"： "65", "gender"： "女性"、"場所"： "カナダ"、"職業"： "退職者", "医療情報": . ., "ライフスタイル": . ., "目標": . . 「仕事」：： "座り仕事"、"課題"： . } }
原文：
Example Prompt for requirements generation.

I am developing an app called ActApp. 
ActApp is a real-time application for T2D patients to ensure an active lifestyle.
The app gives timely reminders for working out,health & disease manage- ment. 
Act and respond as an ActApp user with the persona provided below in JSON format.
The main aim is to elicit the requirements from your perspective.
The gen- erated requirements should each be associated with a unique id,and rationale. 
{“persona”:{ “name”: “Jane Doe”, “age”: “65”, “gender”: “Female”, “location”: “Canada”, “occupation”: “Retired”, “medical info”: . . ., “lifestyle”: . . ., “goals”: . . . “work”: “sedentary”, “challenges”: . . . } }

回答の出力例

ActAppでは、LLMは患者や介護者を含む様々なステークホルダーから情報を収集するために使用される。エージェントは、（以下に例示するように、与えられたペルソナの）利害関係者と仮想インタビューを行い、彼らのニーズ、好み、懸念を特定するために的を絞った質問をすることができる。例えば、エージェントはユーザーに希望する機能やデータプライバシーに関する懸念を尋ねることができる。さらにLLMは、オンラインフォーラム、ソーシャルメディア、類似アプリのレビュー、疾病管理に関する研究論文などの情報を分析・統合し、患者が直面する共通の課題やケアのベストプラクティスに関する洞察を引き出すことができる。この情報は、予備的な要件（例えば、以下のR1とR2）を生成し、後の段階で洗練させることができる。

ActAppの事例情報と初期要件 主なステークホルダー（初期のアプリのアイデアに基づいて特定）：患者、介護者、アプリ開発者、ML科学者、医療専門家（内分泌専門医など）。 R1. 患者は、長時間座っていた場合、立ち上がって動き回るように通知を受け取るべきである。 R2. R2.忙しいときは通知を受け取らない。

SWOT Analysis: LLMs for Requirements Elicitation

強み

対話的支援：エリシテーションを積極的に支援することができる。最初のインプットに基づき、多様な潜在的要件を生成する。未知の発見につながる。
効率的なデータ処理： 24時間体制でエリシテーションを行い、大量のエリシテーションデータを迅速に処理します。様々な形式の大量のエリシテーションデータを迅速に処理します。
ドメイン知識：ドメイン固有のリテラシーを迅速に吸収し、理解することができる。吸収した文献をもとにタスクを自動化します。
多言語・多文化なステークホルダーの支援複雑な専門用語を平易な言葉に正確に翻訳できる。複雑な専門用語を平易な言葉に正確に翻訳し、多様な背景を持つステークホルダを支援する。

弱み

共感とニュアンスの欠如：人間的な共感力がなく、感情的な合図や暗黙の意味を聞き逃す可能性がある。感情的な合図や暗黙の意味を見逃す可能性がある。
ドメイン専門知識の欠如： LLMはドメインの知識を理解しているが、直感や経験には代えられない。領域の専門家の直感や経験に取って代わることはできない。
誤解のリスク：文脈を誤って解釈する可能性や、プロジェクト独自のものを考慮せずに既存の訓練データプロジェクト特有のニュアンスを考慮せず、既存のトレーニングデータに頼りすぎる可能性。

機会

リアルタイムの文書化と処理：要件を文書化しリアルタイムでフィードバックを分析し、完全性と正確性を保証します。
人間中心のエリシテーション：多様なユーザーからのフィードバックを分析することで、LLMはすべてのユーザーニーズが考慮され、エリシテーションへの全体的なアプローチが促進されます。

脅威

過度の依存と信頼の問題：過度な依存は人間中心のインサイトを欠落させる可能性があり、一部のステークホルダーはAIとの関わりを躊躇する可能性がある。
データセキュリティとプライバシーの問題：データセキュリティとプライバシーの問題：LLMを介して要求を引き出すことは、特に機密情報（ChatGPTやBardのような公開LLMベースのエージェントなど）において、データ機密性の問題を引き起こす可能性がある。
潜在的なバイアス：偏ったデータや過去の欠陥のあるプロジェクトで訓練された場合、エリシテーションプロセスに不注意にバイアスをもたらしたり、永続させたりする可能性がある。
定期的な更新と互換性： LLMの確率的な性質を考慮すると、定期的な更新は、技術的な問題やプロジェクト要件の矛盾につながる可能性がある。一方、古くなったLLMはREにとって最適とは言えません。

4 要件の仕様化

4.1 仕様化タスク

要件仕様化では、引き出された原始的な要件情報を、システム設計と実装の青写真として機能する構造化された詳細な文書に変換します。LLMsは、確立されたテンプレートやガイドラインに準拠した整理された要件文書の生成を支援することで、このプロセスに貢献できます。例えば、「shall」スタイルの要件、ユーザーストーリーフォーマット、EARSテンプレート、あるいはVOLEREのような特定の文書テンプレートがあります。プロジェクトのコンテキストを考慮して、非公式な自然言語の要件を構造化された仕様に変換する必要があります—システムが行うべきこと（機能要件）とシステムが持つべき品質属性や制約（非機能要件）の両方です。

要件分析者は、文書全体で用語とスタイルの一貫性を維持し、可読性と明瞭性を高める必要があります。この段階では、利害関係者のニーズ、プロジェクトの制約、および戦略的目標を考慮して要件を優先順位付けすることができます。このフェーズは厳密であり、曖昧さやエラーは後の段階でのプロジェクトの遅延やコストの増加につながる可能性があります。さらに、詳細レベル（細かすぎるか抽象的すぎるか）のバランスを取り、セキュリティや使いやすさのような非機能要件が適切に対処され、軽視されないことを確保することが重要です。要件用語集、例、理由の生成、およびユーザーペルソナの開発など、人間中心の側面を適切にカバーするために行われる追加のタスクは、要件仕様化の間や直後に頻繁に実行されます。

4.2 LLMsの役割

LLMsは、仕様化プロセスを合理化することができます。引き出し段階からの非構造化された要件を、EARSやユーザーストーリーのような構造化されたテンプレートに自動的にフォーマットすることができます。さらに、機能要件と非機能要件に要件を分類し、パフォーマンス、倫理的要件、使いやすさなどのNFRを分類するのに役立ちます。LLMsは、要件用語集、理由、例の生成、ペルソナの開発など、仕様化中の他のタスクを自動化することができます。LLMsのもう一つの利点は、既存の標準、規制ガイドライン、またはベストプラクティスに対する要件のクロスチェック能力です。ActAppのような健康に焦点を当てたアプリの場合、LLMsは健康データのプライバシー基準や医療機器指令との整合性を確保することができます。

LLMsはまた、技術的依存関係、プロジェクトの目標、歴史的データを分析することによって、要件の優先順位付けを提案することができます。しかし、要件の優先順位付けを生成するには、いくつかのSEの役割と深く根付いた専門知識が必要です。したがって、LLMsによって生成される結果は正確ではないかもしれません。同様に、LLMsは仕様化の速度と一貫性を向上させることができますが、「過剰自動化」のリスクがあります。つまり、重要な側面を見落としたり、LLMsによって生成された要件を過度に信頼したりする可能性があります。たとえば、特定のNFRの重要性を決定する—システムがどれだけ安全である必要があるか、またはどれだけスケーラブルであるか—は、しばしば人間の専門知識を必要とします。LLMsはプロセスを支援することができますが、プロジェクトのコンテキストに精通しているドメイン専門家によって決定が検証されるべきです。同様に、コンプライアンスの問題についても、ドメインの専門家が結果を検証することが重要です。

プロンプトの例 以下の BNF 文法で定義された EARS テンプレートを使用して、書式なし要件から <requirement> を生成します。
<requirement> ::= <ubiquitous> | <event-driven> | <state-driven> | <optional> | <unwanted> <ubiquitous> ::= “The system shall <action>.” <event-driven> ::= “When <event>, the system shall <action>.” <state-driven> ::= “While <state>, the system shall <action>.” <optional> ::= “The system shall <action>.” <unwanted>::= “The system shall <preventive-action> to <unwanted-outcome>.” <action> ::= <verb-phrase> <event> ::= <noun-phrase> <state> ::= <noun-phrase> <preventive-action> ::= <verb-phrase> <unwanted-outcome> ::= <noun-phrase> <verb-phrase> ::= “a verb phrase” <noun-phrase> ::= “a noun phrase” Example Output: “When patient is driving, ActApp shall not send notifications.”

ActApp の例（機能要件のユーザーストーリーとして）。 R1.1. R1.1.私はユーザーとして、60分間座っていたら動くように通知を受け取りたい。 R1.2. 介助者として、利用者が移動の通知を受けた後も活動しない場合、ActAppが私に通知し、私が介入できるようにしてほしい。 NFR1.1：アプリは、患者のプライバシーを確保し、GDPRガイドラインに準拠するため、送信時および保存時にすべてのデータを暗号化すること。

例 ActApp では、LLM は（ActApp チームメンバーが希望する）ユーザーストーリーとして洗練された要件を生成できます。要件文書には、導入部、ActApp 利害関係者の説明、機能要件と非機能要件のリスト、優先順位付きの ActApp 機能のリスト、開発プロセスに関連する制約や仮定などのセクションを含めることができます。患者の健康情報のデータプライバシーなどの非機能要件については、LLMはHIPAAやGDPRなどの規制とクロスリファレンスして、コンプライアンスを確保することができます[1]。

5 要件分析

5.1 分析タスク

要件分析は、設計と実装の段階に移る前に、収集された要件を理解、評価、洗練して、それらが高品質（つまり、一貫性があり、包括的で、達成可能）であることを確実にすることに焦点を当てています。このフェーズの重要な要素は、要件品質の自動評価です。これには、曖昧さの解消、一貫性の確保、完全性の保証といった欠陥への対処が含まれます。このフェーズでの不備は、後続のアーティファクトに影響を与え、プロジェクトの遅延、予算超過、利害関係者の期待と合わないシステムにつながる可能性があります。自然言語（NL）要件の主な課題は、曖昧さ、不完全性、不一致、誤りであり、これらは誤解、テスト不能な要件、起源まで遡れない要件、何を構築すべきかに関する利害関係者間のコンセンサスの欠如、矛盾する要件につながります。絶えず進化する要件は、これらすべての問題をさらに悪化させます。時には、文書化された要件や基本的な仮定が、潜在的なリスクや依存関係を見落としてしまうことがあります。そのような場合、これらのリスクを特定し、対策として新しい要件を導入することが重要になります。例えば、矛盾する要件についての合意を得るための要件分析は、交渉を要します。交渉はすべての対立を解決する鍵であり、利害関係者は統一された要件セットに収束します。人間中心のREの観点からは、分析段階は、ユーザーの感情、文化、アクセシビリティのニーズを優先する必要があります。これには、包括性のためのユーザーフィードバックの精査、AIベースのソフトウェアシステムでの倫理とバイアスの懸念の検証、および現行のアクセシビリティガイドラインに対する要件の分析が含まれます。

5.2 LLMsの役割

LLMsは品質評価プロセスを自動化するための強力なツールとして機能します。

品質保証のための自動評価: LLMsは自動的に要件の品質を評価し、曖昧さ、あいまいな用語、不一致、不完全性をフラグ化し、ギャップや重複を強調します。リスクの特定と対策の提案: ドメイン知識を装備したLLMsは、要件やその基本的な仮定に関連する潜在的なリスクを特定することができます。歴史的データや既知のリスクパターンから引き出し、これらのリスクを軽減するための対策として機能する新しい要件を提案できます。対立解消と交渉: 対立領域を特定することで、LLMsは交渉プロセスを容易にします。複数のLLMsエージェントを利用して要件の交渉を行い、妥協点を提案し、様々なシナリオをシミュレートして、利害関係者が統一された要件セットに収束するのを助けます。人間中心の要件強化: LLMsは要件を評価して、それが多様なユーザーニーズ、アクセシビリティ基準、ユーザーエクスペリエンスガイドラインに対応していることを保証します。LLMsはまた、ユーザーペルソナやフィードバックに基づいてソフトウェアの使いやすさやアクセシビリティを向上させる要件を提案することもできます。さらに、バイアスや潜在的な倫理的懸念について要件を評価し、ソフトウェアソリューションが包括的で倫理的に健全であることを保証します。変更影響分析: LLMsはリアルタイムのフィードバックを提供し、反復分析の効率を高め、利害関係者の一致を維持します。LLMsを介した継続的なフィードバックサイクルとして実装された変更影響分析プロセスは一貫性を保証します。LLMsはさらに、要件の変更を積極的に予測し、要件の品質向上に貢献できます。

プロンプトの例コンテキスト ActAppシステムについて、ユーザビリティとデータプライバシーを維持しながら、システムが患者の健康上のニーズに対応できるようにするための要件（FR1～FR7およびNFR1～NFR5）について交渉し、優先順位を付ける必要がある。タスク 2つのエージェントを作成します：エージェント1(A1)は、プライマリユーザ（T2D 患者）を表します。エージェント2（A2）は、システムのソフトウェアアーキテクトを表します。A1 と A2 は、優先順位リストを決定するために、FR1〜FR7 について交渉し、議論します。この交渉において、A1はユーザーエクスペリエンス、健康上のメリット、実用的なニーズに焦点を当て、A2は技術的な実現可能性、既存システムとの統合、アーキテクチャの視点を考慮する。エージェントは時に異なる意見を持つことがあり、より微妙で現実的な議論につながる。いかなる決定もNFR1～NFR5に違反してはならない。期待される出力形式： A1とA2の交渉結果に基づく優先順位の根拠を含む。

6 要件検証

6.1 検証タスク

要件検証は、文書化された要件が利害関係者のニーズを正確に表しており、次の設計および実装段階に向けて準備ができていることを保証します。要件の検証には、利害関係者とのレビュー、欠陥の検査、起源（または他のアーティファクト）へのトレーサビリティの保証、明確な受け入れ基準とテストシナリオの定義など、複雑なタスクがしばしば含まれます。

検証フェーズの主な課題は、利害関係者の「実際の」期待と暗黙の仮定によるギャップがないことを確認することです。要件は利害関係者によって異なって解釈される可能性があり、潜在的なミスアラインメントにつながる可能性があります。プロジェクトのダイナミックな性質は、要件が進化することを意味し、検証プロセスをさらに複雑にします。時には、要件やその基本的な仮定が、特定の制約や依存関係を見落としてしまうことがあります。これは検証タスクにさらなる問題を引き起こします。そのような場合、これらのギャップを特定し、要件をそれに応じて洗練することが不可欠です。

6.2 LLMsの役割

LLMsは、いくつかの繊細な方法で検証フェーズを支援できます。分析フェーズで強調されたように、LLMsは潜在的な曖昧さ、不一致、または事前定義された検証ヒューリスティックスに基づく違反をフラグ化することで、手動レビューと検査を支援できます。LLMsは利害関係者の視点をシミュレートするために利用され、分析者が潜在的な誤解解釈やミスアラインメントを予測するのを助けます。例えば、過去の利害関係者のフィードバックを分析することで、特定の利害関係者の視点から明確化が求められる可能性のある領域をLLMsは予測できます。大量のデータを迅速に処理する能力により、LLMsは他のアーティファクト、例えば設計文書や規制コードへの要件トレーサビリティを支援できます。LLMsは、文書化された要件に基づいて明確かつ正確な受け入れ基準を形成するのにさらに役立ちます。また、包括的な検証スイートを確保するためのテストシナリオを提案することもできます。さらに、LLMsは要件をスキャンして、見落とされた人間中心の側面、制約、または依存関係を特定しフラグ化することで、より包括的な検証を保証できます。

LLMsはほとんどの検証タスクを容易にすることができますが、上記のように、検証タスクにはしばしばプロジェクト全体の概要、ドメイン、および利害関係者の視点が必要であり、LLMsがその抽象レベルで機能することは非常に困難です。これは通常、多くの利害関係者による手作業を必要とします。

7 予備評価

我々は、実際のシステム（ActApp）上でREにおけるLLMsの予備的な評価を実施しました。この評価の目的は、REにおけるLLMsの包括的な評価を行うことではありませんでした。代わりに、要件引き出しにLLMsを統合する実現可能性に主に焦点を当てました。これは、NLP技術をこれらの段階に適用する長い歴史と確立された方法論が一部おかげで、REの残りの段階へのLLMsの適用は比較的直感的であると考えられるためです。したがって、要件引き出しにおけるLLMsの探索が本質的な第一歩であると考えました。

データ収集手順

データ収集の主な目的は、ActAppのユーザー要件を確立し、要件引き出しのためのChatGPTのパフォーマンスを分析することでした。私たちのチームは、3人のActAppの専門家—プロジェクトマネージャー、MLサイエンティスト、ソフトウェアエンジニア—にアクセスできました。これらの専門家は、プロジェクトの焦点を明確にするために研究者であるKatelyn（仮名）と会いました。会議は、REプロセスを理解する広範な文脈の一部でした。バイアスを避けるため、専門家にChatGPTは言及されませんでした。Katelynは専門家と4回の2時間の会議を行い、プロジェクトの概要、システムユーザー、ユーザー要件、ソフトウェア機能を提示しました。

我々は要件引き出しの初期段階を模倣するためにChatGPTを使用しました。この段階では、要件エンジニアが利害関係者からプロジェクト知識を取得し、既存の文書をレビューし、ユーザー要件とコア機能を形式化します。プロセスには4人の参加者が関与しました：JorahとJonは経験豊富なソフトウェア/要件エンジニア、AryaとAegonは初期段階のREおよびNLPの研究学生です。彼らはKatelynからプロジェクトの概要を与えられ、ActAppプロジェクトの開発者として自己紹介しながらChatGPTセッションを開始するよう求められました。プロジェクトの概要に従い、彼らはChatGPTと対話し、45分のセッションでユーザーストーリースタイルの要件を引き出しました。その後、Katelynは参加者がChatGPTを使用して生成した要件を実際のプロジェクト要件と照らし合わせて調べました。

結果

全体として、Katelynは専門家とともにActAppで20の主要なユーザー要件を特定しました。Katelynは、Jorah、Jon、Arya、Aegonが引き出した要件をこれら20の要件と照らし合わせました。引き出されたセットの各要件は、完全一致、部分一致、または一致なしとして分類されました。なお、「完全一致」は元の要件の厳密な構文の複製を意味するものではなく、その本質を効果的に捉えていることを意味します。同様に、「部分一致」は元の要件の本質の一部だけが捉えられていることを示します。精度と再現率の計算では、各完全一致を1の真の肯定（TP）として、各部分一致を0.5のTPとして重み付けしています。Katelynはさらに、すべての「一致しない」要件を、必要に応じてさらなる専門家の審査が行われる可能性のある余分または潜在的に関連があるとして分類しました。表1は、4人の参加者からの全体的な結果を示しています。結果は、この予備評価においてChatGPTを使用する際の経験の重要性を明確に示しています。参加者の中でほとんどの要件を引き出すことができた人はいませんでしたが、プロジェクトの概要と一回の対話セッションで、経験豊富な参加者がほぼ半分の関連要件を得ることができたことは、REのためのLLMsの実現可能性を強調しています。

8 学んだ教訓

予備評価から得られた洞察と課題を以下に示します。

プロンプトと文脈情報の役割 LLMsは意味のある出力を生成するために包括的なプロンプトと文脈情報の利用に大きく依存しています。わずかに異なるプロンプトが非常に異なる出力を生み出す可能性があります。LLMエージェントを採用するためには、プロンプトエンジニアリングの徹底的な実証評価が必要です。

経験の重要性経験豊かな要件エンジニアは、プロジェクトの背景が参加者間で均一であるにもかかわらず、プロンプトの作成、応答の解釈、高品質な出力の取得においてより成功しました。これは、REチームにおける経験とトレーニングの重要性を強調しています。

LLMの能力予備評価は、REの大きな課題である「未知」の要件を発見するLLMsの能力を強調しました。私たちは、元のセットには含まれていなかったActAppの将来の段階のための4つの「潜在的に関連する」要件を3人の参加者から見つけました。LLMsは、多様な利害関係者向けにテキストを解釈し生成するのを支援することができ、多様なプロジェクトチームに固有のコミュニケーション障壁を減らす鍵となる可能性があります。しかし、多くの「偽陽性」候補要件の管理は、エンジニアが多くの無関係または半正確な要件に圧倒されないように注意が必要です。

LLMの問題点 LLMsは、出力にシステマティックな不正確さやステレオタイプ（トレーニングデータに影響される）があるなど、いくつかの固有の問題を持っています。例えば、ChatGPTには32Kトークンの制限があり、大きな文書を処理することやセッションでのタスクコンテキストを維持することが困難になる可能性があります。すべての参加者は、評価セッションでActAppシステムのコンテキストを維持することに問題があり、不正確さに気づいたと報告しました。

ドメイン理解 REでは、正確で完全な要件を引き出し、特定するために、基本的なドメインを優れた理解が必要です。特定のドメイン知識に関するLLMのトレーニングは限られているかもしれませんし、専門家や他のソース、または微調整されたLLMsを通じてドメイン知識を組み込むための対応が必要です。カスタムLLMを微調整するための大量のトレーニングデータへのアクセスは課題になるかもしれません。

オートメーションバイアス人間はしばしばAIに根拠のない信頼を示します。例えば、私たちのケースでのLLMsによって生成された要件です。例えば、セッションを完了した後、AryaとAegonは彼らが引き出した要件に対して顕著な自信を示しました。

セキュリティ、プライバシー、倫理的問題要件は本質的にソフトウェアエンジニアリングにとってミッションクリティカルであり、多くの機密情報を含んでいます。公共のLLMsを介しての開示は、IP損失、展開されたシステムのセキュリティ違反、組織的および個人的なプライバシーの損失、およびその他の懸念を引き起こす可能性があります。不明なソースからのトレーニングデータによって生成された要件の「所有者」は誰でしょうか？

9 結論

REの様々な段階でのLLMsの変革的な可能性を探求しました。我々の探求は、LLMsが自動化、合理化、および人間の能力を増強することで、いくつかのREタスクを強化する可能性があるという位置づけをしました。利害関係者の視点をシミュレートし、代替要件を生成し、要件品質に取り組み、基準と照合し、構造化された文書を生成する能力は革命的です。しかし、LLMsがすべてのRE問題を解決する「銀の弾丸」ではないという、抑えられない楽観主義に対しても警告しました。REへの応用に関連する特定の課題や脅威には、深く根付いたドメインのニュアンスを理解し、全体的なコンテキストを理解し、過度な自動化、過度な仕様化、要件の人間中心の視点を失うことが含まれます。章はさらに、2型糖尿病患者向けのActAppアプリにREのためのLLMsを適用することで得られた教訓を概説しています。