はじめに
「上流工程で作成するドキュメント」というとWordやExcelなどを使い、自然言語（文章など）で表したものをイメージすると思います。しかし、昔から自然言語での表現はあいまいになることが多く、仕様としては適さないことが指摘されています。
皆さんも過去に意味不明な要件定義書を受け取ったことや、「いろいろ書いてあるけど重要なのはたった1行だった」あるいは粒度がバラバラで統一感のないものなどさまざまな要件定義書を見てきたと思います。
前回は要件定義には構造があり、その構造を使うことで要件をスムーズに定義できることを紹介しました。今回はその構造に沿った具体的な定義の方法をご紹介します。
リレーションシップ駆動要件分析（RDRA）は、その名のとおりリレーションシップが重要な意味を持ちます。その情報のつながりを直接表現できる図的な方法としてUMLを使います。
UMLを使って要件を定義する
視点ごとの情報を理解する
視点ごとの情報を整理する
先の記事で示したとおり要件定義には4つの視点があり、各々の視点には定義すべき情報が決まっています。その情報をUMLを使ってモデルとして表現し、そのまま要件定義書とします。情報のつながり方を見ることで言葉を使わなくても意味を表すことができます。
図解することの利点はそれだけではありません。理解が容易で、議論しながら定義できます。UMLを使って考えを伝え、共有し、議論の結果をそのままドキュメントとすることで、UMLがコミュニケーションツールとなります。
考えていることを表現し、議論することが第1の目的ですからUMLの表記法に厳密に従うよりは図として対象を共有することを優先します。従って、要件定義として表現したいことであればUMLの表記法にとらわれずに自由に表現することが大事です。
図1はRDRAで使用するダイアグラム（モデルごとの四角のアイコン）を4つの視点に当てはめたものです。各々のダイアグラムが要件定義の情報を表します。「業務＆UC」は業務フローにユースケースを結びつけたダイアグラムですが、このような点線のダイアグラムは必要な場合にだけ一時的に作成するダイアグラムです。
以下に4つの視点ごとのダイアグラム作成のポイントを示します。
システム価値
システム価値の視点ではコンテキストモデルと要求モデルを作成し、以下の質問に答えます。
- このシステムから価値を得る人と外部のシステムは何ですか？
- システムに関わる人はどのような要求を持っていますか？
- システム化の目的・価値は何ですか？
この質問に答えるために「コンテキストモデル」と「要求モデル」を作成します。
コンテキストモデルはシステムに関係する人と外部システムを記述し、システムの目的も明らかにします。この一枚のモデルでシステムに関わる対象と、システム化の価値・目的が明らかになり、要件定義の出発点になります。
要求モデルでシステム化の方向性を明らかにします。そのために要求の粒度を揃え構造化し、本質的な要求と具体的で明確な要求の両方を明らかにします。
アクターと要求を結びつけることで、アクター別の要求のばらつきや要求漏れを把握することができます。
RDRAでは要求を「要望」「要求」「要件」の3つに分けることを推奨しています。そして「要求」についてはさらに「機能要求」と「非機能要求」に分けます。
