Business Requirements and Solution Design
What to know
Translate business goals into Commerce capabilities. Start with stakeholder discovery, then produce artifacts: business requirements document, functional/non-functional requirements, user stories with acceptance criteria, process flows, and a traceability matrix. Distinguish must-have from nice-to-have and separate configuration (out-of-the-box settings) from customization (code) from extension (third-party module). Know when to recommend native features - customer groups and tier pricing, catalog price rules, cart price rules, configurable/bundle/grouped products, shared catalogs (B2B), company accounts, requisition lists, quotes - before proposing custom work.
Understand non-functional requirements: performance, scalability, accessibility, security/compliance (PCI, GDPR), localization, and SEO. Know the difference between a functional spec (what the system does) and a technical design (how).
Traps
Questions present a requirement and ask the best solution - often the native feature beats a custom build. Watch for requirements that sound custom but map to built-in B2B or promotion features. Another trap: confusing a business requirement with an implementation detail; the exam wants the business outcome, not the code. Also beware scope creep framed as a "small addition" and requirements that conflict with platform constraints (e.g., real-time inventory sync without middleware).
Rule of thumb
Before recommending custom development, ask: does a native feature, a marketplace extension, or a configuration setting satisfy the acceptance criteria? Escalate to customization only when the gap is documented and justified.
Worked example
A B2B buyer needs negotiated per-account pricing. The native answer is a shared catalog with custom pricing assigned to a company, not a new price attribute.