Business Analysis: Tips & Checklist

https://www.linkedin.com/pulse/business-analysis-tips-checklist-himanshu-
sanguri
Himanshu Sanguri, Senior Business Analyst-Treasury, 15/04/2015

I am writing this post to discuss some tips and tools which a Business Analyst
can use during the course of a project life. From my experience, I find these
tools very useful for comprehensive and correct coverage of a business
requirement. Which tool or methodology to use for effective business analysis
depends on many factors like:
Type and size of project
Organization and business for which the project will be done
Software methodology like agile, waterfall or hybrid
The roles and responsibilities of a business analyst has expanded in all the
project phases; staring from requirement engineering till the system starts
doing business, a BA is the single thread to bind all the stakeholders.
Requirements Investigation
Brainstorming sessions
Focus groups: All participants perform the same role
Cross-functional groups: All business functions involved in an end-to-end
process One-on-one interviews
Research of existing artifacts
Prototyping
Wiki (A tool that can be used to allow stakeholders and team members to
collaboratively contribute to the requirements)
Surveys and understanding of business domain
Business Process Diagram
A diagram that models the work flow of a business process. It is very useful to
understand the get the domain understanding of the business and at the same
time get the agreement from business users on the proposed solution.
Business Use Case
A business use case is an interaction with a business that provides value to an
actor (an entity outside the business). Business use-case analysis involves a
number of components: Business use cases to model business services and
processes; business use- case diagrams to indicate the participants in each
process; business use-case descriptions to describe the interaction between
actors and the business area; and business use-case realizations, representing
the internal business process used to implement the functionality. Business
use-case descriptions (specifications) are usually documented as a text
narrative; the text should be augmented with an activity diagram if the flows
connect in complex ways. Business use-case realizations are usually expressed
as activity diagrams, with one partition for each participant. Business use-case
diagrams should be used in early meetings with stakeholders and in
documentation to communicate high-level business issues: the business
processes impacted by the project and the participants involved with each
process. A BA should use business use-case descriptions to describe business
functionality and business use-case realizations to describe the internal work
flow for each impacted process.
Requirements Attribute Table
It is a table used to document properties of requirements, such as authorship,
priority, and so on. It provides information such as priority and stability for
making decisions concerning requirements, such as when to schedule
implementation. It is a central place to look up data about a requirement, such
as its author, current version number, etc.
Requirements Traceability Matrix
A table used to trace each requirement backwards to the business processes
and objectives it supports and forwards to the subsequent artifacts, events,
and changed configuration items that result from it like use cases, functional
specifications and test scenarios. A BA should map requirements to other
artifacts and configuration items so that the upstream and downstream impact
can be determined.
System Use Case and Diagrams
A way that the software will be used by an actor. (An actor is an external entity
that uses the IT system under discussion.). It also defines a user task: The task
must be complete from the user's point of view and yield a result of value to
the user. (The term user, in this context, refers to any entity that uses the
system and may be human or an external IT system; it is equivalent to the
term actor.)
A use case may be of any size but typically represents a unit of work
accomplished in one IT session by a single initiating (primary) actor. It consists
of sequences of interactions between an initiating (primary) actor and an IT
system, covering normal and alternative pathways for carrying out the task. It
may also contain interactions that the IT system initiates with other
(secondary) actors. A related term, scenario, refers to a specific sequence of
actions that illustrates behaviors. A scenario may be used to illustrate one way
the actor-system interaction may play out over the course of a system use
case.
Managing Risk
At the beginning of the project, and periodically as the project progresses, the
BA should support the PM in analyzing risk. A BA should characterize and
evaluate each risk's impact, likelihood, level, type, and risk-management
strategy. Each risk should have an associated plan for managing it. Your plan
should consider the following strategies:
Avoid: Prevent the risk from happening. Possible avoidance plans include
changing the scope and re- planning the project.
Transfer: Transfer the responsibility for dealing with the risk to another
entity.
 Accept: Accept the risk and highlight it immediately to the apposite
stakeholders.
Mitigate: Take action to reduce the impact. Mitigation plans may be
proactive or retroactive--such a contingency plan ("Plan B").
Three vital tools of a Business Analyst: Eyes, Ears and Thinking
No process or tool in the world can help in absence of a thinking head. A BA
should have the strong tendency to read, understand and think intensely. Today
a BA is expected to understand the real business problem and then provide all
possible solutions. A BA should think and find out all the hidden and covered
business problems and should focus on re usability of existing requirements
and solutions.
There are three broad sets of skills and knowledge needed for business
analysis:
1. Technical skills of the profession
2. Business knowledge
3. and a range of personal and interpersonal skills.
A BA should have the capability of listening to multiple voices, viewpoints and
perspectives, analyzing multiple situations, reflecting on all those voices,
synthesizing them and pulling it all together into a proposed way (or ways)
forward that meets both strategic needs and the needs of those on the
ground.
There are times in project when the misunderstanding emerges out between:
Development and QA team during system testing
Development/ QA and UAT team during User Acceptance Testing
Business Users and Project Managers during the actual imolementation
The above conflicts are the true testing waters for a BA, and using some vital
tools and check points is a proven way (based on my own experience) to close
down all the understanding, scope and delivery gaps. I think that is the reason
a BA is called a bridge or conduit.
Thanks
H. Sanguri