Enterprise

Analysis

Business Analysis

Planning &

Monitoring

Requirements

Elicitation

Requirements

Analysis

Solution

Assessment &

Validation

Underlying

Competency

Requirements

Management &

Communication

Techniques

Concepts

BA

Bo

K®

Vers

ion

2 R

ele

ase

2009

Describes the tasks and techniques to analyze stated

requirements in order to define the required capabilities of a

potential solution that will fulfil stakeholder needs.

Covers the definition of stakeholder requirements

Covers the definition of solution requirements

May be performed to develop models of the current state of an

organization

Performance of all requirements analysis activities are governed

by the business analysis plans

Business Case

Business Need

Requirements

RMP

Stakeholder List

Input

Prioritize Requirements

Task

Requirements [Prioritized]

Output

Techniques

Decision Analysis

Risk Analysis

MoSCoW analysis

Timeboxing

Voting

Stakeholders

SME (Domain/Implementation)

Project MangerSponsor

Risk of Failure

Need

Low Medium High

Lo

wM

ed

ium

Hig

h

The need of requirements from operational perspective

If not implemented what’s the risk

Presentation

Prototype

Business Process

High-level Usecase

Presentation

Prototype

Functional Usecase

UAT Test cases/ Scenarios

Detail Usecase's

Workflows

UML Diagrams

Data Models

• Over the life of a systems development project, the project team works from the abstract to the concrete:

– Abstract (Requirements)

• Business Requirements

• Business Processes

– Becoming Less Abstract (Analysis – the WHAT)

• Use Cases

• Test Cases

– Becoming Concrete (Design – the HOW)

• Static (class diagrams) and Dynamic (interaction diagrams) Models

• Data Models

– Concrete (Produce)

• Code

• Infrastructure – hardware and software platforms

Business Requirements

Business Process DesignBusiness Requirements Matrix/ Document

Functional Requirements

Usecase Design

Functional Requirements Matrix/ Document

Data Model Business Rules

Process Rules

Object Model

User Interface Model

Organizational Process Assets

Requirements [Stated]

Solution Scope

Input

Organize Requirements

Task

Requirements Structure

Output

Techniques

Business Rules Analysis

Data Flow Diagrams

Data Modelling

Functional Decomposition

Organization Modelling

Process Modelling

Scenarios and Use Cases

Scope Modelling

User Stories

Stakeholders

Customer

End User

Project Manager

Subject Mater Expert

Requirements [Stated]

Requirements Structure

Input

Specify and Model Requirements

Task

Stakeholder or Solution

Requirements

Output

Techniques

Acceptance and Evaluation Criteria Definition

Business Rules Analysis

Data Dictionary and Glossary

Data Flow Diagrams

Data Modelling

Functional Decomposition

Interface Analysis

Metrics and Key Performance Indicators

Non-functional Requirements Analysis

Organization Modelling

Process Modelling

Prototyping

Scenarios and Use Cases

Sequence Diagrams

State Diagrams

User Stories

Stakeholders

All Stakeholder

Conceptual Process

High Level Process Maps

Detail Process

Task/Activities

Implementation Process

VAC

VAC

EPC

BPMN

BPMN

Value Added Chain Diagrams

Event Driven Process Chain

Business Process Modeling Notation

Develop Actor List

Develop Initial

Use Case List

Develop Initial

Use Case Diagram

Write Use Case

Documents

Develop

Activity Diagram

Refine Use

Case Diagram

Business

Requirements

Usecase

Document

Activity

Diagrams

Usecase

Diagrams

Outside the system

Human

Peripheral device - hardware

External system or subsystem

Time

Use a singular noun to name

In the context of system interactions, a

single role of multiple physical users.

Single role, many users

OR

One user, many roles

A use case name should:

Consist of 2 to 4 words

Begin with a verb

Examples:

Place Order

Edit Customer Information

Submit Invoice for Approval

<Usecase Name>

Check Status

Login

Track User Action

Usecase Documentation:

Usecase Name

Usecase Description/Goal

Actor(s)

Pre-Conditions

Post-Conditions

Basic Flow

Alternate Flows

Exception Flows

Business Rules

Detailed Use Case: UC001 {Usecase Identifier} Create Customer Order {Usecase Name}

Description The Order Clerk enters the Customer Installation Order information and submits the order for processing.

Actor(s) Order Clerk (a.k.a. the user)

Order Management System (a.k.a. the system)

Pre-Conditions 1. The user has selected an active customer for whom the order is to be processed (e.g., from use case UC View

Customer Information).

Post-Conditions 1. An order has been successfully submitted for processing (Order Process State is ‘Submitted’).

Basic Flow {Usecase main flow}

1 The user requests that a new Order be created for the selected Customer.

2 The system creates a prospective order (RULE001.1 New Order is Prospective)

3 The system displays the following prospective order information:

a. Customer Name

4 The user specifies the following prospective order information:

a. Service/Product, selected from a list of services/products

b. Primary Service Location (invoke UC Maintain Location Associations)

5. Etc.

Integrated Business Rules with

Usecase flow

Have the actors’ activities been

identified?

Is the flow of events complete

and sequenced properly?

Does the use case describe

queries and responses of data?

Are the use cases described in

short simple sentences?

Have all use case documents

used the template?

Is an open issue list being

maintained?

Are similar scenarios consolidated

into one use case?

Stakeholder Concerns

Input

Define Assumptions &

Constraints

Task

Assumptions and Constraints

Output

Techniques

Risk Analysis Problem Tracking

Stakeholders

All Stakeholder

Requirements [Any Except Stated]

Input

Verify Requirements

Task

Requirements [Verified]

Output

Techniques

Acceptance and Evaluation Criteria Definition

Problem Tracking

Structured Walkthrough

Checklists

Stakeholders

All Stakeholders

User Story Title: Customer withdraws cash

As a customer,I want to withdraw cash from an ATM,so that I don’t have to wait in line at the bank.

Acceptance Scenario 1: Account is in creditGiven the account is in creditAnd the card is valid And the dispenser contains cashWhen the customer requests cash

Business Case

Stakeholder, Solution, or Transition

Requirements [Verified]

Input

Validate Requirements

Task

Requirements [Validated]

Output

Stakeholders

All Stakeholders

Techniques

Acceptance and Evaluation Criteria Definition

Metrics and Key Performance Indicators

Prototyping

Risk Analysis

Structured Walkthrough