Solution Design, Requirements, and Trade-offs
Solution Design, Requirements, and Trade-offs
This domain tests discovery discipline and decision quality: can you elicit the real requirement, separate it from the stated solution, and defend a trade-off with numbers rather than opinion?
Requirements work
Identify stakeholders and personas, then map current-state journeys and quantify the pain - hours lost, error rates, cost per transaction. Separate functional requirements from non-functional ones: volume, latency, availability, retention, compliance, accessibility. Record assumptions and constraints explicitly; an unstated assumption is a future defect. Maintain traceability from requirement to design to test so scope changes are visible.
Trade-off discipline
Generate two to four genuinely viable options, including "do nothing" and "buy versus build". Score against weighted criteria covering cost, risk, time to value, maintainability, and organizational fit. Document rejected options and the reason. Quantify outcomes: "saves 400 developer days and $180k in licensing over three years" beats "more efficient".
Recurring architectural trade-offs
- Single org versus multi-org: shared customer master and one licence versus release autonomy and simpler segregation.
- Configuration versus code: speed and upgrade safety versus control and testability.
- Phased versus big-bang delivery: earlier value and feedback versus duplicated transitional work.
- Standard objects versus custom: faster delivery and native features versus modelling purity.
Worked example
Three business units with different processes ask for separate orgs. Criteria and weights: need for a shared customer master 0.4, release autonomy 0.2, three-year cost 0.2, available skills 0.2. Multi-org scores well on autonomy but duplicates integration and triples administrative overhead, and it fails the dominant criterion - the customer master must be unified for cross-sell reporting. Single org with record types, distinct permission set groups, and a joint release governance board wins. The rejected option is documented with its cost. That documentation is what makes the recommendation defensible later.
Traps that cost marks
Solutioning before discovery. Gold-plating for unquantified scale. Ignoring licensing and support cost. Invoking "best practice" without context. Omitting non-functional requirements from the design. Leaving assumptions undocumented. Letting scope creep in without a traceability check.
Key points
- Quantify the pain before proposing the fix.
- Always present two to four viable options, including do nothing.
- Weight criteria first, then score.
- Document rejected options and the reasons.
- Non-functional requirements belong in the design, not an appendix.