Business Analysis

Guruprasad R
rgp1981@gmail.com
+91-8971050233
Phases of the Requirements Process

1. Requirement Elicitation(CONT’d)
2. Requirement Analysis
3. Requirement Specification
4. Requirements Approval
Brainstorming

Brainstorming
Brainstorming: What is it?

Solve problems Create consensus

Generate ideas
 Brainstorming: Types

• Individual
• Project team member creates a list of ideas

• Open
• Participants call out ideas that are captured

• Structured
• Participants write down their ideas
• Facilitator goes participant to participant to have them share on idea each
• Continue sharing process until all ideas are exhausted
 Brainstorming: Best Practices

• Determine type of brainstorming meeting ahead of time

• Publish an agenda prior to the brainstorming session

• Clearly state the objective of the meeting

• Create environment to encourage participation

• Establish ground rules

• Do not dismiss or discount an idea or person
• Do build on others’ suggestions and ideas
• Do have fun
Surveys
Surveys: What is it?

Questions to stakeholders Review of quantifiable

to quantify their thoughts data already available
Surveys: Types

• Open-ended questions
• Gives respondents an opportunity to answer in their own words
• Useful, but very time consuming to interpret and catalogue
• Closed-ended questions
• Finite set of answers for each question
• Lends itself to statistical analysis
• Tough to create questions that are not leading or need an “Other” answer
• Questions can vary
• Ranking from “not very important” to “extremely important”
• Ranking from “strongly disagree” to “strongly agree”
• Rank order a list of items
• Multiple choice question
Documentation Review
 Documentation Review: What is it?

• Review existing documentation

• User guides

• Prior system implementation documentation

• Technical documentation

• Lessons learned after completion of latest project

• Formulates context for understanding the scope of the project

 Documentation Review: Pros and Cons

Advantages Disadvantages

Current process documentation provides a starting point Existing documents may be old and out-of-date

The reviewer needs domain and technical expertise to determine if

existing

Can be time consuming, and may not provide the desired payback
 Documentation Review: Best Practices

• Know the purpose for reviewing

• Don’t limit yourself to old systems and old processes and the pain points

around

• Set self-imposed time limits

• Create a glossary of terms from former project documentation

Analyzing Interfaces
Analyzing Interfaces: What is it?

• Independent elicitation activity most of the times.

• ‘User interface analysis’ and ‘System Interface analysis’

• Reviewing the system, people, and process linkages

• Determine needs for input, output, and the medium

• Describes manual and automated processes

 Analyzing Interfaces: Types

• Customer review meetings

• Identify formal requirements to link information, people, and processes

• Drives a robust, complete, and accurate solution

• Developer review meetings

• Happen early on

• Review high-level requirements and system models

• Identify interfaces, regulations, or technical standards

EcoSystem Map for a chemical tracking system
Context Diagrams
Understanding user requirements while conducting Elicitation

• Product-centric approach Vs user-centric and usage-centric approach to requirements

elicitation.

• Discuss what users need to accomplish, in contrast to asking users what they want the system

to do.

• Use cases and user stories work well for exploring the requirements for business

applications but may not be useful for applications such as batch processes,

computationally intensive systems, MIS, business analytics, and data warehousing etc.
Use cases

• A use case describes a sequence of interactions between a system and an

external actor that results in the actor being able to achieve some outcome
of value.
Use cases

• Identify Use cases for Airport check In Kiosk

• Identify Use cases for Online store

Use Cases-Some more examples
Use cases

• Use case describes a sequence of interactions between a system and an external

actor that results in some outcome that provides value to the actor.

• An actor is a person (or sometimes another software system or a hardware device)

that interacts with the system to perform a use case.

• Users Vs actors
Use Case Template
Use Case Template (Cont’d)
Use Case Template (Cont’d)

You could also mention other information and assumptions as part of this
template
Use cases and usage scenarios

• A scenario is a description of a single instance of usage of the system.

• A use case is therefore a collection of related usage scenarios, and a

scenario is a specific instance of a use case.
User Stories

• User story is a “short, simple description of a feature told from the

perspective of the person who desires the new capability, usually a user
or customer of the system”

• As a <type of user>, I want <some goal> so that <some reason>.

Sample Use cases and Corresponding stories
 User Stories

• If an agile development team were discussing requirements for the

CTS, they might come up with user stories such as the following:
• As a chemist, I want to request a chemical so that I can perform experiments.

• As a chemist, I want to request a chemical from the Chemical Stockroom so that I can use it

immediately.

• As a chemist, I want to request a chemical from a vendor because I don’t trust the purity of

any of the samples available in the Chemical Stockroom.

Phases of the Requirements Process

1. Requirement Elicitation
2. Requirement Analysis
3. Requirement Specification
4. Requirements Approval
Visual Modeling Concepts
What is Visual Modeling?

Visual Modeling is…

Graphical representation using a modeling language that takes something
complex and makes it easier to understand.
Benefits of Visual Modeling

• Easily understand complex information

• Receive requirements efficiently
• Identify the underlying problem
• Analyze ‘what if’ scenarios
• Allows remove of irrelevant information
Process Models
What Gets Modeled?

• Current state, “as-is”

• Future state, “to-be”

• Requirements fill the gap

Process Flow Diagram

Start/End

Process

Decision
Process Flow Diagram

Start/End

Process

Decision
BPMN vs UML

Business Process Modeling Notation

vs

Unified Modeling Language

BPMN vs UML: Common Parts

• Activity – Activity within a process, triggered by an event

• Event – Manual or automated action, or delay in time that triggers
an action
• Gateway – Split of pathways, where multiple paths can be taken or
decision on a path must be made per a condition
• Flow – Direction of the sequence or order of events and actions
• Swimlanes – Visual distinction of who is doing what within a
process
UML Activity Diagram
Business Process Modeling (BPMN)
Process Mapping
Representing Entities, Data,
State of objects/Records
Entity Relationship Diagram (ERD)
Data Flow Diagram

Process

External Entity

Database

Data Flow
Data Vs Role CRUD Matrix

You can use a CRUD

matrix in the BPM to
observe how a process
handles data or
Create resources, and what
type of action it
Read performs on them. This
Update can help you perform a
reality check on the
Delete model.
Process Vs Entity CRUD Matrix

Create
Read
Update
Delete
State Diagram

Start / End

Status

Transition
Models to represent system UI
and navigation
User Interface Wireframe