新たな開発に着手する時は要件定義が必要です。本当の要求が何なのか受け手によって解釈が違う事がある為です。　図１はアレクサンダーの「オレゴン大学の実験」に由来する図です。要求を具体化する時、要求者の意図が中々実現しないという例として利用されています。要求はタイヤが木に架かるブランコなのですが、受け手によっていろいろなブランコ？ができるという示唆です。「要件」を纏めることはステークホルダと経験の相関関数です。　つまり関連者が多ければ多いほど要件に揺らぎが生じ、また要件の解釈は経験から導かれます。ゴールの形が良く見えないソフトウェアの場合はその傾向が顕著です。関連者が多ければゴールが見えなくなる可能性があります。

要求　「木に架かるブランコを作ってください」

　人はその人の経験に基づく言葉の理解に基づき会話します。日本人は「阿吽の呼吸」で会話すると言われます。しかし外国の方と話す場合具体的に説明しないと会話が成り立たないことも有ります。話し手と聞き手の間に育った文化の違いがでるのですね。
　「木に架かるブランコ」の複数イラストは、要求とは異なる例えとして利用されます。極端ですがコストを無視した、ジェットコースターの様なイラストもあります。
　真の要求は「タイヤが木に架かる一人で遊べるブランコ」なのです。
　要求は話し手の暗黙の前提を含んだ「ニーズ」です。それを具現化するには明確な事項として「要件」にまとめる必要があります。
　具体的にまとめなければ、タイヤや踏板を見た事のない作り人であれば、ローブを垂らしただけのブランコになるかも知れないのです。

要件　「タイヤが木に架かる一人で遊べるブランコ」

　「要求」を「要件」として取り纏める事を、IPO(input process output)と略して表現することがあります。また参照を含めてIOPRなどとと呼ぶこともあります。これは「要件定義」を「具体的に入出力と機能と条件を定める」こととしています。
　まず、「要求」に含まれる機能と入力と出力を定めるます。さらにコストや情報セキュリティなどの非機能要件を必要に応じて定義します。
　「木に架かるブランコ」の要件は以下の様に解釈できます。出力は「ブランコ」。入力は「人」「木」「ロープ」「人を乗せるもの」。そして機能は「人を乗せて空間で前後に動くこと」となる訳です。
　但し、これだけではまだ、ブランコを作る受け手の解釈ができてしまいます。例えば人は一人で良いのか、二人乗りができる必要があるのかなど細かな仕様が必要となります。そして最終的に「タイヤが木に架かり一人が乗って揺れるブランコ」となる訳です。
　システムは建物のモックアップと違い、最初にその全体像を見通すことが難しい対象です。要求者も受け手に分かりやすい説明をすることが求めらます。

　今でも散見されますが、大規模プロジェクトの失敗でITベンダの経営に多大な損失が多発したことが有ります。その為「言われたことしか作らない」という風潮が生まれました。そして発注者側が「要求」をまとめる為にコンサルタントを入れるというトレンドになりました。

要求と要件　「整理には様々なアプローチがある」

　「要求」は要求者の「ニーズ」に焦点を当てますが「要件」は実現するシステムの「ソシューション」（解決策）に焦点を当てています。　その違いを厳密に線引きすることはできませんので、そのブリッジに様々なアプローチがあります。例えば開発の初期段階で簡単なモックアップを作りながら調整していくスタイルです。すなわちイテレーションアプローチです。また政府のデジタル推進の基準として採用したサービスデザインの考え方なども有ります。只どのアプローチでも5W1Hを忘れずに整理することが肝要です。