正解：ア
各選択肢の解説
ア決定表
正解。条件の成否の組合せを列ごとに並べ、それぞれで取る動作を対応させる表です。 三つの条件なら8通りをすべて並べられるため、抜けている組合せや矛盾がすぐに見つかります。
イDFD
誤り。DFDは、データがどこから来て、どの処理を通り、どこに蓄えられるかという データの流れを図にする手法です。業務の全体像はつかめますが、 条件の組合せごとに結果がどう変わるかという判定の規則は表せません。
ウユースケース図
誤り。UMLの図の一つで、利用者などの外部の存在とシステムが提供する機能の関係を示します。 「会員が商品を購入する」という機能があることは描けますが、 その中で割引率をどう決めるかという条件の細部は扱いません。
エE-R図
誤り。会員、注文、商品といったデータのまとまりと、その間の関係を示す図です。 どんなデータを持つかの整理には向きますが、条件によって処理を分ける規則を表すものではなく、 組合せの漏れを確かめる用途には使いません。
理解を深めるために
条件の組合せは「表」で総当たりにする
「会員で、1万円以上で、セール中なら15%引き。会員で、1万円未満で……」と文章で書くと、 どこかの組合せを書き忘れても気付けません。決定表は、条件を行に、組合せを列に並べて、 Y（成立）とN（不成立）の全パターンを埋めていく表です。 空いたマスがあれば、それが決め忘れの組合せです。
なぜ要件定義で使うのか
割引や料金、審査の可否のように、複数の条件で結果が変わる規則は、 担当者の頭の中にしかないことがよくあります。要件定義でこれを決定表に起こすと、
- 条件が3つなら2×2×2＝8通り、と組合せの数が機械的に決まる
- 「会員でない人がセール中に1万円以上買ったら？」のような抜けが見える
- 同じ組合せに二つの割引率が書かれていれば、矛盾として見つかる
といった効果があり、開発を始めてからの仕様の食い違いを防げます。
混同しやすいものとの違い
| 手法 | 表すもの |
|---|---|
| 決定表 | 条件の組合せと、それぞれで取る動作 |
| DFD | データの流れ（発生源・処理・データストア） |
| ユースケース図（UML） | 利用者とシステムの機能の関係 |
| E-R図 | データのまとまり（エンティティ）とその関係 |
問題文に「条件の組合せ」「漏れや矛盾」とあれば決定表、「データの流れ」ならDFD、 「利用者から見た機能」ならユースケース図と読み分けます。