唐突ですが、現在、出回っている仕様書の思考過程は、おおきく３つに分かれると思います。
■■ その１：９０年代初頭ぐらいに完成した、言語はＣＯＢＯＬベースの仕様書
これのサンプルと、記述方法は、情報処理試験のテキストに載っている
Excelの形式の仕様書や、COBOLの仕様書といわれるのは、これがベースになっている。
仕様書は、だいたい以下のとおり
要求仕様（要件定義）書
外部設計書（帳票、画面、ファイル・テーブル、コード、通信・データ）
詳細設計書
テスト仕様書／報告書
これらの仕様書の書き方が、あらかじめ決まっている（雛形がある）。
Excelの表みたいなかんじでできている。
■■ その２：ＤＯＡを中心とした仕様書
ＤＯＡの流れから来ている。
仕様書は、ＥＲ図
ＤＦＤ図（コンテキストダイアグラム、ＤＦＤ，ミニスペック）
より構成される。
■■ その３：オブジェクト指向を中心とした設計書
ＵＭＬの９種類の図。
図の種類は、以下のとおり
・構造図
（１）クラス図
（２）オブジェクト図
・振る舞い図
（３）ユースケース図
（４）相互作用図
（５）コラボレーション図
（６）ステートチャート図
（７）アクティビティ図
・実装図
（８）コンポーネント図
（９）配置図
このうち、仕様書は、ユーザーとの打ち合わせに用いて、了承を得なければならない場合がある。
ユーザーとの打ち合わせで、了承が必要なものとしては
・要求仕様書
機能要件：ユーザーの業務内容について
非機能要件：レスポンスタイムなど
・概要設計
ハードウエア構成
ソフトウエア構成（いらないときも）
→ハード・パッケージソフトの見積書を別途作成
・外部設計書
画面設計書
というわけで、ＤＦＤやＥＲ図を承認とってもらったりするのではない。
ということで、ＣＯＢＯＬ時代のドキュメントが結構まだのこっていたりすることがある。
しかし、このＣＯＢＯＬ時代のドキュメントをそのまま使っていいというわけではない。詳細設計書に関しては、（Javaで開発するなら）捨てたほうがいい。
COBOLは、オブジェクトのCOBOLでない場合、１プログラム１手続き（＝１メソッド）になる。しかし、Javaの場合、１クラス複数メソッドとなり、あわない。なので、いろいろいじるより、さくっと、フォーマットからかえたほうがいい。
問題は、画面設計書。
これも、ＣＯＢＯＬベースとＷｅｂベースでは、（Ｗｅｂのタイルに相当することを、ＣＯＢＯＬでは、普通やらないため）タイルがある場合、違う雰囲気の画面になる。
なので、流用しないほうが、得策なことが多い。
で、このブログでは、将来、あまり他のブログで書かない、でもいまだに続いている「ＣＯＢＯＬ時代のドキュメント」や手法について、書いてみようかなって、思っています。
アクセス
トータル
ランキング
