仕様書の書き方 ３

若手SEのためのシステム設計の考え方―システム企画から要件定義、システム設計書の作成まで

モジュール仕様書について、もう少し詳しく書いておこうかと…。

具体的な構成は以下の様になります。

(1)機能概要
(2)インタフェース仕様
(3)動作仕様
(4)エラーケース
(5)テーブル構造

まあ、こんな感じで、機能概要はそのままですね。インタフェース仕様というのは、この機能を、他の機能ブロックから使った時の入力と出力、呼び出す関数をまとめた物です。これをモノの本では、外部I/F仕様とか言って、別のドキュメントにまとめたりしています。

ところで「外部」ってなんだ～っ！？って気がしません？"外部" からのインタフェースって事なんでしょうが、インタフェースって外部からでしょう。普通。なんか気持ち悪くて、私はこの言葉を使えません。

動作仕様。ここはそのモジュールの動作の仕様を書きます。状態遷移図とか、状態遷移表とか、フローチャートとかを必要に応じて書きます。例えば状態の無いモデルなのに、状態遷移図なんて書けませんよね。あと、フローチャートは細かく書きすぎるとそのままソースコードになってしまうので、あまり詳しく書かなかったりします。でも書かないよりは、書いた方が良いと思います。

エラーケース。異常な処理、他のモジュールのエラー終了とかが返って来た時の振る舞いをまとめます。

テーブル構造は使ってるグローバル変数とか、他のモジュールが参照するテーブルとか、そんなのをまとめたものです。

と、一応これだけ書けば最低限の材料は揃ったって感じなんですよね。本当はここから実際のコードに近付ける為に、定義、定義を繰り返していくのですが、さすがに端折っています。適当にやっていると、仕様書からかけ離れたものがコードとして、生まれてくる事がありますんで、出来るだけその距離が開かない事を意識して書くというのが、必要なのかなぁ…と。そう思います。

んで、最後になりますけど、多分一番重要なのは、なんの為に仕様書を書くのか？残しておくのか？って事を考えて書く事が重要だと思います。それは、顧客の要望を具体的な仕様に定義するための要求仕様書だったり、レビューを行う為の機能仕様書だったり、自分の中で構造や設計をハッキリさせる為の詳細設計書、構造設計書だったりするので、きっと仕様書とは、あるフォーマットにしたがって記述すれば、それなりのものが出来上がるというものでは無いと、今は、感じます。

書き方について語ってきたのに、最終的には、そんなところです…。

・ソフトウェア開発 で伸びる人、伸びない人 (技評SE新書002)
・Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.6)