Falade Timilehin

Posted on Oct 29

BABOK® v3: Requirements Architecture and Design Options

#analysis #architecture #design

1. Introduction

The Requirements Analysis and Design Definition (RADD) knowledge area helps Business Analysts transform business needs into structured requirements, evaluate possible solutions, and recommend an approach that delivers value.

This article focuses on three connected activities:

Defining Requirements Architecture — organising requirements and their relationships into a cohesive structure.
Defining Design Options — identifying possible approaches for addressing business needs and improving the current state.
Analysing Potential Value and Recommending a Solution — evaluating the expected benefits, costs, risks, and feasibility of each option before making a recommendation.

The final output of RADD is a solution recommendation.

The central principle is that requirements, designs, and solution choices should work together to meet business objectives and stakeholder needs.

For example, a hospital wants to improve patient registration and reduce waiting times. The Business Analyst must organise the requirements, identify possible solutions, compare their costs and benefits, and recommend an approach that is suitable for the organisation.

2. Defining Requirements Architecture

What is requirements architecture?

Requirements architecture is the structured organisation of requirements and their relationships, showing how they fit together to support business objectives.

A business solution rarely consists of one isolated requirement. It usually involves multiple requirements relating to processes, data, users, technology, policies, and organisational responsibilities.

Requirements architecture helps the Business Analyst understand how these elements connect.

Why is requirements architecture important?

It helps the organisation:

Ensure requirements work together coherently.
Identify missing requirements and dependencies.
Understand relationships between business needs, requirements, and designs.
Maintain consistency between functional and non-functional requirements.
Identify conflicts between stakeholder expectations.
Link requirements to relevant solution components.
Support traceability and completeness.
Keep requirements aligned with business objectives.

Example: Hospital appointment system

Suppose a hospital plans to introduce an online appointment-booking system.

The requirements may include:

Patients must be able to register.
Patients must be able to search for available appointments.
Patients must be able to book and cancel appointments.
The system must send booking confirmations.
Patient information must be protected.
Staff must be able to manage appointment availability.
Managers must be able to generate operational reports.

These requirements are connected. Appointment booking depends on available appointment data, while confirmation messages depend on successful booking transactions.

Requirements architecture makes these connections visible and helps the analyst determine whether the requirements form a complete and coherent solution.

Functional and non-functional requirements

Requirements architecture should consider both functional and non-functional requirements.

Functional requirements describe what a solution must do.

Examples:

Allow patients to book appointments.
Allow staff to update appointment availability.
Generate appointment reports.

Non-functional requirements describe qualities or constraints relating to how the solution operates.

Examples:

Protect patient information.
Make the service available during agreed operating hours.
Meet agreed response-time expectations.

A solution that provides the required functions but fails to meet important security or performance expectations may not be suitable.

Architecture templates

The course notes explain that architecture templates can guide Business Analysts in creating a complete and structured requirements framework.

Templates provide a consistent way to organise requirements and relationships, helping analysts avoid overlooking important areas.

The structure should still reflect the organisation's needs and the complexity of the change.

3. Requirements Relationships and Viewpoints

Requirements architecture involves identifying, mapping, and assessing relationships between requirements, designs, and other relevant elements.

The objective is to ensure that these relationships are meaningful, clear, and aligned with stakeholder perspectives.

Understanding requirements relationships

Requirements may be related because one depends on another, both support the same business objective, or they must work together within a solution.

For example:

Appointment booking depends on appointment availability.
Appointment confirmation depends on a successful booking.
Appointment reporting depends on accurate appointment data.
Access controls support the protection of patient information.

Mapping these relationships helps the analyst understand dependencies and identify possible gaps.

Why relationships must be clear

The course notes emphasise that relationships should be:

Consistent.
Unambiguous.
Necessary.
Aligned with stakeholder viewpoints.

Unclear relationships can create confusion about why a requirement exists or how it contributes to the solution.

For example, if a reporting requirement is not connected to any business objective or operational need, the analyst should investigate whether it is necessary and what value it is expected to provide.

Stakeholder viewpoints

Different stakeholders view a solution from different perspectives.

Stakeholder viewpoint	Main concern	Example
Business management	Business objectives, cost, and performance	Reduce administrative costs.
End users	Usability and practical needs	Make booking appointments straightforward.
Technical teams	Integration, architecture, and feasibility	Connect the system to existing databases.
Operational support	Maintenance and support requirements	Make system problems easy to diagnose.
Compliance or regulatory stakeholders	Relevant obligations and controls	Protect sensitive patient information.

A single model may not communicate everything every stakeholder needs to understand.

The Business Analyst should therefore select appropriate models and viewpoints to provide a sufficiently complete picture of the requirements.

Using multiple model types

The course notes identify several model types that can represent requirements holistically.

These include:

Process models: Show activities and workflows.
Data models: Show information and relationships between data elements.
User interaction models: Show how users interact with a solution.
Audit models: Represent audit-related requirements and information.
Business models: Represent relevant business structures, activities, or relationships.

Using several model types helps the analyst examine the same solution from different perspectives.

Resolving conflicts

Requirements may conflict because stakeholders have different objectives or because constraints prevent every preference from being satisfied.

For example, users may request a highly customised system, while technical teams recommend a simpler design to reduce integration costs and maintenance complexity.

The Business Analyst should make the conflict visible, examine its implications, and facilitate a decision based on business needs, constraints, and expected value.

The objective is not simply to document every request. It is to establish a coherent requirements structure that supports the intended business outcome.

4. Tools and Techniques for Defining Requirements Architecture

The course notes identify several techniques that help analysts organise requirements and understand their relationships.

4.1 Modelling

Modelling provides structured representations of requirements, processes, information, and relationships.

For example, a process model can show how a customer request moves through an organisation, while a data model can show which information is required at each stage.

Models help identify dependencies, inconsistencies, and missing elements.

4.2 Data modelling

Data modelling helps clarify the information a solution needs and how data elements relate to one another.

For example, a booking system may need relationships between patients, appointments, clinicians, and locations.

Understanding these relationships helps establish what information the solution must manage.

4.3 Organisational modelling

Organisational modelling helps represent relevant roles, structures, and responsibilities.

For example, a process may involve customers, service agents, supervisors, and administrators. Understanding these roles helps clarify responsibilities and access requirements.

4.4 Functional decomposition

Functional decomposition breaks a larger function or capability into smaller, more manageable components.

For example, a customer service platform might be decomposed into:

Customer registration.
Request submission.
Request allocation.
Request tracking.
Resolution.
Reporting.

This makes complex requirements easier to analyse and organise.

4.5 Group collaboration

Stakeholders contribute knowledge about their responsibilities, expectations, and constraints.

Workshops and collaborative discussions can help the analyst identify relationships, resolve conflicting interpretations, and agree on a coherent requirements structure.

4.6 Agile approaches and modelling frameworks

The course notes also identify Agile approaches and modelling frameworks as relevant tools and methodologies.

These provide ways to structure and communicate requirements according to the needs of the project.

The appropriate approach depends on the organisation, project context, and stakeholder needs.

Output of defining requirements architecture

The output is a requirements architecture describing:

The requirements and designs.
Their relationships and dependencies.
Their connections to business objectives.
Relevant contextual factors.

The resulting structure provides a foundation for defining design options.

5. Defining Design Options

What is a design option?

A design option is a possible approach to addressing a business need or achieving a desired future state.

Defining design options involves identifying opportunities for improvement and considering alternative ways of meeting requirements.

The course notes identify important inputs to this task:

Validated and prioritised requirements.
Change strategy.
Requirements architecture.

These inputs help ensure that proposed options address the actual business need rather than being selected simply because a particular technology is available.

Build versus buy

One important decision is whether to develop a solution internally or purchase an existing product.

Build: Develop a solution specifically for the organisation.

Buy: Purchase an existing commercial product.

For example, a company that needs a document approval platform could:

Build its own approval system.
Purchase an existing approval product.
Extend an existing internal platform.
Improve the current manual process without introducing a new system.

Each option has different implications for cost, flexibility, implementation time, integration, and maintenance.

The analyst should assess the options against the organisation's needs and constraints.

Allocating requirements to solution components

Requirements may be allocated to different parts of the proposed solution.

For example, in an online booking system:

Patient registration requirements may be allocated to the registration component.
Booking requirements may be allocated to the appointment management component.
Notification requirements may be allocated to a messaging component.
Reporting requirements may be allocated to the reporting component.

This helps determine how the solution can be organised to meet the requirements while managing cost and maximising potential value.

What can a design option include?

The course notes identify design elements covering:

Policies.
Processes.
Roles.
Software.
Organisational structures.

A design option is therefore not limited to software or technology.

Sometimes the best improvement involves changing a business process, clarifying responsibilities, revising a policy, or combining organisational and technological changes.

6. Tools and Techniques for Defining Design Options

The Business Analyst uses information about the existing state, desired future state, requirements, and solution scope to identify possible approaches.

The course notes highlight the following techniques.

6.1 Root cause analysis

Root cause analysis investigates the underlying causes of a problem rather than concentrating only on its visible symptoms.

For example, a business may experience delays in processing customer requests.

Possible causes could include:

Duplicate data entry.
Unclear approval responsibilities.
Incomplete information.
Poorly integrated systems.

The analyst should investigate the cause before recommending a solution.

Automating a process without understanding the underlying problem may simply make an inefficient process run faster without removing the actual cause of the delay.

6.2 Market analysis

Market analysis helps the organisation understand available products, suppliers, technologies, and alternative solutions.

For example, a company considering a new customer relationship management system may investigate products already available in the market.

The analysis can reveal existing capabilities and help establish whether purchasing a product is preferable to developing a bespoke solution.

6.3 Group techniques

Group techniques allow stakeholders to contribute ideas and evaluate possible approaches.

The course notes mention techniques such as:

Brainstorming.
Interviews.
Surveys.
Workshops.

These techniques help the analyst gather different perspectives and understand stakeholder expectations.

6.4 Document reviews

Existing policies, process documents, system specifications, reports, and other organisational records can provide information about current operations and constraints.

Reviewing these documents helps the analyst understand the existing state and identify opportunities for improvement.

6.5 Mind mapping

Mind mapping visually connects ideas, requirements, and possible design options.

For example, a mind map for improving customer service might connect the main objective to self-service, staff training, workflow automation, reporting, and knowledge management.

It helps stakeholders explore options and understand how they relate to the wider solution.

6.6 Vendor assessment

Vendor assessment compares suppliers and their proposed solutions against agreed criteria.

A scoring matrix can be used to evaluate vendors consistently.

Possible criteria include:

Functional suitability.
Cost.
Integration capabilities.
Security.
Implementation time.
Support arrangements.
Scalability.

The organisation can assign weights to criteria according to their importance.

For example, a highly regulated organisation may place greater weight on security and compliance than on cosmetic customisation.

The highest-scoring option is not automatically the best choice if it fails a mandatory requirement. Essential constraints and risks must still be considered.

7. Stakeholder Roles and Responsibilities in Defining Design Options

Design options require input from people with different types of expertise.

The Business Analyst facilitates the process, but other stakeholders contribute essential information and decision-making authority.

Stakeholder	Main responsibility	Example contribution
Implementation subject matter experts	Assess technical feasibility, constraints, and implementation costs.	Determine whether a proposed system can integrate with existing software.
Domain subject matter experts	Assess operational suitability and benefits for users.	Explain whether the proposed workflow supports everyday business activities.
Project manager	Manage project scope, resources, risks, and delivery considerations.	Assess whether the proposed option fits the available budget and schedule.
Operational support	Evaluate support needs, maintenance, integration costs, and operational complexity.	Determine whether the organisation can support the system after implementation.
Suppliers	Provide details about product capabilities, specifications, and limitations.	Explain whether a commercial product supports required functionality.
Business Analyst	Facilitate analysis, compare options, and document stakeholder input.	Organise evaluation criteria and prepare a recommendation.

Why stakeholder collaboration matters

A solution may appear attractive from one perspective but be unsuitable from another.

For example, a product may offer extensive functionality but require expensive integration. It may be technically feasible but difficult for employees to use.

The analyst brings these perspectives together so that the organisation can evaluate the options more comprehensively.

Important: Facilitating the recommendation process does not necessarily mean the Business Analyst has final authority to approve funding or select the solution.

The course notes identify the sponsor as responsible for approving or rejecting solutions and controlling funding, while the project manager leads selection activities and assesses risks and value.

8. Analysing Potential Value

Once possible design options have been identified, the analyst evaluates their expected value and compares them against business objectives.

Potential value is not limited to financial returns. It can include operational improvements, stakeholder benefits, compliance, service quality, reduced risk, and other outcomes important to the organisation.

What should be assessed?

The course notes identify several considerations.

Financial impacts

Assess the likely costs and financial benefits of each option.

Costs may include purchasing, development, implementation, integration, training, support, and ongoing maintenance.

Potential benefits may include reduced operating costs, increased productivity, or additional revenue.

Tangible benefits

Tangible benefits can be quantified or measured.

Examples include:

Reduced processing costs.
Fewer staff hours spent on repetitive tasks.
Shorter processing times.
Lower error rates.

Intangible benefits

Intangible benefits are more difficult to express directly in financial terms.

Examples include:

Improved customer satisfaction.
Better employee experience.
Increased stakeholder confidence.
Improved reputation.

These benefits should not be ignored simply because they are difficult to measure financially.

Risks

A design option may introduce risks that reduce its expected value.

Examples include implementation delays, integration failures, security concerns, supplier dependency, or low user adoption.

Dependencies

A solution may depend on other systems, projects, resources, or decisions.

For example, a new reporting platform may depend on accurate data being available from an existing operational system.

If a dependency cannot be satisfied, the expected benefits may be delayed or reduced.

Constraints

Constraints limit the available choices.

Examples include:

Budget limits.
Delivery deadlines.
Technical limitations.
Legal or regulatory obligations.
Staff availability.

Organisational culture

The organisation's working practices and willingness to adopt change can affect whether a solution delivers its expected value.

For example, introducing a new workflow tool may provide little benefit if staff do not receive suitable training or continue to use unofficial processes.

Comparing current and future states

Potential value analysis compares the existing situation with the intended future state.

Current state: The problem, operating context, and impact of the existing situation.

Future state: The desired outcomes and improvements expected from the change.

For example:

Measure	Current state	Target future state
Average request processing time	3 working days	1 working day
Manual data entry	Required at several stages	Reduced through integration
Request tracking	Mostly email-based	Centralised status tracking
Management reporting	Prepared manually	Generated from operational data

The figures are illustrative. In a real project, the analyst should establish the baseline and agree realistic targets with stakeholders.

Comparing the current and future states helps determine whether the proposed solution is likely to address the business problem.

9. Tools and Techniques for Analysing Potential Value

The course notes identify several tools and techniques that support value analysis.

9.1 SWOT analysis

SWOT examines:

Strengths: Internal advantages.
Weaknesses: Internal limitations.
Opportunities: External possibilities for improvement.
Threats: External risks or challenges.

For example, a company evaluating a new customer service platform might identify strong internal technical expertise as a strength and limited implementation funding as a weakness.

SWOT helps stakeholders consider the wider context, although it should be combined with other evaluation techniques when detailed cost, risk, or feasibility analysis is needed.

9.2 Business Model Canvas

The Business Model Canvas provides a structured view of how an organisation creates, delivers, and captures value.

It can help stakeholders understand how a proposed change may affect customers, activities, resources, partners, costs, and revenue.

For example, a new self-service platform may change how customers interact with a business and how staff resources are allocated.

9.3 Acceptance criteria

Acceptance criteria define the conditions a requirement or solution component must satisfy.

They can help assess whether a proposed design addresses the stated needs.

For example, an online request system may need to allow users to submit a request, receive confirmation, and track its status.

However, satisfying acceptance criteria does not automatically prove that the overall solution delivers sufficient business value. The wider business objectives and expected outcomes must also be considered.

9.4 Backlog management

Backlog management helps organise and prioritise work items, requirements, or proposed changes.

It is useful when there are more potential improvements than the organisation can deliver immediately.

The analyst and relevant stakeholders can prioritise items according to factors such as business value, urgency, dependencies, and risk.

9.5 Business case reviews

A business case sets out the justification for a proposed investment or change.

Reviewing the business case helps stakeholders assess whether the expected benefits justify the costs and risks.

It also provides a basis for comparing options and determining whether the proposal remains viable as assumptions or circumstances change.

Stakeholder participation in value analysis

The course notes emphasise engaging relevant stakeholders, including:

Implementation experts.
Domain experts.
Customers.
Regulators.
End users.

Their perspectives help ensure that the analysis considers technical, operational, commercial, and compliance-related factors.

10. Recommending a Solution

After analysing the design options, the Business Analyst supports a recommendation based on expected value, feasibility, cost, risk, and alignment with business objectives.

The recommendation should explain why the preferred option is appropriate and make the relevant trade-offs clear.

Three possible outcomes

The course notes identify three broad outcomes.

Option 1: Recommend the best cost-benefit option

Choose the option that provides the most appropriate balance of benefits, costs, risks, and feasibility.

For example, an existing commercial platform may provide the required functionality at a lower total cost than building a new system.

Option 2: Recommend an option despite its cost because compliance requires it

Sometimes a solution must be implemented to meet regulatory or other mandatory obligations, even when its direct financial return is limited.

In these circumstances, the analyst should make the obligation, cost, and risk implications clear.

Option 3: Recommend no action when the costs are unreasonable

If none of the available options provides sufficient value or is viable within the relevant constraints, the organisation may decide not to proceed.

This should be an informed decision rather than an assumption that a solution must always be implemented.

The analyst may also recommend further investigation or proof-of-concept testing where uncertainty prevents a reliable decision.

Proof of concept

A proof of concept (PoC) tests whether a proposed idea or technology can work under relevant conditions.

For example, before purchasing an expensive system, an organisation might test whether it can integrate with its existing database.

A PoC can reduce uncertainty, reveal technical limitations, and provide evidence for the decision.

It does not necessarily prove that the complete solution is commercially or operationally viable; wider cost, risk, and business-value considerations remain important.

Stakeholder responsibilities in the recommendation

According to the course notes:

Business Analyst: Facilitates analysis and documents stakeholder input to support the recommendation.
Project manager: Leads selection activities and assesses risks and value.
Sponsor: Approves or rejects the proposed solution and controls funding.

The exact decision-making arrangements depend on the organisation, but the key learning point is that analysis, recommendation, approval, and funding are not necessarily the responsibility of the same person.

What should a recommendation communicate?

A useful recommendation should make clear:

Which option is preferred.
How it addresses the business need.
What benefits are expected.
What costs and resources are required.
What risks and dependencies exist.
How it compares with the alternatives.
What assumptions or uncertainties remain.
What decision or approval is required.

The recommendation should give stakeholders enough information to make an informed decision.

11. End-to-End Scenario: Choosing a Digital Expense Management System

Imagine an organisation where employees submit expenses through email and spreadsheets. Managers approve claims manually, and the finance team spends significant time reconciling receipts.

The organisation wants to reduce administrative effort and improve visibility of expenditure.

Stage 1: Define requirements architecture

The Business Analyst organises the requirements into related areas.

These might include:

Employee expense submission.
Receipt management.
Manager approval.
Finance review.
Payment processing.
Reporting.
Access controls and audit records.

The analyst maps relationships between these requirements and the business objectives.

For example, automated approval notifications depend on a functioning approval workflow.

Stage 2: Define design options

The analyst identifies several approaches:

Option A: Improve the existing spreadsheet and email process.
Option B: Purchase an existing expense management product.
Option C: Build a bespoke expense management system.

Each option must be assessed against the requirements, solution scope, and organisational constraints.

Stage 3: Involve stakeholders

Implementation experts assess integration and technical feasibility.

Finance staff assess whether the options support financial controls and reporting.

Employees and managers assess usability and workflow suitability.

The project manager considers resources, timing, and delivery risks.

Suppliers provide information about their products and limitations.

Stage 4: Analyse potential value

The analyst compares each option using relevant criteria.

Evaluation criterion	Option A: Improve current process	Option B: Buy a product	Option C: Build a bespoke system
Initial cost	Potentially low	Purchase and implementation costs	Development costs
Implementation time	Potentially short	Depends on product and integration	Depends on scope and complexity
Customisation	Limited by existing tools	Depends on product	Potentially extensive
Maintenance	Continued manual effort	Supplier and internal support arrangements	Internal or contracted support required
Integration	May remain limited	Depends on available integrations	Can be designed for the required integrations
Risk	Existing inefficiencies may remain	Supplier and product dependency	Delivery and maintenance complexity

The table illustrates the types of trade-offs to assess; the actual outcome depends on the organisation's circumstances.

Stage 5: Recommend a solution

Suppose the existing process cannot meet mandatory audit and reporting requirements, while a commercial product can satisfy them at a reasonable total cost.

The Business Analyst may recommend purchasing the product, provided technical, security, operational, and commercial assessments support that decision.

If the product cannot meet a mandatory requirement, it may need to be rejected regardless of its score on other criteria.

Stage 6: Obtain a decision

The recommendation is presented to the relevant decision-makers.

The sponsor considers approval and funding, while the project manager addresses delivery implications.

The Business Analyst records the analysis, assumptions, stakeholder feedback, and rationale supporting the recommendation.

Lesson: Requirements architecture establishes what needs to fit together. Design options explore how the need might be addressed. Potential value analysis helps determine which option should be recommended.

12. Common Mistakes to Avoid in the Course Test

Mistake 1: Confusing requirements architecture with a technical architecture

In this course context, requirements architecture is concerned with organising requirements and their relationships to support business objectives. It is not limited to designing servers, networks, or software components.

Mistake 2: Treating requirements as isolated items

Requirements often depend on or relate to one another. The analyst must consider the wider structure and resolve conflicts.

Mistake 3: Assuming a design option must be software

Design options can include changes to processes, policies, roles, and organisational structures as well as software.

Mistake 4: Recommending a solution before analysing alternatives

A recommendation should be supported by an assessment of costs, benefits, risks, feasibility, constraints, and stakeholder needs.

Mistake 5: Selecting the cheapest option automatically

The lowest-cost option may fail to meet mandatory requirements, introduce unacceptable risks, or deliver insufficient value.

Mistake 6: Ignoring stakeholders

Technical experts, domain experts, operational support, suppliers, users, project managers, and sponsors contribute different forms of knowledge or authority.

Mistake 7: Assuming the highest-scoring vendor must win

Scoring matrices help compare options, but mandatory requirements and unacceptable risks must still be considered.

Mistake 8: Assuming no action is always a failure

If no viable option provides sufficient value, recommending no action or further investigation can be a reasonable outcome.

13. Quick Revision Table

Topic	Key point to remember
Requirements architecture	Organises requirements and relationships into a coherent structure.
Main purpose	Support completeness, consistency, traceability, and alignment with business objectives.
Requirements relationships	Should be clear, consistent, unambiguous, necessary, and meaningful.
Stakeholder viewpoints	Different stakeholders need different perspectives on the solution.
Modelling	Helps represent processes, data, interactions, audits, and business structures.
Functional decomposition	Breaks a larger function into smaller, manageable components.
Design options	Alternative approaches for meeting business needs.
Build versus buy	Compares bespoke development with purchasing an existing solution.
Root cause analysis	Investigates the underlying cause of a problem.
Market analysis	Investigates available products, suppliers, and solution approaches.
Vendor assessment	Compares suppliers and products against agreed criteria.
Implementation experts	Assess technical feasibility, constraints, and costs.
Domain experts	Assess operational suitability and user benefits.
Operational support	Evaluates support, maintenance, and integration implications.
Potential value	Considers benefits, costs, risks, dependencies, constraints, and business objectives.
SWOT	Examines strengths, weaknesses, opportunities, and threats.
Business Model Canvas	Provides a structured view of how an organisation creates and delivers value.
Backlog management	Organises and prioritises requirements or work items.
Proof of concept	Tests whether a proposed idea or technology can work under relevant conditions.
Solution recommendation	Communicates the preferred option and the evidence supporting it.
Sponsor	Approves or rejects the solution and controls funding, according to the course notes.

14. Self-Assessment Checklist

Before taking the course test, make sure you can explain the following without looking at your notes.

[ ] What is requirements architecture?
[ ] Why should requirements and their relationships be mapped?
[ ] How do stakeholder viewpoints influence requirements architecture?
[ ] Why might multiple model types be needed?
[ ] What is functional decomposition?
[ ] What inputs support the definition of design options?
[ ] What is the difference between building and buying a solution?
[ ] How can root cause analysis help identify suitable design options?
[ ] How do vendor assessments and scoring matrices support comparisons?
[ ] What are the responsibilities of implementation experts, domain experts, project managers, operational support, suppliers, and Business Analysts?
[ ] How do tangible and intangible benefits differ?
[ ] Why must risks, dependencies, constraints, and organisational culture be considered?
[ ] What is a proof of concept?
[ ] When might a solution be recommended despite its cost?
[ ] When might recommending no action be appropriate?
[ ] What is the difference between making a recommendation and approving funding?

Final Takeaway

The key to this RADD topic is understanding how the three activities connect:

Requirements Architecture → Design Options → Potential Value Analysis → Solution Recommendation

First, organise the requirements and establish how they relate to one another. Next, identify realistic ways of meeting those requirements. Finally, compare the alternatives using business objectives, costs, benefits, risks, feasibility, constraints, and stakeholder input.

A strong Business Analyst does not simply recommend a preferred technology. They provide a structured, evidence-based recommendation that explains how the proposed solution addresses the business need and why it represents an appropriate choice for the organisation.