人体はシステムです。
人の機能には歩く、跳ぶ、投げる、泳ぐなどがありますが、人の構造を設計する際には、機能から直接デザインにマッピングして「歩行器官」、「跳躍器官」、「投げる器官」と得られるわけではありません。
人の器官には目、耳、心、肺、肝臓、胃、骨格、皮膚などがあります。これらの器官は人の機能と一対一で対応しているわけではなく、システムの機能を完成させるために互いに協力する際、機能との関係は多対多です。
ソフトウェア開発では、要件から直接設計にマッピングすると、大量の重複したコードが生成され、コストが増加します。一方、設計から要件を定義すると、偽の「要件」が生成され、売上が減少します。どちらの場合も、利益が減少します。
しかし、多くのソフトウェア開発者はこれに気づいていません。
よく「このシステムは8つのサブシステムに分かれており、販売サブシステム、財務サブシステム、在庫サブシステムなどが含まれています」という言い回しを聞きますが、これは要件と設計が分かれていない例です。実際、話者は次のように自分の意図を表現すべきです。「このシステムの機能要件は8つの要件パッケージに分かれています」。
要件パッケージはステークホルダーの視点に基づいてシステム機能をパッケージ化したものであり、サブシステム（UMLの用語ではコンポーネント）はシステムの部品の結合度と凝集度に基づいて内部視点から切り分けられたものであり、これらは一対一に対応しません。所謂の「財務子システム」は実際には「会計が使用する機能を1つの要件パッケージにまとめる」ことがあります。
「機能モジュール」とは誤った用語です
二つ目の一般的な要求と設計の混同を示す表現は「機能モジュール」です。
機能（Function）という言葉が情報システムに適用される場合、システムが全体として外部からのリクエストを受けた時に生じるべき効果を記述しています。
モジュール（Module）という言葉が情報システムに適用される場合、システムが分割された後に得られる各構成要素を指しています。
「機能モジュール」という言葉は、「機能」と「モジュール」には直接の対応関係があるという意識を意味し、ある「機能」に属するモジュール、或いはある「機能」を果たすために存在すると考えています。
前述の人体の例を用いると、「機能モジュール」は「歩行器官」、「歩行サブシステム」...のようになりますが、これは誤りです。
「機能モジュール」は連結して使用されるべきではなく、「機能」と「モジュール」の二つの言葉の意味も曖昧です。
例えば、対象システムとしてATMを考えると、「現金引き出し」は「機能」であり、「ログイン」も機能で、「手数料計算」も「機能」ですが、「機能」の範囲はどれくらいなのでしょうか？「モジュール」はコンポーネントですか？それともクラスですか？
そのため、より正確な用語をできるだけ使用するようにします。例えば、ATMを対象システムとして、「現金引き出し」はユースケースであり、「ログイン」はユースケースの一連のステップであり、「手数料計算」はステップで、システム内には「アカウント」クラスが存在するかもしれません……。
