シリーズ: モデルベース要件定義手法RDRA
- 要件定義手法RDRAの概要と全体像
- RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る
- RDRAによる要件定義の進め方〜第2フェーズ：要件を組み立てる
- RDRAによる要件定義の進め方〜第3フェーズ（１）：システムレイヤーの要素同士を関連付ける
- RDRAによる要件定義の進め方〜第3フェーズ（２）：矛盾を解消し、整合性を高める
- RDRAの成果物と設計プロセスとの連携（本記事）
- 要件定義をAIで加速する「RDRA Agent」その1〜LLMがモデルの叩き台を自動生成
- 要件定義をAIで加速する「RDRA Agent」その2〜要件を仕様化するRDRASpec
- RDRAで見積りを行う方法その1〜要件モデルから工数・金額を自動算出する
- RDRAで見積りを行う方法その2〜ウォーターフォール開発・工数編
- RDRAで見積りを行う方法その3〜ウォーターフォール開発・工期、金額編（近日公開予定）
- RDRAで見積りを行う方法その4〜アジャイル開発（近日公開予定）
TRACERYプロダクトマネージャーの haru です。
本シリーズではここまで、RDRAによる要件定義の進め方を第1フェーズから第3フェーズまで解説してきました。
本記事では、定義したRDRAの成果物が設計プロセスにどのように引き継がれるかを整理します。
具体的には、RDRAの各成果物がクラス設計、データベース設計、画面・API・バッチ処理の設計とどのように対応するかを全体像として示します。
要件定義の目的とゴールは以下のとおりです*1。
- 要件定義の目的：「何を作るか（What）」を決めること
- 要件定義のゴール：設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること
本記事を通じて、RDRAによる要件定義が、要件定義の目的とゴールの達成に寄与することを確認できます。
- RDRAのスコープ外となる要件定義の成果物
- RDRAの成果物とクラス設計の関係
- RDRAの成果物とデータベース設計の関係
- RDRAの成果物と画面・API・バッチ処理の設計の関係
- 要件定義とソフトウェアアーキテクチャ設計
- 最後に
RDRAのスコープ外となる要件定義の成果物
RDRAの成果物と設計の対応関係を整理する前に、まずRDRAのスコープ外となる成果物を確認します。
RDRAがスコープとしない要件定義の成果物*2には、以下があります。
- 非機能要件一覧
- システム構成図（システムアーキテクチャ）
RDRAでは「非機能要求」を定義*3しますが、それを「非機能要件」へ整理するプロセスは規定されていません。
そのため、非機能要求を取捨選択し、洗練して非機能要件一覧を別途作成する必要があります。*4。
「システム構成図」は、主に非機能要件をもとに、システム全体の構造（システムアーキテクチャ）と設計方針を定めたものです。ハードウェアやソフトウェアの主要コンポーネント、それらの相互関係、通信方式、配置などが含まれます。
非機能要件とシステム構成図の作成についてさらに詳しく知りたい場合は、以下の記事を参照してください。
RDRAの成果物とクラス設計の関係
「クラス設計」は、システムが扱う情報の構造と業務上の振る舞いをクラスとして表現します。
その成果物であるクラス図は、クラスとクラス同士の関係を表したもので、業務領域（ドメイン）の知識を反映していることから、一般的に「ドメインモデル」とも呼ばれます。
RDRAの成果物のうち、クラス設計の中心となるのが「情報モデル」です。情報モデルで定義された情報の構造が、そのままクラスの骨格になります。
さらに、情報モデル以外のRDRAの要素も、クラスの属性やメソッドとして設計に反映されます。
- 状態モデル → 状態はクラスの属性として、状態を変更する振る舞いはメソッドとして設計する
- 条件（ビジネスルール） → クラスのメソッド
- バリエーション → 属性が取り得る値
このように、RDRAの各モデルや要素がクラスの構造に対応するため、要件定義からクラス設計への移行を体系的に進めることができます。
要件定義とクラス設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。
RDRAの成果物とデータベース設計の関係
「データベース設計（ER図、テーブル定義）」は、クラス図を基盤として進めます*5。クラス図で定義されたクラスのうち、永続化が必要なものをテーブルとして設計し、属性やリレーションを具体的なスキーマに落とし込みます。
データベース設計では、性能効率、データ品質、セキュリティ、保守性といった「非機能要件」を十分に考慮する必要があります。その際は「非機能要件一覧」を参照します。
データベース設計はRDRAの成果物から直接導出するものではありませんが、RDRAの情報モデル・状態モデル・バリエーションなどの要件がクラス図を経てスキーマに適切に反映されているかを確認することが重要です。
要件定義とデータベース設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。
RDRAの成果物と画面・API・バッチ処理の設計の関係
RDRAでユースケースと関連付けられた画面・イベント・タイマーが、それぞれ以下の設計の対象となります。
- 画面 → 画面設計
- イベント → API設計
- タイマー → バッチ処理設計
これらの設計では、RDRAの「条件」と「バリエーション」を参照し、業務ロジックや分岐を仕様に反映します。
また、処理で使用するデータについては、データベース設計で作成した「ER図」や「テーブル定義」を参照します。
さらに、「システム構成図」に記載された技術要素を前提とし、「非機能要件一覧」に定義された性能やセキュリティなどの非機能要件も考慮して設計します。
要件定義と画面設計、API設計、バッチ処理設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。
要件定義とソフトウェアアーキテクチャ設計
ソフトウェアアーキテクチャは、ソフトウェアシステムの全体構造と主要な設計上の決定を体系的に示したものです。
「システム構成図」で表現されるシステムアーキテクチャがハードウェア・ネットワークを含むシステム全体の構成を指すのに対し、ソフトウェアアーキテクチャはソフトウェア部分の構造や相互作用を対象にします。
RDRAとソフトウェアアーキテクチャ設計は、直接の対応関係はありません。ただし、RDRAで定義された非機能要求を整理した「非機能要件一覧」を通じて、間接的に関係します。
ソフトウェアアーキテクチャの設計では、「システム構成図」に記載されたフレームワークやミドルウェアを前提とし、「非機能要件一覧」に定義された性能やセキュリティなどの非機能要件も考慮して設計します。
要件定義とソフトウェアアーキテクチャ設計の関係をさらに詳しく知りたい場合は、以下の記事を参照してください。
最後に
本記事では、RDRAの成果物と設計プロセスの対応関係を全体像として示しました。
RDRAで定義した各成果物が、クラス設計、データベース設計、画面・API・バッチ処理の設計へと体系的に引き継がれることで、要件定義のゴールである「設計プロセスを円滑に進めるための明確で具体的なインプットを提供すること」が達成されます。
本シリーズでは、第1フェーズから第3フェーズまでのRDRAによる要件定義の進め方と、本記事での設計との連携を解説してきました。
次回は、RDRAによる要件定義をAIエージェントで支援する「RDRA Agent」を紹介します。
参考書籍
*1:詳細は、要件定義の目的とゴールとは - TRACERY Lab.（トレラボ）を参照のこと。
*2:本メディアが推奨する要件定義の成果物。なお、システム構成図は「設計」プロセスに含める場合もあるが、本メディアでは、システムの構成要素はシステム要件定義の段階で定義すべきものと考え、要件定義の成果物に含めている。詳細は、要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】 - TRACERY Lab.（トレラボ）を参照のこと。
*3:RDRA定義・分析Sheetの「非機能要求」シートに定義する。詳細は、RDRAによる要件定義の進め方〜第1フェーズ：枠組みを作る - TRACERY Lab.（トレラボ）の「機能要求、非機能要求を記載する」を参照のこと。
*4:要求と要件の違いについては、要件定義の重要ポイント〜要望・要求・要件を見極める - TRACERY Lab.（トレラボ）を参照のこと。
*5:オブジェクト指向設計を適用する場合。
