Business Analyst_4
Business Analyst_4
Business Analyst_4
Project Requirements: These are the requirements that are created so that the
project can run smoothly. It could be the necessary team members to handle the
workload of the needs so that the scope could be met on that particular time
duration which essentially ensures the smooth progress of the project. It could be
the required access to the client network or the access to the necessary tools from
the client's end. It could even be when the project team be located. These are the
aspects that deals with project as a whole and important for the project to go
through without any major issues popping out.
Business Requirements: These are the requirements that cover the WHY aspect of the
project (i.e.) WHY the client feel the need to do the project. It basically defines
the problem statement that represents the client's need to create the feature.
Functional Requirements: These are the requirements that covers the WHAT aspect of
the project(i.e.) WHAT could be done or developed so that the client's goal is
achieved. It defines about the features that could be added to the application so
that these requirements are met.
For instance,
To quickly address the queries of the end users (why aspect), for which a
live bot chat feature (What aspect) is created in the client's website. This will
give the answers to the common queries with a pre defined process of answers and
offers immediate solutions without a need to make a call to customer care, thus
promoting the end user experience.
In retail stores, to collaborate real time need with the mobile app(why
aspect), for which the location of the product specific to the selected store is
displayed (What aspect) in the mobile app. This helps the end users to shop the
product directly from their location, instead of searching which could be time
consuming. Also, this could lead to the increase in the mobile app downloads.
System Requirements: These are the requirements that addresses the technical aspect
of the project. This is not for a Business Analyst, this is more for the technology
team involved.
Examples: The system must support Windows 10, MAC OS and also LINUX.
The system must interact with third party gateway for payments.
One-on-one interviews
Group interviews
Facilitated sessions
Joint application development (JAD)
Questionnaires
Prototyping
Use cases
Following people around
Request for proposals (RFPs)
Brainstorming
One-on-One Interviews: These are the interviews that happens between a BA and a SME
or a product owner. This is scheduled by the Business Analyst to understand the
requirements in a clear manner, ask for the clarifications and confirm with their
understandings. The agenda and the duration of the meeting( it will be often for
one hour) will already be sent by the BA to the respective SME with the meeting
invite.
Group Interviews: This happens between a BA and multiple people but not more than
3, to understand, brainstorm and come to on an agreeable conclusions on the
requirement. The agenda and the duration of the meeting (often it will be atleast
one hour) will be sent by the BA to the respective product owners or subject matter
experts with the meeting invite.
Facilitated Session: This happens between a BA and a large number of people usually
product owners, SMEs and other stake holders. These meetings are complex in nature
since there is no upper limit on the people who could attend the meeting. Since
every one involved will have a different take on the requirements and contradicting
opinions there is a chance of many conflicts which may get difficult to handle.
There is also the chance of insufficient information when it comes to the
requirement conclusion. So this method is the least preferred method for
requirement gathering.
JAD- Joint Application Development: This technique is very much similar to the
group Interview where the BA schedules the meeting with the 2 or 3 SMEs. As like in
group interview, the BA sends the meeting invite with the agenda but here, there is
no set duration for the meeting. The meeting ends when all the subjects in the
agenda are discussed and finalized. Everyone in the meeting comes prepared and does
not stray away from the topic since they are all aware about the nature of this
meeting. They will all brainstorm together and comes to the agreeable conclusion
about the requirements and then the meeting ends. This is the much preferred
technique because it almost always produce the effective result.
Following People Around: This is not something that Business Analyst would do
because it is not a professional approach. Use it as a last resort before
escalating a matter to the informed.
"In scope" refers to the activities or deliverables that are included within the
boundaries of a project or task. These are the activities that are planned for and
agreed upon as part of the project’s objectives and requirements.
Scope creep refers to the expansion or change in a project's scope beyond its
original objectives or boundaries. It usually happens when additional features,
tasks or requirements are added to a project after it has already started, leading
to the work not being done in the decided period, and some part of the user story
may add up to the next iteration. It basically happens due to
A poor understanding of the original project
Changing market conditions
Competing forces within a company
Scope creep can be avoided when the requirement is clear and when the complexity of
the user stories are understood and allocated to the team members appropriately.
Change Request:
Change Requests happen when the client requests the company to make some changes
regarding the objectives or requirements, or they can also request for the change
in the application that just got delivered to them during that particular
iteration. They can ask for when the client had a change of mind or they are not
very satisfied with the work.
Unless the Change requests are of highest priority, it is usually added in the
upcoming sprints. BA and product owners may discuss when exactly that CR should be
worked upon.
Project Charter:
Project Charter is the document created by the project manager either before or
after the project kick off meeting. It covers the Why aspect of the project and the
project's objectives. It also explains about the project duration, the scope of the
project, the team members from the company side and the stakeholders from the
client side.
It has information about the project so that any new project managers can refer to
this document to understand the in's and out's of this project.