TOPプロジェクト管理> 項目説明書
即活用!業務システムの開発ドキュメント標準化
即活用!業務システムの開発ドキュメント標準化

第4回:詳細設計書(前半)
著者:システムインテグレータ  梅田 弘之   2005/8/2
前のページ  1  2  3
項目説明書

   前回、画面/帳票レイアウトのサンプルと記入方法について説明しました。図4に示す「項目説明書」は、その画面/帳票イメージと対になる設計シートです。基本設計フェーズで作成する「画面/帳票レイアウト」は、基本的にユーザのイメージ確認を主目的としますが、その情報だけでは画面を作成できません。そこで詳細設計フェーズで「項目説明書」を追加し、画面や帳票の各項目について必要な情報を記載します。以下、主な記載項目について説明します。

項目説明書
図4:項目説明書
(画像をクリックすると別ウィンドウに拡大図を表示します)


項目名

   画面や帳票の項目名です。設計書に記載する項目名は、このようにわかりやすい日本語名で記載します。これらの「項目名」は、実際の画面/帳票の「コントロール名」と対比します。この2つは、ER図におけるデータベース項目の論理名と物理名の関係に似ています。

   DUNGEONの詳細設計書はプログラミング設計書ではないので、設計書上にコントロール名までは記載しません。コントロール名については、プログラミング規約を別途用意し、その中の命名規約に基づいてプログラマの裁量にまかせるという方針にしています。


I/O

   各項目の入出力関係を表しています。前回、画面レイアウトの説明で、6やOが表示、9やBが入(出)力というように記号で使い分ける方法を紹介しました。それとある程度重複する情報になりますが、ボタンやチェックボックスなどそれらの記号を使わないコントロールもありますので、項目一覧表でI/Oの区分を一元管理することにしています。


桁数

   一般のコントロールにはMax Length、つまり最大桁数を規定するプロパティがあります。その設定値を設計者が定め、プログラマに通知します。画面/帳票イメージでも、「ZZZ,ZZ6」や「BBBBBB」というように記載することで直感的に何桁かわかるようにしています。しかし、画面幅の関係で見た目以上に入力できるように設定する場合もありますので、上記同様、項目一覧表で各項目の最大桁数を一元的に定義することにしています。


IME(入力モード)

   入力項目に関しては、入力モードのOn/Offを定義します。担当者コードなど半角英数字のみを入力する項目はOff、担当者名など全角文字を入力する場合はOnを指定し、ユーザが切り替えなくても自動的にモード切替ができるようにします。


必須

   入力項目で、なんらかの値が入力されないとエラーにする場合は必須欄に○を定義します。単純な必須チェック項目は○、条件により必須になるような場合は△として、備考欄または補足説明書に詳細を記述します。


参照

   コードなどの入力を補助するためのコード検索(参照)機能の有無を定義します。ここでは、担当者コードのようにポップアップウィンドウを開いてコード検索できるものはW、受注確度のようにプルダウンリストを開いて選択できるものをPという記号で使い分けしています。


データ元(テーブル/列)

   画面や帳票に表示される値が、どのテーブルのなんと言う列のデータであるかを定義します。

   とは言っても、オブジェクト指向設計においては、テーブルの値を直接画面に表すわけではありません。BL(ビジネスロジック)がデータをテーブルから取得し、それを画面にセットするという中間的な役割を果たします。そのため、厳密にはBLのアウトプット変数と紐つけた記述とすべきなのですが、それだとかえって全体がわかりにくいので、ここでは根元のデータソースとなるテーブル/列を記述するようにしています。


値チェック

   入力項目については、必須チェック以外にも誤入力を避けるための値チェックを行います。たとえばコードがマスターテーブルに存在しているかどうかの存在チェック、日付や番号などの(自)≦(至)大小チェック、0と1以外は入力不可とするなどの値チェック、など項目に応じてどのようなチェックを行うかを定義します。


初期値

   画面ロードの際の初期値を設定する場合は、どのような値を初期値とするかを定義します。たとえば日付項目に今日の日付を初期セットしたり、金額欄に0をセットしたりするような処理を指示します。


備考

   上記の規定欄で書ききれないことがらについては、備考欄に自由に記述します。フォーマットは1項目1行となっていますが、スペースが足りなければ複数行にして書くこともOKです。


まとめ

   今回は、オブジェクト指向の要素を取り入れた機能設計書の構成について説明しました。基本設計書のドキュメントに対して、プログラマがこれを読んで作成できるためにいくつかの設計ドキュメントが追加されることになります。

   その中から、第1弾として「表紙/更新履歴」「目次/概要」「項目説明書」の記述様式について説明しました。次回は、「イベント一覧」「BL一覧」「更新仕様書」「補足説明書」を紹介・説明し、詳細設計書の標準ドキュメント化を完了したいと思います。

前のページ  1  2  3



著者プロフィール
株式会社システムインテグレータ  梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。 常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。 国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。


INDEX
第4回:詳細設計書(前半)
  機能設計書のドキュメント体系
  表紙
項目説明書