business analyst ppt

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


Requirements Gathering

Coding

Unit Testing

Design

System Testing

Integration Testing

Deployment

BA Role in SDLC

Strengthened Quality with BA Induction in Development Cycle


• 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


• 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)


• 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 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


• 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


• 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


• 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


• 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


• 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


• Analysis detecting feasibility Economic Analysis

Cost Benefit Analysis Technical Analysis Legal Analysis Alternative Solutions


• 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


Collecting the Information

• Sources of InformationDirect ObservationDocumentationInterviews


• 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


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

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

business analyst ppt

Documents

lie svslem

lie ro polenliui breuli

scope vision provie

oproucl scope ior reieuse

scope ruws

usiness analysis e odelingbv

projecl wiii ullempl

lieir projecl wiii