1. Fundamentals of Business Analysis
Binny

2. Objectives
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

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

4. A Little Later On…
A lot of work was being done... But it was not always productive
Organizations invested in Project Management practices.
But that was not enough…..

5. Something was missing ?

6. Why it doesn’t work?
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.

7. Now .. The Picture is Complete

8. Business Analyst
“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.”

9. “Liaison” and “stakeholder”
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

10. Why we need Business Analysts?
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

11. Project Manager vs Business Analysts
Project managers are responsible for delivering the solution to a problem. 
Business analysts are responsible for discovering the problem and determining the solution.

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. Types of Requirements 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

20. User and System Requirements

21. Functional vs Non-Functional
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 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 - s should be sent with a latency of no greater than 12 hours from such an activity.

22. Requirements 4 C’s Requirements Should be : Complete Clear Correct
Consistent

23. Requirement “x”
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.

24. Highly talented BA’s in the industry

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

26. Questions?

27. SDLC 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.

28. SDLC

29. Popular SDLC models Waterfall Model Iterative Model Spiral Model
V-Model

30. Waterfall Model
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

31. Agile Model
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

32. Methodologies That Are Used to Implement Agile
Extreme Programming (XP)
Feature-driven development (FDD)
Adaptive system development (ASD)
Kanban
Scrum

33. Scrum
Scrum follows a set of roles, responsibilities, and meetings that never change.
More transparency and project visibility.
Easy to accommodate changes.
Increased cost savings.

34. Roles in Scrum
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. 

35. Steps in the Scrum Process

36. Kanban
Kanban is Japanese for “visual sign” or “card.” 

37. Scrum vs. Kanban
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.

38. Scrum vs. Kanban
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.

39. Questions?