Business Analysis 101: Requirements Analysis and Design Definition Design Options and Solution Recommendation

What This Is

Design Options and Solution Recommendation is the set of activities a Business Analyst uses to turn validated requirements into concrete, feasible ways of meeting business needs. The BA creates multiple “design options” (high‑level alternatives), evaluates them against criteria such as cost, risk, and stakeholder value, and then recommends the preferred solution. In a project to replace a legacy CRM, the BA might draft three options – a cloud‑based SaaS platform, an on‑premise upgrade, or a hybrid integration – and recommend the SaaS solution because it scores highest on speed‑to‑value and total cost of ownership.

Key Terms & Techniques

• Design Options – High‑level alternatives that satisfy the solution scope (Requirements Analysis & Design Definition). Deliverable: Design Options Document.
• Solution Recommendation – The BA’s justified choice of one design option (Requirements Analysis & Design Definition). Deliverable: Solution Recommendation Document.
• Evaluation Criteria – Weighted factors (e.g., cost, risk, benefit) used to compare options (Requirements Analysis & Design Definition). Deliverable: Evaluation Matrix.
• Decision‑Making Technique – Structured methods such as Weighted Scoring, Cost‑Benefit Analysis, or Analytic Hierarchy Process (AHP) that turn criteria into a ranked list (Requirements Analysis & Design Definition).
• Stakeholder Analysis – Identifying who will be affected and whose input is needed for option evaluation (Stakeholder Management). Deliverable: Stakeholder Map / Influence‑Interest Grid.
• Feasibility Study – Quick assessment of technical, operational, and economic viability for each option (Solution Evaluation). Deliverable: Feasibility Summary.
• Prototyping / Wire‑framing – Low‑fidelity visual or functional mock‑ups that help stakeholders compare options (Requirements Analysis & Design Definition). Deliverable: Prototype Artifacts.
• Risk Assessment – Identifying and rating risks associated with each option (Solution Evaluation). Deliverable: Risk Register.
• Business Case – A justification that links the recommended solution to strategic goals, ROI, and benefits (Strategy Analysis). Deliverable: Business Case Document.
• Traceability Matrix – Links requirements to design options and the final solution to ensure coverage (Requirements Management & Communication). Deliverable: Requirements‑to‑Design Traceability Matrix.

Step‑by‑Step / Process Flow

1. Gather & Confirm Evaluation Criteria – Meet with key stakeholders (business owners, finance, IT) to agree on the criteria and weighting that will drive the decision.
2. Develop Design Options – Create 2‑4 distinct, feasible alternatives that each satisfy the solution scope; include high‑level diagrams, prototypes, and rough cost estimates.
3. Populate the Evaluation Matrix – Score each option against every criterion, apply the agreed weights, and calculate a total score (often using a spreadsheet).
4. Conduct Risk & Feasibility Review – Populate the risk register and perform a quick feasibility check for each option; adjust scores if high‑risk items cannot be mitigated.
5. Present Findings & Recommend – Prepare a concise recommendation package (Design Options Document, Evaluation Matrix, Business Case) and walk the decision‑makers through the analysis, highlighting why the top‑scoring option best meets the business need.

Common Mistakes

Certification Exam Tips

1. Know the Task Sequence: In the BABOK, Design Options precede Solution Recommendation, which precedes Solution Evaluation. Exam questions often ask “What should the BA do next?” – the answer is usually “Develop design options” if requirements are already validated.
2. Distinguish Input vs. Output: Input = Validated Requirements; Output = Design Options Document and Evaluation Matrix. Remember the “⚠️” trap: the BA does not produce a “business case” at this stage; the business case comes later in Strategy Analysis.
3. Technique Matching: If a question mentions “ranking alternatives based on cost, risk, and benefit,” the correct technique is Weighted Scoring (or Cost‑Benefit Analysis).
4. Stakeholder Involvement: The BA must ensure that the Stakeholder Map is updated before evaluating options; missing this step is a common distractor in multiple‑choice items.

Quick Check Questions

1. Scenario: After a requirements workshop, the sponsor asks the BA to show how two possible CRM solutions compare on cost and user adoption. Which technique should the BA use?
   Answer: Weighted Scoring.
   Justification: Weighted scoring lets the BA assign importance to cost and adoption, score each option, and produce a ranked comparison.

2. Scenario: The BA has three design options for an insurance claims automation project. One option is technically feasible but violates a regulatory rule. What should the BA do before scoring the options?
   Answer: Conduct a Feasibility Study (including regulatory compliance).
   Justification: Feasibility checks identify disqualifying constraints, ensuring the evaluation matrix only includes viable alternatives.

3. Scenario: Stakeholders are split on which design option to choose. The BA needs a visual way to capture their preferences and reach consensus. Which artifact is most appropriate?
   Answer: Prototype / Wire‑frame.
   Justification: Prototypes let stakeholders see concrete representations of each option, facilitating informed discussion and decision.

Last‑Minute Cram Sheet (10 One‑liners)

1. Design Options → Output of the “Design Options” task (Requirements Analysis & Design Definition).
2. Solution Recommendation → Output of the “Solution Recommendation” task; input to “Solution Evaluation”.
3. Evaluation Criteria = weighted factors (cost, risk, benefit, compliance).
4. Weighted Scoring, Cost‑Benefit Analysis, AHP = Decision‑Making Techniques.
5. Stakeholder Analysis is a prerequisite for defining evaluation criteria.
6. Feasibility Study = quick check of technical, operational, and economic viability for each option.
7. Risk Register = input to the evaluation matrix; high‑risk items may lower an option’s score.
8. Traceability Matrix links requirements → design options → final solution.
9. ⚠️ “Business Case” is NOT an output of Design Options; it follows the recommendation.
10. ⚠️ The BA does not “choose” the solution alone – the recommendation is presented to decision‑makers for approval.