RDRAZeroOneから要件定義を始め、RDRASheetで要件を組立てる

1. RDRAZeroOneでLLMでRDRA定義のたたき台を作成

2. RDRAGraphでLLMの出力をグラフィカルに確認し理解する

3. RDRA定義で要件を組立てる

4. 組立てた要件をグラフィカルに確認する

1. 要件定義の背景と業務の概要を入力

2. ３段階でLLMを実行し要件を組立てる

3. LLMで作成した要件をRDRAGraphでグラフィカルに確認

4. RDRA（Spreadsheet）で要件を定義

5. RDRA分析で不整合を検査

6. RDRA分析からRDRAGraphで確認

要件定義を３つのフェーズで進める

フェーズ１：要件定義の立ち上がりに空中戦を避けるために議論のベースを作る

フェーズ２：RDRAモデルの構造を使って要件を組立てる

フェーズ３：条件・バリエーションまでを含めて整合性を合わせ、精度を向上させる

フェーズ１にRDRAZeroOneを活用し素早く議論のベースを作り、要件の組立はフェーズ２で従来通りのRDRAモデルで組立てる

※エンタープライズ向けの要件定義に無理にLLMを使うと効率が落ちるので、フェーズ２から従来通りのRDRA定義を行う

処理の文脈情報を与えて要件定義を開始し、３ステップでLLMを活用し段階的に詳細化する。各ステップでLLMの出力を手直しすることで、要件定義に方向性を持たせ、企業ごとの仕組みや独自情報を与える。

1. ビジネスの外枠を固める

   • 議論に方向性を持たせるために、システム化の外枠を決めるものを定義する

2. ビジネスの組立

   • 業務内の仕事を洗い出し、ビジネス側を固める

3. RDRA要素の抽出

   • 仕事にユースケースをアサインし、情報やアクターなどを出力し、ユースケースにつなぐ

LLMを使うためにOpenAIのAPIキーを登録する

※現状はOpenAIのLLMだけに対応しModelはGPT-4oを使用

要件を定義する対象の背景や業務の概要を記入する。

• ①システム名：「対象システムの名前」を入力。

  • ⇒　データを保存するときの識別して利用する

• ②最重要要求：「結局何が実現できればいいのか」を入力

  • 要件の方向性を与えるために利用する

• ③　A:ビジネスの背景

  • 背景やアクター、外部システム、要求、制約、ビジネスポリシーなどを入力

  • 上記項目は必須ではなく、わかっていることを入力し、徐々に精度を上げる

• ④　B：概要

  • システム化対象が行っていることを箇条書きで記述

  • 分類と業務の２階層で記述する

文脈理解を入力とし以下の要素を出力する

• アクター：システムに関係するアクターを出力する

• 外部システム：システムに関係する外部システムを出力する

• ビジネスポリシー：ビジネス全体を通した決まり事を明確にする

• ビジネスパラメータ：ビジネス上活用している区分や種別を洗い出す

• 業務：入力された業務概要から分類された説明付きの業務を出力する

⇒システム化のスコープを決める

※LLMの反応をよくするためにRDRAの用語とは違う用語を使っている

　　業務：BUC　　　分類：業務

※アクターや外部システムを記述すると、LLMに出力されるものが限定される

※業務の概要を２階層で整理して出力するとLLMもその階層を利用する

　１階層目の先頭に「・」　２階層目の先頭に「- 」を付ける

• 明らかに意図した内容でない場合、または欠けているものがあれば「文脈理解」の入力を見直し再実行する。

• 想定範囲の出力の場合は、不要な行を削除し、名称、説明を見直し再実行する

• 見直しポイント

  • アクター：ビジネスの背景にアクターを追加する

  • 外部システム：ビジネスの背景に外部システムを追加する

  • ビジネスポリシー：明らかに違うものを削除する

  • ビジネスパラメータ：明らかに違うものを削除する

  • 業務：不要な業務を削除し分類と業務名（BUCレベル）を見直す

※時間をかけて見直すのではなく、直感的におかしなところだけ見直す。文脈理解の入力を見直すために、LLMの出力を見直す

業務毎の各項目を見直す

• 要求：業務に対する要求も出力される。

  • 業務を仕事に分解するための方向性を要求として記述。

  • この段階では要求が思いつかない場合は、出力された要求をそのままにしておいてもよい

• 分類：概要で入力した分類が反映される

• 業務：業務の名前（BUC）として適切か否かを確認する

• 説明：業務の説明として妥当か否かを確認する

※２、３回は文脈理解の見直しとLLMの実行を行い、入力の精度を上げていく

ビジネスアイディアの出力がある程度妥当なものであれば、ビジネスデザインのLLMを実行する

• 業務で扱う情報、状態を洗い出す

• 業務を仕事に分割する

• アクターと外部システムを仕事に関連付ける

• 情報・状態モデルの見直しポイント

  • 情報：明らかに不要なものを削除し、欠けているものは追加する。また名前や説明の内容を見直す

  • 状態モデル：明らかに不要（管理しない）な状態を削除し、欠けているものは追加する。また名前や説明の内容を見直す

※明らかにLLMの出力が妥当（想定しているものが出力されない）ではない場合は再度LLMを実行する。数回実行して出力されない場合は、後でRDRA定義の段階で手直しする

※ここで扱う業務と仕事はRDRAのBUCとアクティビティに対応する

• ビジネスの基本的な骨格を組立てる

• 仕事と関連の見直しポイント

  • 要求：業務を仕事に分解するための方向性を要求として記述。

  • 仕事：業務内の不要な仕事を削除し、欠けているものは追加する。

  • 操作情報：仕事に関わる情報を見直す

  • 関連アクター：仕事に関わるアクターを見直す

  • 関連外部システム：仕事に関わる外部システムを見直す

この段階では要求が思いつかないことも多いので、出力された要求をそのままにしておいてもよい

※この段階ではまだ確かなことは決められないので、明らかに違うものを削除、欠けていると思われるものを追加し、内容の変更を行う。迷っているものは基本的に残していくようにする。

ビジネスデザインの出力がある程度妥当なものであればシステム化検討のLLMを実行し、RDRAに必要な要素を出力する

システム化検討では、情報、状態モデルを構造化し、条件、バリエーションを洗い出す。そして、仕事にユースケースを結びつけることで、システム化範囲を明らかにする。さらにユースケースに情報、アクター、外部システム、条件を結びつけてシステムが行うことを明らかにする

※意図したものが出力されない場合は出力結果を修正せずにLLMの再実行を行う

※この段階ではまだ確かなことは決められないので、明らかに違うものを削除、内容の変更を行い、迷っているものは基本的に残していくようにする

• 条件：コンテキストを見直し、不要なものを削除する

• バリエーション：分類を見直し、個々の項目はRDRA定義の参考にする

• 情報：分類の見直し、属性、関連（情報、状態モデル）を見直す

• 状態：分類の見直し、遷移させるユースケースを見直す

• ユースケース：不要な業務を削除し分類と業務名（BUCレベル）を見直す

※条件、バリエーションはRDRA上で定義する場合の参考にするために

※この段階の修正はRDRASheet上でも行えるので、グラフィカルに精度を確認するために分類と関連を中心に見直す

グラフィカルに確認するためにはコンテキスト、分類、業務などのグルーピング、ユースケースとの関係が重要になる

• ↓文脈理解 ↓ビジネスアイディア ↓ビジネスデザイン ↓システム化検討

  • ナビゲーションとしてスクロールする

• LOAD：保存した定義を呼出す（保存データを全て削除する）

• SAVE：入力した定義を保存する

• CLEAR：表示内容をクリアする

• TO RDRA：Google Spreadsheetの「RDRA定義」を表示する

• TO GRAPH：定義内容を反映した「RDRAGraph」を表示する

• SAMPLE：文脈理解のサンプルを表示する

• REGISTER API：API Keyを登録する

ZeroOneではたたき台となるものを素早く作成することが重要

システム検討まで進めるとRDRAGraphやRDRASheetに出力できるようになる

• ToRDRA：RDRASheetに移行できるように定義内容をクリップボードにコピー

• ToGraph：RDRAGraphを表示

RDRAGraphで内容を確認し、必要なところに戻って再度LLM実行を行う

ある程度の精度になったところでToRDRAでRDRA定義のSpreadSheetで編集を始める

※ZeroOneだけで精度を上げようとしない、ある程度システムスコープの合意ができればRDRASheetを使って要件を組立てる

表形式だけでは出力の精度を理解するのは難しいので、RDRAGraphを使って定義内容をオブジェクトから逆引きして内容の精度を確認する

精度を確認するポイント

• アクター：任意のアクターの役割からつながる画面やユースケースの妥当性や偏りを見る

• 外部システム：任意の外部システムの役割からつながるイベントやユースケースの妥当性や偏りを見る

• 情報：情報につながるユースケースの妥当性を確認する

※妥当性はつながりの偏りから判断する。全くつながっていないもの、つながりの多いものなどから妥当性を確認する

ChatBotを使ってLLMに内容を確認する

• メニューChatBotを実行

• 表示されたBotに問合せを行う

• 「ダイアグラムの説明」表示されている内容を説明する

※RDRAGraphを参照

構造から要件の精度をチェックすることができる

• Ⓐ　コンテキストは業務によってつながるはず

  • コンテキストには情報、状態、条件が含まれ、業務にはBUC、UCが含まれる

  • UCと情報のつながりが俯瞰すると業務とコンテキストのつながりに反映する

  • 業務が複数のコンテキストをまたがることでシステムとしての整合性や一貫性を保持する

• Ⓑ　状態を変えるUCが情報につながっていない

  • 状態は情報に保持される

  • UCは情報を操作することで状態を遷移させる

各アイコンの意味のつながりから要件の精度をチェックする

• Ⓐ　ユースケースの名前と関わる情報、状態の関係性がおかしい

  • 「顧客ニーズを把握する」というUCが「販売代理店情報」を使い「販売管理」の状態を変えているが、UCの名前からすると違和感がある

• Ⓑ　サービス販売で受注に結び付いていないので、「販売完了」状態にするのはおかしい

  • 「サービスを提案する」というUCが「販売完了」状態にするのは違和感がある

• Ⓒ　状態モデルと情報が合っていない

  • 「販売代理店情報」と状態モデル「販売管理」につながるのは違和感がある