business analyst ppt
DESCRIPTION
It contains all that one needs to do to be a Good Business Analyst and not what one should do in order to be a BA.TRANSCRIPT
Business Analysis & Modeling
By:Pallavi J. Bhojak
Business Analysis & Modeling• What is Business Analysis?
• Business Analyst Role in a Project
CommunicationExpert
Interface – Development Team
Interface – End Users
Interface-Customer
Business Analysis & Modeling
Requirements Gathering
Coding
Unit Testing
Design
System Testing
Integration Testing
Deployment
BA Role in SDLC
Strengthened Quality with BA Induction in Development Cycle
Business Analysis & Modeling
• Framing the Business Problem• Identification of need
Typical questions for Project Sponsor & End UsersSegregation of Critical & Nice to have features
• System Concepts Documentation• Feasibility Study
Business Analysis & Modeling
• Solution Vision & Scope What are the Scope and Vision of a Project?
A Project’s Scope defines the broad parameters of the project.
A Project’s Vision is the desired state or ultimate condition that the project is working to achieve.
Why Is Defining a Scope and Vision important?Scope & Vision provide the foundation for all
subsequent steps in project or programme cycle. A clear Scope sets the rough boundaries for what the
project will attempt to do. The Scope makes it clear what the team is focusing on
and where the final outcomes will be measured Vision enables the core project team members to
discuss and agree on what the broad purpose of their project will be.
Solution Vision & Scope
Business Requirements
User Requirements
Functional Requirements
Quality Attributes
Other Non Functional
Requirements
Vision & Scope Document
Use Cases
Software Requirements Specifications (SRS)
Business Analysis & Modeling
• Vision vs. Scope Product Vision – A long term strategic concept of the
ultimate purpose and form a new system Project Scope – The portion of the ultimate product vision
that the current project will address. The Scope draws the line boundary what is in and what is out of the current project
Product VisionProduct Vision
Product Scope for release 1.0
Product Scope for release 1.0
Product Scope for release 1.1
Product Scope for release 1.1
Product Scope for release N
Product Scope for release N
Business Analysis & Modeling• Project Priorities
To enable effective decision making, stakeholders should agree on the project priorities
5 Dimensions of a software project
Features
(Scope)
Quality
Schedule
Cost
Staff
Business Analysis & Modeling
• Those must be classified into one of the following categories Constraint – a limiting factor within which the project
manager must operate Driver – a significant success objective with limited
flexibility for adjustment Degree of freedom – a factor that the project manager has
some latitude to adjust and balance against the other dimensions
Vision & Scope Document
• Business Requirements Background Business Opportunity Business Objectives &
Success Criteria Customer or Market
needs Business Risks
• Scope and Limitations Scope of Initial Release Scope of Subsequent
Releases Limitations & Exclusions
Vision of the Solution Vision Statement Major Features Assumptions and
Dependencies
Business Context Stakeholder Profiles Project Priorities Operating Environment
Return on Investment (ROI)
• Assess the ROI potential Breadth – How many people will be helped by the
application ? The greater the number of people, the greater the potential ROI.
Repeatability – How often will people use the application ? The more often an application is used, the greater the ROI
The Objective should be to maximize benefit rather then minimize the cost
Return on Investment (ROI)
• Secondary factors to consider include: Cost – The more costly the task, the greater the benefit from
automation or appropriate technology support Knowledge – The greater potential to re-use the information
in the system, the greater the potential ROI Collaboration – Communication between employees is
costly, so the greater the collaboration component, the greater the potential ROI
Financial measurements should only be compared to otherinternal decisions – not other companies Financial measurements
Business Analysis & Modeling
• Net Benefits (expressed in currency) Incremental Value Generated Productivity gained Expenses Saved Redeployment of Resources Hire new resources to perform the task
• Net Costs (expressed in currency) Recruiting Salaries & Benefits Software Licensing & Maintenance General & Administrative Overheads Training and Education Hardware Costs
Business Analysis & Modeling
• Determining the costs• Acquisition Costs
Hardware, Software, Management, Support, Development & Communications
• Management Costs Budget & Resource expenses, administrative and office costs
• Intangible CostsUnplanned Costs, Downtime, User Costs & Miscellaneous Costs
Business Analysis & Modeling
• Steps to Calculate the Costs Determine period of analysis Collect all the relevant financial, resources and costs
data Identify potential issues and make educated guesses
and action items Understand change control by doing WHAT IF
analysis Set a process of accounting for ongoing costs,
maintenance and support cost management Use the numbers to determine the costs
Business Analysis & Modeling
• Analysis detecting feasibility Economic Analysis
Cost Benefit Analysis Technical Analysis Legal Analysis Alternative Solutions
Business Analysis & Modeling
• Root Cause Analysis Define Problem / Collect Data Criteria for Well defined problem
It focuses on the gap between what is and what should be reflects a change or deviation from the requirement, norm, standard or expectation.
It states the effect. It states what is wrong, not why it is wrong.
It is measurable. It says how often, how much, when. It avoids broad and ambiguous categories like ‘morale’, ‘productivity’ &’communication’
It is stated in positive manner and describes the pain It avoids “lack of” and “no” statements It highlights the significance of effects
Business Analysis & Modeling
Collecting the Information
• Sources of InformationDirect ObservationDocumentationInterviews
Business Analysis & Modeling
• Prototyping
Identify whether S/W is good candidate for Prototyping
Need to develop an abbreviated representation of requirements
Create abbreviated design specification for the prototype
Develop Prototype S/W, test and refine it
Present it to customerFinalize the Prototype
Why requirements necessary?
•Unmet expectations
•Effectiveness (meeting stakeholder’s expectations) & efficiency (time, cost & human resource) are developed
•The need: Requirements errors are the most expensive to fix when found during production but cheapest to fix early in development.
Key benefits of good requirements processes
Improved system quality and customer satisfaction
Easing compliance with standards and regulations
Reduced project cost and delayBetter control of complex projectsImproved team communication
Documentation: Business on paper
Well-documented user requirements are useful information for many groups: designers, testers, user manual writers, management and marketing personnel.
Systematic user requirement documentation at the beginning of the product development saves time and decreases rework in later phases of the project.
Types of documents
•BRD: represent high-level objectives of the organization or the customer requesting the system
• FRD: specify the functionality the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements
•Project plans: for deciding the phases of development of Project as per client
•Use –Case approachFunctional Requirements are then developed based
on the use casesA use case describes a sequence of interactions
between a system and an external actor(s)An actor is a person, another software system, or a
hardware device that interacts with the system to achieve a useful goal.Type of actors do not correspond to user classes.
They rather represent the roles, which a user can play
Business Analysis & ModelingBusiness
Requirements
User Requirement
s
Functional Requirement
s
Quality Attributes
External Interfaces
Vision & Scope Document
Use Cases
Software Requirements
Specifications (SRS)
Business Rules
Features
Constraints
System Requirement
s
Software Engineering process models
•Requirements in Agile SEAgile approaches
People – Oriented rather than process – Oriented
Adaptive rather than predictiveStakeholders are involved throughout
the project, not only in the beginning and in the end of the project
This changes the Scope RE, however does not remove the need for RE as such
Probably, no defined RE process then.
•Correctness and Necessity• Correctness
Each requirement must accurately describe the functionality to be build and correspond well to the intentions of the stakeholder who is the source of that requirement
• NecessityEach requirement should document a
capability that the customers really need or one that is required for conformance to an external system requirement or a standard
• Sign OffFreezing requirements is unwise and
unrealistic, changes are inevitable.Signing off the requirements document by the
customer means that a baseline of requirements agreement has been established. It does not mean that requirements have been finalized
The subtext of a signature on a requirements specification sign-off page should read something like (Wiegers, 2003):
“I agree that this document represents our best understanding of the requirements for this project today. I agree to make future changes in this baseline through the project’s defined change process. I realize that approved changes might require us to renegotiate cost, resource, and schedule commitments for this project.”
Business Analysis & Modeling
Validation vs. verification
Validation – “Am I building the right product?” checking a work product against higher-level work products or authorities that frame this particular product.
- Requirements are validated by stakeholders
Verification – “ Am I building the product right?” checking a work product against some standards and conditions imposed on this type of product and the process of its development
- Requirements are verified by the analysts mainly
•Main issue in validationWhile elicitation and analysis are attempts to
cross the boundary from the domain world to the machine world, validation is an attempt to cross the same boundary in the opposite direction
The difficulty of the former is well acknowledged, and the latter can almost as difficult
Main problem is achieving a sufficient level of understanding of the stated requirements by a particular stakeholder, which may be hindered by: Lack of technical expertise Lack of some special domain knowledge
(domain of another stakeholder)
Requirements change factors• Requirements errors, conflicts and inconsistencies
As the system development proceeds, some errors and inconsistencies may be discovered that were not revealed earlier (in validation) and must be corrected
• Evolving customer/end-user knowledge of the systemCustomers and end-users may develop a better
understanding of what they really require from a system
• Technical, schedule or cost problemsProblems may be encountered in implementing a
requirement. It may be too expensive or take too long to implement certain requirements
•Requirements change factorsChanging Customer priorities
Customer priorities change during system development as a result of a changing business environment, the emergence of new competitors, staff changes, etc.
Environmental changesThe environment in which the system is to be
installed may change so that the system requirements have to change to maintain compatibility
Organizational changesThe organization which intends to use the
system may change its structure and processes resulting in new system requirements
Brief up: After (BRD)
Training / Functional Inputs to Development teamTraining / Functional Inputs to QA teamValue addition during ongoing development workPerform Integration testingInterfacing with the client for clarifications during
ongoing development workTry to achieve early buy in from the customerConduct User training & UAT
Thank You