Evaluating Product Options and Capabilities

Not every decomposed option or capability makes it into the solution — this task evaluates them using decision-making techniques (multi-voting, weighted criteria, consensus-building) and valuation techniques (cost-benefit analysis, a Kano model) to sort each one into accepted, deferred, or rejected. This is a deliberate, defensible sorting process, not an informal judgment call made in passing.

Deferred doesn't mean discarded — it means the requirement has real merit but doesn't make sense for this particular release or baseline, and should be preserved (often in the backlog or a future-scope list) rather than silently dropped and forgotten.

Study focus: a scenario where a stakeholder is upset that their requirement was "cut" is often testing whether you understand the difference between rejected (genuinely out of scope) and deferred (valid, just not now) — and whether that distinction was actually communicated back to the stakeholder.