はじめに
清水吉男さんの書籍・講演で、USDMを知り、開発で取り入れています。
私のプロジェクトでは、USDMにひと工夫を入れ、効果があるなぁと感じたので、そのひと工夫をまとめておきます。
USDMとは
-
清水吉男，「派生開発の混乱を救う「XDDP」（eXtreme Derivative Development Process）」
http://www.juse-sqip.jp/vol10/qualityone_01.html -
清水吉男，「要求仕様記述手法「USDM」ってどんなの？ ～明日から使えるUSDMのエッセンス～」
https://swquality.jp/temp/nagasakiqdg15_usdm.pdf
私達のプロジェクトの問題・課題
問題
要求に対して、仕様が過不足ないか確認しにくい。
課題
「要求に対して、仕様が過不足ないか」を確認しやすくするために、USDMにひと工夫する。
先行研究：D-Case
-
小林展英，「D-Case入門」，Embedded Technology WEST 2015，2015
https://www.ipa.go.jp/files/000046847.pdf -
小林展英，「D-Caseを用いたレビューを見える化する方法の導入事例」，12th WOCS2，2015
https://www.ipa.go.jp/files/000043911.pdf -
「D-Caseとは」
http://www.dcase.jp/p/jintro3.html -
D-Case部会，「はじめてのD-Case」，一般社団法人 ディペンダビリティ技術推進協会，2018
http://dimensions-japan.org/dcase/pdf/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AED-Case.pdf
D-Caseのイメージ
ひと工夫
D-Caseの考え方を応用し、USDMにひと工夫を加える。
「どうやって、その要求から、その仕様が特定したか」を示す、前提と説明をUSDMの要素に加える。
「前提」と「説明」をセットで、「分析結果」という。
要求から下位要求に分解するときにも、必要に応じて「分析結果」を示す。
ひと工夫したUSDMの形式
分析結果は、調査結果などが示された別ファイル・別シートへのリンクとすることが多い。
効果
「分析結果」欄を導入し、「分析結果」が見えるようになり、レビューで以下に気づけるようになった。
- 分析結果がそもそもない
- 分析結果に問題がある
レビューでの指摘をもとに、分析結果を見直すことで、仕様の漏れを検出することができた。
関連研究
- 永山辰巳，「IEC62853と派生開発」，2019
https://www.juse.jp/sqip/symposium/archive/2019/day1/files/E1-3_happyou.pdf
http://deos.or.jp/link/obj/pdf/SYMPOSIUM_20190611_D-ADD.pdf
その他のUSDMに関する知見
教えていただいたこと
清水吉男さんと古畑慶次さんからお聞きしたこと。
- 関係者で同じ認識が持てれば、仕様の表現としては十分。関係者の持っている前提知識によって、最適な仕様書は変わる。
- 環境変化や制約も要求の１つとして捉える。
- 機能は、入力-変換-出力で表現できる。
- 要求は階層化する、仕様はグループ化する。
- 追加、変更、移植の３つで、プロセスは変えるべき/プロセスは変わる。
自分で感じたこと
- USDMは縦に視点を広げやすい。視点を横に広げるにはUSDM以外の手法も組み合わせたほうがいいかも。
関連記事