ラショナル統一プロセス(Rational Unified Process: RUP)の「ソフトウェア要求定義(Software Requirements)」のフレームワーク

ラショナル統一プロセス(Rational Unified Process: RUP)のソフトウェア要求定義(Software Requirements)は、RUPの「方向付けフェーズ」の営みを前提とした上で、テンプレート化とフレームワーク化が可能になる。「要求を束ねよ(Manage Requirements)」というRUPのベストプラクティスを前提とすれば、ソフトウェア要求定義書として網羅すべきなのは自ずと限定されてくる。以下では、まずはソフトウェア要求定義の各項目の背景知識をまとめて、その上でソフトウェア要求定義書のサンプルを提示したい。

RUPのソフトウェア要求定義で言及すべき項目

1.  問題の分析
   1. 問題領域
      1. 問題内容
      2. 問題の影響を受ける人々
      3. 問題の影響内容
      4. システムによる解決策が成功した場合
   2. 要求観点
      1. 要求抽出の対象となる顧客
      2. 顧客のニーズ
      3. システムの対象となるユーザー
      4. ユーザーのニーズ
2. 問題解決策の基本要件
   1. ソフトウェア要求
   2. システムの定義
      1. システムの範疇
      2. システムの機能
      3. 現状や競合製品
      4. 新システムの付加価値
   3. システム開発の管理
      1. 要求属性
      2. 要求属性に基づいた開発優先順位
      3. スケジュールとマイルストーン

以下では、これらの項目について、どのような論点や観点で何を記述すべきなのかについて、一つずつ補足しておく。

「問題の分析」で言及すべきこと

開発するシステムは、何らかの問題を解決する上で有用であるからこそ開発される。逆に言えば、ソフトウェアのシステム開発が要求されるということは、少なからずその背景に「問題」があるということだ。

システムは、そうした「問題」の「解決策」として要求されている。そのため、要求されているシステムを分析するには、まず「問題」を分析しなければならない。

「問題領域」で言及すべきこと

「問題」を分析するには、「問題」の「領域(domain/area)」を特定しなければならない。この「領域」を見極める上で有用となるのは、次のように、「What」や「Who」だろう。

• その「問題」の内容は何か。
• 誰がその「問題」を提起しているのか。
• その「問題」を提起した人はどういった影響を受けているのか。
• 求められる「解決策」は何か。

これをより細分化すると、上述した項目のような論点を展開していかなければならないことがわかってくる。順を追って説明していこう。

「問題内容」で言及すべきこと

その「問題」の内容は何かを特定するのが、文字通り「問題内容」の記述事項となる。この項目では、どのような「デメリット」や「リスク」や「危険」といった特徴で言い表せる状況や状態なのかを端的に列挙した方が良い。

「問題内容」の一例

• 現状の広告効果測定ツールは「サードパーティークッキー(third-party Cookie)」でエンドユーザをトラッキングしている。
• 将来各ブラウザの仕様が変更されて、デフォルトで「サードパーティークッキー」によるトラッキングを拒否するようになった場合に、エンドユーザの広告成果を測定することが困難になる。

「問題の影響を受ける人々」で言及すべきこと

ここでいう影響を受ける人々というのは、上述した「問題内容」で指し示される「デメリット」や「リスク」や「危険」の被害者や関係者を意味する。システム開発の依頼を受ける受注側のエンジニアから観れば、専ら発注者や発注者が関わるエンドユーザが、この影響を受ける人々になる。

「問題の影響を受ける人々」の一例

• 広告主
• 広告媒体の担当者
• 広告を閲覧するエンドユーザ

「問題の影響内容」で言及すべきこと

問題の影響内容では、上述した「問題の影響を受ける人々」が、「問題内容」によって、どのような被害を受けるのかを列挙する。「問題の影響を受ける人々」ごとに、「問題内容」を細分化するように列挙するとわかり易いだろう。

「問題の影響内容」の一例

• 広告主は、広告を媒体に掲載することによる費用対効果を測定できなくなる。
• 広告媒体の担当者は、自身の媒体のクリックや成果(Conversion)に関わる効果を訴求できなくなる。
• 広告を閲覧するエンドユーザは、自身で発生させた成果がその広告経由であるということを立証できなくなるために、クリックや成果に関連付けられたインセンティブを受け取れなくなる。

「システムによる解決策が成功した場合」で言及すべきこと

ここでいう「システムによる解決策」とは、新システムの開発や既存システムの改修によって実現する新機能による「メリット」や「リスクヘッジ」や「危険の回避策」を意味する。したがってこの項目では、これらの解決策が成功した場合の結果を記述することになる。

この「システムによる解決策」を明示することは、システムの範囲(Scope)を特定する上でも有用になる。もしここで取り上げる「リスクヘッジ」が「問題内容」や「問題の影響内容」で明示した「全てのリスク」に対する「リスクヘッジ」であるのならば、そう記述すれば良い。そうではないのならば、「一部のリスク」に対する「リスクヘッジ」である旨を明示すると共に、「その他のリスク」については解決しないということも明示した方が良い。

「システムによる解決策が成功した場合」の一例

• 広告主は、「サードパーティークッキー」が拒否される設定になっているブラウザを前提とした場合でも、広告を媒体に掲載することによる費用対効果を測定できるようになる。
• 広告媒体の担当者は、「サードパーティークッキー」が拒否される設定になっているブラウザを前提とした場合でも、「ファーストパーティクッキー(first-party Cookie)」によって、自身の媒体のクリックや成果(Conversion)に関わる効果を訴求できるようになる。
• 広告を閲覧するエンドユーザは、自身のブラウザで「サードパーティークッキー」を拒否する設定にしていたとしても、自身で発生させた成果がその広告経由であるということを立証できるようになるために、クリックや成果に関連付けられたインセンティブを受け取れるようになる。

「要求観点」で言及すべきこと

「要求観点」は、「要求を束ねよ(Manage Requirements)」というRUPのベストプラクティスと深く関わる。この観点において鍵となる概念は、「顧客(customer)」と「エンドユーザ(end user)」の区別を導入することによって得られる。

「要求抽出の対象となる顧客」で言及すべきこと

この項目では、要求内容のヒアリング対象を特定する。発注と受注の関係から成り立つ開発案件ならば、自ずと「要求抽出の対象となる顧客」は発注者であるということになるだろう。一方、エンジニアの側から企画立案を敢行している場合は、そのターゲットを特定しなければならない。

「要求抽出の対象となる顧客」の一例

• 株式会社○○の広告媒体担当の□□様

「顧客のニーズ」で言及すべきこと

「顧客のニーズ」では、上述した「問題の分析」の結果から得られた「問題内容」や「問題の影響内容」を前提とした上で、実際に顧客が求める問題解決の方向性を特定する。そのために、最終的にどのような問題解決に至っていれば顧客が満足するのかを記述する。

ここで威力を発揮するのが、統一モデリング言語(Unified Modeling Language: UML)の「ユースケース・モデル」であろう。RUPのベストプラクティスの一つである「ソフトウェアを視覚的にモデル化せよ(Visually Model Software)」に倣い、ユースケース図によって顧客のニーズを視覚化すると良い。顧客のニーズが業務フローと関わるのであれば、フローチャート的な視覚化を可能にするアクティビティ図が有用になるだろう。ユースケース図やアクティビティ図のようなシンプルな文法で記述された図であれば、非エンジニアであっても伝わり易い。

「顧客のニーズ」の一例

• 広告媒体の担当者は、「ファーストパーティクッキー」を前提とした計測タグを自分が運営しているWebサイトの広告枠のページに埋め込みたいと考えている。
• 広告媒体の担当者は、広告枠で掲載した広告のクリック数を計測したいと考えている。
• 広告媒体の担当者は、広告枠経由の成果発生件数を計測したいと考えている。

「システムの対象となるユーザー」で言及すべきこと

「要求観点」では、「顧客」と「エンドユーザ」の区別を導入する。発注と受注の関係で成り立った開発案件であっても、ここでいう「エンドユーザ」は必ずしも発注者たる「顧客」に等しいとは限らない。例えば発注者の発注内容が「ECサイトの制作」であるなら、そのECサイトには発注者たる「顧客」とは異なる「消費者」や「購買者」がいるはずだ。ここでいう「エンドユーザ」とは、そうした「消費者」や「購買者」も含まれる。

「システムの対象となるユーザー」の一例

• 広告閲覧者

「ユーザーのニーズ」で言及すべきこと

「顧客」と「エンドユーザ」の区別を導入すれば、「ユーザーのニーズ」が「顧客のニーズ」とは異なるということも明示的になるだろう。顧客が満足するシステムであっても、エンドユーザが満足しなければ、それは顧客の自己満足であるということになってしまう。これでは市場価値の高い商品を制作することができなくなる。

そのため、ソフトウェア要求定義を担当するエンジニアは、「顧客のニーズ」を満たすことだけに注力してはならない。むしろ積極的に「顧客のニーズ」に「ユーザーのニーズ」を対比させるような情報を「顧客」に提示することで、開発プロジェクトをより良き商品の制作へと「方向付けること」もまた、ソフトウェア要求定義の担当エンジニアの職務になる。

「顧客のニーズ」の場合と同様に、「ユーザーのニーズ」を特定する上でも、UMLが有用なツールになる。この「ユーザーのニーズ」は「顧客」にも把握しておいて貰いたい情報であるために、伝達し易いように視覚化しておいた方が良い。

「ユーザーのニーズ」の一例

• 広告閲覧者は、オプトアウトのON/OFFの切り替えができるようになることを望んでいる。
• オプトアウトをOFFにしている広告閲覧者は、成果発生に紐づいたインセンティブを獲得することを望んでいる。
• 広告閲覧者の一部は、「サードパーティークッキー」によるトラッキングを拒否したいと考えている。

「問題解決策の基本要件」で言及すべきこと

これまで言及してきたのは、専ら「問題」であった。「問題の分析」により「問題領域」や「要求観点」を特定して初めて、「問題解決策」も明確化できるようになる。この「問題解決策の基本要件」では、上述した「システムによる解決策が成功した場合」に得られる「メリット」や「リスクヘッジ」や「危険の回避」が成立する諸条件を明示していくことになる。

「ソフトウェア要求」で言及すべきこと

「ソフトウェア要求」の項目では、上述した「システムによる解決策が成功した場合」に得られる「メリット」や「リスクヘッジ」や「危険の回避」が成立する諸条件を明示することで、「推敲フェーズ」以降のアーキテクチャ設計で必要となる情報を特定することを目指す。エンジニアの観点をやや強調して記述して良い。

尚、この段階でユースケース・モデルなどによって視覚化された関連概念を「概念クラス図」や「オブジェクト図」によって整理しておくと、後述する「システムの定義」が効率良く進捗するだろう。

「ソフトウェア要求」の一例

• これまでの「サードパーティクッキー」を前提とした計測タグの場合と同様のユーザ・インターフェイスの管理画面から、「ファーストパーティクッキー」を前提とした計測タグを発行できるようにする。尚、計測タグはJavaScriptタグとする。
• Webページ上で計測タグのJavaScript関数が実行されると、当該Webページのドメインで「ファーストパーティクッキー」が発行される。
• 広告効果計測ツールは、この「ファーストパーティクッキー」の値を参照することで、エンドユーザとなる広告閲覧者の成果発生の可否を検証する。

「システムの定義」で言及すべきこと

「システムの定義」では、上述した「ソフトウェア要求」を前提として、求められる「問題解決策」を「システムによる問題解決策」として明示できるようにしていく。

「システムの範疇」で言及すべきこと

この項目では、当該開発プロジェクトで制作するシステムが、どのような位置付けにあるのかを明確にしておく。制作するシステムが既存のシステムのサブシステムであるのならば、その既存のシステムの名称を明記しておけば良い。制作するシステムが全くの新機能であるのならば、新たに命名する必要がある。

「システムの範疇」の一例

• 本開発プロジェクトで制作するシステムは、既存の広告効果測定ツールにおけるトラッキングシステムの一部となる。

「システムの機能」で言及すべきこと

「システムの機能」では、「システムによる問題解決策」を端的に列挙する。通俗的な表現で言えば、これこそが「システムの機能要件」にある。

先述したように、概念クラス図やオブジェクト図によって関連概念を整理しておけば、何が「問題」で何が「解決策」になるのかを明確化することが可能になる。特に問題が解決された状態や状況で出現する諸概念をクラス図で図示しておけば、問題解決の諸条件を特定することも容易になるだろう。

「システムの機能」の一例

• 計測タグ発行機能
• 計測タグのファーストパーティクッキー埋め込み機能
• 計測タグのファーストパーティクッキー参照機能
• 計測タグの成果発生可否判定機能
• トラッキングシステムの管理画面における計測機能

「現状と競合製品」で言及すべきこと

「現状」としては、「システムによる問題解決策」が実行される前の状況や状態を端的に列挙する。一方「競合製品」としては、既に実行されている他の「システムによる問題解決策」を列挙する。

この項目を設けることの意味は、当該開発プロジェクトの優先度を把握することにあると言える。「現状」が、「システムによる問題解決策」が実行された場合の状態や状況とあまりにも乖離している場合であれば、その「現状」は当該開発プロジェクトの優先度を高める根拠の一つになり得る。

「競合製品」の有無もまた、当該開発プロジェクトの優先度を計る尺度になるだろう。「競合製品」が追従を許さない程に先行優位性を誇っているようであれば、あえて当該開発プロジェクトの優先度を下げて、別の施策を展開するといった戦略も考慮しなければならない場合もある。

「現状と競合製品」の一例

• 現状、トラッキングシステムは「サードパーティークッキー」を前提とした計測タグを発行している。
• 既に「サードパーティークッキー」として成果をトラッキングすることを可能にしているGoogle アナリティクスが競合製品として挙げられる。

「新システムの付加価値」で言及すべきこと

この項目は、「顧客」が見出していない部分に価値を見出せる場合に、当該開発プロジェクトのソフトウェア要求定義を担当するエンジニアの側から提案する場となる。これにより、当該開発プロジェクトを土台とした別のシステム企画へと結び付けることも可能になる。

また、付加価値を提示すること自体が、当該開発プロジェクトの優先度を高める上で有用な情報提供となる。「顧客」にとっての優先順位が低ければ、その開発プロジェクトで積極的なサポートを期待することは難しくなる。付加価値の提示は、エンジニアが当該開発プロジェクトを効率的に進捗させるための布石としても役立つ。

「新システムの付加価値」の一例

• 本システムは、成果発生のトラッキング以外にも、インプレッションやクリックのトラッキングにも応用することができる。

「システム開発の管理」で言及すべきこと

この項目では、要求事項の優先順位を決定することで、システムの開発範囲を管理できるようにしておく。

「要求属性」で言及すべきこと

「要求属性」は、各機能が前提としている「問題」と「解決策」を再度振り返ることで、次の三つの観点から比較可能な状態にする。

1. 「解決の優先度」
2. 「解決策の作業量」
3. 「解決に伴うリスク」

これら三つの指標に関して、「高」、「中」、「低」などといった簡易的なカテゴライズにより、「重み付け」を実施しておく。

「要求属性」の一例

 

「要求属性に基づいた開発優先順位」で言及すべきこと

この項目では、上述した「要求属性」の「重み付け」によって、各機能の実施優先度を列挙していく。「高」、「中」、「低」などといった簡易的なカテゴライズを前提とするなら、例えば「高」が多い機能から先に片付けておくといった観点から優先順位を判断することが可能であろう。

「要求属性に基づいた開発優先順位」の一例

1. 計測タグのファーストパーティクッキー埋め込み機能
2. 計測タグの成果発生可否判定機能
3. 計測タグのファーストパーティクッキー参照機能
4. トラッキングシステムの管理画面における計測機能
5. 計測タグ発行機能

「スケジュールとマイルストーン」で言及すべきこと

この項目では、文字通りスケジュールとマイルストーンを明示する。Work Breakdown Structure(WBS)のような方法やRedmineのようなスケジュール管理ツールで管理する予定であれば、そのURLやパスを記載するだけでも構わない。

 

まとめ

以上のように、RUPのソフトウェア要求定義は「問題」の設定から「問題解決策」の設定までの営みをユースケース・モデルで実践していく営みとなる。ソフトウェア要求定義を担当するエンジニアは、常に顧客やエンドユーザが「問題」を抱えているからこそ「問題解決策」としての「システム」が要求されているということを認識しておかなければならない。如何に優れたシステムを制作したところで、顧客やエンドユーザが抱えている「問題」に対する「問題解決策」として機能しなければ、価値としては認められない。

以下では、上述したソフトウェア要求定義の各項目の背景知識を前提に、ソフトウェア要求定義の一例をテンプレートとして掲載する。サンプルであるため、簡潔な内容となっている。実際の業務で作成するソフトウェア要求定義書ならばもう少し踏み込んだ内容になるだろう。

 

（サンプル）既存トラッキングシステムのファーストパーティクッキー対応に関するソフトウェア要求定義書

1.  問題の分析
   1. 問題領域
      1. 問題内容
      2. 問題の影響を受ける人々
      3. 問題の影響内容
      4. システムによる解決策が成功した場合
   2. 要求観点
      1. 要求抽出の対象となる顧客
      2. 顧客のニーズ
      3. システムの対象となるユーザー
      4. ユーザーのニーズ
2. 問題解決策の基本要件
   1. ソフトウェア要求
   2. システムの定義
      1. システムの範疇
      2. システムの機能
      3. 現状や競合製品
      4. 新システムの付加価値
   3. システム開発の管理
      1. 要求属性
      2. 要求属性に基づいた開発優先順位
      3. スケジュールとマイルストーン

以下では、これらの項目について詳述していく。

問題の分析

問題領域

問題内容

• 現状の広告効果測定ツールは「サードパーティークッキー(third-party Cookie)」でエンドユーザをトラッキングしている。
• 将来各ブラウザの仕様が変更されて、デフォルトで「サードパーティークッキー」によるトラッキングを拒否するようになった場合に、エンドユーザの広告成果を測定することが困難になる。

問題の影響を受ける人々

• 広告主
• 広告媒体の担当者
• 広告を閲覧するエンドユーザ

問題の影響内容

• 広告主は、広告を媒体に掲載することによる費用対効果を測定できなくなる。
• 広告媒体の担当者は、自身の媒体のクリックや成果(Conversion)に関わる効果を訴求できなくなる。
• 広告を閲覧するエンドユーザは、自身で発生させた成果がその広告経由であるということを立証できなくなるために、クリックや成果に関連付けられたインセンティブを受け取れなくなる。

システムによる解決策が成功した場合

• 広告主は、「サードパーティークッキー」が拒否される設定になっているブラウザを前提とした場合でも、広告を媒体に掲載することによる費用対効果を測定できるようになる。
• 広告媒体の担当者は、「サードパーティークッキー」が拒否される設定になっているブラウザを前提とした場合でも、「ファーストパーティクッキー(first-party Cookie)」によって、自身の媒体のクリックや成果(Conversion)に関わる効果を訴求できるようになる。
• 広告を閲覧するエンドユーザは、自身のブラウザで「サードパーティークッキー」を拒否する設定にしていたとしても、自身で発生させた成果がその広告経由であるということを立証できるようになるために、クリックや成果に関連付けられたインセンティブを受け取れるようになる。

要求観点

要求抽出の対象となる顧客

• 株式会社○○の広告媒体担当の□□様

顧客のニーズ

• 広告媒体の担当者は、「ファーストパーティクッキー」を前提とした計測タグを自分が運営しているWebサイトの広告枠のページに埋め込みたいと考えている。
• 広告媒体の担当者は、広告枠で掲載した広告のクリック数を計測したいと考えている。
• 広告媒体の担当者は、広告枠経由の成果発生件数を計測したいと考えている。

システムの対象となるユーザー

• 広告閲覧者

ユーザーのニーズ

• 広告閲覧者は、オプトアウトのON/OFFの切り替えができるようになることを望んでいる。
• オプトアウトをOFFにしている広告閲覧者は、成果発生に紐づいたインセンティブを獲得することを望んでいる。
• 広告閲覧者の一部は、「サードパーティークッキー」によるトラッキングを拒否したいと考えている。

問題解決策の基本要件

ソフトウェア要求

• これまでの「サードパーティクッキー」を前提とした計測タグの場合と同様のユーザ・インターフェイスの管理画面から、「ファーストパーティクッキー」を前提とした計測タグを発行できるようにする。尚、計測タグはJavaScriptタグとする。
• Webページ上で計測タグのJavaScript関数が実行されると、当該Webページのドメインで「ファーストパーティクッキー」が発行される。
• 広告効果計測ツールは、この「ファーストパーティクッキー」の値を参照することで、エンドユーザとなる広告閲覧者の成果発生の可否を検証する。

システムの定義

システムの範疇

• 本開発プロジェクトで制作するシステムは、既存の広告効果測定ツールにおけるトラッキングシステムの一部となる。

システムの機能

• 計測タグ発行機能
• 計測タグのファーストパーティクッキー埋め込み機能
• 計測タグのファーストパーティクッキー参照機能
• 計測タグの成果発生可否判定機能
• トラッキングシステムの管理画面における計測機能

現状と競合製品

• 現状、トラッキングシステムは「サードパーティークッキー」を前提とした計測タグを発行している。
• 既に「サードパーティークッキー」として成果をトラッキングすることを可能にしているGoogle アナリティクスが競合製品として挙げられる。

新システムの付加価値

• 本システムは、成果発生のトラッキング以外にも、インプレッションやクリックのトラッキングにも応用することができる。

システム開発の管理

要求属性

要求属性に基づいた開発優先順位

1. 計測タグのファーストパーティクッキー埋め込み機能
2. 計測タグの成果発生可否判定機能
3. 計測タグのファーストパーティクッキー参照機能
4. トラッキングシステムの管理画面における計測機能
5. 計測タグ発行機能

スケジュールとマイルストーン

別途、Redmineで管理していく。