Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
According to the Business Analysis Body of Knowledge, Second Edition, “business analysis is
the set of tasks and techniques used to work as a liaison among stakeholders ……………….
to recommend solutions that enable the organization to achieve its goals”. A Business
Analyst is any person who performs business analysis activities, no matter what their job
title or organizational role may be.
In the context of the above definition, put simply, a Business Analyst is a problem solver.
The problem need not necessarily be related to software. The success in the role of a
Business Analyst primarily depends on the Business Analyst’s ability to clearly identify
business problems (or opportunities) from his / her elicitation sessions with the key
stakeholders and obtain consensus on them. The need for this ability cannot be emphasized
enough considering the fact that:
1. Most stakeholders don’t understand their own problems but they certainly
think they do. Very often, you see stakeholders specifying solutions when asked to
articulate their problems. I remember a key project stakeholder mentioning in one of
the first project meetings that he needed a Supply Chain Management system, when
asked about the business problems he was facing, being blissfully ignorant of the fact
that what he specified was actually a solution and not a problem.
If stakeholders exactly knew their business problems and could clearly articulate them, the
role of a Business Analyst would be redundant. The Business Analyst adds value by helping
stakeholders understand their problems and recommending the best solution that would
enable them to meet their business goals and objectives.
When someone refers to a ‘Business Analyst’, he very often ‘means’ an SME (Subject Matter
Expert). However, over the years, the industry realized that simply having subject matter
expertise is not enough for effective business analysis. The methods and practices used by
the SME are equally important. This fact, along with the release of the BABOK (Business
Analysis Body of Knowledge) v2.0, made organizations work towards enhancing their
business analysis practices beyond simply recruiting subject matter experts.
This article aims at highlighting the important competency areas a Business Analyst should
possess in order to do justice to his role, primarily on IT projects. Figure 1 shows the eight
major competency areas of an IT Business Analyst, some of which overlap with IIBA’s
Business Analysis Competency Model V2.0 and ESI International’s Business Analysis
Competency Model. The intent of this article is not to present a new competency model but
to expand on the IIBA’s and ESI International’s competency models.
It is imperative for any Business Analyst to internalize the BABOK tasks and
techniques in order to produce consistent results on projects, as far as business
analysis is concerned. For instance, many projects directly begin with a discussion of
‘requirements’, without first obtaining a consensus on the business problems being
encountered by the key stakeholders. The BABOK v2.0 includes a knowledge area
(discipline) called ‘Enterprise Analysis’, that requires the Business Analyst to perform
problem analysis (or opportunity analysis) and arrive at a ‘Business Needs
Statement’, before the solution requirements can be fleshed out.
This approach remains the same, irrespective of whether it’s the Insurance, Capital
Markets, Healthcare or any other business domain. That is the value the BABOK
provides to an SME – a set of global business analysis best practices.
5. Documentation
Business Analyst (E.g. Business Case, Requirements
Competencies Documents)
2. Usability Engineering
(User-Centered Analysis and Usability 6. Business Domain
Testing) (E.g. 5.
Insurance, Banking etc)
Documentation
(E.g. Requirements Documents)
4. Quality Control
8. Technology Awareness
(Reviews, System Testing, UAT)
(E.g. SDLC and IT technologies)
2. Usability Engineering
More often than not, project teams tend to develop solutions, systems or products for
the stakeholders who communicate requirements to them, without being cognizant of
the fact that no matter who communicates the requirements, if the end-users cannot
use the system effectively, the project fails!
The Standish Group, a popular research organization that publishes ‘the top 10
success factors’ on projects, every year, based on its analysis of a large number of
projects in North America, has been including the project success factor ‘user
involvement’ in the top 5 factors every year. It’s strange to see that, in spite of that,
a large number of systems continue to be rejected by end-users, either partly or
wholly, once made available to them, typically during user acceptance testing or
post-deployment. Usability engineering is the answer to this issue.
Most people who don’t understand ‘usability engineering’ invariably think that it is
nothing more than designing user interface screens and their look-and-feel. However,
to be precise, that is part of user-centered ‘design’, which is just one subset of
usability engineering. Usability engineering includes the entire usability engineering
lifecycle, right from UCA (User-Centered Analysis), through UCD (User-Centered
Design) and Usability Testing that ensures that the solution is developed in close
Page 3 of 6
3. Object-Oriented Analysis
The BABOK v2.0 includes a set of 34 generic techniques that can be applied to
multiple business analysis tasks. Many of these techniques are relevant to object-
oriented analysis. Considering the fact that most software systems today are based
on object-oriented technologies, it is important for Business Analysts to be well-
versed with object-oriented techniques relevant to their scope of work.
Most Business Analysts I have seen stay a mile away from UML, thinking that it is
‘technical’ and hence meant for the System Analyst or Technical Analyst. UML
includes a set of over 10 types of models or diagrams that are developed at various
stages of the system development lifecycle. What many Business Analysts probably
don’t know but need to know is that the initial set of diagrams is the responsibility of
the Business Analyst (though this sometimes overlaps with the responsibility of the
System Architect). These diagrams developed by the Business Analyst get further
converted by Technical Designers to lower-level diagrams that form part of the low-
level technical design, during the Low-Level Design phase or activity.
The BABOK v2.0 includes ‘Scenarios and Use Cases’ as well as 5 other UML diagrams
in its Business Analysis Techniques section. If the techniques are described in the
BABOK, they come within the scope of the Business Analyst’s work and hence the
Business Analyst must certainly know them. Again, as I have proved to Business
Analysts in every Business Analysis class of mine, UML is no rocket science and there
is nothing ‘technical’ about it. It can be easily mastered by the so-called ‘non-
technical’ Business Analysts, if they do away with their mental block towards UML.
The industry certainly prefers Business Analysts with an understanding of UML.
4. Quality Control
Since it’s a Business Analyst’s responsibility to ensure that the solution delivered to
stakeholders meets the business need(s) for which the project was undertaken, it’s
important for the Business Analyst to ‘verify’ and ‘validate’ the requirements
Page 4 of 6
(typically part of the requirements review activity) as well as ‘validate’ the solution
(typically part of UAT) to confirm that it actually does meet the business need(s).
These activities are a subset of Quality Control activities.
A Business Analyst must be skilled at planning and facilitating user acceptance tests.
This includes ensuring that ‘all’ the right stakeholders are included in the test and the
right aspects of the solution are validated as part of the test. I have seen very many
UATs that are nothing different from System Testing, except that they are performed
by end-users, that too, not the right ones. It’s not very surprising then that in spite of
an apparently ‘thorough’ UAT, the solution throws up many problems in the
production environment that are not really related to the environment.
System Testing does not fall within the scope of a Business Analyst’s work, as there is
no corresponding task or process in BABOK v2.0. However, a Business Analyst might
often be required to support the System Testing activity. Whether a Business Analyst
is involved in System Testing or not, it is certainly important for the Business Analyst
to understand how functional and more importantly, non-functional testing (such as
performance testing, security testing, usability testing etc) are performed. This is
because it is the Business Analyst’s primary responsibility to elicit and document
‘testable’ non-functional requirements specifications, a requirements-related activity
that I have seen many Business Analysts not even familiar with. It would be difficult
for a Business Analyst to write ‘testable’ non-functional requirements, if he does not
understand how they will be tested.
5. Documentation
This is one competency area that I would say, is the single biggest contributor to
effective and successful business analysis, though the others are certainly very
important. It is a known fact that a large percentage of the defects discovered during
the System Testing and UAT activities are associated with poor quality requirements
documentation. One of the major reasons for this is that the Business Analyst
invariably assumes that the consumer of the documentation, primarily, the System
Development team that actually builds the solution, possesses the same level of
understanding of the business domain, as him or her. This makes him subconsciously
exclude a lot of important details that deserve to be specified.
This problem gets compounded by the fact that most project team members,
including Business Analysts, don’t consider documentation as an activity that
matches up to their expertise. The interesting aspect of an ambiguously written
requirement is that the individual reading and interpreting the requirement might
believe that he has perfectly understood the requirement, when his interpretation
might actually be quite different from what was meant by the Business Analyst who
documented the requirement. Unfortunately, the only time both might get to know
that is during the UAT, or worse, during the production run, that leads to an
unacceptable amount of rework. That explains the need for ‘unambiguous’
documentation.
In all my business analysis classes, I emphasize the need for a Business Analyst to
focus on developing his documentation skills, whether he likes it or not, because
ultimately what gets incorporated into the solution is what’s in the requirements
document! I also know of some Business Analysts taking a course in Technical
Writing. While that might not be absolutely necessary, it only demonstrates their
commitment towards being a better Business Analyst.
6. Business Domain
Page 5 of 6
8. Technology Awareness
Though a solution need not necessarily have an IT component, in all probability, most
of them will, because most businesses today are IT-enabled. Hence it is imperative
for every Business Analyst to possess the ability to understand how IT systems and
technology can help solve business problems. In addition, since an IT Business
Analyst works within the context of a software or IT project, a good understanding of
the SDLC (System Development Life Cycle) is essential to perform business analysis
activities effectively. In fact, the SDLC methodology (waterfall, iterative, agile etc)
selected for the project directly influences what business analysis activities would be
performed and how.
The eight competency areas described above can be used by a Business Analyst,
new as well as experienced, as a self-assessment checklist. The assessment would
highlight those areas that either need to be entirely developed or enhanced further.
______________________________________________________________________________
I hope this article has been insightful as well as useful and also hope that it helps
good Business Analysts get better! If you have any comments, please feel free to
write to me at prasadvkamath1@yahoo.com.