要件定義とは、「誰が、何を、何のために行うのか」を明確にすることです。
しかし、しばしばこの「何のために」が正しく認識されないまま要件定義が完了し、必要のない機能、意図不明な機能、まったく使い物にならない機能などが 着々と開発されていく一方では要件定義漏れが発生し、矛盾による仕様エラーとあわせて多くの手戻りや仕様変更が続出・・・という事態はこの今もどこかでおこっています。
確かに「誰が、何を、どのように実現するか」といったユースケース等を作成するうち、whyではなくhowばかりに重心が置かれてしまうということ は、よく言われるところです。ただ、このような言い方の場合、プロジェクト全体の大局的なWhyを意味している場合が多いようです。ただ要件定義とは Whyが出発点であり、それがHowに置き換わるようなことは順番も論理も違うので、あまり言い訳にはなりません。
とにかくどのような小さな要求にも理由や必然があるのです。
　

様々なフローやマトリクスによるモデリングを行い、美しく作られた要求仕様書が、「何のために」を明確に表しているかというと、これはまったく別の話となります。
大局的な理想や目的を謳うコンサルタントが、個別機能の話になると聞いた要求をそのまま「〜の実現方法を検討する必要がある！」とお得意のパワーポイントでお得意のメッセージを掲げ、いきなり実現方法の検討に入ってしまっているといったこともしばしば見られます。
また様々なモデリング技法や方法論を熟知し、精緻な要求開発手法を実行可能できる（あるいはそう思っている）ことと、要求の理由と必然を明確にし、その妥当性を理解できることは、これもまた別の話です。
例えば要求仕様定義書に聞いただけの「何のため行うのか」という理由がただ書いてあるだけでは何の意味もありません。要件定義の成果物はただの議事録ではないのです。
とにかくむきだしの要求をむきだしのまま機能とするほど危険なことはありません。
複数のユーザークラスの要求を一般化にしたり、あるいは矛盾する複数の要求を調整し、「欲しいもの」と「必要なもの」を整理するには、当然、その理由を明確にする必要があります。でなければ正確なトリアージもできていないことになります。
　

しかしながら、その要求の理由を明確にしないまま（聞いたそのままの理由は記載されていても）、あるいは正しく認識しないまま、仕様化し、実現することが今も多く行われています。
それは以下の理由が考えられます。
• 「なぜか」を聞くスキルがない。（ユーザーの話す内容を理解する前提の知識や経験がない）
• 「なぜか」を質問するスキルがない。 （ユーザーの話す内容に突っ込みを入れる知識や経験、気づきや論理がない。また恥をかくのが嫌なので知ったかぶりをして質問しない。）
• 「なぜか」を分析するスキルがない。（ユーザーの要求をある時は抽象化し、ある時は詳細化して掘り下げるスキルがない）
• 「なぜか」を聞く習慣がそもそもない。
• 「なぜか」を必ず重視する感覚と意識がない。
• とにかく現状通りの仕様または思い通りの要求を実現しようと凄むユーザーに対応できる理論武装と人間力がない。
• 上記の問題に対して正しくファシリテートできる要求アナリスト、リーダーがいない。
　
要件定義とは「なぜか」と「必然」を出発点にお客様とともに創る作業です。
ユーグロナコンサルティングのコンサルタントは常に「なぜか」というあたり前のことを重視する意識を持ち、またその要求の「なぜか」を理解し、突っ込んだ議論と分析できる知識とスキルを持つよう努めております。