BABOK® v3 Study Group

Study Notes
Week 5: Knowledge Area |
Requirements Analysis & Design
Definition

Business Analysis Excellence Pty Ltd

Study Group presented by: Esta Lessing CBAP®

www.business-analysis-excellence.com

[email protected]

+61 3 86 77 0891 (AEST 9am - 5pm)

1 of 25 Copyright 2020 | BAE Pty Ltd

These study notes cover the tasks which are used to structure the requirements that were
elicited and gathered and forms the knowledge area: Requirements Analysis and Design
Definition.

With these notes you will learn what it entails to verify and validate requirements, define
the requirements architecture and defines solution options that could be pursued. It also
describes the task of analysing the potential value and provides guidelines for
recommending a solution.

Task: Specify and Model Requirements

The first task described as part of the knowledge area, Requirements Analysis and Design
Definition, is about analysing the requirements information the business analyst has
elicited from stakeholders and then creating requirements and design artefacts of those
results.

Here we cover the purpose of this task and the different aspects of specifying and
modelling requirements in the context of the task's core elements. You will also learn the
difference between a requirement and a design and how to apply these terms during your
role as a Business Analyst.

Let’s start by considering the purpose of this task.

Purpose
According to the BABOK® v3 guide, the purpose of specify and model Requirements is.

"…to analyze, synthesize, and refine elicitation results into requirements and designs.”

This task is all about the activities you perform to analyze and create representations
(textual or visual) of this information in a format that is digestible by other stakeholders
groups who need the information.

Before we delve more into the elements of this task, let us understand how you should
use the terms ‘requirements’ and ‘designs’ in the business analysis world.

The term ‘requirements’ is used when the focus of the specifying and modeling activity is
on understanding the business need. The outputs that are generated as a result of these
types of analysis activities are referred to as requirements.

The term ‘designs’ is used when the focus of the specifying and modeling activity is on
understanding the solution. The outputs that are generated as a result of these types of
analysis activities are referred to as designs.

Let us consider a practical real-world example of how these terms can be used
appropriately.

An organisation has a need to increase their number of customers. The requirement

here is to ‘increase new customer leads generated’. Because there is a focus here

2 of 25 Copyright 2020 | BAE Pty Ltd

on the business need, the output of the activities to understand this business need
would be referred to as ‘requirements’.

However, a part of the solution to this requirement is to build a new website and to
add additional search engine campaigns. These solutions would be analyzed and
modeled in the form of mock screen layouts, specific marketing campaign pages
and so forth. These would be example outputs where the focus of the analysis
activities are on the solution and would, therefore, be referred to as designs.

The BABOK® Guide makes a point to differentiate between these terms. It is

important that you understand the distinction well so that you can answer exam
questions effectively.
Let us now consider the core elements that a Business Analyst should include when
performing this task.

Elements
There are four elements to consider when you specify and model requirements, they are:

• Model Requirements

• Analyze Requirements

• Represent Requirements and Attributes

• Implement the Appropriate Levels of Abstraction

We will now summarise each of these elements.

Element 1: Model Requirements

What are model requirements and why is it used?

A model is any visual representation of information which has a specific purpose to

support analysis understanding amongst different stakeholder groups.

Models are generally used to confirm the information and identify duplicates, or even
identify information gaps that might exist.

Business Analysts can use any of the following modelling formats to express and
describe their business analysis information:

Matrices

A matrix is simply a type of table structure which is used to express business analysis
information. It is often used when the information lends itself to be categorised and when
the information shares a lot of similar attributes. A matrix is often the best way to display
requirements information which needs to be sorted or prioritised.

Considering the following real-world example: If you have a set of requirements that all
have a certain set of elements such as a Requirements Identifier, a Requirement Category,
a Description, a Priority, a Source, and associated business rules, you can compile and
manage these requirements in a matrix format.

3 of 25 Copyright 2020 | BAE Pty Ltd

Matrices may be used for data dictionaries, requirements traceability, or for supporting
stages of performing a gap analysis.

Diagrams

A diagram is a visual expression of a requirement or set of requirements. Often these sets

of requirements are documented as a picture to aid in representation and understanding.
Diagrams are an effective way to simplify potentially complex concepts to aid in
understanding by a wider audience of stakeholders.

Diagrams are often part of requirements documentation with some of the most popular
diagrams being entity-relationship diagrams, process diagrams and use case diagrams.
There are many other popular diagrams used by Business Analysts and it is important to
consider the purpose and audience of a diagram before choosing to use a particular
diagram.

There are different categories in which models are applied, depending on the category’s
main purpose and scope. Some model categories can include the following:

• People and Roles

• Rationale

• Activity Flow

• Capability

• Data and Information

Let’s now discuss each model category and understand how to apply it by considering a
real-world example:

• People and Roles: This model category represents organisations, groups of

people, roles, and their relationships within an organisation and to a solution.

A real-world example could be:

If the Business Analyst was required to develop a people and roles model to show
all the roles involved in a change management process or project, they may choose
to develop a Stakeholder Map showing roles such as the key Project team roles,
Business stakeholders involved in the change and any change implementation
roles. The role of relationships in relation to the project will also be represented.

Techniques used to represent people and their roles include organisational

modeling, roles, and permissions matrix, stakeholder list, map or personas.

• Rationale: This model category tends to represent the reasons for a change
and answers the question of ‘why’ in different ways.

Let's look at an example of a vehicle sales process.

Using the rational model category, a decision model can be used to illustrate the
different decisions that must be made as part of the vehicle sales process. There
4 of 25 Copyright 2020 | BAE Pty Ltd
will be multiple decision points within this process, and each point will trigger a
different flow. Some example decision points in the context of a vehicle sales
process:

• Is the client choosing a new or used vehicle?

• Will the client pay cash or choose a finance option?
• Did the client accept the vehicle quotation price or was it declined?

There are a number of other modeling techniques you can apply to depict the model
category for showing a rationale, these include Scope Modeling, Business Model
Canvas, Root Cause Analysis, and Business Rules Analysis.

• Activity Flow: This model category represents a sequence of actions, events, or a

course of action that may be taken.

Let's continue the real-world example of a vehicle sales process by applying a

process model to represent the activities in the vehicle sales process. Some of the
high-level activities can include:

• The salesperson receives a customer inquiry

• The customer indicates whether they want a new or used vehicle
• The salesperson suggests a potential vehicle to the customer including a
price for the vehicle
• The client accepts or declines the offer
• If they accept the offer to purchase then the purchase contract will be
produced and signed, however, if they decline the offer the transaction is
closed and the process ends.

All these activities or steps in the process will be documented by using a visual activity
flow model. There are a number of different techniques that can be used to represent
activity flows. These include techniques such as process models, use cases and
scenarios and user stories.

• Capability: This model category is a visual representation of the features or

functions of a solution or an organisation.

For example, a capability model can be used to represent the different functions that an
internet banking application should have. These functions may include the ability for a
new user to signup to the system, the ability to verify existing users, enable password
changes as well as functionality to manage a bank account online.

Techniques that could be used to model the capabilities of a solution include Business
Capability Analysis, Functional Decomposition, and Prototyping.

• Data and Information: This model category represent the characteristics and the
exchange of information within an organisation or a solution.

Techniques that are used to represent data and information include Data Dictionary, Data
flow diagrams, Data Modeling, Glossary, State Modeling, and Interface Analysis.

5 of 25 Copyright 2020 | BAE Pty Ltd

Element 2: Analyze Requirements

What about requirements needs analysis?

Business Analysis information needs to be further decomposed to understand the

information from the following perspectives:

• To ensure that everything that might need to change to meet the business need has
been noted and documented

• Similarly, to ensure that everything that should stay the same to meet the business
need remains intact

• To identify any missing components that are not yet included or specified

• To remove any unnecessary components

• To decompose and document any constraints or assumptions that has an impact

on the components under analysis

By performing an analysis of the business analysis information, the business analyst

provides a basis for discussion to enable the team to reach a conclusion about potential
solution options.

Element 3: Represent requirements and attributes

A Business Analyst is required to document and represent all the attributes identified for a
requirement as part of the elicitation results information.

All requirements must be documented in enough detail such that they exhibit the
characteristics of the requirements and design quality. As part of specifying requirements,
they can also be categorized according to the schema described in an earlier section
about the Requirements Classification Schema. Typically elicitation results contain
information about different types of requirements which means that it is often happening
that different types of requirements are specified at the same time during an initiative.

In a real-world practical example scenario:

You may be reviewing the elicitation results from a recent workshop and discover
functional requirements describing the new online portal’s required functional
capabilities. You also find some non-functional requirements relating to the
performance and security requirements for the online portal a part of the workshop
output.

Element 4: Implement the Appropriate Levels of Abstraction

The level of abstraction of a requirement refers to the different perspectives, level of detail
and representation formats that are used for different stakeholder audiences. All
stakeholders may not require the same level of information or require information in the
same format or representation. It is important for the Business Analyst to keep this in
mind when preparing different models of requirements for different stakeholder groups.

If we refer to an example where we are adding a functional capability to validate a

user during the login process of an existing online banking system:

6 of 25 Copyright 2020 | BAE Pty Ltd

The level of abstraction used when describing the requirements will be very
different when communicating to the Head of the Organisation, compared to the
Development team required to build the new module.

• The Head of the organisation prefers to only know that the user experience is
secure and there is a level of security verification included in the new module.

• The Development team, however, would need to know, for example, the exact
detail of the verification steps and rules, as well as any additional or updated
field level information in order to build the new module.

Inputs and Outputs

With the Requirements Analysis and Design Definition task: Specify and Model
Requirements, there are the following input and outputs:

• Inputs: Elicitation Results (any state)

• Outputs: Requirements (specified and modelled)

•
The task of specify and model requirements was all about taking your elicitation results
and converting it into a set of requirements which has been been modelled and specified
using business analysis techniques and practices.

Let us now move to the next Requirements Analysis and Design Definition task, verify
requirements.

TASK: Verify Requirements

The second task described as part of the knowledge area, Requirements Analysis and
Design Definition, is about verifying the requirements so that the business analyst can
ensure that quality standards have been met and that requirements are fit for purpose.

Here we cover the different aspects of verifying the requirements and we ensure
requirements have been defined correctly. You will also learn the important and critical
characteristics that a good requirement should always have. Let’s start by considering the
purpose of this task.

Purpose

The BABOK® v3 Guide defines the purpose of Verify Requirements as…

”to ensure that requirements and designs specifications and models meet quality
standards and are usable for the purpose they serve….”

If you ask yourself the following question, you will ensure that you have always verified
your requirements:

“Am I building the solution correctly?”

Our next topic will be to discuss the task: Validate requirements, and there you will ask:

7 of 25 Copyright 2020 | BAE Pty Ltd

“Am I building the correct solution?”

The task of verifying requirements ensures that the requirements and designs have been
defined in the correct way by the Business Analyst.

A good quality requirements specification is well written and easily understood by its
intended audience. In a similar way, a good quality model is a model that follows the
formal or informal notation standards and effectively represents reality.

It is essential that requirements and designs are prepared in a way that is effective and
relevant for the intended purpose and meets the needs of the stakeholder.

If we consider this real-world scenario:

A stakeholder has a business need to increase online customer sales. The Business
Analyst analyses this need and produces a requirements specification, showing well
laid out models to describe everything required to build a new website. However,
none of the requirements describe at all how this new website will increase the
sales for this enterprise. This requirements specification is considered by the
stakeholders as not meeting their needs because there is no clear reference or
explanation of the business needs or how the proposed design of a new website will
address their needs.

If the Business Analyst asked our question above: “Am I building the solution correctly?”
he/she would have documented the solution in such a way as to explain to the audience
how a new website, with better search engine optimisation, will address the stakeholder’s
business need to increase online customer sales. In this case, the requirements and
designs would have been considered as good quality because it reflects the stakeholder
needs accurately as well proposes a solution option to the business stakeholders to solve
for their business need.

Elements
There are three elements to consider when you verify requirements:

• Characteristics of Requirements and Designs Quality

• Verification Activities

• Checklists

Here we summarise each of these elements and describe the meaning of the concepts in
a practical way.

Element 1: Characteristics of Requirements and Designs Quality

What are the characteristics of quality requirements and designs?

Good quality requirements and designs will exhibit certain quality characteristics. It is
important for a Business Analyst to keep these characteristics in mind when formulating
requirements and designs as part of their business analysis outputs.

8 of 25 Copyright 2020 | BAE Pty Ltd

 • Atomic: When a requirement is atomic, it can be understood independently of
other requirements or designs. It is also self-contained and can stand on its own as
a statement or expression.

• Complete: The requirement must have enough detail for work to be able to
continue. The level of completeness is not always the same and will depend on the
perspective or methodology as well when in the life cycle the requirement is being
used.

• Consistent: When a requirement is considered as being consistent, it really means

that it is aligned with the identified needs of the stakeholders. It also means that the
requirements are not contradicting any other requirements.

• Concise: A requirement is considered to be concise when it is using just enough

information to describe itself. It doesn’t contain unnecessary explanations or
content.

• Feasible: A requirement is considered to be feasible when it is in line with the

expectations of the project in terms of risk, schedule, budget or when it is
considered worthy to be explored in more detail.

• Unambiguous: A requirement is considered to be unambiguous when it stated in a

clear and straightforward way that describes whether a solution does or does not
meet the associated need.

• Testable: A requirement is testable when it is clear to the reader whether a

requirement or design has been fulfilled by a solution or not.

• Prioritized: A requirement is prioritized when it shows its relative importance and/

or value in relation to the other requirements it is associated with.

• Understandable: A requirement is understandable when it uses common

terminology of the intended audience.

Element 2: Verification Activities

What types of verification activities exist?

Activities to verify the requirements are often performed iteratively throughout the
requirements analysis process.

When requirements are verified, it is often done in an iterative and ongoing way.

Some types of verification types of activities include the following:

• The Business Analyst checks whether organisational business analysis standards,

processes, and tools are used.

• The Business Analyst may check whether the correct use of modeling notation,
templates, or forms are applied.

• Verification that common organisation terminology is used when describing the

requirements and that each requirement is understandable.

• Verifying that examples are included where additional clarification may be required.

• Verifying that all models included in the requirements are consistent and not
missing any information.

Element 3: Checklists

Why would you use checklists when verifying requirements?

9 of 25 Copyright 2020 | BAE Pty Ltd

Checklists are used to assist with quality control during the task of verifying requirements
and designs.

Some example quality check questions that could be included on a checklist include:

• Has the correct and latest document templates been used?

• Are all the calculations and samples used correctly?

• Have training requirements been addressed?

• Have the report requirements been addressed?

• Have policy changes been addressed?

It is a good practice to agree to a standard checklist to use within your business analysis
team to ensure a consistent standard set for all verified requirements in your team.

Inputs and Outputs

With the Requirements Analysis and Design Definition task: Verify Requirements, there are
the following key input and output:

• Input: Requirements (specified and modelled)

• Output: Requirements (verified)

The result of completing the task of verifying the requirements is that the requirements
have a status of being verified. This allows the Business Analyst to move to the next stage
in the life cycle for the verified requirements.

During the next part of these notes we discuss the task, Verify Requirements.

Task: Validate Requirements

The third task described as part of the knowledge area, Requirements Analysis and
Design Definition, is about validating the requirements that align with the business needs
and supports the delivery of the anticipated value.

During this section, you will learn about the nature of validating requirements and designs
as part of your role as a Business Analyst. We also outline the importance of making and
documenting assumptions to ensure clear communication with stakeholders, both
upstream and downstream in the delivery cycle. We also discuss the role of evaluation
criteria to ensure measurability of the value that implemented requirements and designs
will bring to the business. Let's now consider the purpose of the task: Validate
requirements.

Purpose
According to the BABOK® v3 Guide, the purpose of Validate Requirements is…

” to ensure that all requirements and designs align to the business requirements and
support the delivery of needed value….”

10 of 25 Copyright 2020 | BAE Pty Ltd

If you ask yourself the following sample question, you will ensure that you have always
validated your Requirements:

“Am I building the correct solution?”

If you remember in our previous section we addressed the task: Verify Requirements, and
there we asked:

“Am I building the solution correctly?”

This is a simple way to differentiate between Verify and Validate Requirements.

Requirements validation is a task that is performed throughout the life cycle of the
requirements and designs and is primarily concerned with ensuring that the requirements
and designs remain aligned to the business needs. This includes stakeholder
requirements, solution and transition requirements. Ultimately the purpose of
implementing requirements and designs is to achieve business stakeholder’s desired
future state.

The task of validating requirements is also performed to ensure that all stakeholders
remain in alignment with what is required and it helps identify any requirements conflicts
that might exist.

Elements
There are three elements to consider when you Validate Requirements:

• Identify Assumptions

• Define Measurable Evaluation Criteria

• Evaluate Alignment with Solution Scope

The next section summarises each of these elements and describe each in the context of
a practical example.

Element 1: Identify Assumptions

Why should you identify assumptions?

In some cases, it is necessary to identify assumptions that may have been made when
requirements were raised or designs were completed. These assumptions can assist in
providing a basis for decision making where information may not be available or it can
assist in managing any risks that might be associated with a particular solution.

Sometimes when a brand new product or service is launched, it is achieved by making

some assumptions. The assumptions can be about the customer or stakeholder response
and will be used to help drive the project or initiative forward.

It could also be that stakeholders assume that certain benefits can be expected with the
implementation of a certain requirement. These assumptions are defined and
documented to allow the team to move ahead with a solution.

11 of 25 Copyright 2020 | BAE Pty Ltd

Let us look at a real-world example:

In the context of the Vehicle Manufacturing Company where a need to save on

software maintenance costs was identified, it was decided to replace the dealer
management system of the company with a solution that has lower software
maintenance costs. The stakeholders, in this case, assume that this change will
have an overall cost-saving benefit for the company.

Element 2: Define Measurable Evaluation Criteria

While the expected benefits are defined as part of the future state, the specific
measurement criteria and evaluation process may not have been included. Business
analysts define the evaluation criteria that will be used to evaluate how successful the
change has been after the solution is implemented.

This element is about the Business Analyst defining the expected benefits a solution will
bring to the business in a way that is measurable. It is often required that the Business
Analyst start by setting a baseline for the agreed measurable benefits identified and then
to track benefits realisation over an agreed period.

Let us look at a real-world example for identifying and capturing a baseline for an
expected solution benefit:

There is a stakeholder requirement to change the current manufacturer of a specific

product for a company. This requirement exists to address the need to have a faster
manufacturing process, that also delivers at a reduced operational cost.

To measure the benefit of implementing this requirement, the baseline metrics of

the current state should be defined and documented.

Baseline metrics for this product are as follows: The current manufacturing process
takes 3 business days. The delivery time for the product is documented as 2 days
and the cost to manufacture this product is $20 per unit.

Once the baseline metrics are defined, the Business Analyst should work with the
business stakeholders to define a target or future state metrics that can be tracked
over time to demonstrate the business value of the solution.

Element 3: Evaluate Alignment with Solution Scope

This element is about ensuring that the solution being delivered is of benefit to the
stakeholder and aligns with the stakeholder requirements. If it determined that the
requirement or the solution features are not aligning to the business needs, the respective
requirement should be eliminated or the solution scope should be changed.

The purpose of this element is to ensure that the requirement delivers the required benefit
to the stakeholder.

12 of 25 Copyright 2020 | BAE Pty Ltd

Let's look at a real-world example of how this might happen:

A stakeholder has received a new laptop and he needs Microsoft Word and
Microsoft PowerPoint to be installed on his machine.

The documented requirement is that a new mailbox should be set up on the new
laptop. The scope of the solution is defined to include setting up the stakeholder’s
mailbox.

Clearly neither the documented requirement or the specified solution will meet the
needs of this stakeholder and should, therefore, be re-evaluated. It is likely that the
solution scope would need to be changed by eliminating the requirement to set up a
new mailbox and replace it with the requirement to set up Microsoft Word and
Microsoft PowerPoint.

This also requires that the design specification is updated to ensure that the stakeholder’s
need is met.

Inputs and Outputs

With the Requirements Analysis and Design task: Validate Requirements, there are the
following key input and output:

• Input: Requirements (specified and modelled)

• Output: Requirements (validated)

The result of completing the task of validating the requirements is that the requirements
have a status of being validated. Requirements and designs that are validated are those
that will deliver benefits to the stakeholders and is in alignment with business goals and
objectives for the planned change.

During the next part of these notes we discuss the task, Define Requirements
Architecture.

Task: Define Requirements Architecture

The fourth task described as part of the knowledge area, Requirements Analysis and
Design Definition, is defining the requirements architecture. This task is about establishing
the structure of all the requirements to form cohesive requirements that support the
business objectives for the change.

Here you will learn about the different considerations when establishing a requirements
architecture. You will also understand that a requirements architecture will assist the
Business Analyst in all aspects of requirements management and communication
throughout the life of the requirements. It will also become clear how the requirements
architecture supports the successful delivery of the requirements. Let us start by defining
the purpose of this task.

13 of 25 Copyright 2020 | BAE Pty Ltd

Purpose
According to the BABOK® v3 Guide, the purpose of Define Requirements Architecture
is…

" to ensure that the requirements collectively support one another to fully achieve the
objectives….”

The requirements architecture is the way that the requirements are put together as a
holistic view of the requirements for a change. It describes how different requirements
artifacts (models and textual descriptions) relate to each other to form an overall
requirements view for an initiative or change.

A business analyst would use Requirements Architecture for the following reasons:

• The requirement architecture defines which models are appropriate for the domain,
context and solution scope.

For example, business process models to illustrate business processes, and data
models for describing data related requirements.

• The requirements architecture also organizes requirements into structures relevant

to different stakeholders.

For example, The Technology Solutions Department would want to see more
detailed technical structures, whereas the Head of the Organisation would want
just a high-level overview, knowing enough to feel comfortable that the suggested
solution meets the business needs identified.

• The requirements architecture also illustrates how requirements and models

interact with and relate to each other. Ultimately the requirements architecture
makes sure that the requirements are meant as a whole and in alignment with the
overall objectives of the initiative or planned change.

For example, if a requirement would not benefit the overall objective or is in contradiction
with the objective, this should be discussed and potentially removed.

Elements
There are five elements to consider when you Define Requirements Architecture:

• Requirements Viewpoints and Views

• Template Architectures

• Completeness

• Relate and Verify Requirements Relationships

• Business Analysis Information Architecture

Now we will describe each element with a real-world example.

14 of 25 Copyright 2020 | BAE Pty Ltd

Element 1: Requirements Viewpoints and Views

How do viewpoints and views impact the requirements architecture?

A viewpoint is a set of standards or guidelines that define how requirements will be

represented and how these representations will be organised. It also shows how
requirements will be presented and communicated to the stakeholder. A viewpoint
provides a template to use in order to communicate requirements to a particular
stakeholder group.

The following aspects are often expressed as standard or guidelines for a particular
viewpoint:

• Which model types, notations, and attributes should be used for requirements
documentation

• Which approaches should be used to identify and maintain relevant relationships

between models.

Let us look at a real-world example scenario:

An organisation may have a standard business process notation that must be

applied whenever business processes are documented as part of requirements. In a
similar way, the organisation may have requirement statement conventions in place,
such as following the user story format when formulating textual requirements.
These are both considered viewpoints that should be applied when performing
requirements analysis and design definition tasks.

No single viewpoint can form an entire architecture. It is normally a collection of different

viewpoints that will form the requirements architecture.

Certain viewpoints represent the information and architecture of a specific aspect better
than others.

Examples of viewpoints include:

• Business process models

• Data models and information

• User interactions, including use cases and/or user experience

• Audit and security

• Business models

The specific requirements and designs for a solution from a chosen viewpoint are referred
to as a view. A collection of views makes up the requirements architecture for a specific
solution or initiative.

It is the responsibility of the Business analysts to align, coordinate, and structural

requirements into meaningful views for the various stakeholder groups to ensure each
stakeholder group receives a meaningful view of the requirements which is relevant to
them.

15 of 25 Copyright 2020 | BAE Pty Ltd

Therefore a viewpoint consists of various standards and guidelines that a Business
Analyst should follow when preparing a view of the actual requirements for a specific
solution.

Element 2: Template Architectures

What is the importance of template architectures?

In essence, an architectural framework in this context is described as a collection of

viewpoints that is standard across industry, sector or organisation.

These frameworks can be used by Business Analysts as predefined templates to start

from in defining their own requirements architecture.

For example, an organisation has defined its own custom requirements architecture
which was based on the industry architectural framework published by the
International Institute of Business Analysis. This requirements architecture consists
of various templates and notational modelling guidelines (viewpoints) that must be
applied when a Business Analyst prepares requirements documentation for a
particular initiative of the organisation.

Element 3: Completeness

Using a requirements architecture as a guide can also assist in the requirements level of
completeness. This is because using provided templates can guide the author to ask
pertinent, predefined questions that will assist to ensure all requirements and
perspectives are captured.

When the requirements architecture is applied to complete an entire set of requirements it

increases understandability and ensures that a cohesive and complete picture is captured
when describing the requirements.

Element 4: Relate and Verify Requirements Relationships

Requirements are often related to each other and there are various different ways that
these relationships might exist. It is important the Business Analyst identify and analyse
these relationships clearly.

When a relationship is identified between requirements, the Business Analysts will

examine the relationship and ensure that it satisfies the following quality criteria:

• The relationship is defined and the relationship type is described.

• The relationship is necessary in order for the requirements to be understood in a

holistic way.

• The relationship is correctly described between the requirements.

• The relationship is unambiguous in that the relationship is clear and there are no
confusion or multiple interpretations about the relationship.

• The relationship is consistent in the way that it is described between the different
requirements. This means that the relationship description is following a standard
or guideline as it is outlined in the viewpoints of the requirements architecture.

16 of 25 Copyright 2020 | BAE Pty Ltd

Let us now look at what the Business Analysis Information Architecture is and why it
important to consider as part of this task.

Element 5: Business Analysis Information Architecture

The structure of the business analysis information is also referred to an information

architecture and because it describes how business analysis information relates to each
other in a structured way, it forms part of the requirements architecture.

The information architecture helps the stakeholders to understand how the models,
requirements and designs are related, linked and how information is shared between
these.

Inputs and Outputs

With the Requirements Analysis and Design task: Define Requirements Architecture, there
are the following key inputs and output:

• Inputs: Information Management Approach, Requirements (any state), Solution

Scope

• Output: Requirements Architecture

You have now learned that task to define the requirements architecture for an initiative
includes taking the information management approach, the requirements and designs
and solution scope as key inputs to then be transformed into a requirements architecture
which can help support the overall effectiveness and accuracy of the requirements for a
given change.

During the following section we discuss the task where the Business Analyst defines the
design options for an initiative.

TASK: Define Design Options

The fifth task described as part of the knowledge area, Requirements Analysis and Design
Definition, is defining the design options. This task is about defining the solution approach
as well as allocating requirements and designs in a way that will support achieving the
desired future state.

During this section you will learn about the different considerations when defining the
design options.

Purpose
According to the BABOK® Guide, the purpose of Define Design Options is…

” to define the solution approach, identify opportunities to improve the business, allocate
requirements across solution components, and represent design options that achieve the
desired future state….”

17 of 25 Copyright 2020 | BAE Pty Ltd

In a practical way, you can look at this task as the activities you will perform when you are
working out which way to go in terms of implementing the requirements you have
prepared in order to achieve the business value. This is referred as identifying the design
options.

Design options generally refer to the steps that will be taken, to ensure the solution is
delivered.

The design options are not the specific solution functionality but rather the approach that
will be taken to deliver the solution.

Let us look at this real world example:

In this example there are 2 design options identified for a small project which
includes the following:

Design Option 1: describes the approach to implement software changes to an

existing system. A micro phased approach is follow, where only three software
changes are implemented during every release cycle.

Design Option 2: describes the decision to implement a new vendor software

component as part of the overall solution. With this design option, it was decided to
purchase this vendor software component instead of developing it in-house. The
Business Analyst should consider whether this design option will meet all the
requirements for the business stakeholders and whether any trade-offs would need
to be identified and managed accordingly.

If any of these tactical design options require any type of trade-offs to be made in order to
successfully deliver the solution, the business analyst must aim to prevent that these
trade-offs doesn’t impact the requirements in an adverse way.

During the next section we will discuss the specific elements that the Business Analyst
must include when performing the task of defining design options.

Elements
There are four elements to consider when you Define Design Options:

• Define Solution Approaches

• Identify Improvement Opportunities

• Requirements Allocation

• Describe Design Options

Let us discuss each of these elements in more detail below.

Element 1: Define Solution Approaches

When a solution approach formulated, it is essentially a determination of whether a

solution component will be purchased, created or perhaps a combination of these two
approaches.

18 of 25 Copyright 2020 | BAE Pty Ltd

When it is decided to follow an approach where the solution component is created, it
means that the requirements will be used by experts to develop, construct or assemble
the solution. When this approach is chosen, the requirements are at a level of detail which
allows for this approach to be chosen. This solution approach also include any
modifications required to existing solutions.

A real world example of creating a solution component:

A vehicle finance application system already exists within a financial institution.

Based on stakeholder requirements, it is decided to construct and develop a new
module to this system.

When it is decided to purchase a solution component to fulfil the requirements with,

it means that a third party will be involved in executing this solution approach. In
most cases, the third parties will manage and own the solution component whether
it is a service or a product.

A real world example of purchasing a solution component:

An ‘off-the-shelf’ accounting system is selected to meet the accounting

requirements of the organisation and will be delivered by a third party vendor.

In most case though, the solution approach is a combination of the creating and
purchasing different parts of the overall solution and should be defined as such when
defining the design options.

Element 2: Identify Improvement Opportunities

As part of the task to define design options it often includes identifying opportunities to
improve the business operations. There are some common examples of how this might
occur:

• Increase efficiencies

A result of implementing a solution is often the automation of some processes or tasks in

the business operational area.

An every day real world example could be: A new timesheet management solution is
implemented which removes the need for employees to have their timesheets
printed and signed by a line manager prior to submitting it to the payroll
department. This results in a cost and time saving efficiency.

Automate or simplify the work people perform by reengineering or sharing processes,

changing responsibilities, or outsourcing.

• Improve Access to Information

By providing more information access to staff who interface directly or indirectly with
customers, the need for specialised personnel are reduced. This also aids in preventing a
19 of 25 Copyright 2020 | BAE Pty Ltd
customer being sent from one customer service person to another to get different types
of services or information.

• Identify Additional Capabilities

Highlight capabilities of a new solution that have the potential to provide future value to
the business and can be supported by the solution.

Element 3: Requirements Allocation

What is requirements allocation?

Requirements allocation is an activity where requirements are assigned to specific

solution components or planned releases to ensure that requirements are delivered in the
most efficient way whilst providing the highest business value.

A real world example could be:

It will be rather pointless to implement a special Christmas themed product or

service at the wrong time of the year!

Element 4: Describe Design Options

Design options are described while considering the desired future state, and the
anticipated business value it must deliver. It is also described to ensure the design option
is valid and feasible.

A design option is often described using design elements. These elements may describe
the following types of information:

• Business policies and business rules that applies

• Business processes to be performed and managed

• People who operate and maintain the solution, including their job functions and
responsibilities

• Operational business decisions that must be made

• Software applications and application components that is used in the solution, and

• Organisational structures, including interactions between the organisation, its

customers, and its suppliers.

During this section you have learned about all the elements to consider when you perform
the task of define design options.

Inputs and Outputs

With the Requirements Analysis and Design task: Define Design Options, there are the
following key inputs and output:

• Inputs: Change Strategy, Requirements (validated, prioritised), Requirements

Architecture

• Output: Design Options

20 of 25 Copyright 2020 | BAE Pty Ltd

You have learned that the design options are formulated after considering various
elements and utilising inputs such as the change strategy, requirements and the
requirements architecture.

Task: Analyze Potential Value and Recommend Solution

The sixth and final task described as part of the knowledge area, Requirements Analysis
and Design Definition, is to analyse potential value and recommend solution. This task is
about assessing the potential business value of each design option and to recommend
the best design option that will meet most of the business’s defined requirements.

During this task you will learn about the different considerations when analysing the
potential value of the design options as well as what is involved when recommending a
solution.

Purpose
According to the BABOK® v3 Guide, the purpose of Analyze Potential Value and
Recommend Solution is…

"to estimate the potential value for each design option and to establish which one is most
appropriate to meet the enterprise’s requirements….”

It is easy to understand from that that this task is about working out the potential value of
each the design option. It is also about considering which option will be most appropriate
to meet the organisation's requirements.

Let us use a practical everyday example to explain this further.

You are at Point A, and want to find a way to travel to Point B. These points are all
land-based so you choose to travel by road.

You have different transportation options, for example:

• You can travel by bicycle

• You can travel by motorcycle
• You can travel by motor vehicle

These options are all recommended solutions to get from Point A to Point B, however, the
value you will gain by each possible solution option is very different. Let us now consider
each option and what the potential of each could be.

• Option 1: If you choose to travel by bicycle, it will be the most cost-efficient but it
will take a long time to reach point B.

• Option 2: If you choose to travel by motorcycle, you can see that it would be very
time-efficient, however, you will not be able to take all your luggage or any of your
family members along.

21 of 25 Copyright 2020 | BAE Pty Ltd

 • Option 3: If you choose to by motor vehicle you know it might not be as time-
efficient as option 2, and a bit less cost-effective than option 1 and option 2 but it
brings additional value to you in the form of being able to carry all your luggage and
you are able to take your family along with you. If being able to carry luggage and
bring family is part of your requirements, then Option 3 will meet all your
requirements without any additional costs for sending luggage or family separately
from you.

Even with this simple example, you can see that there are many factors that need to be
considered when you assess the potential value a design option will bring to the
organisation.

Different types of value can be identified and considered and typically include the value
that is described in terms of finance, reputation, or even impact on the marketplace.

In some cases, it is required to build a proof of concept first to determine the best design
option. It can also happen that the best decision is to not implement the change at all.

Lets now discuss the detail of the key elements to consider when analysing the potential
value and recommending a solution.

Elements
There are four elements to consider when you Analyze Potential Value and Recommend
Solution:

• Expected Benefits

• Expected Costs

• Determine Value

• Assess Design Options and Recommend Solution

The following section will discuss the detail of each element and outline real-world
examples to clarify each concept further.

Element 1: Expected Benefits

When you consider the expected benefits of a solution you focus on the positive value
that a particular design option can bring to the business when it is delivered. The
expected benefits can include financial benefits as well as benefits such as reduced risk,
compliance with business policies and regulations, improved user experience or any
positive outcome for the organisation.

A real-world example could be described as follows:

The stakeholders of an organisation agree that a new website is required to

represent the organisation online and they would like an external website provider
to manage and implement this solution.

It is expected that the new website will increase traffic to the website, and therefore
also increase product sales.

22 of 25 Copyright 2020 | BAE Pty Ltd

It is expected that a new website will provide the company with a new market
image which will make the company more attractive to potential new clients. It is
also expected that the user experience will be much better than using the current
website.

In this example, there are two key expected benefits identified with a particular
design option. These benefits relate to an increase in sales (financial benefit) and an
improved reputation and brand image which will attract more customers and satisfy
existing customers from a user-experience perspective.

Element 2: Expected Costs

When you consider the expected costs of a solution you focus on the negative value a
new solution may introduce to the organisation.

Negative value can be described in different ways including the cost to acquire the
solution or any negative effects it might have on stakeholders. It can also include the cost
to maintain the solution over time.

Some types of expected costs that should be considered when analysing the potential
value of each design option can include the following: timeline, effort, operating costs,
purchase and/or implementation costs, maintenance costs, physical resources,
information resources, and human resources.

Element 3: Determine Value

Now that you have considered the expected benefits and the expected costs, it is time to
look at deterring the value of a particular design option. You do this by establishing
whether the expected benefits outweigh the expected costs or vice verse.

A real-world example could be described as follows:

Consider a new pre-paid gift card project. The national post office decided to
extend its service offering to the public by introducing a brand new product in the
form of a pre-paid gift card. This card will be sold in all the local post offices around
the country. Some of the costs associated with this project include implementing a
brand new team to establish and manage the product, establishing relationships
with card payment processing and manufacturing 3rd party vendors and an
extensive marketing campaign of this new product to the public. The potential
benefits to the overall business, however, are described to exceed the costs of
establishing a new product line within the first year.

After a few months into the project, a new card processing cost was introduced as a
result of a legislative change. This changed the potential benefits to only be realized
after the 2nd year of operation.

This example describes some of the costs and the benefits that exist in a real-world
example however, it also illustrates that the potential value can be affected when change
is introduced and new requirements must be met. It is important to keep this analysis
23 of 25 Copyright 2020 | BAE Pty Ltd
relevant to the current situation whilst design options are being evaluated. This brings us
to the last element for this task.

Element 4: Assess Design Options and Recommend Solution

As we have mentioned, each design option is assessed based on the potential value it is
expected to deliver to the business. It is the role of the business analyst to analyze all the
relevant benefits and costs associated with each design option for the solution. This
includes an assessment of any trade-offs that a design option might include.

There are several factors to take into consideration when doing this assessment:

Available resources

It is important to assess the availability of resources to implement any design option. If

there is a limit on the resources that could be utilized to implement a solution, this must
be highlighted and determined whether there are any ways to change this limiting factor
(for example, can further budget be released to help with making more resources
available).

Constraints on the solution

The Business Analyst should be aware of any regulatory requirements or business

decisions that may require requirements to be handled in a different way to other
requirements in terms of how it is delivered.

Dependencies between requirements

Understanding the relationships between different requirements are important to ensure

that there is an understanding that some capabilities may in and of themselves provide
limited value to the organisation but need to be delivered in order to support other high-
value requirements.

A real-world example could be described as follows:

An organisation wants to implement a fully integrated call center solution. In order

to be able to implement this solution, they need to replace all existing phone
handsets because the existing handsets are not compatible with the special
integration requirements for a fully integrated call center solution.

In this example, the organisation has no need for new phone handsets as such, however,
this has been identified as a requirement dependency. Therefore, it must be included in
order for the call center solution to be fully functional when implemented.

Inputs and Outputs

With the Requirements Analysis and Design task: Analyze Potential Value and
Recommend Solution, there are the following key inputs and output:

• Inputs: Potential Value, Design Options

• Output: Solution Recommendation

24 of 25 Copyright 2020 | BAE Pty Ltd

You have learned that when performing the task of analysing the potential value and
recommending a solution there are a number of key elements to include as well as using
the potential value information and design options available as key inputs. This results in
a well-justified and sound solution recommendation as a key output of this task.

25 of 25 Copyright 2020 | BAE Pty Ltd