仕様書の書き方 2 | 羊雲

仕様書の書き方 2


Software people―ソフトウェア開発を成功に導くための情報誌 (Vol.3)

仕事でこれしかやってない所為か、ついつい仕様書の書き方について考えてしまいます。今更そんなに必要なのかって意見もあると思います。最近では…というか、かなり前から Case ツールとか、仕様書作成ツールとかの性能が上がってきて、コードから仕様書を吐いたり、UML で書かれたクラス図からコードを吐いたりと、メチャメチャ便利になってます。Visual Studio 2005 も発売される事ですし、なんて言ったって21世紀ですもんね。まったく。

でも、なんで私がそんな事をやってるのかと言うと、そういうツールが高くて買えないというわけではなく、結局そういう話ってハイエンドのシステム開発 SE のお仕事だったりするわけですよ。Java とか Visual C++ とかその辺の Windows アプリ。私の様な SE 界の雑草の様な、組み込みエンジニアからはちょっと遠い話なのです。(あ、別に組み込みエンジニアリングを愚弄しているわけでは無いです。なんだかんだ言っても私はこの仕事に誇りを持っています)

さて、前置きが長くなってしまいました。ちょっとノッて来たので、仕様書、設計書に具体的に何を書いたらいいのか、という話をしようと思います。

私が書いている仕様書の種類は以下の様になっています。

(1)基本設計書
(2)システム構成図
(3)モジュール仕様書

基本設計書はシステム全体で、どんな機能ブロックがあって、どんな構造になっていて、それぞれの構成なんかをざっくりと書いています。あと OS の共通 API なんかはここでまとめてしまいます。

システム構成図では、文字通り"図"で、タスクとメッセージ(キューとか)のつながりを書きます。タスクには優先度とかを記述し、図を見るだけで、まあ、モジュール構成の矛盾が無いかどうかを確認します。1つのキューから2つ以上のタスクが、メッセージを取ってたり、1つ前のタスクの方が優先度が高い時などは注意が必要です。

で、モジュール仕様書。これは機能ブロックごとの仕様を、それなりに突っ込んで書きます。状態遷移図・表、フローチャートとかを使って、その機能が、ちゃんと動くモデルであるという事を書きます。あと他の機能ブロックからのインタフェース(入力と出力とグローバル関数)なんかもここに書きます。ちなみにクラスの場合もここ。

まぁ、ざっくりとそんな感じなのですが、いろいろ流儀があるらしく、仕事でいろいろ調べてみたら、結構、楽しめました。…と、ドキュメント作りにどっぷりと浸かってしまって、最近コードを書いていません…。コードを書いている時が一番楽しいのですけどね…。

仕様書の書き方 3 へ続く

管理者になったとき困らない 実践的ソフトウェア開発工程管理
図解でわかる ソフトウェア開発のすべて―構造化手法からオブジェクト指向まで