ICTソリューション総合誌　月刊ビジネスコミュニケーション

ホーム >  要求工学 >  2006年4月号 >  第18回：ゴール分析 応用編つづき  前へ  1  2  3 

RPPG-10（消費者に対する説明及び情報提供）

【記述】

事業者、事業者団体及び政府機関等の関係機関は、電子タグの利用目的、性質、そのメリット・デメリット等に関して、消費者が正しい知識を持ち、自ら電子タグの取扱いについて意思決定ができるよう、情報提供を行う等、消費者の電子タグに対する理解を助けるよう努める必要がある。

【分析のポイント】

最終的な目的はどこにあるかと考えると、「電子タグの利用目的、性質、そのメリット・デメリット等に関して、消費者が正しい知識を持ち、自ら電子タグの取扱いについて意思決定できる」ようにすることだと考えられる。さらにこの中で、「消費者が正しい知識を持つ」ことと「電子タグの取扱いについて意思決定できる」ことが並列に存在できると考えると、この２つが親ゴールになる。

次に「情報提供を行う等、消費者の電子タグに対する理解を助けるよう努める」という箇所を検討すると、「情報提供を行う」のは「消費者の電子タグに対する理解を助ける」ための手段だと考えられる。したがって、サブゴールは「消費者の電子タグに対する理解を助ける」となり、そのサブゴールが「電子タグに関する情報提供を行う」ことになる。

【ゴール図】

RPPG-10に対するゴール図を図６に示す。親ゴールは「消費者が正しい知識を持つようにする」ことと「消費者が電子タグの取り扱いについて意思決定できるようにする」ことである。サブゴールは「消費者の電子タグに対する理解を助ける」ことで、その手段が「電子タグに関する情報提供を行う」ことになる。

ソフトゴールの分類

チャンらのNFRフレームワーク[2]では、ソフトゴールを３種類に分類している（表２）。

・非機能型ソフトゴール

システム全体に対する制約を与える。

例:顧客を正確に管理する

・操作型ソフトゴール

非機能型ソフトゴールを実現する手段となる。

例：顧客を識別するための索引を用意する

・主張型ソフトゴール

意思決定に関する根拠となる理由を提示する。

例：プラチナ顧客は重要である

操作型ゴールの場合、ゴールが達成されているかいないかが明確に判定できる必要がある。たとえば、「情報を提供する」「～表示する」とか、「～保護する」といったソフトゴールは操作型でもよいかもしれない。

これに対して、「理解を助ける」「正しい知識を持つようにする」「意思決定できるようにする」などは、ゴールの達成条件があいまいなので、非機能型である。

主張型ゴールの例としてはRPPG-6の「電子タグに記録された情報を個人情報保護法上の個人情報として扱う」があった。

ゴール図の効果

ゴール図を描いていて気づいた点として、ガイドラインのタイトルのつけ方に「目的」の場合と「手段」の場合があることと、本文の記述の中に「目的」が記述されている場合とそうでない場合があることが挙げられる。幸いにして、今回の場合には目的がタイトルもしくは本文のどちらかに記述されていたので判読できたけれども、もしタイトルと内容の両方に手段しか記述されていなければ、ゴールを発見することは困難だっただろう。逆に言えば、ゴール図を描くことでこのような仕様の欠陥を発見できることになる。要求仕様書の視点から考えると、タイトルや本文を記述する上で、目的あるいは手段のどちらを記述するのかを予め記述要領で規定しておくことが重要だ。

また、本文の中に問題点が記述されている場合にも、目的の記述を見失いやすいことがある。問題点についてはゴール図では表現しないので、この点が少しわかりにくいかもしれない。あえて描くとするなら図７に示したように、主張型ゴールとして問題を記述することができるだろう。なぜそのゴールが必要なのかを問題点を明記することにより、理由を説明できるからだ。

今回は前回に引き続き、ゴール分析手法で電子タグプライバシーガイドラインを具体的に分析した。読者の皆さんが想像していたゴール図と比べてどうだったであろうか？

ゴール図は簡単だと思われただろうか？やはりとっつきにくいものだと思われただろうか？もし前者であれば幸いだ。

要求定義ではソフトウェアが何をすべきかを記述する。なぜソフトウェアが必要なのかを明らかにするのが、ゴール分析だ。最近の要求工学ではゴール指向要求工学（GORE, Goal Oriented Requirements Engineering）が盛んに研究されている。ぜひ修得していただきたい技術のひとつだ。

参考文献

• [1]総務省・経済産業省：
  http://www.soumu.go.jp/s-news/2004/pdf/040608_4_b.pdf
• [2] Lawrence Chung, Brian Nixon,Eric Yu, John Mylopoulos, Non-Functional Requirements In Software Engineering, Kluwer Academic Publishers, 2000.