Business Analysis 101: Requirements Life Cycle Management - Requirements vs. Design, Business Requirements, Stakeholder Requirements, Solution Requirements

What This Is

Requirements vs Design is the discipline of distinguishing what the business needs (business, stakeholder, and solution requirements) from how the solution will satisfy those needs (design). In the BA lifecycle the BA elicits, analyzes, and documents requirements; the design (often produced by architects or developers) translates those requirements into a concrete solution blueprint.

Real?world example: A bank wants a new Customer Relationship Management (CRM) system to improve sales?lead tracking. The BA captures business requirements (e.g., “increase cross?sell rate by 15?%”), stakeholder requirements (e.g., “sales reps need a mobile view of leads”), and solution requirements (e.g., “the system shall provide a REST API for mobile access”). The design then defines the technical architecture, data model, and UI wireframes that will deliver those solution requirements.

Key Terms & Techniques

• Business Requirements (BR) – High?level statements of the problem or opportunity; produced in the Business Analysis Planning & Monitoring (BAPM) and Elicitation knowledge areas. Deliverable: Business Requirements Document (BRD).
• Stakeholder Requirements (SR) – Detailed needs of individual or groups of stakeholders; captured during Elicitation. Deliverable: Stakeholder Requirements Specification.
• Solution Requirements (SolR) – The characteristics the solution must have; split into Functional (what the system does) and Non?functional (how it performs). Produced in Requirements Life Cycle Management (RLCM). Deliverable: Solution Requirements Specification.
• Requirement Types Matrix – A table that maps BR-SR-SolR, showing traceability; belongs to RLCM. Deliverable: Requirement Traceability Matrix (RTM).
• MoSCoW Prioritization – Must, Should, Could, Won’t – a technique to rank requirements; used in Elicitation and RLCM. Deliverable: Prioritized Requirements List.
• Use Cases / User Stories – Narrative formats that capture functional requirements; part of Elicitation and RLCM. Deliverable: Use?Case Model or Product Backlog.
• Wireframes / Prototypes – Low?fidelity visual representations that illustrate solution design; created in Solution Evaluation (or as a design artifact). Deliverable: Wireframe Pack, Prototype Demo.
• Design Specification (DS) – Detailed technical blueprint (architecture, data model, interface design) that implements solution requirements; belongs to Solution Evaluation (or “Design” knowledge area in some organizations). Deliverable: Architecture Diagram, Detailed Design Document.
• Verification & Validation (V&V) – Activities that ensure requirements are correctly captured (verification) and that the solution meets business needs (validation); core to RLCM and Solution Evaluation. Deliverable: V&V Report, Acceptance Criteria.
• Change Control Process – Formal method for managing requirement or design changes; part of BAPM and RLCM. Deliverable: Change Request Log, Baseline Documentation.

Step?by?Step / Process Flow

1. Identify & Analyze Business Need – Review the project charter, market analysis, or problem statement to surface the business requirement (e.g., “reduce claim?processing time”).
2. Elicit Stakeholder Requirements – Conduct workshops, interviews, and surveys with sales, claims, IT, and compliance teams; capture each stakeholder’s needs (e.g., “claims adjuster needs a single?click status update”).
3. Translate to Solution Requirements – Decompose stakeholder requirements into functional and non?functional solution requirements; create a Requirement Types Matrix to maintain traceability.
4. Validate & Baseline Requirements – Review the compiled requirements with all stakeholders, resolve conflicts, obtain sign?off, and baseline the requirement set (creates the Baseline Requirements Document).
5. Collaborate on Design (but don’t own it) – Work with architects and developers to ensure the design (wireframes, data model, integration specs) aligns with the solution requirements; document any design?related decisions that affect requirements.

Common Mistakes

Certification Exam Tips

1. Know the Knowledge?Area Boundaries – Elicitation produces requirements; Solution Evaluation (or “Design” in some contexts) produces design artifacts. Exam questions often ask you to pick the activity that belongs to the correct KA.
2. Hierarchy Matters – Remember the BABOK hierarchy: Business-Stakeholder-Solution. If a question asks “Which requirement type is most abstract?” answer Business Requirement.
3. “What does the BA do next?” – After a requirements workshop, the next BA step is Validate & Baseline (not design). Look for verbs like “confirm,” “obtain sign?off,” or “baseline.”
4. Prioritization Techniques – MoSCoW, 100?point, and Weighted Scoring are all valid; the exam will test whether you can match the technique to the scenario (e.g., “must?have vs. nice?to?have”).
5. Traceability is a Must?Know – The RTM links BR-SR-SolR. If a question mentions “ensuring a change is reflected across all requirement levels,” the answer is Requirement Traceability Matrix.

Quick Check Questions

1. Scenario: After a stakeholder workshop, the sales team says “we need the lead list exported to Excel” while the compliance team says “the export must be encrypted.” Which BABOK artifact should the BA create to capture both needs?
   Answer: Solution Requirements Specification (functional requirement for export + non?functional requirement for encryption).
   Justification: Both statements describe how the solution must behave; they belong to functional and non?functional solution requirements, not business or stakeholder requirements.

2. Scenario: The project sponsor asks the BA to show a visual mock?up of the new CRM’s home page before any functional requirements are approved. What should the BA do?
   Answer: Create a Wireframe/Prototype after baseline requirements are signed off, and use it to validate the solution requirements, not as a requirement itself.
   Justification: Design artifacts support validation but do not replace the need for approved requirements; the BA must not treat the wireframe as a requirement.

3. Scenario: During requirements validation, a stakeholder objects that a functional requirement conflicts with a regulatory non?functional requirement. Which technique helps resolve the conflict?
   Answer: MoSCoW Prioritization (or any prioritization technique) to negotiate “Must” vs. “Should” items and achieve consensus.
   Justification: Prioritization clarifies which requirement is non?negotiable (regulatory) and which can be adjusted.

Last?Minute Cram Sheet (10 One?liners)

1. Elicitation = activity; Requirements = output. The BA elicits information, not the requirements themselves.
2. Business Requirements are the highest?level “why” statements; they never contain “shall” language.
3. Stakeholder Requirements translate the “why” into “who needs what.”
4. Solution Requirements are the only layer that uses “shall” statements (functional & non?functional).
5. Requirement Traceability Matrix links BR-SR-SolR and is the primary artifact for change impact analysis.
6. MoSCoW is a prioritization technique, not a categorization of requirement types.
7. Wireframes/Prototypes belong to the design artifact set; they support validation but are not requirements.
8. Baseline = freeze the requirement set; any later change must go through the Change Control Process.
9. Verification checks that requirements are correctly written; Validation checks that the solution meets the business need.
10. Non?functional Requirements (performance, security, compliance) often drive the architecture and must be captured before detailed design begins.

Good luck – you now have the practical map to navigate Requirements vs Design and ace the IIBA exams!