はじめに
派生開発カンファレンス2022で、「D-Case記法を応用した変更要求仕様書の提案」というタイトルで発表をさせていただいた。
発表を通して、得られた知見を記録しておく。
発表資料
発表内容の概要
状況
我々のプロジェクトでは，派生開発において，仕様の漏れ・誤りによる不具合の流出を防ぐため，USDM（変更要求仕様書）を導入した．
要求と仕様を階層構造で表現したことで，レビューで変更仕様の漏れ・誤りを検出できるようになった．
しかし，レビューで変更仕様の漏れを見逃す事例を，完全になくすことはできなかった．
問題
変更要求仕様書には，変更要求から変更仕様を特定した根拠が明確に示されていなかったため，部分理解の状態のレビューアでは，問題を検出することは難しい．
フォース（制約）
- 変更要求仕様書を導入済みのプロジェクトでの改善である．
- レビューアも部分理解の状態である．
- レビューアは，D-Caseのトレーニングを受講し，実開発でD-Caseを利用した経験あり．
解決策
D-Case記法を参考に，要求と仕様の階層構造に，「戦略」と「前提」を要素として加える．
具体的には，変更要求仕様書に分析結果欄を設け，「何をもとに，どのようにして，その変更仕様を特定したか」を示すルールとした．
発表へのフィードバックから得た知見
- 「どうしてそのような方法で仕様を抽出するのですか？納得できません。」というような以下の質問があった。こういった質問（＝議論）があったのは良かった。こういった議論を生み出すことが、今回の工夫の目的であるため。
- どうして要因から仕様を考えるのですか？ 送信失敗という対象条件を検知する方が自然に思えるのですが。
- 派生開発では対象ソフトウェアの振る舞いを理解する際に元の仕様だけでなくそれに基づくテストの結果も見る必要があると思います。
- ソースコードが「完成していた」というご説明は理解できませんでした。必要な変更は必要箇所に施すものだと思っているためです。
- 変更要求仕様書の書き方に関する指摘
- 例が、変更要求仕様書（変更要求、変更仕様）の記述になっていない。機能仕様書の書き方になっている。
- 変更仕様は、仕様になっていない。
- よかったとコメントいただいたこと
- レビューのベースが明確になるのはとても良いと思います。
- 変更の戦略を検討するという発想はいいですね。
- 仕様がどうやってこのような仕様になっているのかわからない場合があり、前提条件などが書かれていると良いか悪いかレビュー出来るようになってよいと思いました。作った当時よりも後から振り返って見たときにも有益な情報かなとも思いました。
- 要望をいただいたこと
- 追加で記載することは負荷が増えると考える。定量的な費用対効果を知りたい。
- D-Caseを知らなくても前提など不明点の記載していけば良いと思った。D-Caseを理解しているとない場合での違い(D-Caseのよさ)はあるか知りたい。
- D-Case以外のフレームワークを変更要求仕様書に組み込むことでも効果がでないか知りたい。
- 今後に向けて示唆をいただいたこと
- 変更の方針、戦略を変更要求にもとづいて、議論（レビュー）するプロセスを設計するのがよさそう。
関連記事