スポンサーリンク

◆失敗を防ぐ要求仕様書のレビュー・ポイントは?

プロジェクト管理

◆仕様書
 次に仕様書の基本的なチェック項目を紹介するので参考にされたい。さらに、記載内容については前述の「質の高い仕様書の基準」や「分かりやすい表現」も合わせてチェックしていただきたい。ソフトウェア開発というのは、意図するところを人間の言葉からコンピュータの言葉に置き換えるバケツリレーのようなところがある。最初にこぼれた水は、なかなか途中で注ぎ足すことが難しい。

(1)題名は、「..システム仕様書」のように、システム名を明記しているか。
   ”名は体を表す”というので、一考を要する。
(2)システム概要(業務フロー)は、システムの全体、業務との関連、他システム
   及び業務との連携が理解できる内容か。5W1Hに照らし合わせてチェック。
(3)帳票は、名称、入出力の区分、データ項目、レイアウト、入出力方法、入力チェック
   及び条件が明確か。
   各帳票に対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(4)画面は、名称、入出力の区分、データ項目、レイアウト、入出力方法、入力チェック
   及び条件が明確か。また、各画面の操作方法、メニュー構成及び遷移が明確か。
   各画面に対応する業務プロセスと利用目的が、業務フロー上で明示されているか。
(5)ファイルは、名称、入出力の区分、論理構造、各データ項目の名称、属性、長さ、
   キー項目等が明確か。
    *既存の帳票、画面、ファイルは、識別可能な名称があれば、自明な詳細事項の
     記述は不要。
   各ファイルに対応する業務プロセスと利用目的が、業務フロー上で明示されてい
   るか。
(6)各画面・帳票等の要求機能、処理方法は理解できる内容か。
    処理条件、処理サイクル、タイミング、処理件数の平均値と限界値、必要性能
   (処理時間、レスポンス)、エラー処理、データのバックアップと廃棄処理、
   セキュリティ対策等は明確か。
(7)入力~処理~出力の流れ及び関連が、業務プロセスに対して矛盾無く理解できるか。
(8)各帳票、画面と関連ファイルのデータ項目は対応付けされているか。
(9)各帳票、画面、ファイルの各要素に対し、新規、改修、既存が判別できるか。
(10)要求仕様は、業務上の期待効果の実現に対し、過不足や矛盾はないか。
   上位文書である、要件定義書の各業務要件と各要求仕様の追跡性を確保しているか。
(11)要求仕様は、技術的、費用対効果的に実現可能かつ必要十分な内容か。
(12)要求仕様は、見積書のデータ型(帳票、画面、ファイル)の種類及び数と整合性が
   とれているか。
(13)略語、専門用語、コード表、エラーメッセージ表等の説明があり、明確か。
(14)購入ハードウェア/ソフトウェアとの関連は明確かつ整合性がとれているか。
(15)データの移行作業等が検討されているか。必要な場合は、移行条件等が明確か。
(16)運用上の制約条件や障害発生時の回復時間などを規定しているか。

コメント

タイトルとURLをコピーしました