紹介文 :
　システムのディペンダビリティを説明しステークホルダ間の合意形成を行うことを目的として、D-Caseという手法が提唱されている。発表者らは2013年度にD-Caseを用いて曖昧な要求仕様を明確化することに成功し、その後も現場への適用拡大に取り組んできた。しかし、D-Caseの使いどころや論証方法が難しいという点から導入が進んでいない。
　対策として「D-Case適用ガイドライン」を策定し、プロジェクトへの適用手順を明確にした。その際、いきなりD-Caseを書き始めるのではなく、D-Case作成前のチーム議論によってプロジェクトの目的、リスク、チャレンジしたい内容をチームで共有することに重点を置いた。また、ソフトウェア開発によくある具体的なパターン（D-Case適用パターンと呼ぶ）をガイドライン中に掲載し、初めてD-Caseを作成する人の指針となるようにした。さらにD-Case適用ワークショップを開催し、開発プロジェクトごとに少人数のグループにわかれた議論を行いD-Caseを作り上げた。現在は、作成したD-Caseから導出されたタスクの実行と効果の確認を行っている。
　本発表では、D-Case適用ガイドラインの内容と適用の結果を報告する。

紹介文 :
本発表は、D-Caseをソフトウェア開発に導入した事例の紹介である。
ソフトウェアの妥当性をテストで評価するためには、期待結果が明確でなければならない。しかし、一部のソフトウェアには、期待結果を一意に決
めにくいものがある（乱数を用いたシミュレーションなど）。そのようなソフトウェアに対しては、単体テストや画面系テストなど「決めやすい」
テストは一生懸命行うが、ソフトウェアの重要な「決めにくい」部分の確認方法は明確化されず、関係者間での合意も行われないまま放置されがち
である。そして、開発後期の大きい手戻り、責任の押し付け合い、出荷後不具合を引き起こすことがある。
DEOSプロジェクトで提唱されているD-Caseは、システムのディペンダビリティについての説明責任を果たし、ステークホルダ間で合意を形成するた
めの手法である。我々はD-Caseを用いて、ソフトウェアの「決めにくい」期待結果を明確化し、関係者間の合意を行うことに成功した。本発表で
は、その経緯と成果について紹介する。