2. Definition of business analysis & business analyst
profession
Exploring the knowledge areas of business analysis
Definition of requirements & its types
Project Manager vs Business Analyst
SDLC
Objectives
4. A lot of work was being done... But it was not always productive
Organizations invested in Project Management practices.
But that was not enough…..
A Little Later On…
6. Only 16.2% of projects will be completed on time & on
budget
About 40-56% of project conflicts can be traced to
requirement errors
Finding and fixing requirement errors consumes 70-85% of
project rework costs
The average project exceeds its planned time schedule by
120%
About 52.7% of projects will cost 189% of their original
estimate
About 30% of projects are cancelled before completion.
Why it doesn’t work?
8. “A business analyst works as a liaison among stakeholders in
order to analyze, communicate, and validate requirements for
changes to business processes, policies, and information
systems.”
Business Analyst
9. Liaison - communication or cooperation that facilitates a close working
relationship between people or organizations.
Stakeholder - a person with an interest or concern in something,
especially a business
“Liaison” and “stakeholder”
10. Communication is a process of exchanging verbal and non verbal messages.
It is a continuous process. Pre-requisite of every communication is a
message.
This message must be conveyed through some medium to the recipient.
It is essential that this message must be understood by the recipient in same
terms as intended by the sender. They must respond within a time frame.
Thus, communication is a two way process and is incomplete without a
feedback from the recipient to the sender on how well the message is
understood by them.
The key role of a business analyst is to ensure that the requirements are well
communicated, documented, analyzed and understood for the success of a
project
Why we need Business Analysts?
11. Project managers are responsible for delivering the
solution to a problem.
Business analysts are responsible for discovering the
problem and determining the solution.
Project Manager vs Business Analysts
19. Business Requirements
higher-level statements of the goals, objectives, or needs of the
enterprise.
User Requirements
statements of the needs of a particular stakeholder or class of
stakeholders.
System Requirements
describe the behavior and information that the solution will
manage
Types of Requirements
21. A functional requirement describes what a software system should do,
while non-functional requirements place constraints on how the system
will do so.
Example - A system must send an email whenever a certain condition is
met (e.g. an order is placed, a customer signs up, etc.)
The non-functional requirement is describing the behavior of the
system as it relates to the system's functionality. The non-functional
requirement elaborates a performance characteristic of the system.
Example - Emails should be sent with a latency of no greater than 12 hours
from such an activity.
Functional vs Non-Functional
22. Requirements Should be :
Complete
Clear
Correct
Consistent
Requirements 4 C’s
23. Requirements Elicitation is about finding out what customers (and potential
customers) say they think they want. It produces a wish list (well, you might be polite
and call it something else, but that's what it is).
Requirements Analysis is about distilling the wish list to produce a list of actual
requirements together with dependencies between them. It also involves saying that
some things on the wish list are out of scope for one reason or another (e.g., you're
proposing to do a project on some client software and the customers asked for you to
do something that clearly requires major server changes).
Requirements specification: the process of recording the requirements in one or more
forms, including natural language and formal, symbolic, or graphical representations;
also, the product that is the document produced by that process.
Requirements validation: the process of confirming with the customer or user of the
software that the specified requirements are valid, correct, and complete.
Requirement “x”
27. SDLC is the acronym of Software Development Life Cycle.
SDLC is a process followed for a software project, within a
software organization.
It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software.
The life cycle defines a methodology for improving the
quality of software and the overall development process.
SDLC
29. Waterfall Model
Iterative Model
Spiral Model
V-Model
Popular SDLC models
30. Waterfall is best used for simple, unchanging projects.
Its linear, rigid nature makes it easy to use and allows
for in-depth documentation.
Changes can’t be easily accommodated
Software isn’t delivered until late
Gathering accurate requirements can be challenging
Waterfall Model
31. Agile software development is based on an
incremental, iterative approach.
Change is embraced
Faster, high-quality delivery
Strong team interaction
Continuous improvement
Customers are heard
Agile Model
32. Extreme Programming (XP)
Feature-driven development (FDD)
Adaptive system development (ASD)
Kanban
Scrum
Methodologies That Are Used to
Implement Agile
33. Scrum follows a set of roles, responsibilities, and
meetings that never change.
More transparency and project visibility.
Easy to accommodate changes.
Increased cost savings.
Scrum
34. Product Owner: The Scrum Product Owner has the vision
of what he or she wants to build and conveys that vision to
the team.
Scrum Master: Often considered the coach for the team,
the Scrum Master helps the team do their best possible
work.
Scrum Team: The Scrum Team is comprised of five to seven
members. Everyone on the project works together, helps
each other, and shares a deep sense of camaraderie. Unlike
traditional development teams, there are not distinct roles
like programmer, designer, or tester.
Roles in Scrum
36. Kanban is Japanese for “visual sign” or “card.”
Kanban
37. Scrum and Kanban are both flavors of Agile, but they
have some distinct differences.
Scrum requires specific roles whereas Kanban has no
required roles.
Scrum is based on timeboxed iterations, combining
planning, process improvement, and release. In
Kanban, you can choose to do these activities on a
regular cadence or whenever you need.
Scrum vs. Kanban
38. Scrum resists change, whereas Kanban easily accommodates
and embraces change. In Scrum, once the team has committed
stories to a sprint, you can’t add additional stories later on. In
Kanban, you can add or change stories as you please, assuming
that it’s within WIP limits.
A Scrum board is reset after each sprint. A Kanban board is
continuously used.
A Scrum team is cross-functional and one team owns the Scrum
board. In Kanban, teams don’t need to be cross-functional and
anyone can own the Kanban board.
Scrum teams require estimation, whereas Kanban doesn’t.
Scrum vs. Kanban
