USDMで仕様書を書いてみた

「強いプログラミングを作るテクニックを学ぶ」の連載3回目で、『要求分析の重要さと難しさ』というサブタイトルで、要求仕様の分析について取り上げました。その中で、USDM(*)という仕様書の表記をご紹介しました。
　※ LEDキューブシステムUSDM版仕様書　>> Download ： specofledcube_specusdm_v1a.xls

このUSDM版仕様書をご覧になった皆さんは、どう思われたでしょう？
私も当初は、ドキュメント形態として重くて面倒だな．．．と思っていました。その後、いろいろ試す中で、USDMを使うのも悪くないなと思うようになりました。その理由を、3つばかりご紹介しておきます。

【こんな時に、USDM作ってみてよかったと思った】

(1)　仕様理解のために使う
連載本編でもこの方法をご紹介しました。
以前から、仕様書を読んでQ&Aシートを毎回作っていましたが、それでも理解の漏れ、勘違いはあります。USDM表記法に則り、理由を考えて要求・仕様を埋める。Defaultや、異常系など、各要求項目に対して決まったルールで仕様を確認する。などにより、抜け漏れ、勘違いのフォローができました。
... 気が向いたら、Interface誌 3月号で詳細は読んでみてね。

(2)　仕様に対する確認用に使う
実は、これが一番のおすすめポイントだと思ってます。
ご紹介したUSDM仕様書、CQ出版さんのサイトからダウンロードすると、各仕様項目のところに3つのチェックボックスが点いている事に気づいた方いらっしゃいますでしょうか？　これは、後工程での確認用に作ったものなのです。

●仕様の確認で1コ目にチェック
要求元と仕様の確認ができたところで、確認済みのチェックを入れます。仕様未定の部分があれば、次工程に進めるために必要な仮仕様を書いて、チェックボックスには“未”の印をつけておきます。そうすることで、この仕様に絡む箇所は、後で仕様変更がでてくる可能性があることが見て取れます。

●設計レビューで２コ目にチェック
（基本設計などのレベルではなく、）実装目前の設計レビューでチェックを入れます。
これについては、” (3) 保守・派生開発時のベース資料 ”↓ のほうで詳しく説明します。

●テスト設計で3コ目にチェック
どの仕様に対して、テスト設計してテストケースを作成したかを確認した時点で、チェックを入れます。

(3) 保守・派生開発時の資料として使う
一旦作ったシステムも、保守・派生開発時には、システムの設計を知るための資料が必要です。それを、このUSDM仕様書に情報を付加して使えるようにしようというものです。

仕様項目の横に、設計した結果、どこでその項目が実現されているのかを、印を付けていきます。
つまり、XDDP(**)で言うところのTM（Traceability Matrix）を作ってしまうのです。設計段階でこのマトリクスを作ってしまえば、後の保守・派生開発時には、これがそのまま影響範囲分析、変更設計のための調査資料として使えます。

また、この方法で仕様と実装の関連を残していくと、凝集度の悪い設計箇所があれば、一つの機能に対し沢山の実装箇所に印が付くことになります。そういった目線で、設計結果を確認することで、設計品質を確かめるためのレビュー資料としても使えます。

USDMの仕様記述は、確かに大変です。
折角手を掛けた仕様書ですから、やはり2度、3度これを使いまわさないと、作った効果は薄いと思います。

．．．とはいえ、現状のUSDMでは、未だに気になっているところもあります。
　・EXCELはやっぱり使いにくい
　・仕様項目間の依存関係が表せない
その辺は自作でツールをつくるなど、改善策を考える必要がありそうです。

しかし、今手持ちのツールですぐに試せる方法です。設計品質をあげるにはどうしたら．．．　っと、手をこまねいて悩んでいるのだったら、お試ししてみるのもありだと思います。

最後に、
Interface誌に掲載するに当たり、USDM版仕様書の作成についてご指導いただきました清水吉男さんに感謝いたします！！　ありがとうございました。

(*) USDM ： (Universal Specification Describing Manner)　抜け漏れしにくい仕様書の表記法
　　　関連書籍　『要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?』
(**) XDDP： （eXtreme Derivative Development Process）　派生開発に特化したプロセス
　　　関連書籍　『「派生開発」を成功させるプロセス改善の技術と極意』

※　関連記事：　Interface 2011年3月号