シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する（本記事）
- 要件定義とソフトウェアアーキテクチャ設計
TRACERYプロダクトマネージャーの haru です。
要件定義のゴールは、設計の精度を高めるためのインプットとなる成果物を作成することです。適切な成果物があれば、設計工程での手戻りを減らし、スムーズなシステム開発につながります。
本記事では、システム要件定義の成果物を整理し、設計に活用できる形でまとめます。
開発品目の一覧と機能要件、非機能要件
ユースケースとロバストネス図によるシステム要件定義 - TRACERY Lab.（トレラボ）では、ロバストネス図から開発対象の品目と機能要件、非機能要件を抽出しました。
開発品目や機能要件は一覧表にまとめると、開発管理や見積りにも活用できます（非機能要件については後述）。
| 種類 | 開発品目 | 機能要件 |
|---|---|---|
| 画面 | 売上ダッシュボード画面 | ・日別の売上推移、商品別売上、地域別売上を表示できる ・期間、商品の検索条件を指定できる ・システムにログインしているユーザーのみ参照可能 ・閲覧履歴がシステムに記録される。 |
| API | 売上データ抽出*1 | ・日別に集計した売上データを、検索条件に従って出力する |
| API | 売上レポートPDF出力 | ・売上ダッシュボード画面の簡易版をPDF形式でダウンロードできる ・出力項目は売上ダッシュボード画面の項目とする |
| バッチ処理 | 売上データ集計処理 | ・売上ダッシュボード画面に表示するデータを定期的に作成する |
非機能要件
ユースケースとロバストネス図によるシステム要件定義 - TRACERY Lab.（トレラボ）では、以下の非機能要件*2を抽出しました。
- 画面表示は3秒以内
- 売上ダッシュボードに表示するデータは1日ごとに最新化される
機能要件は各機能ごとに定義されるのに対し、非機能要件はシステム全体に共通するものとして定義されるのが特徴です。ただし、すべての非機能要件がシステム全体に適用されるわけではありません。
上記の非機能要件は、売上ダッシュボード表示という機能をもとに抽出されたものですが、それがシステム全体に適用されるのか、あるいは特定の機能に限定されるのかを慎重に判断する必要があります。
例えば、応答時間の要件は全システム共通かもしれませんが、データ更新頻度の要件はダッシュボード特有のものかもしれません。こうした点を考慮し、システム全体に適用すべき非機能要件と、特定の機能にのみ適用されるものを明確に分類し、リストアップしましょう。
IPAの非機能要求グレード
システム全体に共通する非機能要件を明らかにしていくには、IPAが提供している非機能要求グレードが有用です。非機能要求グレードは、システムの品質特性を明確にし、適切な要件定義を行うための指針となります。
このグレードでは、性能、可用性、セキュリティ、運用管理などの観点から非機能要件を分類し、それぞれに求められる水準を定めています。
概念モデル
概念モデル（Conceptual Model）は、システム開発において業務の本質的な構造や概念を可視化するためのモデルです。
業務領域の主要な概念（エンティティ）とその関係性を整理し、ステークホルダー間で共通認識を持つために活用されます。
ロバストネス図から抽出したエンティティを整理し、エンティティ間の関係を明確にすることで、概念モデルを構築できます。
システム構成図
システム構成図とは、システム全体の構造や各コンポーネントの関係（システムアーキテクチャ）を視覚的に表現した図です。ハードウェア、ソフトウェア、ネットワークなどの要素とその関係性を図示します。
システム構成図を作成するにはさまざまな表記法がありますが、ここではUMLの配置図（Deployment Diagram）*3を使用します（下図）。
機能要件と非機能要件を実現するための適切なシステム構成を検討し、その結果をシステム構成図として作成します。
最後に
下図に、システム要件定義の成果物の関係をまとめました（下図）。
システム要件定義の成果物として以下を作成しました。
- ユースケース
- ロバストネス図
- 開発品目の一覧、機能要件、非機能要件
- システム構成図
- 概念モデル
これらの成果物を元に、システムやソフトウェアの設計を進めることができます*4。
要件は一度で確定するものではなく、議論を重ねる中で決まっていきます。その際、「要望・要求・要件」と「事業・業務・システム」の観点から整理するとよいでしょう。各観点の詳細については、以下の記事を参照してください。
- 要望、要求、要件
- 事業、業務、システム
次回は、システム要件定義で作成した成果物とソフトウェアアーキテクチャ設計の関係について解説します。
*1:画面からアクセスする内部API（外部システムからのエンドポイントではなく、画面からのみアクセスされるもの）について、前記事のロバストネス図上では「バウンダリ」ではなく「コントロール」として表現されている。筆者としては、内部APIを「コントロール」として扱ってよいと考えている（バウンダリでも良い）。
*2:システムの動作や性能、品質に関する要件のこと。機能要件が「システムが何をするか」に焦点を当てるのに対して、非機能要件は「システムがどのようにそれをするか」に焦点を当てる。セキュリティ、性能、信頼性、可用性、保守性、ユーザビリティ、互換性、移植性、法令遵守などがある。
*3:システムがどのようなハードウェア環境（ノード）で構成され、ソフトウェアコンポーネントがどのように配置（デプロイ、インストール）されるかを視覚的に表現する図。主に、システムの物理的な構成や、ソフトウェアのデプロイメント（展開）を明確にするために使用される。
*4:開発対象のシステムによっては、要件定義で複雑なビジネスロジックやデータの状態遷移を整理し、明確にする必要があります。しかし、これらの説明は複雑になるため、本連載「要件定義とはそもそも何か」では割愛します。
