仕様バグの三つ目は「誤り」である。要求に漏れも重なりもない状態になっても，その要求自体が間違っていれば，使いにくいシステムができてしまう。間違いとは，例えば「部門間のデータ連携に不整合があり，面倒な手作業が発生する」「入金済みの金額を集計したいのに，契約済みの金額が集計される」といったものだ。
こうした要求の誤りを発見し，修正する知恵を学ぼう。
あり得ないモデル図
要求の誤りは図に表れることがある。「（DFDとE-R図を要求定義の標準モデルと位置付けているが）誤りがあると，『そんなことあるはずがないだろう』というおかしな図になっている。さらなる改善の候補が見えてくることもある」（住生コンピューターサービス 品質保証部 品質保証グループ長 小浜耕己氏）。
例えば，データがストアされているのに，どこからも参照するプロセスがないものがある。「データをストアするからには，何かしらの目的があるはず。その目的が何なのかを意識することが重要」（小浜氏）。
そういうところを改めてヒアリングしていくと「実は…」「例外的には…」といった新たな情報が出てくるものである。「（以前）あるデータが欲しいという要求があった。しかし，実際には既にそのデータは存在しており，必要な担当者にデータが渡されていなかっただけだと判明したこともある」（小浜氏）。
エンドユーザーがそのデータをどういうシチュエーションでどのように使っているのかを業務のレベルで理解することが重要である。フローやデータの一つひとつの目的が分かれば，その業務フローの確からしさが腹に落ちるのだ。住生コンピューターサービスの小浜氏はこうしたノウハウをまとめた資料を作成し，現場に配布している（図9）。
 |
| 図9●DFDから要求の誤りを見つける例 住生コンピューターサービスの小浜氏は「チェックリスト」を作成し，現場に配布している。この図はオリジナルの資料を基に作成した [画像のクリックで拡大表示] |
