内部仕様書（機能仕様書、詳細設計書）で書くべきことです。
内部設計と言う工程がなく2つか3つに分かれていることもあります。
外部設計が「何を作るか(what)」に焦点を当てていたのに対して、内部設計や「どうやって作るか(how)」を論じます。
内部設計書には以下を書きます。
- モジュール一覧と実現する機能
- モジュールのインタフェース
- データ構造、テーブル構造
- 各部位の性能
- クラス図、シーケンス図、状態遷移図などコーディングで必要なもの
- 設定値一覧
- エラーメッセージ一覧とトラブルシューティング
内部仕様書で書くべきこと
イト屋です。
内部仕様書は「基本仕様書」「機能仕様書」「詳細仕様書」とも言われます。プロジェクトによっては、基本仕様書は外部仕様書ですので注意しましょう。
また仕様書ではなく設計書と言われることもあります。
つまり、内部設計書、機能設計書、詳細設計書などです。
書かれることは、外部仕様書で「仕様」としたことをどう実現するかを書きます。
最もたくさん書くプロジェクトでは、何も考えずにコードが書けるくらいになるまで詳しく書きます。
また、内部仕様書書を書くプロジェクトにいる人から見ると信じられないかもしれませんが、内部仕様書を書かないプロジェクトもあります。
せめてデータ構造とクラス図くらいは書きましょう。書かなくても検討はしましょう。
モジュール一覧と実現する機能
モジュール一覧と実現する機能を書きます。
外部設計書に書いたならいらないです。むしろ外部設計書に一覧を書いてモジュールごとに1冊ずつ書くというプロジェクトが多いかもしれません。
モジュールのインタフェース
各モジュールが、他モジュールに対して公開するインタフェースを書きます。以下のような種類があります。
- 単なる関数コール
- プロセス間通信のやり方
- httpでREST
コールする前提というかルールも書いておきます。
openして何か処理をしてcloseするとか、エラーになったらcloseしてね、とか。
データ構造、テーブル構造
データ駆動にものを作ると、理解しやすく、おかしなものの形にはなりません。
メモリ上のデータ構造、ディスク上(ファイル）のデータ構造、データベースのテーブル構造
をしっかりと設計することによって何をどうやって作るかが、自然に決まってくるのが理想です。
データベースの勉強などをしっかりしておきましょう。
各部位の性能
どこまでシビアな性能を求めるかによって書くことは異なります。
1日に1回コールされて全体で数時間のジョブで、数msの処理の性能はあまり書かないかもしれません。数秒の処理だったら書いていって積みあがっても大丈夫よ、みたいなことを書いたりします。
1秒の処理の10個に分かれたうちの1個の処理が数msであれば、性能を見積もって書くと思います。
ケースごとに性能仕様を書くべきかどうかを判断してください。
クラス図、シーケンス図、状態遷移図などコーディングで必要なもの
プログラムを書くための構造を書きましょう。
紙で検討する必要がないところまで持っていきます。その基準はプロジェクトごとであり、個人差もあります。
イト屋は、クラスを細分化する過程はコーディングでやるのが効率がよいので、主要なクラスの構造、使用するデザインパターンを決めておきます。状態遷移図は抜けがあると困るので、コーディングまで持ち越すことはありません。ここでしっかり検討しておきます。
コーディングに習熟していない人は、先輩、上司に相談しておきましょう。後々助けてくれるかもしれません。
設定値一覧
ユーザに設定してもらう設定値は当たり前ですが、設定してもらわないけど固定の設定値があるなら、書いておきます。
不良発生時に、設定値をオンにして調査するんだ、みたいなのもしっかりと書いておきましょう。隠し持っていてもいいことはありません。忘れないうちに書いておきましょう。
エラーメッセージ一覧とトラブルシューティング
トラブルシューティングマニュアルを作るか作らないかに限らず、エラーメッセージは必須です。一覧の完成はコーディング後になるかもしれませんが、一覧を作らないということはありません。
まとめ
内部仕様書で書くべきことをまとめました。
主な目的は、あまり悩まずにコーディングできるようになることです。
>>> 【ITエンジニア】工程ごとの分類
コメント