こんなことありませんか?
- 仕様書通りにバグがないように開発したが、実際にエンドユーザに利用してもらうと評判が悪い。
こんなことは、実際には良くあることだと思います。 この原因は、ずばり、「ユーザ不在設計」をしているからです。
では、どうすればいいか?
一言でいうと、「ユーザ中心設計」をすればいいです。しかし、具体的にどうすればいいのか?ウォーターフォール開発を実施している、という前提でいうと、以下の通りとなります。
・外部仕様策定において、以下を区別して考えることです。
- 要望
- ビジネス要件定義
- システム要件定義
- 外部仕様設計
それぞれ、どういうことか簡単に説明します。
要望
エンドユーザ等からの「こういうことができたらいいな」という願望です。語尾「〜したい」と表現できます。
ビジネス要件定義
要件をどのように実現化するかをステークホルダー目線で記述します。ここでは、開発対象のシステムだけではなく、開発しないものも登場させます。ステークホルダーが関係すること、それを洗い出すのです。
システム要件定義
ここで、システム化対象に絞った要件をまとめます。ここでの記載は、具体的である必要はありません。重要なのは、なぜそのように作る必要があるのか、理由がわかることです。
外部仕様設計
ここではじめて、システム化対象の具体的な仕様を記載します。ここでは、仕様の記載が重要です。なぜそのような仕様になるかは、既に「システム要件定義」で記載しているので、ここでは、仕様を淡々に、より厳密に記載するのです。
まとめ
外部仕様策定において、以下を区別して考えるだけで、ユーザが本当に望むものが作れるはずです。
- 要望
- ビジネス要件定義
- システム要件定義
- 外部仕様設計