This document is containing details about Business Analysis & Business Analyst the agendas are as below : Introduction to Business Analysis Scope of Business Analyst in IT & Non-IT Organizations Require Skill Matrix & Prerequisites for Business Analyst Business Analysis Methodology Role Business Analyst in SDLC Alternatives & BA Professional Courses Introduction to CMMi Levels & Role of BA in CMMi Levels

1. By : Shivang Mehta
Date : 27th July, 2013

2. Introduction
to
Business Analysis
Scope
of
Business Analyst
Require Skill
and
Prerequisite
Techniques
of
Business Analysis
Role of BA
in
SDLC
Alternatives
&
BA Courses
Introduction
to
CMMi Levels
Pros & Cons
and
Questionnaire

4. Why Business Analysis Require ?
 Identify where the business stands in relation to rivals, etc.
 Collect and use data to inform business decision making
 Identify strengths and weaknesses in the business
 Use information to inform strategic planning
What is Business Analysis ?
Business Analysis is the set of tasks and techniques used to work as a liaison among
stakeholders in order to understand the structure, policies and operations of an
organization and to recommended solutions that enable the organization to achieve its
goals.
Key Concepts of Business Analysis
 Domains Understanding
 Solution Factors
 Requirements Nature

5. Domain Understanding
A domain is the are undergoing analysis. It may correspond to the boundaries of an
organization or organizational unit, as well as key stakeholders outside those
boundaries and interaction with those stakeholders.
Solution Factors
A solution is a set of changes to the current state of an organization that are made in
order to enable that organization to meet a business need, solve a problem, or take
advantage of an opportunity.
Requirements Nature
 Customer Requirements
 Architectural Requirements
 Structural Requirements
 Behavioural Requirements
 Functional & Non-functional Requirements
 Performance Requirements
 Design Requirements
 Derived Requirements
 Allocated Requirements
 Technical Requirements

6.  Lack of Shared Vision / Requirement Understanding
 Getting Time With Product Management / Business
 Operational V/S Forward Looking
 Building Relationship
 Fear of Requirement Failure
 Lack of Techniques and Tools
 Set expectation and get time commitment during inception
 Acceptance of New Technology & Process Updation
 Communication Gap while Requirement Development
 Requirements Feasibility
 Iteration and coverage on shared understanding
 Everyone moving os same direction
 Etc...

8.  The IT business analysis field has grown significantly over the last decade
 Through 2014, the expectation is job growth of more than 27%
 Realization that projects – whether IT or non-IT - need a business analyst
 Hot Jobs (CIO Magazine June 2007)
 Expected shortage of skilled business analysts in Canada (Computing Canada, July 9, 2006)
 The majority of BAs fall into position without training
 Employers are giving preference to BAs with training/certification

10. What Business Analyst Is Not?
 Project Manager
 Organizational Developer
 Quality Assurance
 Technical Designer
What Business Analyst Is To?
 Provide Solutions To :
 Process Improvement
 Organizational Change
 Technology Component
 Utilize their techniques, skills, and abilities required to clearly define a problem faced by
the business, working with the development team to determines the scope of the
solution to the problem.

12. Listening
Active listening involves eliminating distractions,
maintaining an attentive posture and eye contact, and
restating key points to confirm your understanding. You
need to grasp what people are saying and also to read
between the lines to detect what they might be hesitant
to say. Learn how your collaborators prefer to
communicate and try to avoid imposing your personal
filter of understanding on what you hear the customers
say. Watch for assumptions that underlie both what you
hear from others and your own interpretation.

13. Interviewing & Questionning
Most requirements input comes through discussions, so
an analyst must be able to ask the right questions. For
example, users naturally focus on the system’s normal,
expected behaviors. However, every programmer knows
how much code is needed to handle exceptions. Ask
questions such as, ―What should happen if...?‖ or ―Could
<some problem> ever arise?‖ so you can determine how
the system should handle anticipated exception
conditions. With experience, you’ll become skilled in the
art of asking questions that reveal and clarify
uncertainties, disagreements, assumptions and unstated
expectations. Donald Gause and Gerald Weinberg
describe ―context-free questions‖ in Exploring
Requirements: Quality Before Design (Dorset House,
1989).

14. Analytical
You’ll need to be able to operate at various levels of
abstraction. Sometimes you must drill down from high-
level information into details. In other situations, you’ll
need to generalize from a specific need that one user
described to a set of requirements that pertain to a
whole class of users. Critically evaluate the information
gathered from multiple sources to reconcile conflicts,
separate user wants from needs, and distinguish
solution ideas from requirements.

15. Facilitation
Requirements elicitation workshops are a common
technique; to succeed, they require a neutral facilitator.
You’ll need strong questioning and observational skills to
help groups build trust and to improve the sometimes
tense relationship between business and information
technology staff. In Requirements by Collaboration:
Workshops for Defining Needs (Addison-Wesley, 2002),
Ellen Gottesdiener provides a wealth of advice for the
workshop facilitator.

16. Observation
If you conscientiously watch a user perform his job or
put a current application through its paces, you can
detect subtleties that the user might not mention and
thus expose new areas for requirements discussion.

17. Writing
Your main deliverable will be a written specification for
customers, marketing, managers and technical staff; for
this task, you need a solid command of the English (or
other natural) language. Strive for clarity; avoid
ambiguous words and phrasing, grammatical errors
and overly idiomatic expressions.

18. Organization
You’ll be faced with a vast array of jumbled information
gathered during elicitation and analysis. Structuring all
the rapidly changing bits into a coherent whole demands
exceptional organizational skills, along with patience and
tenacity.

19. Modeling
From the venerable flowchart through structured
analysis models (data flow diagrams, entity-relationship
diagrams and the like) to contemporary UML notations,
diagrammatic tools should be included in every analyst’s
kit. Some of these techniques will be useful when
communicating with users; others, with developers.
You’ll often need to educate other stakeholders on the
value of these techniques and how to read them—and
you’ll find that these tools are useful ways to represent
information even when you’re not discussing a computer
system.

20. Interpersonal
You must be able to get people with competing interests
to work together, and you should feel comfortable
talking with individuals in diverse job functions and at all
levels of the organization. You might also need to work
with distributed teams whose members are separated
by geography, time zones, cultures or native languages.

21. Creativity
The analyst is not merely a scribe who records
whatever customers say. In his article, ―Eureka! Why
Analysts Should Invent Requirements‖ (IEEE Software,
July/Aug. 2002), requirements authority James
Robertson suggests that the best analysts propose
requirements. Analysts might conceive innovative
product capabilities, imagine new markets and business
opportunities and think of ways to surprise and delight
their customers. A really valuable analyst finds creative
ways to satisfy needs that users didn’t even know they
had.

22. Pre-sales Documents
 Current State Analysis Document
 Project Vision Document
 Solution Vision Document
 Business Requirement Document
 Business Process Design Document
 Use Case Model Document
 Use Case Specification Document
 System-wide Requirement Document
 Solution Glossary Document
 Organization Proposal Document
 Minutes of Meetings Document
 Project Charter Document
 Task List Document

23. Post-sales Documents
 Functional/Technical Requirement Document
 System Requirement Specification Document
 Sign-off Agreement Document
 Requirements Planning Document
 Requirements Checklist Document
 Modeling Document
 Prototype/Wireframe Document
 Data Dictionary Document
 Data Flow Diagram Document
 Class Diagram Document
 Object Diagram Document
 System Flow Diagram Document
 Entity Relationship Diagram Document

24. 1. Former User
2. Former Programmer
3. Subject Matter Expert
4. Business Process Expert
5. Organization Process Guide
6. Any person who are interested to be a Business Analyst

26.  Define Business Requirements
 Identify Project Stakeholders and User Classes
 Elicit Requirements
 Analyze Requirements
 Write Requirement Specification
 Model the Requirements
 Lead Requirements Validation
 Facilitate Requirements Prioritization
 Manage Requirements
 Validate Requirements

27.  Define Business Requirements
 Identify Project Stakeholders and User Classes
 Elicit Requirements
 Analyze Requirements
 Write Requirement Specification
 Model the Requirements
 Lead Requirements Validation
 Facilitate Requirements Prioritization
 Manage Requirements
 Validate Requirements

29. Acceptance and Evaluation Criteria Definition
To define the requirements that must be met in order for a solution to be considered acceptable
to key stakeholders.
Brainstorming
Brainstorming is an excellent way to foster creative thinking about a problem. The aim of
brainstorming is to produce numerous new ideas, and to derive from them themes for further
analysis.
Benchmarking
Benchmark studies are performed to compare the strengths and weaknesses of an organization
against its peers and competitors.

30. Business Rules Analysis
To define the rules that govern decisions in an organization and that define, constrain, or enable
organizational operations.
Data Dictionary & Glossary
A data dictionary or glossary defines key terms and data relevant to a business domain.
Data Flow Diagram
To show how information is input, processed, stored, and output from a system.
Data Modeling
The purpose of a data model is to describe the concepts relevant to a domain, the relationships
between those concepts, and information associated with them.

31. Decision Analysis
To support decision-making when dealing with complex, difficult, or uncertain situations.
Document Analysis
Document analysis is a means to elicit requirements by studying available documentation on
existing and comparable solutions and identifying relevant information.
Estimation
Estimating techniques forecast the cost and effort involved in pursuing a course of action.
Focus Groups
A focus group is a means to elicit ideas and attitudes about a specific product, service or
opportunity in an interactive group environment. The participants share their impressions,
preferences and needs, guided by a moderator.

32. Functional Decomposition
To decompose processes, functional areas, or deliverables into their component parts and allow
each part to be analyzed independently
Interface Analysis
To identify interfaces between solutions and/or solution components and define requirements
that describe how they will interact.
Interviews
An interview is a systematic approach designed to elicit information from a person or group of
people in an informal or formal setting by talking to an interviewee, asking relevant questions
and documenting the responses.

33. Lesson Learn Process
The purpose of the lessons learned process is to compile and document successes,
opportunities for improvement, failures, and recommendations for improving the performance
of future projects or project phases.
Metrics & Key Performance Indicators
The purpose of metrics and key performance indicators are to measure the performance of
solutions, solution components, and other matters of interest to stakeholders.
Non-functional Requirements Analysis
The purpose of non-functional requirements is to describe the required qualities of a system,
such as its usability and performance characteristics. These supplement the documentation of
functional requirements, which describe the behavior of the system.

34. Observation
Observation is a means of eliciting requirements by conducting an assessment of the
stakeholder’s work environment. This technique is appropriate when documenting details about
current processes or if the project is intended to enhance or change a current process.
Organization Modeling
Organization Modeling is used to describe the roles, responsibilities and reporting structures
that exist within an organization and to align those structures with the organization’s goals.
Problem Tracking
Problem tracking provides an organized approach to tracking, management, and resolution of
defects, issues, problems, and risks throughout business analysis activities. Management of
issues is important so that they can be resolved in a timely manner to ensure success.

35. Process Modeling
To understand how work that involves multiple roles and departments is performed within an
organization.
Prototyping
Prototyping details user interface requirements and integrates them with other requirements
such as use cases, scenarios, data and business rules. Stakeholders often find prototyping to be
a concrete means of identifying, describing and validating their interface needs.
Requirement Workshops
A requirements workshop is a structured way to capture requirements. A workshop may be
used to scope, discover, define, prioritize and reach closure on requirements for the target
system.

36. Risk Analysis
To identify and manage areas of uncertainty that can impact an initiative, solution, or
organization.
Root Cause Analysis
The purpose of root cause analysis is to determine the underlying source of a problem.
Scenarios & Use Cases
Scenarios and use cases are written to describe how an actor interacts with a solution to
accomplish one or more of that actor’s goals, or to respond to an event.
Scope Modeling
Scope models are used to describe the scope of analysis or the scope of a solution.

37. Structured Walkthrough
Structured walkthroughs are performed to communicate, verify and validate requirements.
Sequence Diagrams
Sequence diagrams are used to model the logic of usage scenarios, by showing the information
passed between objects in the system through the execution of the scenario.
State Diagrams
A state diagram shows how the behavior of a concept, entity or object changes in response to
events.

38. Survey / Questionnaire
A survey is a means of eliciting information from many people, sometimes anonymously, in a
relatively short period of time. A survey can collect information about customers, products,
work practices and attitudes. A survey may also be referred to as a questionnaire.
SWOT Analysis
A SWOT analysis is a valuable tool to quickly analyze various aspects of the current state of the
business process undergoing change.
User Stories
User Stories are a brief description of functionality that users need from a solution to meet a
business objective.
Vendor Assessment
To assess the ability of a potential vendor to meet commitments regarding a product or service.

40.  IIBA – International Institute of Business Analysis
 CBAP – Certified Business Analysis Professional
 IBAT – Institute of Business Analysis Training
 CSBA – Certification Software Business Analyst
 BACP – Business Analysis Certification Program
 SATC – System Analyst Training Certification
 ISA – Information System Analyst
 BPM – Business Process Management
 PMP – Project Management Professional

42. What is CMMi (Capability Maturity Model Integration)?
CMMI models are collections of best practices that help organizations to improve their
processes. These models are developed by product teams with members from industry,
government and the Software Engineering Institute (SEI).
This model, called CMMI for Development (CMMI-DEV), provide a comprehensive integrated set
of guidelines for developing products and services.
Why CMMi ?
The CMMI-DEV model provides guidance for applying CMMI best practices in a development
organization. Best practices in the model focus on activities for developing quality products
and services to meet the needs of customers and end users.

43. CMMI Level 2 For Development
 CM – Configuration Management
 MA – Measurement Analysis
 PMC – Project Monitoring and Control
 PP – Project Planning
 PPQA – Process and Product Quality Assurance
 REQM – Requirement Management
 SAM – Supplier Agreement Management
CMMI Level 2 For Services
 CM – Configuration Management
 MA – Measurement Analysis
 PPQA – Process and Product Quality Assurance
 REQM – Requirement Management
 SAM – Supplier Agreement Management
 SD – Service Delivery
 WMC – Work Monitoring and Control
 WP – Work Planning

44. CMMI Level 3 For Development
 DAR – Decision Analysis Resolution
 IPM – Integrated Project Management
 OPD – Organizational Process Definition
 OPF – Organizational Process Focus
 OT – Organizational Training
 PI – Product Integration
 RD – Requirements Development
 RSKM – Risk Management
 TS - Technical Solution
 VAL - Validation
 VER – Verification
CMMI Level 3 For Services
 CAM – Capacity & Availability Management
 DAR – Decision Analysis Resolution
 IRP – Incident Resolution & Prevention
 IWM – Integrated Work Management
 OPD – Organizational Process Definition
 OPF – Organizational Process Focus
 OT – Organizational Training
 RSKM – Risk Management
 SCON – Service Continuity
 SSD – Service System Development
 STSM – Strategic Service Management

45. CMMI Level 4 For Development
 OPP – Organizational Process Performance
 QPM – Quantitative Project Management
CMMI Level 4 For Services
 OPP – Organizational Process Performance
 QPM – Quantitative Project Management

46. CMMI Level 5 For Development
 CAR – Causal Analysis & Resolution
 OPM – Organizational Performance Management
CMMI Level 5 For Services
 CAR – Causal Analysis & Resolution
 OPM – Organizational Performance Management

47. There are two categories of goals and practices:
Specific : Specific goals and practices are specific to a process area.
` Generic : Generic goals and practices are a part of every process area.
A process area is satisfied when organizational processes cover all of the generic and
specific goals and practices for that process area.