The document provides an overview of business analysis and the business analyst profession. It defines business analysis and the key roles and responsibilities of a business analyst, which include acting as a liaison between stakeholders to analyze, communicate, and validate requirements for changes to business processes and information systems. The document also discusses different types of requirements like business, user, and system requirements, as well as popular software development lifecycles (SDLC) like waterfall, iterative, agile, and scrum models.

1. Fundamentals of Business
Analysis
Binny

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

3.  Projects were like a battlefield
In the Beginning...

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…

5. Something was missing ?

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?

7. Now .. The Picture is Complete

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

12. Can I become a BA ?

13. Business Analyst

14. Business Analyst

15. Business Analyst Mantra

16. Business Analyst Responsibilities

17. Business Analyst Detailed
Responsibilities

18. Requirements

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

20. User and System 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”

24. Highly talented BA’s in the industry

25.  Business Analysts
 Business Analysts role in software development
 Business Responsibilities
 Requirements
 Types of Requirements
Summary

26. Questions?

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

28. 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

35. Steps in the Scrum Process

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

39. Questions?