BABOK® v3 Study Group

Study Notes
We e k 3 : R e q u i re m e n t s L i f e c y c l e
Management

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 17 Copyright 2020 | BAE Pty Ltd

Requirements Life Cycle Management is the knowledge area that describes the tasks that
a Business Analyst performs to manage and maintain requirements from initiation right
through to final implementation.

These notes talks about the tasks which are involved during the process of managing and
maintaining the requirements through the life cycle of an initiative.

• Purpose of this knowledge area

• Task: Trace Requirements

• Task: Maintain Requirements

• Task: Prioritize Requirements

• Task: Assess Requirements Changes

• Task: Approve Requirements

• Test your knowledge

2 of 17 Copyright 2020 | BAE Pty Ltd

What is Requirements Life Cycle Management?
Requirements life cycle management refers to the tasks and activities that a Business
Analyst performs as part of their role to manage the requirements throughout to duration
of any initiative, from the start and to the very end. These activities also include
maintaining the requirements during this process.

Ultimately, the goal of requirements life cycle management is to make sure that all the
different types of requirements and designs are not only aligned and consistent with each
other but also that these requirements are maintained and implemented in the initiative’s
solution. This means that the Business Analyst has control over the requirements as well
as input into how these requirements will be implemented and delivered as part of the
solution.

TASK: Trace Requirements

The first task described as part of the knowledge area, Requirements Life Cycle
Management is that of tracing requirements during the life of the initiative.

Here we will gain an understanding of why requirements are traced as well as learn about
the key elements of traceability that a Business Analyst should consider.

Purpose
According to the BABOK v3 Guide, the purpose of Trace Requirements is to

“…ensure that requirements and designs at different levels are aligned to one another, and
to manage the effects of change to one level on related requirements.”

So ultimately the purpose of requirements traceability is to trace where each requirement

or design comes from or originated and what its lifecycle is throughout the project.

If it is known why a requirement exists, or where it originated from, it will ensure that once
the solution has been delivered that it does in actual fact solve the original requirement.

By knowing where a requirement came from, or what the need that should be addressed
is, the business analyst will know who to communicate to as well as be able to manage
the risk, scope and any change associated with that requirement.

Why trace requirements?

There are a number of reasons why you want to trace a requirement:

• It will enable quick identification of gaps within the supplied solution, as well as the
supplied requirements

• It will aid in the understanding of the sise of the change

• By tracing a requirement through development, testing and implementation you

keep track of the requirements’ status throughout the life cycle of the project

• Traceability also supports requirements allocation and release planning

3 of 17 Copyright 2020 | BAE Pty Ltd

Requirements traceability provides a clear view of requirements in a way that allows the
team to plan and allocate which requirements to include into which releases. This way
when looking at requirements within the same subject matter area, they can potentially be
allocated to the same resource group for implementation as well as the same release
period. This, in turn, will assist in the speed of solution delivery.

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

• Level of formality

• Relationships

• Traceability repository

Let us now consider each of these elements to understand the scope of the task in more
detail.

Element 1: Level of formality

Is a high level of formality and detail required?

Always consider that the more the level of formality increases the more difficult it
becomes to effectively trace a requirement.

There might be a few reasons why a certain level of detail is being documented for a
specific requirement.

Let us consider the following example to explain this further.

The requirement is to implement a new product, within a Bank’s credit card division.
A high level of formality and detail will likely be chosen, as there will be many aspects,
business rules, as well as other business area impacts to consider relating to this
requirement.

For example some of the complexities with this example can include product specific
business rules, product features, customer application rules and customer verification
processes. Even physical card designs and delivery processes will possibly need to be
considered for this requirement. In this case the detailed requirements will be traced
formally and at a low level of detail.

As a 2nd example - the same Credit Card division has a requirement to be able to send
their customers a text message once a new card has been issued for their account. Due to
the simpler nature and size of this requirement as well as the smaller overall business
impact, the level of formality and hence level of detail to trace the requirement to will be a
lot less than in the first example.

Element 2: Relationships

What are the relationships between requirements?

4 of 17 Copyright 2020 | BAE Pty Ltd

There are several types of relationships between requirements, it helps to know and
understand these relationships in order to determine the most appropriate traceability
approach for your specific project situation and traceability needs:

Let us consider the following example to explain these relationships further:

A bank is required to build an online loan application solution.

These relationships are:

• Derive – An applicant would need to login to the bank’s online system to use the
online loan application solution. The information required to validate whether the
user is a valid and registered user of this system is derived from the login process.
• Depends – For an applicant to be able to complete a loan application form, the
applicant would need to be logged in and validated on the bank’s online system.
Thus the completion of the form requirement is dependent on the login and
validation requirements process.

There are two further types of dependency relationships to consider in this example:

• Necessity – It is required to now also add new database fields to the bank’s
existing database to hold user online registration details. Without this data, it
will be impossible for the validation process to function, and is thus a
“necessity.”
• Effort – It will most likely be easier to implement all file changes at the same
time, seeing that some changes to a specific file or table is currently required
but because future fields on the same tables are envisaged, it will be less
“effort” to implement all file changes at the same time.

• Satisfy – Has the implemented solution satisfied the need to allow an applicant to
complete an online application securely, according to the company standards for
example?

• Validate – Has the requirement successfully been validated against the test case?

As a Business Analyst, you should, therefore, consider the purpose of each of these types
of traceability relationships prior to finalizing the traceability approach that you will be
implementing for your project.

Element 3: Traceability Repository

Requirements traceability is documented and maintained in line with the methods and
tools identified by the business analysis approach. Many organizations today will manage
traceability with elaborated spreadsheet templates but it should be noted that there are
sophisticated Requirements Management software tools, for example, Jira, available to
facilitate effective traceability on projects.

During this section we have learned about the purpose of tracing requirements as well as
understood what the different types of relationships are that could be used as a base for
tracing requirements. During this section we also covered some of the tools used to trace
requirements as well as gain an understanding of the level of formality required when it
comes to tracing requirements on an initiative.

5 of 17 Copyright 2020 | BAE Pty Ltd

During the following section we take a look at the importance of maintaining requirements
throughout the life of the initiative.

Inputs and Outputs

With the Requirements Life Cycle Management task: Trace Requirements, there are the
following key input and outputs:

• Inputs: Requirements and Designs

• Outputs: Requirements (traced) and Designs (traced)

You will notice that the output status of the requirements and designs changed to being
“traced” when you completed the task of tracing requirements.

TASK: Maintain Requirements

You will know that when working with requirements on an initiative, there are many factors
that can influence the requirements on a regular basis. The task of maintaining
requirements is all about working to keep requirements as accurate and consistent
throughout the entire initiative.

During this section we will understand the underlying purpose of maintaining

requirements in their entirety as well as explore which types of requirements are suitable
for reuse on multiple initiatives.

Purpose
According to the BABOK v3 Guide, the purpose of the Maintain Requirements task is to

“ … retain requirement accuracy and consistency throughout and beyond the change
during the entire requirements life cycle, and to support reuse of requirements in other
solutions.”

To understand the purpose of this task better, consider the following example.

Consider building a vehicle designed to perform like a race car, which is at the peak of its
group and level.

There are certain specific requirements, for example, rules and regulations around vehicle
weight, engine size and capacity. These are prescribed by the Racing Industry and must
be followed in order for a new car to be eligible to compete.

Thus in the future, when someone builds a vehicle designed for racing, or they repair an
existing vehicle, the rules, regulations, and requirements have been documented and
maintained for future use.

A requirement that continues to remain valid or continue to exist after a project has been
completed, must be maintained.

6 of 17 Copyright 2020 | BAE Pty Ltd

In order to maximize the benefits of maintaining and reusing requirements the
requirements should be:

• Consistently represented

• Reviewed and approved for maintenance using a standardized process that defines
proper access rights and ensures quality

• Easily accessible and understandable

Elements
There are three key elements to consider when you maintain requirements:

• Maintain requirements

• Maintain attributes

• Reusing requirements

Let us now consider each of these elements to understand the scope of the task in more
detail.

Element 1: Maintain requirements

It is required that a business analyst continuously conducts maintenance to ensure that

the requirement is correctly and accurately documented and readily available. If anything
with regards to the requirement changes, it is analyzed and updated in a timely way. The
Business Analyst must also aim to maintain the relationships between requirements and
any associated information describing the context in order to ensure the requirements
remain in line with the original intent of each requirement.

Element 2: Maintain attributes

The attributes of a requirement can continuously change throughout a project and needs
to be maintained at all times. The documentation thereof is referred to as Maintain
Attributes.

Requirements attributes refer to things like its source, priority, and complexity. This might
change even if the requirement itself remains the same. For the exam, be clear about the
term requirements attributes.

Element 3: Reusing requirements

It will drastically decrease the time spent on future analysis of requirements if certain
requirements can be reused and are documented as such.

During the course of an initiative, you often find that there are some requirements that can
be reused, either in different areas of the business or within other current projects.

Generally speaking, requirements which are described at an abstract level or have a

somewhat general nature, lend themselves to be candidates for reuse. These types of
requirements are often stable and don’t have specific reference to a particular solution or
situation.

7 of 17 Copyright 2020 | BAE Pty Ltd

Some example requirements categories that often contain requirements that are suitable
for re-use include the following: Non-functional requirements such as Performance,
Availability, Usability standards and security requirements amongst others.

Examples of business-focused requirements categories that often contain re-useable

requirements are Data privacy requirements, regulatory and compliance requirements and
fraud-related business rules that must be met. Different industries may have different
categories of re-usable requirements.

It is recommended to document these types of requirements without any links to a

specific project.

During this section we covered the key elements for maintaining requirements on an
initiative and specifically outlined the considerations for maintaining and reusing
requirements throughout the life cycle of the project.

Inputs and Outputs

With the Requirements Life Cycle Management task: Maintain Requirements, there are
the following key input and outputs:

• Inputs: Requirements and Designs

• Outputs: Requirements (maintained) and Designs (maintained)

Once the business analyst has performed the task of maintaining the requirements, the
status of the requirements as an output to this task changes to being maintained.

During the next section we understand the role and description of the task for prioritising
requirements during the initiative life cycle.

TASK: Prioritize Requirements

The task of prioritizing requirements is important to the overall life cycle of the
requirements because it reflects the level of importance that stakeholders place on a
specific requirement relative to all other requirements.

During this section we will delve into the reasons why prioritising requirements on an
initiative is important, we will discuss the key elements that the Business Analyst should
know and apply during prioritisation activities. We include the elements describing the
basis of prioritisation, the challenges that arise during prioritisation activities and
understand the continuous nature of prioritisation during the life cycle of the
requirements.

Purpose
According to the BABOK v3 Guide, the purpose of the task Prioritise Requirements is to

”… rank requirements in the order of relative importance.”

Let's look at a practical example to understand this task further:

8 of 17 Copyright 2020 | BAE Pty Ltd

A company has decided that they require a new website, and the following high-level
requirements have been documented:
• The technical director wants the website to be fast and responsive
• The sales director requires the website to increase the number of new customers
visiting the website
• The creative director says the website must be aesthetically pleasing with lots of
images as they have a big portfolio to display
• The technical website design company requires the website to be mobile-friendly.

However when enquiring about the priorities of these requirements you will find that each
stakeholder has their own opinion of the relative importance of each. It is your role as the
Business Analyst to facilitate a session with all the stakeholders involved to prioritize the
requirements according to an agreed prioritization method.

Let’s consider the detail of the prioritization activities.

Why do we need to prioritize requirements?

Requirements are prioritized in order to document their relative importance to

stakeholders. This is a very important step in the requirements life cycle management
knowledge area because when the requirements of a project have been prioritized, you
can determine the order in which they will need to be delivered. It will also aid in
understanding the value that the stakeholders attach to each of the requirements.

Dependencies between requirements can also often assist in the prioritization of

requirements.

Prioritization of requirements is not a once-off activity but rather an ongoing activity that
needs to be closely monitored and activity managed by the Business Analyst in close
collaboration with all other stakeholders.

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

• Basis of Prioritization

• Challenges of Prioritization

• Continual Prioritization

We will describe the elements of the task of prioritizing requirements and understand
each with an example.

Element 1: Basis of Prioritization

There are many factors that influence the priority of a requirement. It is important to
consider each of these factors and in collaboration with the stakeholders determine which
of these factors will carry the most weight when requirements are being prioritized within
the team.

Factors that influence prioritisation include:

• Benefit

9 of 17 Copyright 2020 | BAE Pty Ltd

 • Penalty

• Cost

• Risk

• Dependencies

• Time sensitivity

• Stability

• Regulatory or Policy Compliance

Remember that more than one of these factors will likely play a role in the prioritisation
activities. It is important to get some level of agreement between stakeholders about what
the relative importance are of each factor before you start facilitating prioritisation
sessions for the requirements as a whole.

Let us consider each of these prioritisation factors in more detail and with practical
examples.

Benefit
Generally, the requirements with the greatest business benefits or value associated with it
will be implemented first.

For example, if you would need to choose between a requirement that would increase
sales, or decrease fraud, each group of stakeholders will have a different view on priority,
and conflict resolution skills might beneficial here to assist in the stakeholders’ agreement.
The requirement with the greatest benefit would need to be identified and prioritized as
such.

Penalty
The penalty factor refers to the consequences of not implementing a given requirement.

If for example a financial fine, or other penalties will be incurred by the organization if a
specific requirement is not met, that requirement will have a higher priority associated with
it.

Cost
This factor refers to the costs associated with the effort and the needed resources to
implement the requirement.

Often a requirement is documented and requested initially, but when the stakeholder or
team realizes the cost to fulfill the requirement might be much higher than the perceived
benefits to the organization, it might be reconsidered as a lower priority.

Risk

The risk describes the likelihood that the requirement cannot deliver the potential value,
or cannot be met at all.

In an example: Requirements with a high operational risk associated with them, for
example, fraud prevention-related requirements will likely be prioritized to the top of the
list.

Dependencies

If certain requirements cannot be completed without others being done first (or at all), all
dependent requirements should be prioritized together.

10 of 17 Copyright 2020 | BAE Pty Ltd

For example, when increasing sales is seen as a priority, however, to be able to increase
sales effectiveness, new products must be created. For these new products, there are
new fields required within certain database tables. These new fields were not seen as a
priority when considered on their own. But, from a strategic point of view, the increase in
sales is the highest priority, and can only be achieved by adding new products. The new
database fields immediately also get a higher priority.


Time sensitivity

This factor describes the “best before” date of the requirement. Once this date passes,
the implementation of the requirement loses significant value to the organization. This
includes time-to-market scenarios, in which the benefit derived will be exponentially
greater if the functionality is delivered ahead of the competition. It can also refer to
seasonal functionality that only has value at a specific time of year.

For example: Delivering a new electronic gift card solution after the Christmas Season has
passed will have a much lower financial benefit to the organization than delivering this at
the appropriate timeframe before the Christmas Season.

Stability

If the stakeholder has not agreed on the final details of a requirement it might be changed
to a lower priority due to the immaturity or what we refer to here as the stability level of
the requirement. This is because it is assumed that the requirement will still change as
and when new information becomes available. From an initiative delivery point of view, it
doesn’t make sense to spend time and resources on requirements which are not finalized
or considered somewhat unstable due to the fact that any work and effort might have to
be reworked once the stakeholders come to an agreement on the intent and content of a
particular requirement.

Regulatory or Policy Compliance

A specific requirement might have a specific deadline due to industry bodies’ rules and
regulations.

For example, auditors and other government bodies might set rules and deadlines that
the project needs to adhere to in order to ensure company compliance.

Element 2: Challenges of Prioritization

What are the challenges when it comes to requirements prioritization?

We have already determined that prioritization is really an assessment of the relative value
of requirements. Each stakeholder may value a different aspect of the requirements set
and have different motivations for supporting certain requirements to have a high priority
for implementation. This can cause conflict amongst stakeholders. It is the role of the
business analyst to notice these conflicts and to work with stakeholders to determine the
appropriate priories for requirements, even if this includes making some trade-offs. It is
important to help stakeholders avoid the temptation to indicate certain requirements at
levels of priority which will affect other requirements priorities.

11 of 17 Copyright 2020 | BAE Pty Ltd

Element 3: Continual Prioritization

Priorities may continuously change. For example, stakeholders may initially prioritize
based on benefits. The implementation team may then re-prioritize the requirements
based on the sequence in which requirements must be implemented due to technical
constraints. Once the implementation team has provided the cost of each requirement,
the stakeholders may choose to re-prioritize again.

Inputs and Outputs

With the Requirements Life Cycle Management task: Prioritize Requirements, there are
the following key inputs and outputs:

• Inputs: Requirements and designs

• Outputs: Requirements (prioritized) and designs (prioritized)

Once the business analyst has performed the task of prioritization of the requirements,
the status of the requirements as an output to this task changes to being prioritized.

During the next part we will discuss the activities that is part of performing the task of
assessing changes to requirements. The introduction of changes to requirements would
impact the prioritisation, maintenance and traceability aspects of managing the
requirements throughout the life cycle of requirements.

TASK: Assess Requirements Changes

Every Business Analyst knows that change is a constant factor that must be managed
during any initiative. The task of assessment requirements changes outlines the purpose
of these tasks as well as the key elements to consider when change occurs with the
requirements. These key elements include assessing the formality required for a particular
initiative in terms of the nature of the initiative, which factors may have an impact on the
initiative and needs to be considered during this task as well as the final outcome of
whether a change is being accepted or rejected.

Let us now start this part with a clear understanding of the purpose of assessing
requirement change as a core Business Analysis task.

Purpose
According to the BABOK v3 Guide, the purpose of Assess Requirements Changes is

"to evaluate the implications of proposed changes to requirements and designs”.

Ultimately the Business Analyst must determine whether a change that is being proposed
to a requirement will increase the value of the overall solution. If it will increase the value,
it is important to then determine what action should be taken to make this happen.

Let us consider a practical example to understand this task further:

A company that owns an online store has a requirement to be able to do deliveries to the
customers. It was initially decided that full integration into another specialized delivery
company will be the best solution. However, it was later decided by the stakeholders that
12 of 17 Copyright 2020 | BAE Pty Ltd
the same delivery company will still be used but full electronic integration will no longer be
required and that the orders need to be reworked in-house before manually submitted to
the delivery company for execution.

In this example scenario, the assess requirements changes task needs to be performed in
order to determine whether the proposed change to the solution will increase the value of
the solution and if so what action should be taken to ensure this is implemented.

When the Business Analyst assesses changes to a requirement or set of requirements,

the following must be considered:

• Does the proposed change align with the overall strategy

• Will the proposed change affect the value delivered to the business or stakeholder
groups

• Will the proposed change have an impact on the time to deliver or the resources
required to deliver the value

• Will implementing the proposed change make a difference to any of the risks,
opportunities, or constraints associated with the overall initiative.

Elements
There are three key elements to consider when the Business Analyst assesses
requirements changes:

• Assessment Formality

• Impact Analysis

• Impact Resolution

Let us now consider each of these elements to understand the scope of the task in more
detail.

Element 1: Assessment Formality

Is a high level of formality and detail required when assessing a proposed change to a
requirement?

The amount of information available may determine the level of formality required in the
assessment process. The other two factors that may impact the level of formality that is
required during the assessment of the change to a requirement include the perceived
importance of the proposed change as well as the organization's governance process.

Predictive and Adaptive Approaches

As you know there are two moan types of approaches that exist, predictive and adaptive:
The predictive approach to delivery is a more formal approach and hence can cause a
rework of tasks and activities already completed when a change is implemented as well
as the activities required to assess the proposed change on the whole.

A lot of requirements elicitation and analysis are done in the early phases of a project
follow the predictive approach. This means when a change is required during later phases
of this type of project, there is often a higher impact on time, cost and effort required.

13 of 17 Copyright 2020 | BAE Pty Ltd

Whereas an adaptive approach will try and minimize the impact of changes by iterative
implementations from an early stage of the project. This approach typically lends itself to
a less formal and more adaptable approach to manage the impact of change that is
introduced during the life cycle of the project. Within the adaptive approach to delivery,
the idea of an evolutionary delivery may also reduce the need for a formal impact
assessment to be performed when a change is proposed to a requirement.

Element 2: Impact Analysis

What are the effects of a change to a requirement?

An impact analysis determines the effect of a change, by considering certain factors

relating to the requirement and the proposed change of that requirement.

For the exam, take special care to understand the considerations when assessing the
impact of a proposed change. It is important to notice that 'scope' is not listed explicitly
as an impact consideration. The scope is being defined as a 'cost' consideration in this
context.

Let us consider the following example to illustrate these factors:

A Bank has decided to add a credit card product to its portfolio. The new magnetic strip
credit cards have been designed and manufactured for the Bank, however the Banking
Regulatory Body has determined that all credit cards issued after a certain date must have
a microchip installed and specific data must be carried on this microchip.

Some key factors to consider when assessing this change to the requirements:

Benefit: What is the benefit that will be gained by adding this change to the requirement?
Compliance with the Banking Regulatory Bodies and improved security for customers
and the Bank.

Cost: What is the cost associated with the original requirement, and the cost impact to
add this change? In this case the cost of the original credit cards already exist and due to
the regulation these will need to be destroyed, thus the cost of this change in requirement
is the sum of the original cards plus the new and more expensive compliant cards.

Impact: The number of customers or business processes affected if the change is

accepted. Let’s continue our example of the microchip requirement for all credit cards. By
approving this change, the customers that have already been issued with the existing
credit card might be impacted, as they could potentially be recalled to replace their
current cards. A new business process must also be designed and implemented to
facilitate this recall of cards.

Schedule: What is the impact on existing delivery timelines if this change is approved?

Urgency: How urgent is this change? For example, what is the timeframe to become
compliant with this microchip requirement?

Element 3: Impact Resolution

Has the change been approved or denied?

14 of 17 Copyright 2020 | BAE Pty Ltd
The Business analyst is required to document and communicate all impacts and
resolutions resulting from the change analysis to share with all stakeholders. The
stakeholders will be responsible to approve or deny the proposed change.

The decision as well as the detail of the proposed change must be traced to the
requirement being assessed for a potential change. In the exam you must be able to
relate this task to the other tasks in this knowledge area by applying it to practical
scenario.

Once the decision to proceed or not has been made by the change control decision
makers, the Business Analyst should document and keep this information available and
up to date for any further reference that may be required during the initiative’s life cycle.

Inputs and Outputs

With the Requirements Life Cycle Management task: Assess Requirements Changes,
there are the following key inputs and outputs:

• Inputs: Change (proposed), Requirements and designs

• Outputs: Requirements Change Assessment and Designs Change Assessment

As an output to this task, the proposed change has been assessed both to a requirement
or a design. The status of this means that the change assessment is completed.

TASK: Approve Requirements

The Business Analyst will reach the stage in the requirements life cycle when the
requirements and designs must be approved in order for the life cycle to progress to the
next stage of an initiative.

During this section we gain a deeper understanding of why the task of approving
requirements is an important step during the requirements life cycle and we also discuss
what to consider when addressing conflicts and issues during this task. We discuss
aspects to include when gaining consensus amongst stakeholders regarding the
requirements under discussion and we cover the final stage of getting the final approvals
from the appropriate stakeholders.

Purpose
According to the BABOK v3 Guide, the purpose of the task: Approve Requirements is to

"… obtain agreement on and approval of requirements and designs for business analysis
work to continue and/or solution construction to proceed. ”

A key responsibility of Business analysts is to ensure clear communication of

requirements, designs, and other business analysis information to the stakeholders who
are responsible for approving the business analysis information.

The level of formality associated with the approval processes often depends on the type
of delivery approach that is being followed, being predictive or adaptive. During initiative
which follows a Predictive approach the approvals are often performed during end of
phase meetings or during change control meetings. With initiatives where an adaptive
15 of 17 Copyright 2020 | BAE Pty Ltd
approach is applied, the requirements are often approved on a just in time basis prior to
build and implementation activities. This is an ongoing process which happens as part of
a typical iteration or release cycle.

The communication of a required approval of a proposed change can be illustrated with a

practical example:

Let us consider that a change is proposed in the loan application process within a banking
environment, it will be required that all stakeholders needs to be aware and approve the
proposed changes.

Communication in connection with this change needs to include stakeholder groups such
as:

The Credit Department: To ensure they have all the information required to do correct
credit scoring and all this information is still valid and included in the proposed solution.

The Call Centre: To ensure they have all the information at hand to perform all current and
future required customer service tasks within the call centre environment.

The Collections Department: To ensure they agree that the proposed change will not
affect their processes in an adverse way and they agree with the proposed change.

All impacted stakeholder groups should be involved during the assessment of the
proposed change but most crucially receive the relevant communication about providing
their responsibility to also approve the change apply the required format or forum for the
initiative.

Elements
There are four key elements to consider when a Business Analyst performs the task:
Approve Requirements:

• Understand Stakeholder Roles

• Conflict and Issue Management

• Gain Consensus

• Track and Communicate Approval

Let us now consider each of these elements to understand the scope of the task in more
detail.

Element 1: Understand Stakeholder Roles

It is the responsibility of the Business Analyst to understand who holds the decision
making power to approve a change. The Business Analyst should also be aware of whom
to inform or consult with regards to a requirement. It is important for the Business Analyst
to consider that there may only be a small number of stakeholders who have the authority
to approve or reject requirements or changes to requirements, but many stakeholders will
have some level of influence and input into these approval decisions.

Element 2: Conflict and Issue Management

16 of 17 Copyright 2020 | BAE Pty Ltd

As a Business Analyst, you are responsible to gain consensus on requirements well in
advance of requesting from stakeholders to formally approve any requirements.
Stakeholders and stakeholder groups may different opinions, priorities, and perspectives
on the requirements and hence conflicts may need to be identified and resolved prior to
seeking formal approval from stakeholders or key decision-makers. It is the role of the
Business Analyst to continuously monitor and work with stakeholders to resolve any
issues or points where there may be conflicts.

Element 3: Gain Consensus

It is the responsibility of the Business Analyst to ensure that the stakeholder with approval
authority is comfortable and in agreement with the requirements and the business value,
it will generate. The Business Analyst can gain consensus by facilitating effective
communication with accountable individuals and ensuring all decision-makers are in
agreement and accepting the requirements for the solution being delivered.

Ideally, all stakeholders will be in agreement about the requirements but where this is not
the case, and it is decided to proceed with some stakeholders, not in full agreement, it is
important to assess the risks this pose to the initiative’s successful delivery and actively
managed as such.

Element 4: Track and Communicate Approval

The Business Analyst is required to keep a record of all approval decisions and of current
approval statuses. Stakeholders must be able to determine what requirements and
designs are currently approved and ready to progress to the next phase of the project.

Inputs and Outputs

With the Requirements Life Cycle Management task: Approve Requirements, there are the
following key inputs and outputs:

• Inputs: Requirements (verified) and Designs

• Outputs: Requirements (approved) and Designs (approved)

As an output to this task, the requirements or designs have been approved.

In a nutshell, as a Business Analyst it is important to plan and execute the activities

required to achieve the output of approved requirements and designs.

17 of 17 Copyright 2020 | BAE Pty Ltd