設計書の品質を高めるには-2

次に基本設計について

• 入出力の確定(必要とするものは網羅）
• 処理概要
• 処理方式(あくまで概要)
  システム方式、ネットワーク方式、運用方式、システム障害、共通処理
• ハードウェアの全体概要
• 共通アプリケーション処理(概要)

全体構成をまず考えて、概要全般をかき、あとから詳細化。
整合性から、全体像から部分を構成

さらに性能などの諸要件は、総合テスト仕様書全般の概要を記載しておく。
要は設計書に具体的な処理内容に触れるものや例文は総合テスト仕様書に記載し、品質管理面の強化を図ることが重要です。

設計書はあくまで対顧客、そして総合テスト仕様書の結果が全てです。
これを忘れると、単なる言葉遊びではないですが、顧客側の思いとシステムを作る側の思いが整合していない場合が多いです。
顧客によっては、例文のほうが理解しやすいし、システムを作る側の品質も向上します。

設計書の品質を高めるには-1

設計書をかくことが下手な人が多い。ベンダーなどによってさまざまな書式があるが、なぜ必要とする設計書なのかを理解していない人が多い。
各工程は連続にあり、それぞれが独立しているのではない。

また要件定義などで未確定事項が多い、また新技術で、どのように設計書をかくか悩むことも多いだろう。
基本を忘れないでほしいことがある。

要件定義で必要なのは、何をするのか、どのように行うのかを明確にする。
単なる要望書でもなく、希望的憶測でもないのは確かであるが、多くのものは憶測や、希望的見解を述べて、技術的根拠がないものも見受けられる。
技術的検証などの工程があれば問題はないが、これがない場合はどうするのか。

ベンダーによっては、
1)予算などが豊富なベンダはパイロットチームが、先に技術的検証をしながら、工程単位に確認を行う。
2)予算のなし、や製造で何とかしようとするベンダーは確認をせずに設計書を固める
圧倒的に多いのは、2)のほうで、1)を行うベンダが少ないのが実情
品質が悪くなったり、手戻りが多く、工数が激増するのはこのことも一つの要因。

基本的には小さくともパイロットを作成し、確認を行うことが重要である。