1. Introduction to the RADD Knowledge Area
The Requirements Analysis and Design Definition (RADD) knowledge area focuses on transforming information gathered from stakeholders into clear, structured, and useful requirements and designs.
During elicitation, a Business Analyst (BA) gathers information about business needs, stakeholder expectations, problems, and opportunities. However, gathering information alone is not enough. The analyst must organise, analyse, model, verify, and validate the information so that it can guide the development or selection of a suitable solution.
The purpose of RADD is to ensure that requirements and designs are sufficiently clear, complete, consistent, and aligned with business objectives to support effective decision-making and implementation.
For example, if a hospital wants to reduce patient waiting times, the Business Analyst must understand the current process, identify the underlying problems, document what the future process should achieve, and evaluate possible solutions.
The solution might involve a new appointment-booking system, improved patient registration, or changes to existing procedures. RADD helps the analyst define and assess the requirements and designs needed to address the business need.
Why RADD matters
RADD helps organisations to:
- Translate business needs into structured requirements and designs.
- Identify gaps, contradictions, assumptions, and constraints.
- Represent processes, information, people, and capabilities clearly.
- Check that requirements are of sufficient quality before implementation.
- Confirm that requirements and designs support business objectives.
- Assess whether potential solutions can deliver meaningful business value.
- Improve communication between stakeholders, analysts, developers, testers, and decision-makers.
Key principle: Requirements describe needs and desired outcomes, while designs represent possible ways of satisfying those needs.
A requirement may state what the business needs. A design may describe how a solution could meet that requirement.
2. The Six RADD Tasks
The RADD knowledge area contains six tasks:
- Specify and Model Requirements.
- Verify Requirements.
- Validate Requirements.
- Define Requirements Architecture.
- Define Design Options.
- Analyse Potential Value and Recommend Solution.
The first three tasks are particularly important in the course notes supplied, especially the specification and modelling of requirements, verification, and validation.
Task 1: Specify and Model Requirements
This task involves analysing information obtained through elicitation and expressing it in an organised, understandable form.
The Business Analyst uses text, diagrams, matrices, and other models to communicate requirements and designs to stakeholders.
Example: A hospital wants to introduce an online appointment system. The analyst documents the patient's booking requirements and models the process from selecting an appointment to receiving confirmation.
The output should provide a shared understanding of what is needed.
Task 2: Verify Requirements
Verification checks whether requirements and designs meet appropriate quality standards.
The analyst examines whether the requirements are clear, complete, consistent, feasible, and testable.
Example: A requirement states, “The system should be fast.”
This is vague because it does not define what fast means. The analyst could refine it into a measurable requirement, such as:
“The system must display appointment search results within two seconds under the agreed operating conditions.”
Verification improves the quality of the requirement before it progresses to later stages.
Task 3: Validate Requirements
Validation determines whether requirements and designs support the business need and are expected to deliver value.
A requirement can be written clearly and correctly but still fail to address the actual business problem.
Example: A hospital may specify a technically sound appointment-booking system. However, if its main problem is that patients are not reminded about appointments, the proposed system may not address the most important cause of missed appointments unless reminders are included.
Validation helps the analyst establish whether the requirements and designs are appropriate for the intended business outcome.
Task 4: Define Requirements Architecture
This task organises individual requirements and designs into a coherent structure.
The analyst considers how requirements relate to one another and how they fit together to support the overall solution.
For example, an online appointment system may have related requirements covering patient registration, appointment availability, booking confirmation, reminders, and cancellation.
A requirements architecture helps stakeholders understand these relationships and identify dependencies or gaps.
Task 5: Define Design Options
The Business Analyst identifies and describes possible approaches for meeting the requirements.
Options may include purchasing commercial off-the-shelf software, developing a bespoke solution, or adapting an existing system.
For example, a hospital considering an appointment system might compare:
- Purchasing an existing healthcare appointment platform.
- Building a system specifically for its needs.
- Extending its current patient management software.
The analyst helps assess the available options against the business need, constraints, feasibility, and expected benefits.
Task 6: Analyse Potential Value and Recommend Solution
This task assesses the potential value of different solution options and supports a recommendation.
The analyst considers factors such as expected benefits, costs, risks, feasibility, and alignment with business objectives.
For example, a bespoke appointment system might provide greater customisation but require more time and money. An existing commercial product might be quicker to implement but offer fewer opportunities for customisation.
The analyst evaluates these trade-offs to help stakeholders make an informed decision.
Exam reminder: Be able to distinguish between defining possible solution options and analysing their potential value.
3. RADD Core Concepts
RADD uses six core concepts to help Business Analysts understand and communicate the relationship between business needs, change, solutions, context, value, and stakeholders.
| Core concept | Meaning in business analysis | Example |
|---|---|---|
| Need | A problem or opportunity that creates a reason for change. | Patients are waiting too long to book appointments. |
| Change | The transformation required to address the need. | Introducing online appointment booking. |
| Solution | A specific way of satisfying one or more needs. | Implementing an appointment management platform. |
| Context | The circumstances and environment surrounding the change. | Existing hospital systems, staff capacity, policies, and data requirements. |
| Value | The benefit or importance of the solution to stakeholders. | Reduced waiting times and fewer missed appointments. |
| Stakeholder | An individual, group, or organisation involved in or affected by the change. | Patients, receptionists, clinicians, managers, and IT teams. |
How the six concepts work together
A business need creates a reason for change. The Business Analyst works with stakeholders to understand that need and the context in which the change will occur.
The analyst then identifies and evaluates possible solutions, considering their feasibility and potential value.
The objective is not simply to produce requirements. It is to ensure that the requirements and designs support a meaningful business outcome.
Resolving contradictions
Stakeholders may have conflicting expectations.
For example:
- Patients want an appointment system that is easy to use.
- Clinicians want detailed information before appointments.
- Managers want to reduce operating costs.
- IT teams want a system that can integrate securely with existing software.
The Business Analyst must explore these perspectives, identify conflicts, and work with stakeholders to establish priorities and appropriate trade-offs.
The final requirements and designs should reflect an agreed understanding of the business need and the solution's intended value.
4. Specifying and Modelling Requirements and Designs
Specification and modelling turn elicitation results into organised representations that stakeholders can understand, discuss, and assess.
The analyst chooses a suitable format according to the information being communicated, the complexity of the problem, the project stage, and the audience.
The course notes identify five modelling categories.
4.1 People Models
People models describe individuals, groups, roles, or relationships relevant to a solution.
They help identify who interacts with a system or participates in a business process.
Example: An online hospital appointment system may involve patients, receptionists, clinicians, and system administrators.
A people model can help clarify who performs each activity and who needs access to particular information.
4.2 Rationale Models
Rationale models explain the reasoning behind decisions, requirements, or proposed changes.
They help stakeholders understand why a particular requirement or decision is important.
Example: A hospital introduces automated appointment reminders because missed appointments reduce service capacity and waste clinical resources.
Documenting the rationale helps stakeholders understand the business justification for the change.
4.3 Activity Flow Models
Activity flow models represent the sequence of activities within a process.
They help analysts identify unnecessary steps, bottlenecks, dependencies, and opportunities for improvement.
Example: A patient books an appointment, receives confirmation, attends the hospital, and checks in.
A process model can show where delays occur and where automation may improve efficiency.
4.4 Capability Models
Capability models describe what an organisation or solution needs to be able to do.
They focus on abilities rather than merely listing individual activities.
Example: A hospital may need capabilities for patient registration, appointment management, clinical communication, and reporting.
A capability model helps determine which abilities are required to support the future state.
4.5 Data Models
Data models describe information and the relationships between data elements.
They help clarify what information a solution must store, use, or exchange.
Example: An appointment system may need patient details, appointment dates, clinician information, and booking status.
A data model can help identify relationships between patients, appointments, and clinicians.
Why modelling is important
Modelling helps the Business Analyst:
- Break down complex business problems.
- Identify missing requirements and dependencies.
- Examine changes, gaps, and constraints.
- Communicate ideas to different stakeholder groups.
- Establish a shared understanding of the proposed solution.
- Represent requirements at the appropriate level of detail.
Choosing the right level of detail
Requirements should be presented at a level appropriate to their audience and purpose.
Senior managers may need a high-level view of business capabilities and expected benefits. Developers may need detailed functional requirements, data structures, and system interactions. Testers may need measurable acceptance criteria.
The analyst should avoid overwhelming stakeholders with unnecessary detail while ensuring that important information is not omitted.
5. Tools and Techniques for Specification and Modelling
The course notes emphasise the use of structured techniques, standardised notations, diagrams, matrices, and collaborative review.
The choice of technique depends on the problem being analysed and the information stakeholders need.
Textual requirements
Text is useful for expressing specific business rules, functional requirements, constraints, and expected system behaviour.
A good requirement should communicate one clear expectation and avoid ambiguous language.
Weak requirement:
“The system should be user-friendly.”
Improved requirement:
“Users must be able to locate an available appointment and submit a booking using the agreed booking process.”
The improved version is more specific, although additional acceptance criteria may still be needed to define how usability will be assessed.
Matrices
Matrices organise information into rows and columns.
They can be used to compare requirements, record dependencies, identify stakeholders, and map requirements to business objectives.
Example: A requirements matrix might list each requirement, its priority, its business justification, and its acceptance criteria.
Diagrams
Diagrams represent processes, relationships, interactions, or structures visually.
They can help stakeholders understand complex information more easily than lengthy descriptions.
For example, a process flow diagram can show how a patient moves through appointment booking and confirmation.
Acceptance criteria
Acceptance criteria define the conditions that must be met for a requirement or solution component to be accepted.
They help make requirements measurable and testable.
For example, acceptance criteria for appointment booking might specify that:
- The patient can select an available appointment.
- The system prevents the same appointment slot from being booked twice.
- A successful booking produces a confirmation.
- An unavailable appointment cannot be selected.
These criteria provide a basis for assessing whether the specified behaviour has been delivered.
Collaboration and review
Stakeholders should participate in elicitation, modelling, and review.
Collaboration helps identify misunderstandings, resolve contradictions, and establish agreement about requirements and designs.
The analyst should choose techniques that help stakeholders communicate effectively rather than assuming that one format will work for everyone.
6. Verifying Requirements and Designs
Verification determines whether requirements and designs are of sufficient quality to support further analysis, design, development, or implementation.
The input is the specified and modelled requirements and designs. The output is the verified requirements and designs.
Quality characteristics of requirements
The course notes identify the following quality characteristics.
| Characteristic | Meaning | Example of a problem |
|---|---|---|
| Atomic | Expresses a single requirement or expectation. | One requirement combines booking, payment, reporting, and cancellation. |
| Complete | Contains the information needed to understand the requirement. | A booking requirement does not explain what happens after submission. |
| Consistent | Does not conflict with other requirements or models. | One requirement permits cancellation while another prohibits it in the same circumstances. |
| Concise | Avoids unnecessary wording. | A requirement contains repeated explanations that do not add meaning. |
| Feasible | Can reasonably be achieved within relevant constraints. | A requirement exceeds the available technology or budget. |
| Unambiguous | Has one clear interpretation. | “The system must respond quickly.” |
| Testable | Can be assessed against observable or measurable criteria. | “The system should provide excellent service.” |
| Prioritised | Has an understood level of importance. | A critical legal requirement is treated like a minor enhancement. |
| Understandable | Can be interpreted by its intended audience. | A business requirement is written in unnecessarily technical language. |
These characteristics help ensure that requirements are suitable for use by the people who will develop, test, approve, or implement the solution.
Verification questions
When reviewing a requirement, the Business Analyst can ask:
- Is the requirement clear?
- Does it express one main expectation?
- Is important information missing?
- Does it conflict with another requirement?
- Is it achievable within the relevant constraints?
- Can its satisfaction be tested?
- Has its priority been established?
- Will the intended audience understand it?
Verification techniques
The course notes highlight techniques such as:
- Checklists.
- Requirements repositories and life cycle management tools.
- Reviews with stakeholders and subject matter experts.
- Acceptance criteria.
- Item tracking.
- Metrics and key performance indicators (KPIs).
These techniques help identify quality problems and make requirements easier to manage.
For example, a requirements repository can help analysts track changes and relationships, while a review checklist can ensure that important quality characteristics are considered consistently.
Important distinction: Verification checks the quality of requirements and designs. It does not, by itself, establish that they are the right requirements for the business.
7. Validating Requirements and Designs
Validation determines whether requirements and designs are aligned with business needs, objectives, and the intended future state.
A requirement may be complete, consistent, and testable but still fail to deliver meaningful value.
For example, a hospital might define a technically precise reporting feature. If the feature does not help staff address the actual causes of patient delays, it may not contribute sufficiently to the intended business outcome.
Validation helps ensure that the proposed requirements and designs are worth pursuing.
What validation examines
The Business Analyst considers whether:
- Requirements address the identified business need.
- Designs support the intended future state.
- Expected benefits are realistic.
- Assumptions are understood.
- Risks could undermine the expected value.
- The solution supports stakeholder needs.
- Requirements remain aligned with the agreed scope.
- Success can be assessed against appropriate criteria.
Assumptions and risks
Assumptions are beliefs treated as true for planning or decision-making, even though they may not yet have been confirmed.
For example, a hospital might assume that most patients can access online appointment booking.
If many patients cannot use the online service, the solution may need additional options, such as telephone booking or assisted registration.
Risks are uncertain events or conditions that could affect the outcome.
For example, a lack of integration with existing hospital systems could delay implementation or reduce the usefulness of the new appointment platform.
The analyst should work with stakeholders to identify and assess assumptions and risks before committing to a solution.
Baselines and target metrics
Validation can use baseline and target measurements to establish whether the proposed change is expected to deliver value.
- Baseline: The current state before the change.
- Target: The desired state after the change.
Suppose a hospital's average appointment-booking time is currently 12 minutes, and the target is 5 minutes.
The difference provides a measurable objective for assessing the intended improvement.
Other measures might include:
- Average waiting time.
- Number of missed appointments.
- Cost per appointment processed.
- Staff time spent on administration.
- Patient satisfaction.
The selected measures should reflect the business objectives rather than simply what is easiest to count.
What happens when a requirement does not deliver value?
If a requirement does not support the agreed business need or future state, the analyst may work with stakeholders to:
- Refine it.
- Reconsider its priority.
- Defer it.
- Exclude it from the agreed scope.
This prevents effort and resources from being spent on features that do not provide sufficient value.
8. Tools and Techniques for Validating Requirements and Designs
The course notes identify several ways to assess whether requirements and designs are expected to deliver the intended business benefits.
Financial analysis
Financial analysis helps assess the costs and expected financial benefits of a solution.
For example, an organisation may compare the cost of buying a software product with the cost of building and maintaining a bespoke alternative.
The analyst can help stakeholders assess whether the anticipated benefits justify the investment.
Return on Investment (ROI)
ROI is one measure used to evaluate financial returns relative to investment.
A commonly used simplified formula is:
ROI = (Net Benefit ÷ Investment Cost) × 100%
For example, if a solution costs £20,000 and produces an estimated net benefit of £30,000 over the period being assessed:
ROI = (£30,000 ÷ £20,000) × 100% = 150%.
This calculation assumes that £30,000 is the net benefit after relevant costs have been accounted for. In practice, the analyst should make the assumptions, time period, and treatment of costs explicit.
ROI is useful, but it should not be the only consideration. Security, compliance, service quality, accessibility, and other non-financial benefits may also be important.
Risk analysis
Risk analysis examines factors that could prevent the solution from achieving its intended benefits.
For example, a new patient registration platform may face risks involving data quality, integration, user adoption, or service availability.
The analyst helps stakeholders understand these risks and consider whether the solution remains appropriate.
Stakeholder reviews
Group reviews allow stakeholders to assess requirements and designs together.
They can help determine whether the proposed solution addresses business needs and whether its expected benefits are realistic.
Checklists and acceptance criteria
Checklists provide a structured way to review alignment with objectives, while acceptance criteria help establish whether defined requirements have been satisfied.
Used together, these techniques support more consistent assessment of solution suitability and expected value.
9. Verification vs Validation: A Critical Exam Topic
This distinction is one of the most important concepts in RADD.
| Area | Verification | Validation |
|---|---|---|
| Main question | Are the requirements and designs of sufficient quality? | Do the requirements and designs address the business need? |
| Primary focus | Quality and clarity. | Business alignment and value. |
| Checks | Completeness, consistency, testability, feasibility, and ambiguity. | Business objectives, stakeholder needs, expected benefits, assumptions, and risks. |
| Example question | Can the requirement be understood and tested? | If implemented, would it help achieve the intended outcome? |
| Potential problem | The requirement is unclear or contradictory. | The requirement is clear but does not solve the right problem. |
Easy way to remember
Verification = quality.
Validation = value and business need.
Example
A company wants to reduce the time employees spend submitting expense claims.
Requirement A states:
“The expense system must allow employees to submit claims.”
It is understandable, but it may not be sufficiently detailed or testable. Verification would examine whether it needs clearer conditions and acceptance criteria.
Now suppose the company specifies a detailed automated expense-reporting feature that works exactly as documented, but employees still spend considerable time manually entering receipt information.
The requirement may have been verified successfully, yet validation could reveal that the solution does not adequately address the underlying business problem.
The lesson is that a well-written requirement is not automatically a valuable requirement.
10. End-to-End RADD Scenario: Improving an NHS Appointment System
Consider an NHS service experiencing long appointment-booking delays and a high number of missed appointments.
Step 1: Understand the need
The Business Analyst works with patients, receptionists, clinicians, service managers, and IT staff to understand the problem.
The identified needs might include reducing booking delays, improving appointment communication, and reducing missed appointments.
Step 2: Specify and model requirements
The analyst documents the requirements and develops suitable models.
These may include:
- A process model showing the current and future booking processes.
- A people model showing the relevant roles.
- A data model identifying patient and appointment information.
- Acceptance criteria defining expected system behaviour.
Step 3: Verify requirements
The analyst checks whether the requirements are atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritised, and understandable.
A requirement that says “send reminders promptly” may need a defined timeframe and clear conditions.
Step 4: Validate requirements
The analyst checks whether the requirements address the original business need.
For example, the team may discover that appointment reminders are valuable, but the main cause of booking delays is limited staff capacity and a poorly designed registration process.
The requirements may therefore need to address both the booking process and reminders.
Step 5: Define requirements architecture
The analyst organises related requirements and identifies dependencies between registration, booking, notifications, and reporting.
Step 6: Define design options
The analyst compares purchasing an existing platform, building a bespoke application, or extending an existing system.
Step 7: Analyse potential value and recommend a solution
The analyst considers costs, feasibility, risks, and expected benefits.
The recommendation should explain why the preferred option offers an appropriate response to the business need.
Step 8: Measure the intended outcome
The team establishes baseline and target measures, such as average booking time and missed-appointment rates.
After implementation, the organisation can assess whether the change delivered the expected improvements.
Lesson: RADD connects the analysis of requirements with the evaluation of possible solutions and their expected value.
11. Common Mistakes to Avoid in the Course Test
Mistake 1: Confusing verification with validation
Remember that verification assesses requirement quality, while validation assesses alignment with the business need and intended value.
Mistake 2: Assuming every stakeholder request should become a requirement
A request must be assessed against the business need, priorities, constraints, scope, and expected value.
Mistake 3: Treating modelling as diagram creation only
Modelling includes structured representations such as text, matrices, and diagrams. Its purpose is to analyse and communicate requirements and designs.
Mistake 4: Assuming detailed requirements are automatically good requirements
A requirement may be detailed but still be ambiguous, inconsistent, infeasible, or unaligned with business objectives.
Mistake 5: Ignoring assumptions and risks
A solution may appear valuable only because an important assumption has not been challenged. Validation should explore whether expected benefits are realistic.
Mistake 6: Evaluating solutions only on cost
Financial analysis matters, but solution evaluation should also consider risks, feasibility, stakeholder needs, and alignment with business objectives.
Mistake 7: Forgetting the stakeholder perspective
Requirements and designs must be understandable and relevant to the people affected by the change. Collaboration is essential for resolving contradictions and establishing agreement.
12. Quick Revision Notes
| Topic | Remember this |
|---|---|
| Purpose of RADD | Analyse and structure requirements and designs so they support business needs and value. |
| Six tasks | Specify and Model; Verify; Validate; Define Requirements Architecture; Define Design Options; Analyse Potential Value and Recommend Solution. |
| Core concepts | Need, Change, Solution, Context, Value, Stakeholder. |
| People models | Represent relevant people, roles, and relationships. |
| Rationale models | Explain the reasoning behind decisions or requirements. |
| Activity flow models | Represent the sequence of activities in a process. |
| Capability models | Represent what an organisation or solution needs to be able to do. |
| Data models | Represent information and relationships between data elements. |
| Verification | Check quality: atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritised, and understandable. |
| Validation | Check business need, stakeholder benefits, future-state alignment, assumptions, risks, and expected value. |
| Baseline | Measurement of the current state. |
| Target | Desired measurement after the change. |
| Acceptance criteria | Conditions used to assess whether a requirement has been satisfied. |
| Financial analysis | Helps compare costs and expected financial benefits. |
| Risk analysis | Examines uncertainty that could affect the solution or its expected benefits. |
| Design options | Alternative approaches to meeting the requirements. |
| Potential value | The expected benefits and importance of a solution to stakeholders. |
13. Self-Assessment Checklist
Before taking the course test, make sure you can answer the following questions without referring to your notes:
- [ ] What is the purpose of the RADD knowledge area?
- [ ] Can I name all six RADD tasks?
- [ ] Can I explain the six core concepts?
- [ ] Can I distinguish requirements from designs?
- [ ] Can I explain the five modelling categories?
- [ ] Can I identify the nine requirement quality characteristics?
- [ ] Can I explain the difference between verification and validation?
- [ ] Can I explain why assumptions and risks matter?
- [ ] Can I distinguish a baseline from a target?
- [ ] Can I explain how acceptance criteria help make requirements testable?
- [ ] Can I explain how financial and risk analysis support solution evaluation?
- [ ] Can I describe how the analyst compares solution options and assesses potential value?
Final Takeaway
The Requirements Analysis and Design Definition knowledge area helps Business Analysts turn elicited information into structured, high-quality requirements and designs, then assess whether they address the real business need.
The central lesson is to specify and model requirements clearly, verify their quality, validate their business value, and assess solution options in the context of stakeholder needs and organisational objectives.
Top comments (0)