AI時代の要件定義
•
0 likes•1,033 views
RDRAモデルによる要件定義を紹介 １．AIを使ってRDRAモデルの要素を洗い出す ２．表形式で要件を定義 ３．要件の精度を向上させるために定義内容を分析 ４．表形式からグラフ形式に変換 トレーサビリティ 凝集度・結合度把握 ５．AIを使って要件を要約し俯瞰する
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AI時代の要件定義
Similar to AI時代の要件定義 (20)
More from Zenji Kanzaki
AI時代の要件定義
- 1. AI時代の要件定義
- 2. • ㈱バリューソース 代表取締役 • 神崎 善司 • Facebook page：要件定義の散歩道 https://www.facebook.com/youkennotsubo?ref=hl • twitter：@zenzengood • RDRA：https://www.rdra.jp/ • 著作 • モデルベース要件定義テクニック • RDRA2.0ハンドブック • 仕事 • RDRA導入支援 • 要件定義支援 • 好きな事 • モデリング • Google Sheetでのモデリング 2
- 3. 今日の内容 3 アイディアからRDRAモデル生成 RDRAモデルで要件の組立 様々な視点から要件を確かめる ０➡１： １➡２： ２➡３： 要約を使って俯瞰する 組み立てる ChatGPT システムの可視化をツールを使い精度高く素早く行う ０➡１ AIを使いアイディアを形にする １➡２ 表形式で整合をさせながら組み立て⇒整合性を確認し精度を上げる ２➡３ ビジュアルに結合状態、トレーサビリティを確認する ３➡４ 要約して全体の適切さを確認する 凝集度・結合度 を可視化する トレーサビリ ティを確認する AIに背景を説明する行為 を行いながら、課題や要 求を明らかにし、AIに行 間を埋めてもらう 全体を要約して俯瞰する ３➡４： ChatGPT 整合性を確認
- 4. 背景となる世界観 • 要件と仕様 • 要求 • システム化したいこと • 要件 • 要求の組立 • 画面Aがあり誰が使う • 仕様 • 実装可能な決め事 • 画面Aの項目 画面Aの振舞 • 論理データモデル • 背景の題材 • サービスとバックエンド • バックエンド • 会社の基幹システムとしての機能 • マーケティング • 販売・購買・在庫 • ~ • サービス • 役務サービスを提供する企業のバックエンド業 務支援 要求 要件 仕様 実装 要求→要件→仕様→実装 要求 一覧 要求を網羅 重要な要求から要件と して膨らます RDRA コード ビジネスの現場で使うルール 会社／組織 バックエンド作業 （基幹システム） サービス サービス サービス サービス サービス サービス サービス 外部サービスの利用 取引先 アナログ作業 4 題材の背景
- 5. RDRAとは
- 6. RDRAの関心 • 要件定義での関心事項 • 素早く定義する • その場で作りその場で「決める」 ⇒ どんどん組立 どんどん直す • 精度を高める • 整合性を高め網羅性を確保する仕組みをもつ • ビジネスルールを表現できる • 構造が要件を導出する • システムは情報で整合をとる • ユースケースは情報を操作し状態を返す ⇒ ユースケースは状態を遷移させる • 既存システムの可視化 • ToBeに向けたAsIsの可視化 • 保守開発の品質を上げたい • 関係者の認識を合わせる • システムの今を表し議論の土台を作る 6
- 7. RDRAレイヤー 依存 システム価値 システム外部環境 システム境界 システム Why Why Why アイコン アイコン アイコン アイコン システムに価 値をもたらす 視点 システムの使われ 方を示す視点 システムの入出 力を明らかにす る視点 システム化対象 のビジネス上の 情報と状態 7
- 9. ダイアグラムの関係 9 システム価値 システム外部環境 シ ス テ ム 境 界 シ ス テ ム 情報モデル バリエーション 条件 バリエーション / 条件 状態モデル 状態 遷移 ビジネス コンテキスト 組 織 組 織 組 織 業務 組 織 業務 ビジネス ユースケース システム コンテキス ト 目的 要求モデル 状態モデル 状態 遷移 条件 UC複合図 業務フロー付き UC 情報 画面 イベン ト UC 情報 画面 イベン ト Act Act UC複合図 業務フロー付き 条件 UC 情報 画面 イベン ト UC 情報 画面 イベン ト Act Act 条件 UC複合図 業務フロー付き UC 情報 画面 イベン ト UC 情報 画面 イベン ト Act Act UC複合図 業務フロー付き 条件 UC 情報 画面 イベン ト UC 情報 画面 イベン ト Act Act UC複合図 業務フロー付き 条件 UC 情報 画面 イベン ト UC 情報 画面 イベン ト Act Act バリエーション / 条件 ビジネス コンテキスト ビジネス ユースケース 要求モデル システム コンテキス ト 状態モデル 情報モデル UC複合図 システム価値 システム外部環境 システム境界 システム 外部システム ユースケース バリエーション 条件 アクター 業務 業務 業務 業務 状態 画面 イベント UC複合図 業務フロー 利用シーン付き 依存 業務フロー ユースケース 利用シーン
- 10. バリエーション / 条件 ビジネス コンテキスト ビジネス ユースケース 要求モデル システム コンテキス ト 状態モデル 情報モデル UC複合図 ダイアグラム毎の役割 システム価値 システム外部環境 システム境界 システム 外部システ ム ユースケー ス バリエーション 条件 アク ター 業務 業務 業務 業務 状態 画面 イベン ト UC複合図 業務フロー 利用シーン付き UC複合図 情報モデル 状態モデル 依存 組 織 組 織 業務 組 織 業務 組 織 業務フロー ユースケー ス 利用シーン 目的 システム コンテキスト 要求モデル ビジネス コンテキスト ビジネスユースケース 業務フロー 階層化してス コープを決める システム化の方向性 を求める システム化の詳細化 整合性を維持する 10
- 11. 業務からシステムを組み立てる 11 組織 顧客 申請 法人 申請 仕入 先 商品 申込 顧客 金融機関 システム 仕入先シ ステム 審査 XX登録 経理 組織 自社 顧客 取引先 商品 申請 業務 仕入先 金融機関 金融 機関 金融機関 システム 商品 食料品 生鮮品 金融機関 都市銀行 地方銀行 顧客 大口顧客 通常顧客 イベ ント XX契約 を登録す る 登録 審査 条件 XXを審 査する XXを 申し 込む 申込 画面 申込 審査 XX契 約 経理 申込 審査 XX契 約 状態モデル 申込済み 審査中 顧客 金融 機関 商品 登録済み XXを 申し 込む XXを審 査する XX契約 を登録す る [申請：業務] ビジネスユースケース図 ビジネスコンテキスト図 [申請：BUC] UC複合図 自社の業 務は？ 業務に関わる ビジネスの要 素は？ 業務を価値や責 務に分割する そのBUCはどのよ うなビジネス要素 と関わるのか？ このBUCはどの ようなステップ で進むのか？ まずは各ステップ をビジネス要素ど の相互作用として 組み立てよう そのビジネス要素にはバリエーションがあるか？ 各UCで何 を行う？ 顧客 金融 機関 申込 審査 XX契 約 商品 情報モデル トランザクショ ン系の情報 これビジネスを駆 動する情報だね 情報を構造 化すると 申込、契約には状 態があるよね？ 状態は何処 で変わる？ 業務はどのようなBUC からできているか？ リソース 系の情報 そのBUCはどのような仕 事で組み立てているの？ 外部システムとつ なぐにはイベント が必要
- 12. 事前準備 • 準備 • 利用する以下のGoogle Sheetを自分のGoogleDriveにセーブしてください • 1.サービス申込RDRAGPT_V0.9：AIでRDRAモデルの組立 • https://docs.google.com/spreadsheets/d/1oGVZmlVTF6Mr8pZ2aPaaK2B6TQVSFkJQ9ecNU_UX8r0/edit? usp=sharing • 2.サービス申込RDRA定義_V0.9：表形式でRDRAモデルの組立 • https://docs.google.com/spreadsheets/d/1XRnsP9Vanl5SQ04jH7gd2HJXeerWHNm4RHVqr88cHD4/edit? usp=sharing • 3.サービス申込RDRA分析_V0.91：定義情報の分析 • https://docs.google.com/spreadsheets/d/1bb4RK2nvj_65114mq2pVLNnBgx3lRp-ihV- qxWqQ1_4/edit?usp=sharing • 4.サービス申込RDRA説明_V0.9：定義情報の要約 • https://docs.google.com/spreadsheets/d/16lsdkGNU1o0geWKCSW8VW6x_hUoNHfwN_K2jxqFZP_c/edit ?usp=sharing • セーブ方法 • 上記リンクを開く • ファイル／コピー保存 自分のGoogleDriveに保存する 12
- 14. 表でRDRA構造を再現 分類 アクター 機能要求 説明 機能要求 分類 アクター 非機能要求 説明 検証方法 非機能要求 アクター 外部システム 情報 条件 バリエーション 状態 14 業務・BUC・アクティビティ・UC 情報 画面 アクター イベント 外部システム
- 15. Google sheets 表で構造化する BUC アクティビティ・UCにつながるオブジェクト定義 業務 画面 ユースケース アクティビティ BUC 外部システム アクター イベント 情報 状態 条件 状態 条件 UC ユースケース バリエー ション 条件 画面 外部システム 会員 状態モデル アクター 状態モデル UC 15 状態 情報 外部システム ユース ケース イベント 条件 業務 アクター BUC 画面
- 16. 分類 アクター 機能要求 説明 分類 アクター 非機能要求 説明 検証方法 表で業務を組み立てる 表の構造 機能要求 非機能要求 アクター 外部システム 情報 状態 「BUC」シート 画面 イベント タイマー バリエーション 条件 業務 BUC アクティ ビティ UC 情報 条件
- 17. 今回の定義内容 RDRA2.0 情報 外部システム ユース ケース イベント 条件 業務 アクター BUC 画面 アクティ ビティ クラウドサービス 提供会社 サービス 申込画面 サービス 紹介 個人申込 申込 決済機関 会員 管理 法人申込 入会 退会 営業 法人 顧客 課金 清算 サービ ス申込 課金 清算 法人契約 登録 法人管理 者登録 法人会員 登録 クラウドサービス利用者 会社／組織 サービス を申込む 入金を確 認する 入金連絡 サービス料の支払い 個人 顧客 申込 請求情 報作成 請求書送 付 清算 請求 入金 請求情報を 作成する 会員 会員情 報登録 会員を登録 する 支払方 法登録 サービス プラン サービス 顧客 管理者 役務サービスを提供する会社に対してバックエンドの処理をクラウドサービスとして提供するビジネス 担当 経理 17
- 18. ０➡１ AIを使ってRDRAモデルを作成 • ５ステップで要求からRDRAモデルへ組み立てる • 狙い： • ０を１にする 形を作ることが重要 • 正確さは狙わない 正確さより気づきを得ることが大事 • 議論の出発点にする • これじゃない 例えばこんな感じ • 活用： • 知らないドメインについて体系的な知見を得る • 自分たちで仮説をもつ 業務： プロセス： プロセスの内容 機能 目的 行うこと 業務： プロセス： 仕事 情報 アクター 外部サービス 業務： プロセス： 仕事 ユースケース 情報 アクター 外部サービス 情報 状態 アクター 外部 システム バリエー ション 条件 Google Sheet 1.サービス申込GPT_V0.9 18
- 20. 試してみよう #業界 役務サービスを提供する企業 #問題・課題 サービスを支援するバックエンドの作業 負荷が大きい #要望 サービス利用者の登録、会員管理作業、 課金清算のシステムなどのバックエンド 作業をシステム化したい ■ 機能： 会員管理システム 目的： 会員 の情報を効率的に管理し、会員間のコ ミュニケーションをスムーズに行う 行う こと： ユーザーの登録情報をデータベー スに保管し、更新と追跡を自動化します。 また、会員間のメッセージングを効率的 に管理します。 ■ 機能： 課金清算システム 目的： ～ #会社のビジネス概要 クラウドサービスをいくつか提供してい る #サービスの種類 小規模事業社向けのサービス開発 #狙い 小規模企業のバックエンド処理を ワンストップで提供する #関心 サービス 利用企業のビジネスの受注から入金まで を支援する #制約 ものを扱わずクラウド環境だけで 完結できるサービスにする 業務：会員管理 プロセス：ユーザー情報の管理 ユーザーの登録情報をデータベースに 保管する ユーザーの登録情報の更新と追跡を自 動化する プロセス：会員間コミュニケーションの ～ #サービス利用者 自社の業務をサービス を #サービス利用者の顧客 サービスプラン を画面で設定し役務サービスを受け、利 用料を支払う #サービス提供社の営業 サービス利用者 を開拓し受注につなげる 業務：会員管理 プロセス：ユーザー情報の管理 仕事1：ユーザーの登録情報をデータベー スに保管する 情報：ユーザーの登録情報 アクター：サービス利用者 ～ #サービス利用者 サービス利用者の顧客を開拓する 役務 サービスを提供する 必要な時は会員設定を変更する #サービス利用者の顧客 サービスプランを画面で設定し役務サー ビスを受ける 利用料を支払う #サービス提供社の営業 サービス利用者と契約がとれたらサービ ス利用者を登録する 登録されたサービス利用者は会員となる サービス利用者のクラウドサービスの利 用状況を確認する ■業務：会員管理 プロセス：ユーザー情報の管理 仕事1：ユーザーの登録情報をデータ ベースに保管する ユースケース：サービス提供社の営 業はサービス利用者をデータベースに登 録する 情報：ユーザーの登録情報 アイディア 業務の組立 仕様の組立 UCの組立 20 B3 B4 ChatGPT,Bard,Bing プロンプト D8 B8 プロンプト D8 B8 B3 B4 D7 B7 B3 D7 B7 B3 プロンプト プロンプト プロンプトをコピーしてAIにペースト 結果をシートにコピー
- 22. １➡２ RDRAモデルで要件の組立 • 適切なシートを使う • 誰が使うシステムなのか 「アクター」シート • どのような外部システムとつながるのか 「外部システム」シート • ビジネスで管理するIDは何か 「情報」シート • ビジネスで管理する状態は何か 「状態」シート • 業務とシステムの組立 「BUC」シート • ビジネスで使用する区分が洗い出されたら 「バリエーション」シート • ビジネスルールが出てきたら 「条件」シート Google Sheet 2.サービス申込RDRA定義_V0.9
- 23. ビジネスを表現 • システム化対象 • 誰がシステムに関わるのか • どのような業務で使われるのか • 業務にはどのような仕事があるのか • 仕事はどのような手順で行われるのか • 関わる人によって仕事や手順が変わるか • 仕事の進め方にルールはあるか • システムに関わる外部のシステムはあるか • そのシステムとの連携は • ビジネス上の決め事 • アクター（顧客...）には分類はあるか • サービスプランはあるか • 仕事のルールにはどのようなものが在るのか • 決済機関別の方式の違いはあるか サービス 紹介 個人申込 申込 決済機関 会員 管理 法人申込 入会 退会 最終 法人 顧客 課金 清算 サービ ス申込 課金 清算 法人契約 登録 法人管理 者登録 法人会員 登録 クラウドサービス利用者 会社／組織 サービス料の支払い 最終 個人 顧客 請求情 報作成 請求書送 付 清算 会員情 報登録 支払方 法登録 サービス 営業 管理者 担当 経理
- 24. システム化対象 • システム化対象 • どの仕事をシステム化す るか • システム化対象をUCと して明示する • インターフェース • システムに関わるアク ターは誰か • アクターが関わるイン ターフェースは • システムに関わる外部シ ステムは何か • その連携方法は • その時に決め事はあるか • ユースケース（UC） • UCが扱う情報は • UCにビジネスルールは あるか • クラウドサービス 提供会社 サービス 申込画面 サービス 紹介 個人申込 申込 決済機関 会員 管理 法人申込 入会 退会 課金 清算 サービ ス申込 課金 清算 法人契約 登録 法人管理 者登録 法人会員 登録 クラウドサービス利用者 会社／組織 サービス を申込む 入金を確 認する 入金連絡 サービス料の支払い 申込 請求情 報作成 請求書送 付 清算 請求 入金 請求情報を 作成する 会員 会員情 報登録 会員を登録 する 支払方 法登録 サービス プラン サービス 法人 顧客 個人 顧客 営業 管理者 担当 経理
- 25. １➡２ 整合性をとりながら整理する • 定義の不整合を訂正する シート間の関係を利用する • 分析しながら作る Pivotテーブルで関係性を把握する Google Sheet 3.サービス申込RDRA分析_V0.91
- 26. 整合性をとりながら整理する • Ⓐ：以下のシートで定義されていないものが BUCシートで使われている • アクター、外部システム • 情報、状態、条件 • Ⓑ：情報シート • 情報間の関連で未定義な情報が定義されてい る • Ⓒ：状態シート • 状態を遷移させるUCとして定義されたUCが BUCシートで定義されていない • 状態遷移先の状態が遷移元の状態として定義 されていない • Ⓓ：条件シート • 条件シートに定義されたバリエーションが、 バリエーションシートに定義されていない • 条件シートに定義された状態モデルが状態 シートに定義されていない • Ⓔ：以下のシートで定義されているがBUCシー トで使われている • アクター、外部システム • 情報、条件 RDRAとしての不整合はツールが明示する Ⓐ Ⓑ Ⓒ Ⓓ Ⓓ Ⓔ
- 28. 試してみよう • 定義を変更する 2.サービス申込RDRA定義_V0.9 • アクターの関りの見直し • 条件を追加してみよう • 候補 • 「支払方法の設定」 • 金融機関に差異は無いか • 決済方法で追加情報は無いか • 条件によって影響は受けないか • 候補 • ユースケースの追加など • 分析シートで確認してみよう 3.サービス申込RDRA分析_V0.91 • 「不整合」シート • 「UC-PIVOT」シート 2.サービス申込RDRA定義_V0.9 ↓ 3.サービス申込RDRA分析_V0.91
- 29. ２➡３ 様々な視点で精度を上げる • トレーサビリティ―の確認 • 結合度を把握する • 結合度を把握する
- 31. トレーサビリティを確認する • アクター視点 • ユーザーストーリー ユーザーのタッチポイント • 逆引き • 情報から／バリエーションから／条件（ビジネスルール）から 31 線のつながりが トレーサビリ ティになる ユーザー視点でシス テムとの接点を示す
- 32. 結合度を把握する • 結合度を把握する • 結合度の適切さをを早い時点から検討する • 最上位の関係性 業務⇐⇒BUC 32 業務・BUCとコンテキ ストの結合度を検討 結合度が分かることで 何処から計画が立てや すくなる ※：BUC、コンテキスト（UC、条件） 業務とコンテキス トの結合度を検討 BUCに ブレークダウン
- 33. 凝集度を把握する • 凝集度 • コンテキストの要素の関りを把握する • 情報と状態が同じコンテキストで適切か • 情報と条件の関係は適切か • 情報とバリエーションの関係は適切か • バックログの単位 • どこから進める 33 コンテキストに含まれ る要素間の関係から、 凝集度を測る 情報 状態
- 34. 大規模なシステムを見てみる • クラウドサービスの基幹システム • 業務の対比 • 申込 3.サービス申込業務 • 会員 4.会員活動管理業務 • 清算 5.清算業務 • コンテキストの対比 • サービス利用 サービス受注記録 • 最終顧客 サービス受注記録 • 清算 生産実績 https://vsa.co.jp/rdratool/rdragraph0.9/rdraGraph.html?init 確認してみよう ・トレーサビリティ ・結合度 ・凝集度
- 35. ３➡４ 要約して全体を俯瞰する • 重要な要素を洗い出す • 「重要性分析」シート • RDRAモデルを文章化する • 段階的に組み立てる • 集約単位で必要な要素を選ぶ GoogleSheet：4.RDRA説明_V0.9 https://docs.google.com/spreadsheets/d/1bb4RK2nvj_65114mq2pVLNnBgx3lRp-ihV-qxWqQ1_4/edit#gid=1240873646
- 36. 重要な要素でシステム全体を把握可能にする • システム全体を把握する ⇒ 重要性の把握 • 関連の多いものを重要と考える • 重要なアクター ⇒ 画面とつながりの多いもの • 外部システムを把握 ⇒ イベントのつながりの多いもの • 重要な情報を把握 ⇒ 情報同士のつながりの多いもの 情報の中心性 • 重要なUCを把握 ⇒ 重要な情報につながるUC 状態につながるUC
- 37. 関連数から重要な要素を把握する • システム全体を把握する ⇒ 重要性の把握 • 関連の多いものを重要と考える • 重要なアクター ⇒ 画面とつながりの多いもの • 外部システムを把握 ⇒ イベントのつながりの多いもの • 重要な情報を把握 ⇒ 情報同士のつながりの多いもの 情報の中心性 • 重要なUCを把握 ⇒ 重要な情報につながるUC 状態につながるUC
- 40. おまけ 質問の中で利用する 40
- 42. RDRA以後の進め方 • 関心 • 手戻りを極力減らしたい • 要件と仕様の切り分け • 要件はHowに影響されない • 仕様はHowに影響を受ける • 手戻りを減らすための横断的に影響を及ぼす仕様を明らかにする 仕様 設計 実装 テスト 要件：RDRA 仕様 設計 実装 テスト 手戻りの発生 スコープ 依存 B 仕様 設計 実装 テスト 仕様 設計 実装 テスト C D A 手戻り 発生 手戻り 発生 仕様 設計 実装 テスト 要件：RDRA 仕様 設計 実装 テスト 手戻りを減らす方法 スコープ 依存 B 仕様 設計 実装 テスト 仕様 設計 実装 テスト C D A 手戻りを最 小化する 仕様化準備⇒横断的仕様 手戻りを減らす ための横断的な 準備 要件定義 RDRA 横断的仕様 仕様 実装 イテレーション
- 43. イテレーション：開発単位 • 開発単位 • BUC駆動（価値駆動） • BUC ビジネスユースケース • UC ユースケース • ドメイン駆動 • コンテキストマップ • ドメインオブジェクト • 関心 • 凝集度・結合度 組 織 組 織 業務 組 織 業務 組 織 ビジネス コンテキスト ビジネスユースケース UC複合図 A 画面 B C 画面 情報 情報 情報 UC複合図 A 画面 B C 画面 情報 情報 情報 UC複合図 A 画面 B C 画面 情報 情報 情報 UC複合図 A 画面 B C 画面 情報 情報 情報 情報モデル 状態モデル 状態 遷移 コンテキストマップ 情報モデル 状態モデル 状態 遷移 コンテキストマップ 情報モデル 状態モデル 状態 遷移 ユーザー価値 中心で進める ビジネスの中心 構造で進める BUC駆動 ドメイン駆動 43
- 45. ビジネススピードに適応する
- 47. 依存性の構造 情報 情報 情報 情報 ユース ケース ユース ケース ユース ケース ユース ケース ユース ケース アクティ ビティ アクティ ビティ アクティ ビティ アク ティビ ティ アク ティビ ティ アクティ ビティ アク ティビ ティ アクティ ビティ アクティ ビティ アクター アクター アクター アクター アクター アクター ユース ケース 整合性 網羅性 ユースケー ス ユースケー ス ユースケー ス ユースケー ス 情報 情報 情報 ユース ケース ユースケー ス アクティ ビティ アクティ ビティ アクティ ビティ アクター アクター アクター アクター アクター アクター 利用シーン 利用シーン 状態A 状態B ユース ケース ユース ケース 要件 要求を実現し たＢＵＣ 情報を中心につじつまが合うか？ 関わるアクター、外部システムの仕 事が回るか
- 48. RDRAは何を変えるのか 物事のつながり で詳細を語る 成果物作成より も合意を重視 一覧と詳細 ユース ケース 画面 情報 イベント 物事の関係性を語る 一人で考え一人で作成 一つ一つを完成させる 徐々に洗練化する 成果物ではなく 要件を組立てる 構造が要件を組 み立てる 文書で意味を伝える 関係で意味を伝える みんなで考えその場で作成 What Why 文書では関わり が分かりづらい 粒度の細か い定義 粒度の細 かい定義 粒度の 粗い 定義 X xx X xx X xx X xx X xx X xx 詳細化を目指す 次工程で扱い やすくする 要件を決める仕組み がない 要件を決める仕組 みがある 依存 RDRAレイヤー 依存関係が要件 を決める 粒度を揃え る 48