Table of Contents

Chapter 1................................................................................................................................................. 3
Digital Transformation Landscape .......................................................................................................... 3
Chapter 3................................................................................................................................................. 5
Career Paths For BAs............................................................................................................................... 5
Chapter 4................................................................................................................................................. 6
Earning potential for BAs ........................................................................................................................ 6
Chapter 5................................................................................................................................................. 8
Critical BA Skills ....................................................................................................................................... 8
Chapter 6............................................................................................................................................... 10
Debunking BA myths ............................................................................................................................. 10
Chapter 7............................................................................................................................................... 13
What is Business Analysis?.................................................................................................................... 13
Chapter 8............................................................................................................................................... 15
Stakeholder Management .................................................................................................................... 15
Chapter 9............................................................................................................................................... 18
Requirements Engineering.................................................................................................................... 18
Chapter 10............................................................................................................................................. 23
What type of BA do you want to be?.................................................................................................... 23
Chapter 1

Digital Transformation Landscape

If you are reading this book, there is every chance that you have come across the phrase, ‘Digital
Transformation’.

I felt it necessary to start off with a chapter about WHY the role of a Business Analyst is of critical
importance in the age that we are in, the Digital Age, (you can argue, Information Age, Computer
Age, New Media Age etc). And there is no better place to start than with the effect that Digital
Transformation has had on businesses and the subsequent rise of the importance of the Business
Analyst within Digital Transformation.

Digital transformation is creating a shift in the way business is done across the globe and this has
created a ripple effect across industries, sectors and professions. Competition is getting stiffer, as
the internet has enabled organizations reach a whole new global audience, customers have more
choice and more voice as they are able to drive businesses to make rapid change, now more than
ever before.

Digital Transformation is said to be the way in which organizations transform their business model to
leverage the opportunities created by digitization. Digital transformation can be as localises as
changing paper forms to web forms and as globalised to changing an entire organizations business
processes and business model to an online one. It can even include creating entire new markets and
industries.

Digital Transformation has come to stay and it is global, not local. Every business will experience
Digital Transformation at some point. From the street hawker who now has to call in their
replacement order or fill in a form online, to the small business owner installing an accounting
software for the first time. From the law firm trying to reach a new audience online to the
Manufacturing company who has to create digital designs and prototypes to reduce costs. Gone are
the days when an organization can be content being a brick an mortar business. To survive,
businesses are quickly realising they need to move with changing technology.

The choice organizations have to make is usually about ‘how’ they leverage technology to either
exploit their opportunities, overcome their weaknesses, enhance their strengths or combat external
threats. This is where the Business Analyst is critical to an organization’s success. In chapter 9, we
break down what Business Analysis actually is, and what it is not. We also define our role with
clarity, to ensure everyone, including ourselves, know who we are and what we do.

I recently worked with a start up Higher Institution that required all it’s business processes digitised.
From it’s enrolment process, to its bursary process, to its learning management. This was a Digital
Transformation program that seemed simple but became complex really quickly, due to the multiple
layers of decision making that was required. Questions like, should we make all students enrol
online? Should we allow brokers and agencies take cash? Should we digitise all library books? Should
we have classroom content online? Should we train lecturers on the learning management system?
All of these questions have technological implications that required a cost vs benefit analysis to
make the right decision, the questions also have dependencies that needed to be considered, as well
as risks to prepare for.
Digital Transformation as a concept, drives businesses to succeed using the opportunities made
available by technology. Digital Transformation as a practice, drives businesses to make intelligent
decisions daily while transforming the organization an embedding change into its fabric. Digital
Transformation is about the happy medium between the use of technology, management of
business change and intelligence of business decisions across all levels within an organization.

BAs within Digital Transformation

It is critical to have a Business Analysis exercise when going through Digital Transformation. Business
Analysis is all about analysing a business situation, to find out where improvements can be made
and how improvements can be made. It also includes a process to arrive at a sound business
decision when embarking on any change, including Digital Transformation. In order to make a sound
business decision, an organization should understand its organizational context, including its
strengths, weaknesses, external factors that may affect it positively or negatively, Its strategy, its
culture, its competitive landscape and more. Once that context is understood, an organisation
should seek to carry out internal investigation of its current problems to identify the causes of failure
in any given area. After which, it should consider the individual perspectives of key influential
stakeholders within the organization. Before carrying out a Digital Transformation program, an
organization should also carry out a gap analysis to gain clarity of where they currently are and
where they would like to be, so that a list of potential options for change can be evaluated. Once an
evaluation is done, usually through the production of a business case, then the Digital
transformation may commence. By far the most popular business analysis exercise is the gathering
of requirements, where A Business analyst is usually required for bringing together the requirements
for the digital transformation program and any associated projects within it.

Business Analysts help businesses to make the right business decisions across strategic, tactical and
operational levels. The BA’s primary role is to help the business make improvements, as a result, all
of the activities mentioned above can be carried out by Business Analysts.

The Business Analyst is an expert of the Business and know what the business needs in order to
improve. As a result, the BA ensures all the moving parts of any transformation program are held
together in a way that coherently drives the business to a successful change.

Companies are spending record amounts on Digital Transformation and many are struggling to see
the transformation succeed. According to Digital Journal, 85% of executives said they will spend 25%
of their entire budget on digital transformation in 2018. However, only about 50% of organizations
are achieving any significant success. This is good news for the BA as I have seen, in my personal
experience that programs with a robust Business Analysis function tend to achieve success. This, I
believe is down to the role of the BA as the conduit between Business teams and technology teams
and the clear view that the BA has on the program as a whole.

In other words, Digital Transformation needs Business Analysts now, more than ever before, an Its
about time that Business Analysts realise the opportunity in front of them.
Chapter 3

Career Paths For BAs

There are a couple of accreditation bodies globally that define a set of standards for the Business
Analysis profession, namely British Computer Society (BCS), International Institute of Business
Analysts (IIBA) and Project Management Institute (PMI). The PMI have a Business Analysis
Certification (PMI-BA)

My views in this chapter are independent of the suggestions made by the BCS, PMI or IIBA.

Getting into Business Analysis

I became a Business Analyst by default. I started my career in Training and Development. I worked
on developing both classroom learning content as well as e-learning content. I also helped
organizations transition to e-learning through the implementation of bespoke learning management
systems. My experience of working with developers on Learning Management systems exposed me
to the business analyst role. From that point on, I found myself defining requirements for new IT
solutions, mainly CRM systems, mapping business processes across organizations and driving
enterprise change programs across multiple levels.

Your path may be different. Many of my colleagues and students also found themselves in Business
Analysis by default while some actively sought to transition to Business Analysis actively.

One of my friends worked in a local authority within the UK for many years as a financial assessor.
He found himself writing requirements for a financial solution with a 3rd party supplier as a subject
matter expert and by default was the council’s representative with the suppliers. He became a
Business Analyst by leveraging the experience gained on some of the projects he worked on.

Another friend of mine was a community engagement officer with a Housing Association. She was
involved in helping residents get much needed access to facilities, training, support etc. she worked
on a project to set up a community online platform that residents could use to report issues and get
support from the Housing Association. She was pulled into other similar projects within the
organization and found herself being successful in a Business Analyst role.

Growing as a Business Analyst

As a Business Analysis consultant, I was brought in to help an organization write requirements for a
software system they built, so that they can carry out end to end testing of the solution effectively. I
spent some time understanding the business challenges and then proposed a dual approach to the
sponsor of the program. I suggested that 50% of the time I had with them should be spent on writing
their requirements whilst the other 50% should be spent assessing the readiness of the business to
support the solution. The sponsor accepted and I was given the opportunity to develop an operating
model for the business and make recommendations on how they can improve as they scale their
business.

One of my coaching clients got a job as a Business Analyst within a healthcare organization and
supported the development of a business case for the implementation of a Customer Relationship
Management system. After a few months, she was leading the business change function in charge of
aligning benefits across all the organizations programs to its strategic goals.
There are several paths for a Business Analyst an here are my top suggestions

1. Senior/Lead Business Analyst – typically a natural path after a few years of experience as a
Business Analyst
2. Business Architect – Perhaps the most natural career progression option for the Senior/Lead
Business analyst. Many of the skills acquired as a Business Analyst are the basis for the tasks
carried out by Business Architects, for example high level Process models are used to
determine the organizations Value Stream, the Business Activity Model may be used to
determine the Capability Model and Target Operating Model
3. Enterprise Architect – Enterprise Architecture includes Business Architecture, Data
Architecture, Applications Architecture and Technology Architecture. A natural progression
for the Business Architect who wishes to be more technology focussed.
4. Product Owner – Within rapidly changing organizations, it is not uncommon to have
someone dedicated to the development of products from its ideation to its business benefits
realisation. A Business Analyst can be ideal for such a role
5. Head of Business Analysis – Another natural path for a Lead Business Analyst or Business
Architect who wishes to develop a BA function within an organization. Many organizations
are beginning to see the value of a robust and mature BA function
6. Business Change Manager- At a program level, the BCM tends to be responsible for the
benefits realisation of all change initiatives. This strategic level role has become more high
profile in recent times

One role that I have seen on many similar lists as the one above is the Project Manager role. I have
chosen to leave this role out of my list as I believe that the BA role is very different from a PM role
and although there are many transferable skills, the core skills of a Business Analyst lends itself more
to better development with the 6 roles mentioned above.

Ultimately, the BA can develop skills that will be suitable for many strategic level roles within an
organization.

Chapter 4

Earning potential for BAs

One of the reasons many people get into Business Analysis is the potential for increased
earnings.
The average pay for BAs in the UK rose by 8% in 2018, and I believe it will rise even further
into the coming years.

There are many factors that contribute to our understanding of the earning capacity of
Business Analysts, including the industry, your specialism, your domain or subject matter
expertise, the organization’s budget, your level of experience, your negotiation skills and
more.

This chapter takes a static snapshot view of the salary landscape of Business Analysts across
industries within the UK as at August 2018. (sources: itjobswatch, Reed, Payscale and
cwjobs)

Junior BA 1 – 2 Years’ Experience

Contract - £250 a day
Permanent - £31,000 a year

Mid Level BA 3 – 5 Years’ Experience

Contractor £450 a day
Permanent £ 50,000 a year

Senior BA 6 – 10 Years’ Experience

Contract - £500 a day
Permanent – £57,500 a year

Other chapters in this book focusses on how to get into the Business Analysis profession and
how to develop your BA career and increase your earnings.
 Chapter 5

Critical BA Skills

I speak to new and prospective BAs very regularly and it amazes me how many people do not know
which skills are critical to the success of a Business Analyst.

As with many professions, the BA profession has a specific set of skills that are key to our success. An
understanding of these skills would be useful before deciding to become a BA.

Imagine trying to be an accountant and you can’t stand the sight of numbers and spreadsheets. You
may be a good enough accountant, but I’m not sure you will progress much within the accounting
career. Similarly, someone who is a BA but not great with people or with bringing together
information for people at all levels within an organization. You may get by as a BA for a while, but I
doubt you’ll progress much within the profession.

I think it is very important to carry out a self assessment before deciding if Business Analysis is right
for you, by taking stock of your skills and identifying the gaps so that you are able to plan your career
more effectively

According to the Business Analysis 3rd Edition, there are 3 broad sets of skills that a BA should
endeavour to develop. Personal Qualities, Business Knowledge and Professional techniques.

Whilst professional techniques are relatively easy to learn, Business Knowledge and personal
qualities are relatively more difficult to develop.

Personal qualities Business knowledge Professional techniques

Communication Business finance Project management

Relationship building Business case development Strategy analysis

Stakeholder analysis and

Influencing Domain knowledge
management

Team working Subject matter expertise Investigation techniques

Political awareness Principles of IT Requirement engineering

Analytical skills and critical

Organization structures Business modeling
thinking

Attention to details Supplier management Data modeling

Problem solving Business architecture Gap analysis

Leadership Facilitation skills

Self Belief Portfolio management

Professional development Benefits management

Agile thinking

Take a minute to review the list above and identify which one of the skills you are proficient in.

Developing these skills, is a long term project for the Career BA, It may sometimes take several years
to develop a handful of personal qualities for the level of experience you have as a BA.

However, I always say to my students, there are 3 key skills you need to be confident in, as you start
your business analysis career.

!. Stakeholder Management

2. Process Modelling

3. Requirements Engineering

Within these 3 skills, you ill find enough to get you through your early days as a Business Analyst. In
subsequent chapters, I will break down each of these skills
Chapter 6

Debunking BA myths

There are so many misconceptions about the role of the Business Analyst and this chapter seeks to
debunk some of those myths. These myths tend to be a barrier to many people trying to become a
BA.

Myth 1 – I need to know how to develop software

This myth is perhaps one of the more nebulous myths as it tends to be couched in language that is
ambiguous. For example, I was speaking with customer service officer recently and when I asked her
if she considered a career as a BA, she said, ‘I don’t know anything about IT’, however what she
meant to say was that she doesn’t know how to develop software. I know this because I probed
further and asked her questions about the infrastructure they use within the organisation, the
platform her team uses, the relationship between her team and the IT team and it turns out she
does know about IT, she just doesn’t know how to write software code.

Many BAs do not know how to develop software, neither are they expected to. The BA does need to
understand how IT works and some basic principles so that the communication with the
development teams will be effective.

Many Systems Analysts and software developers are making the transition to Business Analysis and
they do have some advantage when communicating with the development teams. However, they
also have some distinct disadvantages for example, they may suffer from a cognitive bias called,
‘curse of knowledge’ where the temptation of doing the work of the developer becomes so strong
that they lose sight of their own role and the bigger picture. They also may lack the skills required to
engage with business stakeholders as they are not used to doing so.

Myth 2 – I need to have years of experience as a BA

This myth seems to hold true on the surface, however when you delve deep, you’ll realise that there
are ways around the challenge of ‘work experience’

As with many careers in the UK, the need to start with some level of experience is a constant
conundrum faced by many new entrants.

Think about it from an organization’s perspective; would you feel better if you hire someone who
knows what they are doing and won’t need you to babysit them? Of course! However, if you find
someone who demonstrates the ability, to o the job you wish to hire them for, the relevant skill,
some evidence of having used that skill, would you not consider that candidate? Of course! So, it’s
not necessarily the experience of being a Business Analyst that a hiring Manager is looking for, but
the ability to demonstrate your skills as a Business Analyst. It just so happens that work experience is
the easiest way for most people to demonstrate their skill.

When I got my first ‘proper BA job’, I was already experienced at the level of a Senior BA. How does
that make sense?

I leveraged my experience from working as a Training Manager.

How did I do that?

I simply identified the Business Analysis related tasks that I performed when I was a Training
Manager. It just so happened that many of the things I did on a regular basis were BA tasks, for
example:

1. Business Case development – I regularly had to write a cost benefit analysis for organizations
looking to implement a learning management system. I also had to justify training initiatives
for staff
2. Process Modelling – Many organizations have their learning and development team within
the HR department and when implementing Learning Management Systems, it was
important to map the HR processes, particularly the ones impacted by the new solution. I
also had to model processes prior to training staff on new systems, when mergers happened
and when departmental restructure happened
3. Requirements Engineering – I had to ensure requirements were effectively managed on
every LMS implementation I was involved in. I have also sat through walkthroughs,
workshops, and reviews of requirements documentation for projects that impacted my
teams.
4. Stakeholder Management – As a Trainer, this was one of the most important aspects of my
job. I had to manage expectations of managers, delegates, heads of departments etc

There are just a few of the skills I had acquired long before I ever got my first Business Analysis role.
Many Business Analysts also have similar paths where they simply got involved in projects that
affected their business area, as a subject matter expert, advisor, team lead or simply an observer.

This means that you do not have to have worked as a ‘proper BA’ before getting a job as a BA.

If you already have some experience in an industry or in using a particular software tool, you can
leverage that experience as a platform for your career as a Business Analyst.

Myth 3 – I have to be certified before I become a BA

This myth is not as common as the above 2, however, I have heard many prospective BAs use it as an
excuse.

You do not need to be certified before you become a Business Analyst, however, it does greatly help
to get trained so that you are aware of the boundaries of your role and the expectations from you.

I am a big advocate of Certification but some organizations and industries value certification more
than others. Getting certified gives you a solid foundation and knowledge of the basics of the
Business Analysis role

Myth 4 – BA’s are only required on IT Projects

I hear this myth more times than I can stomach these days but I’m sure not every BA will agree with
me.

There is a distinction between IT projects, pure business change projects and IT-enabled business
change projects
IT Project - It is arguably easier to describe projects in this manner since projects deliver change with
an IT solution focus. This does imply an over-dependant focus on technology. Many of these projects
are simple localised implementation of an IT solution such as the replacement of an existing IT
system

Business change Project – Business change makes it clear that the focus is on a change to the
business activities of the organisation that don’t involve IT. For example, changes to a business
process, organizational restructure, changes to teams structures and reporting lines etc

IT-enabled business change – these types of projects suggest improvements in the way an
organisation carries out its business brought about through the effective use of information
technology. Many of the projects we work on, tend to be IT enabled business change projects but
we quite easily work on the others as well.

The role of the BA was borne out of the need to bridge the gap between Business and IT, however,
our role has evolved significantly since then, to include tasks that are not related to IT and initiatives
that are not about leveraging IT.

Note that as Business Analysts, our purpose is to help the organization improve, and to do that, we
analyse the competing forces and variables that can affect improvement and then we make
recommendations to the business. One of such recommendations may be projects that do not
involve IT. For example, if an organization wishes to increase sales, we carry out our investigations
and realise that data is not easily accessible, or it takes too long to get information, we may
recommend the procurement or development of a sales pipeline management system, however, we
may also recommend a change to the sales process that may or may not involve the development of
an IT solution.

In today’s Digital age, there is every chance that most business improvement initiatives we are
involved in, will have an element of IT, it’s more likely that it is an IT-Enabled business change

Myth 5 – Only big companies need BA’s

A friend of mine is a partner at an NHS GP practice, he called me up one evening and told me about
the difficulties they are facing at their practice. They have just brought together 2 separate practices
under one roof and they think they need to streamline their processes because they are spending a
lot more than they should. This practice employs 20 staff and has about 5,000 registered patients. In
the grand scheme of things, not a big organization by any stretch of the imagination.

I was able to get them a Business Analyst with some experience of working within a GP practice to
help them increase their efficiency.

The practice would not have been able to afford a Business Analyst on a contractors wage or full
time salary, however, they still needed to improve their business.

There is a massive opportunity for new and prospective BAs to develop their skills by offering small
and medium sized organizations their BA services either for free or for a small fee, This creates a
win-win situation for both parties.

I believe small and medium sized organizations need Business Analysts more than they realise.
Chapter 7

What is Business Analysis?

You have read a few chapters on why Business Analysis is a career on the rise and why the Business
Analyst career is an attractive career option in this Digital Age.

This chapter delves a little deeper into what Business Analysis actually is and what it is not.

Business Analysis is a relatively new discipline, so there persists a lack of clarity about what the role
really involves

This chapter examines business analysis as a specialist profession and considers how we might
better define the business analyst role.

I speak to people everyday about Business Analysis and most people I speak to, are not Business
Analysts, but they have decision making powers within organizations. When I ask them what
Business Analysis is, or what their BAs do, the almost always say that BAs are the ones that gather
requirements for an IT project. Their limited understanding of the role of Business Analysis worries
me. In fact, many recruiters and hiring managers I speak with, tend to share this limited view as well.

A number of Business Analysts are hired by Project Managers or other people other than Senior
Business Analysts or Heads of Business Analysis. It becomes increasingly difficult for there to be a
consistency in the evaluation of the BAs work and a consistent development of the BA profession. As
a result, getting clarity of the definition of Business Analysis becomes of paramount importance

The most interesting definition is one culled from the Business Analysis book used as a basis for the
BCS certification program.

“An internal consultancy role that has the responsibility for investigating business situations,
identifying and evaluating options for improving business systems, defining requirements and
ensuring the effective use of information systems in meeting the needs of the business.”

Debra Paul et al (Business Analysis 3rd Edition)

The focus of Business Analysis is to ensure that IT meets the needs of the Business. In order to do so,
the Business Analyst engages in a number of activities that will ensure that business needs are met.

1. Understand the Business Context – To understand internal and external factors that may
impact change
2. Investigate the Business Situation - To uncover the issues and problems or opportunities
associated with current system
3. Consider Stakeholder Perspectives - To take stock of the range of stakeholder perspectives
about the business system under investigation; these perspective may further analyse to
uncover stakeholder values
4. Analyse Business Needs - To explore the differences between the current and desired
situations and to identify opportunities for business change by analyzing ‘gaps’ This section
includes the Gap analysis as well as mapping the as is and to be processes
 5. Evaluate Options for change - To collect together the range of potential changes into
packages of improvement actions; which can be used as basis of developing the options. This
stage includes the development of the Business Case to ensure viability of the chosen option
6. Define Requirements - To produce a well-formed requirements document with the business
requirements for new business system; this document must include clear textual
descriptions and sufficient information to trace each requirement from its source to its
development and in line with the business needs and objectives

As you can see, Business Analysis is a lot more than gathering requirements for an IT system. This
also means that the level of skill and experience required for different BA tasks vary significantly. For
example, not many Junior BAs will be tasked with developing a Business Case or provide
recommendations to the business on whish business change option to embark on. Usually, Junior
BAs may be supporting the elicitation of requirements but not necessarily be responsible for the
production of the requirements document.

Some of the Business Analysis tasks mentioned above also require a level of strategic thinking that
may be too much for a Junior or Mid level BA to handle. On the other hand, some tasks may be too
technical or detailed in nature for a Senior/Strategic thinking BA to handle, for example, writing
acceptance criteria for requirements using Gherkin Syntax or writing test cases for User Acceptance
testing.

Ideally, Business Analysts should aim to be well rounded, however, it is only natural for people to
have a preference of tasks, tools, techniques that they are comfortable with.

Business Analysis is the one of the few roles that are required at all levels within an organization,
including Strategic levels, tactical levels, operational levels and technical levels.

Business Analysis is a role required within any organization going through change, that ensures best
practice tools, practices and processes are utilised to enable the organization achieve its business
goals and the solution developed through change, meets the business needs.
Chapter 8

Stakeholder Management
Perhaps the most important skill that a Business Analyst must have

Many BAs focus almost entirely on the development of their professional techniques and pay very
little attention to their soft skills. Stakeholder Management, although a professional technique for a
BA, requires a great deal of personal qualities to ensure its effectiveness.

In this chapter, I will focus on 2 approaches:

• Stakeholder Power vs Interest

• Stakeholder Attitudes

Many business analysts I speak with, mention the issue is stakeholder management as an important
topic within their career and usually struggle with this concept.

One of the most common Interview questions for Business Analysts is; ‘tell me about a time you
have had to deal with a difficult stakeholder, what happened and how did you deal with the
stakeholder?’

Many Business Analysts I speak to, struggle with this question, not because it is a difficult skill, or
they don’t know how to deal with difficult stakeholders, but because they find it difficult to
articulate how they deal with difficult stakeholders.

Who is a Stakeholder?

A generic definition commonly quoted by business analysts: A stakeholder is anyone who is affected
by change within an organization or who can influence change within an organization. Given this
definition, almost anyone can be considered a stakeholder.

Answering questions about Stakeholder Management

Answering stakeholder management questions can be quite tricky. It is important to answer such
questions with clarity as this will set your answer apart from everyone else’s.

Ensure that you mention the professional technique you used as well as the soft approach you used.

Professional Techniques

The Power Interest Grid

The Power Interest grid is a common stakeholder management technique that focusses on the levels
of power/influence and interest a stakeholder/stakeholder group may have. This will allow the
appropriate communication technique to be employed. For example, the power interest grid suggest
that a stakeholder with low power but high interest should be kept informed.

Here is how it looks

Stakeholder Attitudes

It is important to understand the attitudes of specific stakeholders/stakeholder groups as this will

ensure you have a clear understanding of the preferred attitude of your stakeholder in comparison
to their current attitude.

Typically, you may want your key stakeholders who have high power and high interest to be a
champion as they will have the drive, passion and significant authority to ensure your project is
successful. On the other hand, you may want your stakeholders with high interest and low power to
be supporters as they may not have enough authority to ensure project success, but they will enable
the adoption of change and buy in and acceptance.

Here are the different stakeholder attitudes within this model and they range from Blocker to
Champion. With more key stakeholders with positive attitudes, your project will have a better
chance of success:

Here are the possible stakeholder attitudes:

Champion:- will actively work for project success

Supporter:- In favor of the project but will probably not be an active promoter

Neutral:- Has expressed no opinion in favor or against

Critic:- Not in favor, but probably not actively opposed

Opponent:- Will work actively to disrupt, impede or derail the project

Blocker:- Will obstruct progress, maybe for reasons outside of the project itself

A typical stakeholder management plan may look like this:

Dealing with stakeholders may well be one of the most important aspects of the Business Analysis
role and being skilled at the hard and soft aspects of dealing with stakeholders will ensure success as
a Business Analyst
Chapter 9

Requirements Engineering

There is one task that is unarguably firmly within the remit of a Business Analyst and that is
Requirements Engineering.

Lets start with a basic definition of requirements – according to the IIBA

1. A condition or capability needed by a stakeholder to solve a problem or achieve an

objective.
2. A condition or capability that must be met or possessed by a solution or solution component
to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

Most people I speak with, think that the BA only gathers requirements within a project and that is
the extent of their role. Of course, we know that is not the case.

Either way, requirements management is one skill that a Business Analysts must be competent in.

I will use the terms Requirements Management, Requirements Gathering and Requirements
Engineering interchangeably for the purpose of this book, even though they have different
meanings.

Requirements Engineering encompasses the full requirements lifecycle from elicitation (gathering)
to management.

Requirements Gathering can be considered as the generic term for eliciting requirements, although,
I have heard many Business Analysts refer to the full Requirements lifecycle as Requirements
Gathering

Requirements Management is the task of managing changing requirements after the initial
requirements have been signed off.

The Requirements Lifecycle (Based on the BCS model)

• Requirements Elicitation
• Requirements Analysis
• Requirements Validation
• Requirements Documentation
• Requirements Management

Each of these distinct stages have several activities that should be completed.

The aim of this chapter is not to teach you how to Gather Requirements, ( I highly recommend a
training course for that, visit careertransitioner.com for more info) but to share my experience of
dealing with requirements, throughout the Requirements Lifecycle.

As a Business Analyst, it is important to understand the business context and the environment you
are working within. Understand the culture, the standards across the industry, the organizational
drivers, the key influencers and most importantly the change delivery methods.
In my experience, I found that most organizations start off with an aim to adopt a best practice
approach for project delivery, off the shelf and realise that they do not have the organizational
support to adopt that best practice approach.

Requirements Elicitation

Eliciting requirements is all about getting information from people and understanding it in a way
that makes sense for what is being built. Eliciting requirements is all about the personal qualities you
display, as well as the logical reasoning you possess. Personal qualities so that you can get people to
open up to you and logical reasoning so that you can organize the requirements and translate the
information into actual requirements.

There are many techniques we use to elicit requirements, however most Business Analysts defer to
just 2 techniques; Workshops and Interviews. I will share my views and experience on these two
shortly.

Here are a few techniques for eliciting requirements

The obvious 2, Interviews, Workshops, and then a number of less used techniques including:
Observation, Protocol Analysis, Special Purpose records, ethnographic studies, scenarios analysis,
activity sampling, questionnaires, prototyping, and more. As a Business Analyst, you should be able
to use the appropriate technique at any given time. I once had to use Activity sampling on a project
once to try to make a case for automating a particular process. Activity sampling is when you
observe a particular event with the aim of identifying how long actors are spending on that
particular activity.

One of the things I have learnt over the years when eliciting requirements is that people don’t know
what they want, and more annoyingly, people are reluctant to commit. I remember eliciting
requirements once and the solution owner, who was the main authority for the project refused to
commit to a baseline set of requirements. He kept a neutral stance on every requirements, neither
saying yes or no to any requirement. After one particular workshop, I remember feeling like I had no
idea if people really agreed or understood what the solution we were building was supposed to do.
There were a number of statements of wishes uttered by participants and when I looked at the list
of requirements, I remember thinking, ‘this doesn’t make much sense’. That’s when I had to really
bring to the forefront of peoples awareness, the purpose and the business need based on the
business problem we were trying to solve. In my experience, this is one of the most important
aspects of requirements elicitation.

The main output from the requirements elicitation stage is an initial list of requirements ready to be
analysed. From this point on, the requirements engineering process becomes an iterative process,
rather than a linear process.

Requirements Analysis

One of the most important stages of the requirements engineering process is the Analysis stage. I
remember conducting a Requirements Assurance exercise once where I had to review the quality of
the requirements that had been documented and I realised that there was absolutely no analysis
done. What I saw, was a list of requirements with a number of basic attributes such as Identifier,
Description, Business Area and not much else.

The Requirements Analysis stage is where you as a Business Analyst ensures that the initial
requirements are well formed and represent that capabilities needed for the solution. This is the
stage that the requirements are categorised, prioritised, filtered, linked/grouped and written in a
way that removes any ambiguity.

Requirements Categorisation

Typically, there are 4 categories of requirements, however it’s not uncommon for projects to have
just 2 or 3 categories.

General – High level business policies, constraints and capabilities.

Technical – business Requirements that dictate the technical capabilities for the solution, such as
interface requirements, hardware requirements, software requirements

Functional – The requirements that dictate what the solution should do, including what users want
to be able to do. Functional requirements include data entry or retrieval requirements and
procedure requirements

Non Functional – the requirements that dictate how the solution should enhance the functionalities
or the solution as a whole. Non functional requirements include performance, how fast the solution
should respond, capacity, access, portability, scalability, security and all the ilities

Once requirements are categorised effectively, I go on to prioritise requirements to ensure that the
most important requirements are agreed on and understood by the development team.

You may have heard of MoSCoW prioritisation, well, there are other prioritisation techniques,
including Value based prioritisation, Kano Analysis, 100 dollar method and more. You should try
different types of prioritisation sometime, they can be so much fun.

Another activity performed when analysing requirements is the application of filters. Its very
important to ensure that the requirements being documented are the right requirements. When
applying filters, you should check for multiple requirements, check for conflicting requirements,
check for overlapping requirements, and then ensure the requirements are clear, concise, relevant
and are actually requirements and not just statements of random information

Requirements Validation

Validating requirements is all about getting sign off for requirements. Many projects have a formal
sign off activity called the walk through, where the requirements owners and the project team agree
on the validity of the documented requirements. I always recommend that you have a review group
that will help ensure that validation is successful.

The Review group, should include the following roles:

Business Sponsor – mainly concerned with the project meeting business objectives and scope

Business Owners – mainly concerned with solution meeting their own business needs

Domain Expert – they help ensure that requirements meet best practice

Developer – helps ensure technical feasibility of the solution

Tester – helps ensure the requirements are testable

I always recommends spending time with each stakeholder in your review groups and ensure their
buy in and engagement to ensure that your requirements are signed off on time and without
objection.

Requirements Documentation

When discussing requirements documentation, we have to discuss the software development

lifecycle. Typically you will find that the 4 main system development lifecycles are:

Waterfall – a linear traditional approach to developing software starting with Requirements, then
Design, the Development, Then Testing then implementation

Incremental – a variation of waterfall where Requirements and Design are done upfront and
Development, Testing and Implementation are broken up into phases.

V Model – Typically used by Testers where the pre development stages are aligned with the different
test levels such as component testing, system testing and user acceptance testing.

Iterative – typically used in an Agile environment where requirements, design, development, testing
and release are done rapidly within short iterations, typically 2 – 4 weeks,

When documenting requirements, it is important to ensure that the requirements are packaged to
suit the lifecycle being used.

Many organizations use a hybrid of sorts or a combination of a number of these lifecycles, as a

result, you may find that many software projects document requirements in a variety of different
ways.

In an Agile environment, you typically document requirements at a high level and then document all
planning levels till development is done.

Typically, high level requirements or business capabilities are called Epics which are broken down
into User Stories, which are simply statements of functionality from the perspective of the user.

User stories also have acceptance criteria, which are objective statements that ensure that the
functionality is developed effectively. The acceptance criterial also aids sign off of the requirements.

When Documenting requirements, it is important to identify the artefacts required, depending on

the development environment. Here are some artefacts that should be considered:

• Requirements Catalogue
• Functional Models – Use Case Diagrams
• Data Models – Class Diagrams, Entity relationship diagrams
• Glossary of terms
• Product Backlog

Requirements Management
The process of managing changing requirements would usually require the use of a software tool,
usually called CARE or CASE Computer Aided Requirements Engineering or Computer Aided Software
engineering.

These tools ensure changes are tracked, requirements are traceable, reports can be easily
generated, a central repository is maintained for the documentation and the project team have a
single view of the solution documentation as it evolves.

If you are starting out as a Business Analyst, I would highly recommend getting familiar with
software tools such as Jira or Visual Studio team Server from Microsoft as these are 2 of the most
popular requirements management tools apart from Microsoft Excel There are many more tools and
there would undoubtedly be many more in years to come.
Chapter 10

What type of BA do you want to be?

The Business Analysis profession is a very broad role and in my opinion, one of the very few roles
that spans across organizational strata, from Strategic through tactical and to operations.

As a Business Analyst you could work closely with strategic level stakeholders trying to decipher the
goals of the change initiative and very quickly engage in conversations with technical stakeholders
about the different system interfaces required and the data flows across multiple systems.

It is important to be clear about the type of Business Analyst you want to be as you begin your BA
journey.

Technical/IT Business Analyst

You may have seen some roles online with the title IT Business Analyst; I personally do not support
the idea that there is such a role as an IT Business Analyst. I believe it goes against the fundamental
purpose of the role of a Business Analyst, however, we are where we are. Organizations sometimes
have Business Analysts within IT departments and these Business Analysts work primarily on IT
projects and mainly work on requirements engineering within these projects.

As an IT Business Analyst, there is an expectation that you have some technical or IT skills, especially
data related skills such as; Structured Query Language (SQL) data mapping and modelling,
sometimes even a basic understanding of programming languages. There is sometimes also an
expectation that you are skilled at low code development using tools like Pega, K2, Appian etc

If you are detail oriented and good with data and numbers, this may be a good place to be. As a
technical/IT Business Analyst, you will be close to the development teams. This will enable you
develop an appreciation for how business requirements will be translated into workable solutions.

On the other hand, there is a risk that you may be far removed from the business and you may
struggle to understand the business needs and the drivers for business decisions.
Strategic Business Analyst

A business analyst should understand business problems and should be able to identify options for
improving the business or solving those business problems.

The Strategic Business Analyst takes a high level view of the problems and the various options and is
analytical in their approach to solve that problem. There is a wide range of skills required to be
effective at this role.

I knew a Business Analyst that was once brought in by an organization to gather requirements to
enable testing, after their solution was built. The solution was a greenfield software product that
was built in collaboration with 3 different suppliers. The Business Analyst took the business on a
journey of business readiness that took on a holistic approach. The first thing the Business Analyst
did was to identify the internal and external factors that may affect the business in relation to their
new product. He identified a number of factors and ranked them in a way that compelled the senior
stakeholders in the business to address their risks before going live with this product. The BA held a
number of interviews, ran a few workshops, analysed a number of documents they already had and
produced a business readiness report that ranked their risks across a number of areas within the
business. His report covered areas such as Governance, People, Processes, Data and IT Solution. The
BA went on to make a number of recommendations that would improve the business in preparation
for Going Live with their new product. The Business Analyst saved the organization a considerable
amount in reputational damage, loss of revenue, increased costs all stacking up to about 20% of
their revenue.

A strategic Business Analyst is skilled at identifying the main problems a business faces and
facilitates the process of improving the business situation.

One of the most important skills a Strategic business analyst possesses is the ability to gain the ears
and respect of the decision makers in a business and the financial acumen to be able to quantify the
problems and make sound recommendations that will help their business achieve their goals,
regardless of what those goals may be.

A strategic Business Analyst is not constrained to a project already initiated, but may provide data
and insights to enable the business initiate projects.

The Dynamic Business Analyst

I believe that a skilled and experienced Business Analyst should be dynamic enough to be both a
Strategic Business Analyst and a Technical/IT Business Analyst