第3回：ウォーターフォールにおけるドキュメント作成ポイント (1/3)

基本設計書は詳細設計とテストのインプットとなる

「第2回：開発モデルに共通するドキュメントをまとめる視点」では、開発モデルに関係なく、開発ドキュメントをまとめる上で大切となる視点について解説しました。第3回、第4回では、具体的な開発モデルを取り上げ、ドキュメント作成における重要なポイントを押さえていきます。今回取り上げるのはウォーターフォールモデルです。

ウォーターフォールモデルの特徴は、各工程を順番に1回だけ行い、原則として後戻りが許されない点です。各工程は、前工程の成果物をインプットとして、次工程のインプットとなるアウトプット（成果物）を作成するために作業を行います（今回は、図1のV字モデルと工程名で説明を進めます）。

要件定義から詳細設計までは、インプットもアウトプットもドキュメントです。実装から受入テストまでは、インプットはソフトウェアとテスト仕様書、アウトプットはソフトウェアとテスト結果となります。加えて、テスト仕様書の作成では対応する上流工程のドキュメントもインプットとなります。各工程は開発ドキュメントで繋がるため、ウォーターフォールモデルは「ドキュメント駆動型」の開発モデルであるといえます。

基本設計書の3つのポイント

顧客向けの開発ドキュメントを作成する工程は、基本設計という名前で定義されます。この工程で作成される開発ドキュメントは、一般的に「基本設計書」と呼ばれます。

基本設計では、ソフトウェアの外部に対する振る舞いを設計することに加え、次工程の詳細設計のインプットとなる設計を行うことが目的です。加えて、この工程の成果物は総合テストのインプットにもなります。ここでは、基本設計書を作成する上で重要となるポイントを3つに絞って説明します。なお、仕様書の名前は読者の皆さんが所属する組織によって異なったり、複数に分かれていたりすると思いますが、その場合は適宜読みかえてください。

1つ目は「外部に対する振る舞いをわかりやすく説明する」ことです。外部に対する振る舞いで真っ先に思い浮かぶのは画面設計でしょう。それが重要であることは「第2回：開発モデルに共通するドキュメントをまとめる視点」説明しましたので、ここではデータベースの論理設計についてを取り上げます。

データベースを使うソフトウェア（特に業務システム）の場合は、画面から入力された情報がデータベースに格納されます。画面に表示される情報も、データベースに格納されている情報を加工したものです。つまり、データベースを使うソフトウェアは、データベースへの情報を出し入れするのが基本の処理となります。また、顧客にとっては蓄積したデータは重要な資産ですので、ソフトウェアを変えてもそのまま使えることが理想です。顧客にとって、データベースにどのような情報をどのような形で格納するのかはとても重要なことです。物理設計は詳細設計で行えば良いのですが、論理設計は基本設計段階で整理し、基本設計書に記述します。

2つ目は「外部に対する振る舞いの視点から分割を行い、それを説明する」ことです。基本設計書をインプットとする作業は、直後の詳細設計と総合テストです。その2つの工程に漏れなく情報を伝えるだけでなく、作業がしやすいような工夫をしておく必要があります。

基本設計以降の工程では開発に関わる人の数が増え、複数のチームに分かれて作業をします。各チームが作業しやすいようにソフトウェアを適当に分割して、それをチームに割り当てます。各チームが作業しやすい状態とは、別のチームの作業に依存しない状態です。そのためには、外部に対する振る舞いの視点から「結合度を低く、凝集度は高く」なるように分割する必要があります。このような作業が可能なのは、ソフトウェア全体を対象として作業をする基本設計の段階だけですので、注意深く行い、基本設計書に記述する必要があります。

3つ目は「要件定義の間違いや漏れを検出し、必要に応じて前に戻り修正する」ことです。ウォーターフォールモデルでは、原則として後戻りが許されませんが、完璧な作業を行うことは不可能であり、現実には漏れや間違いが発生します。その場合でも、直後の工程で漏れや間違いを発見できれば、最小限の後戻りで対応可能です。ウォーターフォールモデルでは、漏れや間違いは直後の工程で発見し、即解決をすることが大切です。基本設計書の作成は、要件定義書の結果に漏れや間違いが無いかを確認する作業であるともいえます。 次のページ