9. FAQ(よくある質問)

1. ゴールは命題の形をしていなくてはいけない

ゴールを、戦略ノードを通してサブゴールに分解するとき、分解の仕方が複数考えられる場合が多い。例えば、あるシステムのディペンダビリティを議論する場合、まずそのシステムの機能毎に分けて議論し、それぞれの機能ごとにリスクに対処できることを議論するか、あるいはまずリスクごとに議論し、それぞれのリスクごとに、関係する機能がそのリスクに対処できることを議論してもよい。また、システムのライフサイクルで生成されるドキュメントの中で、どのドキュメントに着目するかで、議論の構造は大きく変わりうる。例えば、ウエブサーバのD-Caseを記述するとき、「アーキテクチャ設計文書」にまず着目し、ウエブサーバ、アプリケーションサーバ、データベースサーバごとに分けて議論することもできる。あるいは「SLA文書」に着目し、SLAとして要求されている項目ごとに議論することもできる。ディペンダビリティケースの現在の研究においては、サブゴールをどのように分けるべきか、明確な基準を定義するに至っていない。ここでは、当たり前であるが、これまで考えてきた基準を示す。
D-Caseを見せる人の立場にたって、議論構造、内容を考える。
 D-Caseを用いて利害関係者に説明するとき、その利害関係者が理解できない、興味がないことを説明しても理解は得られない。例えば、相手企業の上層部の人に対して、システムの技術の詳細を説明しても仕方がない場合がある。上層部の人に対しては、システムのディペンダビリティ要件(SLA文書など)がサブゴールごとに議論されているトップレベルの議論構造を見せ、詳細は省くなど、工夫したほうがよい。逆に、相手企業の技術部門の人に対しては、システムの技術的詳細に関するD-Caseを示し、その技術が関わるディペンダビリティ要件が適切なテストやベンチマークによって達成されていることを議論したほうがよい。そしてトップレベルの議論構造と、技術的詳細を説明する部分がつながり、一つのD-Caseを構成するのが理想である。
システムのディペンダビリティにとって重要なものから議論する。
 システムのディペンダビリティは、システムライフサイクルで生成されるすべてのドキュメントに関係しうる。それらすべてのドキュメントを用いてD-Caseを記述すると、D-Caseは巨大になりすぎるかもしれない。まずシステムのディペンダビリティを考える上で、重要な観点(運用ワークフローに沿った観点など)を決め、それに従って議論を展開し、必要なドキュメントを選びながらD-Caseを作っていったほうがよい。

2. D-Caseと既存ドキュメントの違いについて

よく聞かれる質問である。基本的には、D-Caseは既存のリスク分析解析ドキュメントや、仕様書を置き換えるものではない。D-Caseは既存ドキュメントを参照し、あるいは既存ドキュメントを展開して構成される、ディペンダビリティを保証するドキュメントである(図1)。

3. D-Caseと他のゴール指向要求分析手法との違いについて

D-Caseはゴール指向要求分析手法の一種にもクラス分けされうる。他のゴール指向要求分析手法との違いは、簡単には以下のようにまとめられる。
目的
  • D-Case: システムのディペンダビリティの確認、保証
  • 他の手法:要求されるゴールを達成するための手段などの分析
ゴールの分解の仕方
  • D-Case: 複数あり、分解の観点が重要
  • 他の手法:分解の観点はほぼ1通り
しかしながら、木構造であることは同じであり、厳密に他の手法と分けることは難しいかも知れない。D-Caseと全く同一なドキュメントはこれまで使ったことがないと企業の方からよく聞く。システムのディペンダビリティの観点から、様々なドキュメントをまとめ、対象とする利害関係者に対して、理解が得られるようにわかりやすく説明するためのドキュメントがD-Caseである。

 ゴールの分け方、議論構造の決め方などは、一意に決められるものではない。我々は、これまでの記述実験を通して、システム領域ごとに適切なサブゴールの分け方、議論構造を考えてきており、だいぶまとまってきた。今後それらをまとめ、公開していく予定である。他の手法との利用用途の違いを明確にし、他の手法とうまく組み合わせた手法などに、D-Case手法を発展させていきたい。