ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

外部仕様書の構成について、確認してみる。

2006-01-17 14:03:36 | 開発ネタ

 唐突ですが(理由は最後に書きます)、一度書いた気もするけど、
 外部仕様書に必要な仕様書の構成について。
  まあ、外部仕様書でなくても、プログラミング、あるいは詳細設計に入る手前に必要な仕様書とそのドキュメント構成とかんがえてもらっていいです。




で、その外部設計書の構成は、こんな感じだと思う。

●表紙(なくても支障はないが)
●はじめに(ないときもある)
●目次(なくてもいいけど、ふつう、付けよう)

●修正記録(なくてもいいけど、付けろといわれることも)

●システム概要
 →要求仕様で出てくる、大項目レベルの機能要件に関して、
  体系的に文章でまとめる。これが、ちょー短い場合は、
  はじめにに書いてしまって、ここはない。

●ハードウェア構成

●ソフトウェア構成・環境
  本システムの位置づけ(というのを指摘する場合も)
  →フレームワークなども使う場合には、ここに書いておく

●ネットワーク・通信について(必要あれば)

●機能概要
 要求仕様に出てくる大項目から展開し、以下の外部入出力の関連が
 わかり、システムができそうと思えるくらいブレークダウンする。
 →これは、状況により、レベルが変わる

●画面定義
 画面遷移
 各画面の詳細

●ファイル定義
 ファイル名一覧
 ファイル内容(固定長等:レコードレイアウト
        XML:タグと属性)

●DB定義

●通信等
 その他、入出力インターフェースの内容

(なお、このほかに、用語集や、要素技術やフレームワークの説明がはいったりなどもある)
(管理情報も、このあとに入れることもある(スケジュールなど))




 機能概要で、各プログラムのインターフェースまで落とし込んでしまう場合もあります。
 順番はこのとおりとは限りませんし、名称は違うと思います。
 機能概要のところがUMLだと、クラス図と、シーケンス図になったり、
 DB定義をER図にしたり、などなど。。さまざま。 

 で、問題は、なぜ、こういう構成をとっているか、なぜ、これが、外部仕様書なのかというところですよね。

 外部=システム外部に対する仕様なので、本来、外部との境界線(バウンダリつーのかな)となる、ファイル定義と、画面定義、ネットワークなんかあるとき、通信などを示せばいい。
 このとき、あくまでも、外部に対する仕様なので、ファイル定義でも、内部で利用する作業ファイルはかかなくてもいい。
 (ただし、DB定義に関しては、完全に内部にとじることが明白でない限り、DBの特徴に、「共用性」(ほかのシステムも利用できる)があるため、一般にはDB定義もいれる)

 なので、画面定義以降が必要なことは、分かっていただけると思う。

 その上は、この画面定義などの、妥当性を示すのに使う。
 ある入出力があったとき、その入出力をつかって、処理を本当に行うことができるのか、その処理は、要求を満たしているのか?ということで、後に書かれる、画面定義、ファイル定義のことばを使い、要求仕様書の該当する要求を明示し、そのつながりを書くのが、機能仕様になる。
 これで、要求仕様書と、画面入出力がつながる。

 しかし、その要求は、コンピューター上で実現できるのか?というのを示さないといけない。それが、ハードウエア、ソフトウエア、通信の仕様書になる。機能仕様に書かれている処理は、その環境で実現できるかどうかを確認する。

 そして、はじめに、そもそも、このドキュメントは、要件仕様書のどこを受け、どの範囲に書かれているかというのを示すために、「はじめに」と「システム概要」がある。

 目次については、あるとべんり。
 
 表紙や修正情報は、ドキュメント管理上、必要な項目が書かれる。

 ということで、こんだけは必要。あとは、お好みで付け加えることになる。




 って、思ってて、いままで、だいたいその路線で間違いなかったんですよ。

 でも、今お仕事やっている、外部仕様書みて、びっくり!

 画面の様子しか、書いてないんですけどお。。

 これで、ファイルになにを落とせというの(^^;)

 つーか、トップ画面って、どれ??

 お客さんがいったことを、まとめてるだけのよーな気がー

 念のためにいっておきます。

 そのような、お客さんの言ったことをまとめたものを、「メモ」といいます。
 そのうち、要求部分をまとめ、ある形式化したのを、要求仕様、要件定義書といいます。

 でも、じゃあ、おなじように、お客さんからの外部部分をまとめ、形式化したのを、外部仕様書というかというと、違います。
 たぶん、こう勘違いしたんだとおもうけど。。。
 お客さんに見える外部は、画面なので、お客さんからのメモをまとめて書いたら、画面だけです。さらに、自分に関心があるのしか書かないので、トップ画面は分からなかったりします。
(いま手元にある仕様書はそうだ、部分部分しかない)

 だけどね、他のシステムとのインターフェース、たとえばね、他のシステムにファイル転送する場合(今回、それが中心なんですけど)
 そのファイルも、外部なのですよ。他のシステムですから。
 つまり、そのファイルフォーマットも、外部仕様書に入れないといけません。
 そーしないと、プログラムが作れません。

 でも、お客さんは、そんなの知んないわけよ。自分が知らないうちに転送してるんだから。
 だから、外部設計書には、お客さんの知らないこともまとめないといけないんだけど。。
 。。。わかってんのかなあ。。。

 。。。わかってないのかなあ。。

 最近の世の中は、こんな感じになってきてしまったのかなあ。。


この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« NHKが、「ライブドア 証取法... | トップ | inputのtextに、表示幅より長... »
最新の画像もっと見る

開発ネタ」カテゴリの最新記事