Concept and mechanism
Validating requirements means asking whether satisfying the written statement contributes to the need. A clear requirement can still solve the wrong problem. Use objectives, scope, assumptions, and evaluation criteria to check that connection. Then compare feasible options: building, buying, adapting a process, or combinations as appropriate. Make mandatory conditions explicit before applying preference scores. If an option fails a confirmed recovery condition, a high usability score does not automatically compensate for that failure. The owner may revise the condition through the agreed process, but the analyst should not hide it inside an average. Also connect requirements with components, teams, and releases to understand what each option actually delivers.
Guided application
In an example, A costs 20 thousand euros to install and 10 thousand annually; B costs 35 thousand and 4 thousand annually. Over three years, without discounting or other costs, A totals 50 thousand and B 47 thousand. The cheaper installation does not identify the lowest cost over that horizon. Record exclusions such as transition, training, or decommissioning. For preferences, weights of 60% and 40% with scores of 4 and 2 produce 3.2; this is not a probability of success. Try plausible alternative weights to assess recommendation stability. If a small change reverses the choice, present that sensitivity to the decision maker. A prototype helps clarify use but does not replace evidence of capacity, security, or recovery.
An aggregate score compares only options that meet mandatory conditions.
Common pitfalls
Preference treated as obligation; initial cost treated as total cost; prototype treated as operational proof.
Related topics: Plan analysis and decisions · Elicitation, evidence, and collaboration · Life cycle, priorities, and changes
Recommend with visible criteria, assumptions, and evidence limits.
Reference: Requirements designs categories and traceability · Six-knowledge-area blueprint / handbook May 2026