Decision tables fundamentals: which structural components are explicitly defined to separate conditions from resulting actions?

Introduction / Context:
Decision tables are a requirements-analysis and rule-specification tool used in MIS, software engineering, and operations. They present complex logic as a matrix of conditions and actions, improving completeness and reducing ambiguity compared to prose requirements or scattered if-then rules.

Given Data / Assumptions:

• A standard decision table has four quadrants: condition stubs, condition entries, action stubs, and action entries.
• We are asked to identify the named components that define the “what” to check and the “what” to do.
• “Decision hierarchy” and similar terms are outside the classic table structure.

Concept / Approach:
The condition stubs list the factors to be tested (e.g., order value > threshold?). The action stubs list the responses or operations (e.g., require manager approval). The entries in the body of the table map specific combinations of condition outcomes to the actions taken. This explicit separation enables systematic coverage and test-case derivation.

Step-by-Step Solution:

Verification / Alternative check:
Requirements engineering texts depict the four-part decision table layout, confirming the terminology used here.

Why Other Options Are Wrong:
Other phrases are either generic or do not correspond to the formal structure of decision tables.

Common Pitfalls:
Forgetting to consider completeness across all condition combinations; failing to identify mutually exclusive actions.

Final Answer:
condition stubs and action stubs