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
Linked Data
Requirements Requirements Elements

Usability Linked
Business
Performance Functional Rules
Requirements
Maintainability
&
Supportability
Security Technical

Availability/ Requirements
Reliability

Scalability
 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 ?
Requirements-
Exercise 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 project-
approval 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
Requi Sourc Forma
Data Element red Field Validation e t
Proof of military Radio button
service yes (yes/no) user
Proof related to Radio button
dates yes (yes/no) user
Total Active numeri
service yes text box; auto tab user c
Receiving Radio button
Disability benefit yes (yes/no) user
From where the
member is Radio button
receiving (VA,Military, Don't
disability yes know) user
Radio button
Active or Inactive yes (Active/Inactive user
Dishonorably Radio button
discharged yes (yes/no) user
Radio button
POW yes (yes/no) user
 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 An iteration:
Iterations:
 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
1. Business or non-viable)
Modeling
2. Requirements
3. Analysis & Design
4. Implementation
5. Test
6. Deploy
Elaboration: Product Architectural
Milestone (architecture
1. Business Modeling is proven)
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 Human Actions Artifacts Produced
Disciplines
Business Step 1: For initial iteration, Target
Modeling ELICIT Business Rules, Organizational
(Business Business Needs, Assessment
Understanding) Business Document, Business
Understanding ; for all Glossary Document,
subsequent x iterations Business Rules
DETAIL Business Rules, Document, Business
Needs, Understanding Use-Case Model,
Step 2: For initial iteration, Business Vision,
IDENTIFY all significant Object Model,
Business Use-Cases, Business
Specifications, Models, Architecture
Rules, Vision, and Document,
Architecture; for all Supplementary
subsequent x iterations Business
DETAIL Business Use- Specification,
Cases, Specifications, Business Glossary
Models, Rules, Vision,
Architecture
Contd..
Process Human Actions Artifacts
Disciplines Produced
Requirements Step 3: For initial iteration, ELICIT Stakeholder
(User/System Requirements (Requests), & Requests
Requirements Rules; for all subsequent x iterations Requirements
Gathering) 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, Use-
Step 5: PRIORITIZE or Case Package
REPRIORITIZE USE-CASES by Diagrams, User
RISK. Interface
Prototype
Process Human Actions Artifacts Produced*
Disciplines
Analysis & Step 6: For initial iteration, CREATE Communication
Design Collaboration Diagrams, Analysis Classes, Diagrams, Object
(Behavioral & Analysis Packages, Charts, Realizations, Diagrams, Sequence
Structural Definitions, & Analysis Models; for all Diagrams, State
Modeling) subsequent x iterations DETAIL Charts, Activity
Collaboration Diagrams, Analysis Classes, Diagrams, Package
Analysis Packages, Charts, Realizations, Diagrams, Class
Definitions, & Analysis Models to match all Diagrams, Software
lower-level Design Class Diagrams and Architecture
higher-level Use-Case Models. Document,
Step 7: For initial iteration, CREATE Sequence Deployment Model,
Diagrams, Analysis Classes, Analysis Analysis Model,
Packages, Charts, Realizations, Design Model, Proof-
Definitions, & Analysis Models; for all of-Concept
subsequent x iterations DETAIL Sequence Prototype, Use-Case
Diagrams, Classes, Packages, Charts, Realizations, Design
Realizations, Definitions, & Models to Packages,
match all lower-level Design Class Subsystem Design
Diagrams and higher-level Use-Case Models. Packages, Design
Step 8: For initial iteration, CREATE Design Classes, Unit Test
Classes & Class Diagrams; for all Classes, Analysis
subsequent x iterations ns DETAIL Design Classes, Data
Classes & Class Diagrams to match all Models, Data
higher-level Analysis Classes, Diagrams, & Definitions
Models.
Step 9: For initial iteration, CREATE Data
Models; for all subsequent x iterations
Implementatio For initial iteration, CREATE Component Implementation
n Diagrams & Models; for all Model,
(Process subsequent x iterations DETAIL Component
Modeling) Component Diagrams & Models to Diagrams
reflect any changes to Design
Classes, Diagrams, & Models.

Test For initial iteration, CREATE Class Test Cases, Test

(Quality Diagrams, Logs, Lists, Components, Classes, Test Plan,
Assurance) Classes & Architecture; for all Test Evaluation
subsequent x iterations DETAIL Class Summary, Test
Diagrams, Logs, Lists, Components, Scripts, Test Ideas
Classes & Architecture. 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, End-
User 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.
Project For initial iteration, CREATE Project Plan, Iteration Plan,
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.
Change Management Plan,
Change Request,
Configuration Audit
Findings
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