Business Analysis in Practice

BUSINESS ANALYSIS IN PRACTICE
Practical Training Course
Author: Tran Cong Cao

Phone: 0909 146 976
Email: cao.trancong@gmail.com
Fb: fb/cao.trancong (#caotran)
1 Author: APEX Learning Content Development Team
Introductions and Expectations
Participant introductions
v Name
v Position and background
v How long experience with Business Analysis or Requirement
Engineering?
v What do you want to get out of this course (expectation)?

Learning Objectives
v Understand the concepts of software requirements
v Understand and appreciate the requirements process
v Describe the importance of requirements in software development life cycle
v Describe how requirements are used to solve business problem, create
products and solution that meet the stakeholders’ needs
v Use the requirements practices in the highly competitive software world
v Organize and facilitate communicate between stakeholders, users and
developers
v Plan and setting the stage for requirements development
v Elicit and analyze requirements correctly and efficiently
v Document and validate requirements in a quality manner
v Manage changes to requirements during the development process

Logistics

Rules of Engagement
Participate.
One person speaks at any given
time.
Keep discussions and questions to
the point.
Turn on your cell phones and other
communication devices to Silence
mode.
Be prompt returning from breaks.

Business Analysis In Practice Course Agenda
v Module 1: Introduction to Requirement Engineering

v Module 2: Requirements Elicitation
v Module 3: Requirements Analysis
v Module 4: Requirements Specification
v Module 5: Requirements Validation
v Module 6: Requirements Management

INTRODUCTION TO REQUIREMENT
ENGINEERING
Business Analysis In Practice – Module 01

Learning Objectives
v Understand the Requirement Engineering

v Understand the role of Requirement Engineer
v Understand the competencies needs to success the role
v Understand the relationships of requirements in the IT projects
v Understand reason why requirement is important support IT project
success
v Understand the requirement approach with new project
v Understand the common techniques to identify stakeholders and prepare
for the project
v Transform to requirement engineer mindset

What is Requirement Engineering?
v A method of obtaining a precise formal specification from the informal and often
vague requirements with customers.
v The science and discipline concerned with analyzing and documenting
requirements. It comprises needs analysis, requirements analysis, and
requirements specifications.
Requirement Development
Requirement Management
Requirements
Requirement
Requirement Baseline
Elicitation
Analysis
(Gathering)
Requirements
Traceability
Requirements
Requirement
Verification & Requirement Change
Specification Management
Validation
* Based on IEEE Standard Terminology

What is Requirement?
v A condition or capability needed by a user or

customer to solve a problem or achieve an
objective.
Customer Provider
v A condition or capability that must be met by a
system or system component to satisfy a contract,
Satisfaction
standard, specification, or other formally imposed Documents
Systems
document.
Capability
Objectives
v A document representation of a condition or Conditions
Needs
capability.
v Requirements are descriptions of the necessary
and sufficient properties of a product or service
that will satisfy the customer’s need.
* Based on IEEE Standard Terminology

Software Requirements
v Requirements describe the behavior of the software as seen from the

customer’s perspective.
v Requirements serve as a communications channel between customers,
users and project managers who are concerned with the development of
software products or services.
v If software people do NOT have well written requirements that users
agree to, how can they develop software that satisfy those users?

Software Requirements
v The “TO DO” List of the Project Team.

v The List of “WHAT” Customer’s need.
v The List of “WHAT” the software must do to satisfy its Customers.
v The List of “WHAT” components must be built.
v The List of “WHAT” each component must “DO” and “HOW” they will
“INTERACT”.

Requirements Engineer Role
v Requirements engineer: a software engineer who has the responsibility

to gather, analyze, document and validate the needs of the project
stakeholders.
v This role in collecting and disseminating project information is critical and
requires a lot of experience and training.

Requirement Engineer – Job Titles
Requirements Engineer
Business Analyst
System Analyst
System Engineer
Project Manager
Data Analyst
Product Owner Development Lead

Three Levels of Business Analysis in the Enterprise
Level 3
Level 2 v Focus to Business

Problem Solving to define
the strategy
v Most time work with senior
Level 1 v Focus to Business
managers and SME
Problem Solving
v Most work products is
v Most time work with middle
Business Model, strategic
managers and SME
v Focus to Requirement plan
Engineering in detail business requirement as:
v Most time work with end- Business case, project
user and technical team proposal
User requirement and
software requirement

Underlying Competencies
v Underlying competencies reflect knowledge, skills, behaviors,

characteristics, and personal qualities that help one successfully
perform the role of the Requirement Engineer.

Requirements Engineer’s Tasks
1) Define business requirements

2) Identify stakeholders & user classes
3) Elicit requirements
4) Analyze requirements
5) Write requirements specifications
6) Model the requirements
7) Lead requirements validation
8) Facilitate requirements prioritization
9) Transfer requirement
10) Manage requirements

Where Do Requirements Come From?

Relationships of Requirements
Requirement
Business
Requirements Documents
Vision & Scope

User’s view
User
Requirements
Use Case
System
Requirements
Developer’s
Software
Requirements view
Hardware
Requirements Software Requirement
Specification

Relationships of Requirements
Business Needs
System
Subsystem A Subsystem B Subsystem C
Hardware Software Hardware Software Hardware Software

What are the problems of Product/System?

Wrong Belief
v Many peoples believe that for every project there is a set of firm requirements.
v If they can get them, they can build them and produce a perfect product or
solution.
v Project team believe customers will clearly provide:
Functional requirements
How they want the work to be done
How it will be used
Performance & Scalability
System boundary (Scope)
Operating environment (Domain)
Verification criteria
Is this true?
Actually
v Customers will provide:

A wish list of what they would like to have.
A solution to their problems without knowledge about how it might be
implemented.
A vague description that limits implementation.
A technology that they read from newspapers.
Changes as they often change their minds.
Strict budget & schedule.

Why Is It So?
v Many customer expectations are NOT based on needs but wants.

v University training is still focusing on solving problems NOT identifying
problems.
v Most software engineers do not receive adequate training on
requirements engineering.
v Many software engineers want to
work on solutions rather than take
time to understand the problem (code
first, ask questions later).

Who is the Customer?
v A customer is an individual or organization who derives either direct or

indirect benefit from a product.
v A software customer is an individual or organization who request, pay for,
select, specify, use or receive output generated by a software product.
Is there all stakeholders is customer?

Who are Stakeholders?
v Stakeholder is a person or group that has an interest in the software and

can influence the software requirements or can be impacted by the
software product.

REQUIREMENTS ELICITATION

Requirements Development
Requirement
Requirement
Elicitation
Analysis
(Gathering)
Requirements
Requirement
Verification &
Specification
Validation

Requirements Development Process
Re-Evaluate
Elicitation Verification &

Analysis Specification
(Gathering) Validation
Clarify Re-Write
Correct and Close gaps
Iterative process - Multiple-steps, Not sequential

Wants vs Needs
Al Davis’s Definition:
Wants = The Stakeholders wish to have.
Needs = The Stakeholders must have.
The ideal situation will satisfy both,

but in reality the Software Engineer must satisfy
all of the needs and some of the wants.

Practical Techniques
v Interviews
v Workshops
v Observation

Practical Technique
INTERVIEWS

Purpose
Asking relevant questions
An interview is a
systematic approach Documenting the responses
designed to elicit business
analysis information from a
person or group of people Establishing relationships and
by talking to the building trust
interviewee(s)
Build support for a proposed
solution
Interview structure
v Structured Interview
v Unstructured Interview

Interview Goal
v The overall purpose of performing a set of interviews, based on a

business need
v The individual goals for each interview, based on what the interviewee
can provide.
v The goals are to be clearly
expressed and
communicated to each
interviewee.

Potential Interviewees
v Potential interviewees are identified with the help of the project manager,
project sponsors, and other stakeholders, based on the goals for the
interview.

Interview Questions
v Collecting data,
v Researching the stakeholder’s view of the change or proposed solution,
v Developing a proposed solution, or
v Building rapport with or support for the proposed solution from the
interviewee.
v Question Types
Open-ended questions
Closed questions

Interview Logistics
v The location for the interview.

v Whether or not to record the interview
v Whether or not to send the questions to the interviewees in advance.
v Whether the interview results will be confidential

Interview Flow
Opening the interview includes:

v Describing the purpose and the interviewees' time is needed,
v Confirming the interviewees' roles and information
v Explaining how information from the interview will be used.

Interview Flow
During the interview, the interviewer:

v Maintains focus on the established goals and predefined questions
v Adapts based upon the information provided and non-verbal
communication from the interviewees,
v Considers both the willingness and concerns of the interviewees
v Practices active listening to confirm what the interviewer has said
v Takes written notes or records the interview as appropriate.

Interview Flow
Closing the interview includes:

v Asking the interviewees for areas that may have been overlooked in the
session,
v Providing contact information for the interviewees to follow up with
additional information after the meeting as needed,
v Summarizing the session,
v Outlining the process for how the interview results will be used
v Thanking the interviewees for their time.

Interview Follow-Up
v Organize the information and confirm results with the interviewees as

soon as possible after the interview.
v Sharing the information that has been learned allows the interviewees to
point out any missed or incorrectly recorded items.

Successful Interviewing Depends on Factors
v Level of understanding of the domain by the interviewer,

v Experience of the interviewer in conducting interviews,
v Skill of the interviewer in documenting discussions,
v Readiness of the interviewee to provide the relevant information and the
interviewer to conduct the interview,
v Degree of clarity in the interviewee’s mind about the goal of the interview,
and
v Rapport of the interviewer with the interviewee.

Strengths
v Simple, direct technique that can be used in a variety of situations.

v Allows the interviewer and participant to have full discussions and
explanations of the questions and answers.
v Enables observations of non-verbal behaviour.
v The interviewer can ask follow-up and probing questions to confirm their
own understanding.
v Allows interviewees to express opinions in private that they may be
reluctant to express in public, especially when interview results are kept
confidential.

Limitations
v Significant time is required to plan for and conduct interviews.

v Requires considerable commitment and involvement of the participants.
v Training is required to conduct effective interviews.
v There is a risk of unintentionally leading the interviewee.

REQUIREMENT ANALYSIS

Re-Evaluate

Clarify Re-Write

Requirements Analysis
v The process of analyzing the stakeholder’s needs to prepare the

definitions of system and software requirements.
v The process of transforming business needs into system descriptions
with performance parameters and partitioning them into subsystems
where allocation to hardware and software can take place.
v Since stakeholders and developers may have different views and
expressions, to facilitate better understanding, Software Engineers
should use abstract descriptions that are easy to understand and
interpret.

Different Views
Objective: To define what the system will do

Stakeholders Developers
vQualitative definition vFunctional definition
vInterpretation to be expected vPrecise, clear
vAll requests must be met vComplete
vRequirements are evolving vFrozen, baseline
vOn going process vMust complete within time
vSchedule driven vTask driven
vSystem must work v“Good” if not perfect system
How do stakeholders and developers communicate?

Requirement Analysis
v Requirements analysis results in requirements models.

v Requirements models are user requirements represented by diagrams,
structured text (lists, tables, matrices) or a combination.
v Requirements analysis also focuses on trade-offs among requirements
to make decisions about their relative importance to support
prioritization.
v Software Engineers are responsible to analyze all requirements and
collaborate with stakeholders to prioritize their needs.
v Requirements analysis is an iterative process.
Why Requirements Models?

REQUIREMENTS SPECIFICATION

Re-Evaluate

Clarify Re-Write

Requirements Specification Is
v A specification can be:
a written document,
a graphical model,
a formal mathematical model,
a collection of usage scenarios,
a prototype,
or a combination of these.
v A baseline agreement between stakeholders and project teams.
v A description of system behavior under various conditions.
v A document describing the characteristics and behavior of the proposed system from
the user’s point of view.
v The basis for subsequent planning, design and coding.
v The foundation for system testing, and user documentation.
v A bridge between user needs and the software requirements specification that the
project team will use to develop the system.

Documentation
WHY WHAT HOW WELL HOW

System Goals User System
Vision Goals Requirements Architecture
User
Objectives System System
Requirements
Performance Constraints
System Goals System
Requirements System Software
Business Constraints Requirements
Requirements Functional
Requirements Non-Functional
Requirements
(Quality attributes)

REQUIREMENTS VERIFICATION & VALIDATION

Re-Evaluate

Clarify Re-Write

Verification & Validation
v Requirements Verification
The process of checking that a deliverable produced at a given stage of
requirements development satisfies the conditions or specifications of the
previous stage.
Verification ensures that you build the software correctly.
v Requirements Validation
The stage of software development
in which the product is checked to
ensure that it satisfies its intended
use and conforms to its
requirements.
Validation ensures that you build
the correct software.
REQUIREMENTS MANAGEMENT

Requirements Management
Requirements Requirements
Elicitation Analysis
Requirements
Management
Requirements Baseline
Requirements Requirements Change Requirements
Requirements Traceability
Validation Specification

The Facts About Requirements
v Most software efforts are increasing in size and complexity and require
an iterative development approach.
v Requirements will change over the life of the project due to changes in
technology, user needs, the environment, and change by issue of
requirement engineer
v Requirements continue to change as more information is obtained
during development.
v Requirements drive the verification and test process.

Requirements Management
v Quality Requirements Management requires that Software Engineers

follow a defined process to manage requirements that:
consist of specification baseline, change control, and traceability;
and identifies how stakeholders must be involved in the process throughout
the development life cycle.

BUSINESS ANALYSIS IN PRACTICE
Apex Global Contact Info:

Email: info@apexglobal.com.vn
Phone: (+84) 028 62 718 187
Hotline: (+84) 0963 801 047 website:
http://apexglobal.com.vn/

Business Analysis in Practice - Apex Global - Demo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysis in Practice - Apex Global - Demo

Uploaded by

Copyright:

Available Formats

Practical Training Course

Author: Tran Cong Cao

2 Author: APEX Learning Content Development Team

3 Author: APEX Learning Content Development Team

4 Author: APEX Learning Content Development Team

5 Author: APEX Learning Content Development Team

v Module 1: Introduction to Requirement Engineering

6 Author: APEX Learning Content Development Team

7 Author: APEX Learning Content Development Team

v Understand the Requirement Engineering

8 Author: APEX Learning Content Development Team

* Based on IEEE Standard Terminology

9 Author: APEX Learning Content Development Team

v A condition or capability needed by a user or

10 Author: APEX Learning Content Development Team

v Requirements describe the behavior of the software as seen from the

11 Author: APEX Learning Content Development Team

v The “TO DO” List of the Project Team.

12 Author: APEX Learning Content Development Team

v Requirements engineer: a software engineer who has the responsibility

13 Author: APEX Learning Content Development Team

14 Author: APEX Learning Content Development Team

Level 2 v Focus to Business

15 Author: APEX Learning Content Development Team

v Underlying competencies reflect knowledge, skills, behaviors,

16 Author: APEX Learning Content Development Team

1) Define business requirements

17 Author: APEX Learning Content Development Team

18 Author: APEX Learning Content Development Team

Vision & Scope

19 Author: APEX Learning Content Development Team

Subsystem A Subsystem B Subsystem C

Hardware Software Hardware Software Hardware Software

20 Author: APEX Learning Content Development Team

21 Author: APEX Learning Content Development Team

v Customers will provide:

23 Author: APEX Learning Content Development Team

v Many customer expectations are NOT based on needs but wants.

24 Author: APEX Learning Content Development Team

v A customer is an individual or organization who derives either direct or

Is there all stakeholders is customer?

v Stakeholder is a person or group that has an interest in the software and

26 Author: APEX Learning Content Development Team

27 Author: APEX Learning Content Development Team

28 Author: APEX Learning Content Development Team

Elicitation Verification &

Correct and Close gaps

Iterative process - Multiple-steps, Not sequential

29 Author: APEX Learning Content Development Team

The ideal situation will satisfy both,

30 Author: APEX Learning Content Development Team

31 Author: APEX Learning Content Development Team

32 Author: APEX Learning Content Development Team

Asking relevant questions

33 Author: APEX Learning Content Development Team

v The overall purpose of performing a set of interviews, based on a

34 Author: APEX Learning Content Development Team

35 Author: APEX Learning Content Development Team

36 Author: APEX Learning Content Development Team

v The location for the interview.

37 Author: APEX Learning Content Development Team

Opening the interview includes: