A requirement, at the very basic level, is a change.
BA is the person who drives the requirement from a
conceptual stage to material form. BA always requires wearing many hats at the
same time, being a functional expert (client’s person) in project team and an
application expert for clients.
BA being a person to elicit, analyze and document the
requirements often plays a very critical role in the project execution.
Embracing change - BA should be the person who will visualize
the changes first, then convert these changes in tangible form and help
business and other stakeholders to understand and bring change to reality. Thus,
he/she enables stakeholders to embrace the change.
Engaging stakeholder: This is critical focus area. There should
be warm and cordial relationship between different BA and stakeholders. This
will be very helpful in avoid any communication gap and lack of understanding.
Also, this will ensure that all the critical information flows smoothly from
stakeholders to BA and implementation team. BA should ensure to make them part
of implementation as much as possible. Frequent demos and prototypes will help
stakeholders to understand system better and propose changes, if any, at early
stage itself.
Efficient and Complete Communication – It is utmost important
that all stakeholders are on the same page and have access to
information/documents available. This will help to avoid misunderstandings if
any and to mitigate risks on time.
Enhanced Artifacts: BA should not consider BRD, FSD are just
for documenting requirements. The success of project will depend on these
documents. Hence, these documents should be such that they provide meaningful
insight about the application to clients. A detailed BRD serves many purposes. Users
can refer to steps mentioned in BRD for usage of application. Users can refer
to different technical/functional constraints mentioned while using
application.
Also, the same BRD can be used by development team to
develop application and by testing team to test application. Because of lot of details BRD can become
verbose and hence, boring. So, BA should focus on making BRD more interactive
and scenario driven.
Early Risk identification and elimination - The sooner the
risks or potential failure areas are identified; the less will be impact on
project health. BA should focus on exceptional scenarios, alternate scenarios
and the scenario's which could possibly fail.
Empowerment to team members - BA/PM should make promote their
contribution and welcome their suggestions. Make developers/testers feel part
of project. Often they are the people who point out technical
challenges/limitations in advance. Also, they can highlight the conflict and
impact of different changes. Also, it would be good if they are part of
clarification sessions.
Change is inevitable and at times more complex than
imagined, a BA can help you to get safely.