要件定義という工程があります。
特定のお客さんがいる場合は必ず実施されるべき工程です。また、不特定多数のための製品づくりであっても「何を作るか？」ということを決める必要があるので、必要と考えられます。
「要求仕様の探検学」という本を紹介しながら要件定義という工程で何をやるかを紹介します。
要求仕様の探検学
要件定義という工程は
何が望まれているかを人々が発見しようと試みるプロセス
です。
設計工程やテスト工程ではチーム内のコミュニケーションが主になりますが、要件定義という工程はチーム外のお客様とコミュニケーションが主要な部分を占めます。
「こうすれば上手くいく」というような絶対的なものはありません。「要求仕様の探検学」という本がヒントになります。
お客様は、多くの場合ITについては詳しくありません。
したがって多くの場合、要求仕様はお客が用意するのではなく、
プロのITエンジニアがお客様にいろいろ訊いて文書化します。
要求はお客様から出てくるので、途中で要件が変わる場合はお客様が費用負担するのが当然という考え方がある一方、訊きだしたエンジニア側に責任があるんじゃないか、という考え方があります。
これが、顧客が無条件に要件変更をしてくる最大の理由になっています。
なるべく途中変更など起きないようにしたいです。
曖昧さをなくす
本記事では「要求仕様の探検学」という本をお薦めします。
ワインバーグの本は、多様な例に溢れています。例の記述が頭に残り、例に対応する主張を忘れてしまうことがよくあります。
例が面白い本として読んでもいいですが、ITに関する技術も盛りだくさんですので、そちらも習得しましょう。
「要求仕様の探検学」は、要件の曖昧さをしっかりと説明し、曖昧さをどう失くしていくかを考えていきます。
曖昧さに関する考察で、本の前半を費やしています。
要件を作成するヒント
本の後半は、「機能」「属性」「制約」「選考（オプション）」「期待（を制限する）」から要件を正確に導き出そうということです。
この通りにやれば要件を正確に導き出せるかもしれません。
多くの要件定義では、「機能」の段階で終わっていると思います。
ぜひ、それ以降の考察も含めて、工程途中の要件変更を回避してください。
まとめ
「要求仕様の探検学」を紹介しました。
筆者は筆者であるワインバーグのファンで翻訳されているものはほぼ全て持っています。
ぜひ、一冊お求めください。
>>> 【ITエンジニア】工程ごとの分類
コメント