Business Analyst Training

Role of a Business Analyst

Responsible for analyzing the business
needs of their clients and stakeholders to
help identify business problems and
propose solutions.
System Analyst vs. Business Analyst
Goals

Reduce waste
Complete projects on time
Improve efficiency
Document the right requirements

Software
Engineering

Software Engineering

Software Engineering is a collection

of techniques, methodologies and
tools that help with the production of
a high quality software system
with a given budget
before a given deadline
while change occurs.
20

Software Development Life Cycle

Otherwise called software

development process
SDLC -Building the system
Steps
Feasibility Study
Analysis
Design
Development
Testing
Implementation
Maintenance

Software Development Processes

Several processes, each describing approaches to

a variety of tasks or activities that take place
during the process.

Waterfall Model:
After each step is finished, the process
proceeds to the next step.

Continued.

Iterative development:
Construction of initially small but ever larger
portions of a software project
Agile
Extreme Programming
Scrum
Others
Rational Unified Process
Agile methods differ from iterative methods
in that their time period is measured in
weeks rather than months and work is
performed in a highly collaborative manner.
Others

Waterfall method

Where SDLC fits

Questions ?

Project Management

Types of Projects
Greenfield Engineering
Development starts from scratch, no prior
system
exists, the requirements are
extracted from the end
users, the client,
applicable standards
Triggered by user needs
Re-engineering
Re-design and/or re-implementation of an
existing
system using newer
technology
Triggered by technology enabler
Interface Engineering
Provide the services of an existing system in a
new
environment

Project Life Cycle

Project Initiation

Turn an idea or work request into a defined project by

specifying scope and objectives, identifying resources,
and determining project approach and milestones.
Steps in Initiation
Client Project Meeting: Initial meeting with the client
to discuss what they would like to accomplish,
timing, etc.
Project Definition (also known as a 'Project
Charter')/Project Proposal: A document that
describes the purpose, objectives, scope and
deliverables of the project
Project Approach (also known as a 'Project Life
Cycle'): A document that describes the phases, kinds
of results, and major review points of the project

Project Scope

Scope defines what is or is not included in the

project and controls what gets added or
removed as the project proceeds.
Project changes that impact scope include:
requirements, constraints, assumptions and
risk

Business Opportunity/Problem
Identify and document business
process to understand what is being
built
This is a critical activity in any
project

Business Architecture Workflow

Business Process model helps
understand the business
environment
Captures significant events that are
of interest to the business
Sets context for tasks to be
supported by system
Easily documents as a series of steps
or process diagram

Business Objectives

Business Objectives will

Explain why the project is needed
Identify business
improvements/opportunities to be
addressed
Provide the basis for determining the
success of the investment
Clarify the boundaries of the initiative
Define what the business is expected to
deliver
Support Corporate objectives
Examples Reduce cost of operations, Increase
customer satisfaction, expand customer base

Project Objectives

Characteristics of Project Objectives

Define the scope of the project
Summarize the purpose of the project
Identify at a high-level the products of
the project
What the project team is expected to
deliver
Example- Automate services, Develop
the connectivity to send and receive
information

Needs and Features

Needs
Originate from a business stakeholder
and define the initiate problem or
opportunity the project addresses

Features
High-level description of system
behavior
What the product will do

Exclusions, Assumptions, Constraints

Exclusions
Details that the project will not address
Assumptions
True, real or certain
Involves a high degree of risk

Ex- system can be implemented all over the world

Constraints
Applicable Restrictions that will affect the
performance of the project
Should not be tied to cost or schedule unless
these have been agreed as fixed values
Ex. Automate by next June

Scope Creep

Seemingly small and incremental scope

and requirement changes lead to
substantial cost, budget and schedule
overruns.

Points to Remember

Before exploring requirements for a new

project you have to understand the
following:
The business problem or opportunity
Scope of the Project
Stakeholder interests in the project
Constraints on an acceptable solution

Questions ?

Requirements

What is a Requirement ?
Features

become Requirements
A requirement is a

necessary attribute,
capability,
characteristic or
a quality factor of a system or product.

Requirements must be unambiguous,

complete, correct, consistent, traceable,
modifiable, understandable, verifiable,
ranked for importance and stability.

Requirements Definitions

Business Requirements:
High level capability required to meet business
need
What needs to be done, not how it is done

Functional Requirements:
An action that the product must be able to take
functional characteristic of end solution
Should not include technical directions on how to
achieve requirement
Should only be derived from business
requirements

Requirements Definitions

Technical Requirements:
Specific attribute or characteristic of end
product and behavior it must exhibit to meet
functional needs
Low level detail typically containing technical
language

Non Functional Requirements:

Describe quality, characteristic or property that
a solution must have
Typically apply to entire solution and/or
multiple business requirements
Not necessarily project specific can be
leveraged at the program level

Definitions Examples

Business Requirement
Claim Service Representatives (CSR) must be able
to verify customer information while on a customer
support call

Functional Requirement
CSRs must search for a customer based on name,
address, policy/account number or social security
number

Technical Requirement
The information the system needs will come from
the Client, Insurance Policy, and Bank Account
domains

Non Functional Requirement

Availability must be accessible 24/7
Performance system must be able to process
transaction within 90 seconds 90% of the time

Requirements Visual Breakdown

Non-Functional

Business

Requirements

Requirements

Usability
Performance

Functional
Requirements

Maintainability
&
Supportability
Security
Availability/
Reliability
Scalability

Technical
Requirements

Linked Data
Elements
Linked
Business
Rules

Requirements Management

1. Gathering Requirements- Identify

sources of raw requirements data
2. Analyzing Requirements- Develop and
analyze raw requirements data and Develop
basic models ( Process Maps, Use Cases)
3. Specifying Requirements- Develop
requirements. Develop BRDs
4. Validating Requirements- Review the
Requirements
5. Tracking Requirements- Develop
Traceability Matrix and track changes

1. Gathering Requirements

Gather information about present methods,

procedures, systems, work processes and
data operations to understand needs.
Choosing a technique: Is there a
right/wrong You decide what works
best.
Techniques used:
A. Hard Sources (documentation)
B. Interviews, Surveys, Questionnaires
C. Brainstorming
D. Joint Application Development (JAD)

D. JAD

Structured workshop session

More structured and more productive
Meeting agenda provides structure, a
facilitator directs the process and visual aids
clarify concepts being discussed.
Facilitator, End users, developers, Tie
breaker, Observers, Subject Matter Experts.
JADs drive major requirements and
interface look and feel
Addresses Requirements, data and process
models, screens, and report designs

Steps to develop Requirements

Identify Users (Users become Actors)
Identify Tasks (in the process
diagram) performed by the users
(Tasks become Use Cases)
Detail the tasks in use case format
Document Non-functional
requirements
Document business rules

2. Analyzing Requirements

Two sections:

Individual gathering requirements outline: by

utilizing documentation, templates and
Additional requirements
Modeling techniques: process maps, data
elements, business rules and use cases

3. Specifying Requirements
Create the Requirements document
Prioritize the requirements
Peer review- Done by your project
team
All requirements should be testable
Each Requirement should have a
unique identifier

What is a Testable Requirement?

SMART - Specific, Measurable, Action Oriented,

Realistic, Time Bound

Imperative Shall, Will, Must, Must Not,

Required

Complete - must be able to stand on its own

Non Ambiguous only one interpretation

Non Compound no sub-requirements (and, or,

nor, if/else/then)

Correct verified by business owners

4. Validating Requirements
Formal Requirements Review
Authorize the Requirements
documents

5. Tracking Requirements
Develop a Traceability Matrix
Change Requests if changes are
needed

Questions ?

RequirementsExercise 1

Business Analyst
Deliverables

Possible BA Deliverables

Vision
Glossary
Process Maps As is and To be
Business Requirements Document
Software Requirements Specification
Business Rules
Data Elements
Use Cases
Supplementary Specifications
Traceability Matrix
Test Cases

Vision
Also called Product Requirements
Document
The Vision captures very high-level
requirements and design constraints
to give the reader an understanding
of the system to be developed.
It provides input to the projectapproval process

Glossary

Business Definitions

Ex. SLA- Service Level Agreement: It is the

length of time agreed upon by our Company
to provide service to the customer

Process Maps

A visual presentation of the flow of work required to

produce the desired response to a business event.

Components of a process map:

Swim lanes: Horizontal lanes showing( person, group

or system) performing business processes.
Process Shapes: Will depict the processes or activities
utilized in a flow

Business Requirements Document

Captures Business Requirements
Traditional method
Optional

Software Requirements Specification

Captures the complete software
requirements for the system, or a
portion of the system.
Package containing use cases and
applicable Supplementary
Specifications and other supporting
information.

Data Elements

Pieces of information needed by the business

Type/ length- Data type and length of data

element
Numeric(99) Length of 99 with numbers
Alphanum(99)- length of 99 can contain Letter, number and special
characteristics

Allowed values- (E.g. up to 4000)

Business Rules- Any other editing information

that may apply to this field ( E.g. required,
optional)

Exceptions- Any exceptions state

where/where not a data element exists. ( E.g.
IL only, Not Ohio)

Determine Eligibility:Military Data

Elements
Military
Data
Data Element
Proof of military
service
Proof related to
dates
Total Active
service
Receiving
Disability benefit
From where the
member is
receiving
disability
Active or Inactive
Dishonorably
discharged
POW

Requi
red

Field Validation

Sourc
e

yes

Radio button
(yes/no)

user

yes

Radio button
(yes/no)

user

yes

text box; auto tab

user

yes

Radio button
(yes/no)

user

yes

Radio button
(VA,Military, Don't
know)

user

yes

Radio button
(Active/Inactive

user

yes

Radio button
(yes/no)

user

yes

Radio button
(yes/no)

user

Forma
t

numeri
c

Business Rules
Calculations
Guide or constraint on business
behavior or activity

Ex. Gold card customers have a limit of 20000; Silver

10000
Ex. APR calculation
A credit card account can have only 1 primary
cardholder
Premium is calculated using X divided by Y

Explicit conditions/rules regarding

Data Elements

Use Cases

Defines a goal-oriented set of interactions

between external actors and the system
under consideration.
Actors are parties outside the system that
interact with the system.
An actor may be a class of users, roles users
can play, or other systems.
A primary actor is one having a goal
requiring the assistance of the system. A
secondary actor is one from which the
system needs assistance.
Use cases capture who (actor) does what
(interaction) with the system, for what
purpose (goal), without dealing with
system internals.

Use Case Template

Use Case ID (UC - 1)
Use Case Name ( Verb + Noun)
Actors
<List of actors involved in use case may be users, external
systems or events>
Description
<Goal to be achieved by use case>
Pre-conditions
<Any conditions that apply to execute the use case
successfully>
Basic Flow
<Sequence of interactions between actors and system
required to achieve goal> Ex. open credit card account- log
in first time
Post-conditions
<Any conditions that apply after the use case has been
executed>
Alternative Flows
<Any alternative flows of events which may occur> Ex.
Open saved credit card application
Exceptions
<Describe Error Conditions. Add additional flow identifier
blocks as needed> Ex. Incomplete/Information
Special requirements
Assumptions

Use Case Exercise 3

Supplementary Specification

Capture Non-functional requirements

FURPS
Functionality
Usability
Reliability
Performance
Supportability

Design constraints
Implementation requirements
Interface requirements
Physical requirements.

Traceability Matrix

The traceability matrix is used to

ensure all requirements are met and
to locate affected system
components when there is a
requirements change

Test Cases

A Test case is a set of test inputs, execution

conditions, and expected results developed for
a particular objective, such as to exercise a
particular program path or to verify
compliance with a specific requirement.
Test cases reflect the requirements that are
to be verified.
The requirements you choose to verify will be
a balance between the cost, risk, and
necessity of having the requirement verified.

Questions ?

Assignment - Case
Study 1

End of Session 1

Rational Unified
Process

Iterative Approach
Phases and associated
Iterations:

An iteration:

Inception
Iterations focus on management, requirements, and design
activities

Elaboration
Iterations focus on defining, validating, and base lining the
architecture

Construction
Iterations focus on design, implementation, and testing

ex. Fixing Bugs iteration needed including implementation and testing

Transition
Iterations focus on testing and deployment

ex. User feedback iteration needed

Inception: Project Objectives Milestone

(project
viable
or non-viable)
1. Business
Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy

Elaboration: Product Architectural

Milestone
(architecture
is proven)
1. Business
Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy

Construction: Operational Capability

Milestone (all functionality developed)
1. Business Model
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy

Transition: Product Release Milestone

(product released into production)

1. Business Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy

RUP phases and their milestones

WORKFLOW STEPS FOR AN ITERATION

Process
Disciplines

Human Actions

Business
Step 1: For initial iteration,
Modeling
ELICIT Business Rules,
(Business
Business Needs,
Understanding)
Business
Understanding ; for all
subsequent x iterations
DETAIL Business Rules,
Needs, Understanding
Step 2: For initial iteration,
IDENTIFY all significant
Business Use-Cases,
Specifications, Models,
Rules, Vision, and
Architecture; for all
subsequent x iterations
DETAIL Business UseCases, Specifications,
Models, Rules, Vision,
Architecture

Artifacts Produced
Target
Organizational
Assessment
Document, Business
Glossary Document,
Business Rules
Document, Business
Use-Case Model,
Business Vision,
Object Model,
Business
Architecture
Document,
Supplementary
Business
Specification,
Business Glossary
Contd..

Process
Disciplines
Requirements
(User/System
Requirements
Gathering)

Human Actions

Artifacts
Produced

Step 3: For initial iteration, ELICIT

Stakeholder
Requirements (Requests), &
Requests
Rules; for all subsequent x iterations
Requirements
DETAIL Requirements
Management
(Requests), & Rules.
Plan,
Step 4: For initial iteration, IDENTIFY
Supplementary
all significant Use-Cases and
Specification,
classify by risk; for all subsequent x
Use-Case
iterations DETAIL Use-Cases (high
Specification,
risk Use-cases first),
Use-Case Model,
Specifications, Models,
Glossary,
Realizations to match all lower-level
Software
Analysis Classes and Analysis
Requirements
Diagrams and higher-level Business
Specification,
Rules, & Requests.
Storyboard, UseStep 5: PRIORITIZE or
Case Package
REPRIORITIZE USE-CASES by
Diagrams, User
RISK.
Interface
Prototype

Process
Disciplines
Analysis &
Design
(Behavioral &
Structural
Modeling)

Human Actions
Step 6: For initial iteration, CREATE

Artifacts Produced*

Communication
Diagrams, Object
Collaboration Diagrams, Analysis Classes,
Diagrams, Sequence
Analysis Packages, Charts, Realizations,
Diagrams, State
Definitions, & Analysis Models; for all
Charts, Activity
subsequent x iterations DETAIL
Diagrams, Package
Collaboration Diagrams, Analysis Classes,
Diagrams, Class
Analysis Packages, Charts, Realizations,
Diagrams, Software
Definitions, & Analysis Models to match all
Architecture
lower-level Design Class Diagrams and
Document,
higher-level Use-Case Models.
Deployment Model,
Step 7: For initial iteration, CREATE Sequence
Analysis Model,
Diagrams, Analysis Classes, Analysis
Design Model, ProofPackages, Charts, Realizations,
of-Concept
Definitions, & Analysis Models; for all
Prototype, Use-Case
subsequent x iterations DETAIL Sequence
Realizations, Design
Diagrams, Classes, Packages, Charts,
Packages,
Realizations, Definitions, & Models to
Subsystem Design
match all lower-level Design Class
Packages, Design
Diagrams and higher-level Use-Case Models.
Classes, Unit Test
Step 8: For initial iteration, CREATE Design
Classes, Analysis
Classes & Class Diagrams; for all
Classes, Data
subsequent x iterations ns DETAIL Design
Models, Data
Classes & Class Diagrams to match all
Definitions
higher-level Analysis Classes, Diagrams, &
Models.
Step 9: For initial iteration, CREATE Data
Models; for all subsequent x iterations

Implementatio For initial iteration, CREATE Component

n
Diagrams & Models; for all
(Process
subsequent x iterations DETAIL
Modeling)
Component Diagrams & Models to
reflect any changes to Design
Classes, Diagrams, & Models.

Test
(Quality
Assurance)

For initial iteration, CREATE Class

Diagrams, Logs, Lists, Components,
Classes & Architecture; for all
subsequent x iterations DETAIL Class
Diagrams, Logs, Lists, Components,
Classes & Architecture.

Implementation
Model,
Component
Diagrams

Test Cases, Test

Classes, Test Plan,
Test Evaluation
Summary, Test
Scripts, Test Ideas
List, Workload
Analysis Model, Test
Data, Test Results,
Test Log, Test
Guidelines, Test
Classes, Test
Components, Test
Interface
Specification, Test
Automation
Architecture, Test
Environment
Configuration

Deployment For initial iteration, CREATE

(Environment
Deployment Diagrams,
al
Builds, Instructions,
Modeling)
Plans, Notes, Releases;
for all subsequent x
iterations DETAIL
Deployment Diagrams,
Builds, Instructions,
Plans, Notes, Releases.
For initial iteration, CREATE
Component Diagrams,
Builds, Instructions,
Plans, Notes, Releases;
for all subsequent x
iterations DETAIL
Component Diagrams,
Builds, Instructions,
Plans, Notes, Releases.

Deployment Diagrams,
Alpha Software
Build Releases, Beta
Software Build
Releases, Versioned
Software Build
Releases, Release
Notes, Deployment
Plan, Bill of
Materials,
Installation
Instructions, EndUser Support
Material, Training
Materials, Artwork

Change
For initial iteration, CREATE
Management
Change Management
(Risk & Capacity
Plan, Requests,
Planning)
Findings; for all
subsequent x iterations
DETAIL Change
Management Plan,
Requests, Findings.

Change Management Plan,

Change Request,
Configuration Audit
Findings

Project
For initial iteration, CREATE
Management
Project Management &
(Resource & Time
Iteration Plans, Lists,
Management)
Records, Cases,
Orders, Assessments;
for all subsequent x
iterations DETAIL
Project Management &
Iteration Plans, Lists,
Records, Cases,
Orders, Assessments.

Project Plan, Iteration Plan,

Business Case, Software
Development Plan,
Iteration Assessment,
Status Assessment,
Problem Resolution
Plan, Risk Management
Plan, Risk List, Work
Orders, Product
Acceptance Plan,
Measurement Plan,
Quality Assurance Plan,
Issues List, Project

Unified Modeling
Language