システム開発プロジェクトでは、中間成果物としてさまざまなドキュメントが作られる。発注側がその内容をチェックし、問題ないかを確認していくのが、ドキュメントレビューだ。そのチェックポイントを紹介する。
プロジェクトを進めるうえで、トラブル発生による手戻りを未然に防止するほかに、進ちょくを測ったり、リスクを予測したりするためには、ドキュメントレビューが効果的である。ここでは、主要なドキュメントに対するチェックポイントを紹介する。
以下に仕様書の基本的なチェックポイントを紹介する(なお、第4回の「急がば回れ──質の良い仕様書の作り方」も併せて参考にしていただきたい)。
ソフトウェア開発というのは、意図するところを人間の言葉からいくつかの成果物(ドキュメント)を経て、コンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水を途中でつぎ足すことは、なかなか難しいもの。早い段階──仕様書には“漏れ”がないようにしたい。
(1)題名は、システム名を明記しているか
仕様書の題名に「?システム仕様書」のように、システム名が明記されているか。“名は体を表す”というが、分かりやすいシステム名にするよう一考を要する。安易な題名は、入り口で重大な勘違いを誘発する。
(2)システム概要は、業務との連携が理解できるか
システム概要(業務フロー)は、システムの全体、業務との関連、他システムおよび業務との連携が理解できる内容か。5W1Hに照らし合わせてチェックする。
(3)帳票の名称および仕様は明確か
帳票は、名称、入出力の区分、データ項目、レイアウト、入出力方法、入力チェックおよび条件が明確か。各帳票に対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(4)画面の名称および仕様は明確か
画面は、名称、入出力の区分、データ項目、レイアウト、入出力方法、入力チェックおよび条件が明確か。また、各画面の操作方法、メニュー構成および遷移が明確か。各画面に対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(5)ファイルの名称および仕様は明確か
ファイルは、名称、入出力の区分、論理構造、各データ項目の名称、属性、長さ、キー項目などが明確か。各ファイルに対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(6)各画面・帳票などの要求機能、処理方法は理解できるか
各画面・帳票などの要求機能、処理方法は理解できる内容か。処理条件、処理サイクル、タイミング、処理件数の平均値と限界値、必要性能(処理時間、レスポンス)、エラー処理、データのバックアップと廃棄処理、セキュリティ対策などは明確か。
(7)入力?処理?出力の流れが、矛盾なく理解できるか
入力?処理?出力の流れおよび関連が、業務プロセスに対して矛盾なく理解できるか。
(8)各帳票・画面は、データと関連付けされているか
各帳票・画面と関連ファイルやデータ項目は関連付けされているか。
(9)各要素の新規、改修、既存が判別できるか
各帳票、画面、ファイルの各要素に対し、新規、改修、既存が判別できるか。
(10)要求仕様に、過不足や矛盾はないか
要求仕様は、業務上の期待効果の実現に対し、過不足や矛盾はないか。上位文書である、要件定義書の各業務要件と各要求仕様の追跡性を確保しているか。
(11)要求仕様は、実現可能かつ必要十分か
要求仕様は、技術的、費用対効果的に実現可能かつ必要十分な内容か。
(12)要求仕様は、見積書の各要素の種類・数と整合性があるか
要求仕様は、見積書の帳票、画面、ファイルの種類および数と整合性が取れているか。
(13)略語、専門用語などの説明は明確か
略語、専門用語、コード表、エラーメッセージ表などの説明があり、明確か。言葉の違いや誤理解に端を発したトラブルがなんと多いことか。用語の定義統一に始まり、類似語・同音異義語・同義異音語など整理し、一意に解釈できるようにしなければならない。
(14)購入ハード/ソフトの関連は明確かつ整合性があるか
購入ハードウェア/ソフトウェアとの関連は、明確かつ整合性が取れているか。
(15)データの移行作業などが検討されているか
データの移行作業などが検討されているか。必要な場合は、移行条件などが明確か。
(16)制約条件や回復時間などを規定しているか
運用上の制約条件や障害発生時の回復時間などを規定しているか。
Copyright © ITmedia, Inc. All Rights Reserved.