Business Analysis for Practitioners

- Requirements Elicitation and

Analysis (Domain 3)
 COURSE STRUCTURE
Introduction to Business
Needs
Business Analysis
Assessment
Analysis Planning
Module 2
Module 1 Module 3

Requirements
Traceability and Solution
Elicitation and
Monitoring Evaluation
Analysis
Module 5 Module 6
Module 4
 COURSE OBJECTIVE
At the end of this course, you will
understand what business analysis is all
about, why it is essential to the success of
any project and how to perform it on your
projects...
Business Analysis for
Practitioners
MODULE 4
MODULE OBJECTIVE
 REQUIREMENTS ELICITATION
AND ANALYSIS
Requirement elicitation involves:
-Drawing out information from
stakeholders and other sources about
the causes of the business problem or
the reasons for addressing a current
opportunity

-Drawing out information that will be

used to derive sufficient level of
requirements to enable solution
development and implementation
 REQUIREMENTS ELICITATION
AND ANALYSIS
The BA focuses highly on requirements management
because this is fundamental to project success – scope,
cost and schedule
Ever been on a project team that failed?
If adequate requirements
elicitation had been done, do
you think the odds for that
failure would have been
greatly reduced?
 Importance of Eliciting Information

Information is not only elicited to generate

requirements or answer questions from the solution
team, but the information becomes the basis to
effectively complete other business analyst tasks,
such as:
• Support executive decision making.
• Apply influence successfully.
• Assist in negotiation or mediation.
• Resolve conflict.
• Define problems.
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:
Develop the elicitation
plan
Prepare for elicitation
Conduct elicitation
activities
Elicitation techniques
Document outputs
from elicitation
activities
Complete elicitation
Elicitation challenges
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:
Plan for Elicitation
- Develop the Elicitation Plan
(Finding Information, Techniques
for Eliciting Information and
Sequencing the Elicitation
Activities)

Prepare for Elicitation

- Determine the Objectives
- Determine the Participants
- Determine the Questions for
the Session
 Develop the Elicitation Plan
Some of the elements in an elicitation plan include
but are not limited to:
• What information to elicit. What does the business analyst need to
know in order to define the problem, solve the problem, or answer the
question?
• Where to find that information. Where is that information located:
in what document, from what source, in whose mind? Identify who has
the information or where it is located.
• How to obtain the information. What method will be used to
acquire the information from the source?
• Sequencing the Elicitation Activities. In what order should the
elicitation activities be sequenced to acquire the needed information?.
Example of Completed Elicitation Plan
 Prepare for Elicitation
Elicitation preparation is the planning performed to
conduct an effective elicitation session. Preparation
notes can be used to measure the progress achieved
in a session against what was planned to be achieved
and can be used to adjust expectations for future
sessions.

1. Determine the Objectives

2. Determine the Participants
3. Determine the Questions for the Session
Example of Preparation Notes for an
Elicitation Session
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Conduct Elicitation Activities

- Introduction
- Body (Types of Questions, How
to Ask the “Right” Questions and
Listening)
- Close
- Follow-Up
 Conduct Elicitation Activities
There are four stages during the actual elicitation
activity in which information is gathered:
• Introduction. The introduction sets the stage, sets the
pace, and establishes the overall purpose for the elicitation
session.
• Body. The body is where the questions are asked and the
answers are given.
• Close. The close provides a graceful termination to the
particular session.
• Follow-Up. The follow-up is where the information is
consolidated and confirmed with the participants.
 Types of Questions
The types of questions that can be asked are as
follows:
• Open-ended question. A question that allows the respondents to
answer in any way they desire.
• Closed-ended question. A question that calls for a response from a
limited list of answer choices. Types of closed-ended questions are
forced choice, limited choice, and confirmation.
• Contextual question. A question that requires an answer regarding
the subject at hand; namely, the problem domain or the proposed
solutions.
• Context-free question. A question that may be asked in any
situation. Context-free questions are also used as lead-ins to obtain
information to define the solution.
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:
Elicitation techniques
- Brainstorming
- Document Analysis
- Facilitated Workshops
- Focus Groups
- Interviews
- Observation
- Prototyping
- Questionnaires and Surveys
 REQUIREMENTS ELICITATION
AND ANALYSIS
Elicitation techniques include:
Facilitated
Brainstorming Interviews
workshops

Prototyping
Observations (Storyboarding Questionnaires
& wireframes)

Document
Surveys Focus groups
analysis
 Interviews
There are two basic types of interviews:
• Structured interviews. Begin with a list of prepared questions with the goal of
asking and obtaining answers to every question on the list or within the allotted
time.
• Unstructured interviews. Begin with a list of prepared questions, but the only
question that is definitely asked is the first. After that, the subsequent questions are
based on the answers to the previous questions.
Interviews may be conducted :
• Synchronous Interviews. These interviews are performed live or in real time. These
can be conducted in a number of ways, such as face-to-face where the business
analyst and the interviewee are in the same room, or they can be conducted over the
telephone, with video conferencing, internet collaboration tools, etc. The key is that
the interview is being conducted with the interviewee and interviewer at the same
time.
• Asynchronous interviews. These interviews are not conducted in real time; the
business analyst or interviewer is not involved in the interview at the same time as
the interviewee.
 Observation
Observation is a technique that provides a direct way of viewing
people in their environment to see how they perform their jobs or
tasks and carry out processes. It is particularly helpful for detailed
processes when people who use the product have difficulty or are
reluctant to articulate their requirements.
There are four types of observation; each is used in a
different situation:
• Passive observation
• Active observation.
• Participatory observation.
• Simulation.
 Prototyping
Prototyping is a method of obtaining early feedback on requirements
by providing a working model of the expected product before building
it.

A prototype can be a mockup of the real result as in an architectural

model, or it can be an early version of the product itself.

The key element to prototyping is the iterative process of creating the

prototype, reviewing it with the pertinent stakeholders, making
adjustments and modifications to the prototype, and reviewing it
again. This process continues until all parties agree that the prototype
has provided the needed information to the solution team.
 Prototyping
There are two types of prototypes.: Low-Fidelity and High-Fidelity
Prototype

• Low-fidelity prototype. Low-fidelity prototypes are completed with a

pen and paper, marker and whiteboard, or modeling tool on the
computer. Examples of low-fidelity prototypes include:

○ Wireframes,
○ Mockups of interface screens or reports,
○ Architectural renderings of a building,
○ Floor plans,
○ Sketches of a new product, and
○ Any design that is evolving.
 Prototyping
• High-fidelity prototyping. High-fidelity prototypes create a representation of the
final finished product
There are two types of high-fidelity prototypes: throwaway and evolutionary.

○ Throwaway prototypes are discarded once the interface has been confirmed. This
is similar to the product prototypes developed by manufacturing companies. The
prototype is used to help define the tools and process for manufacturing the product
but the prototype itself is not sold.

○ Evolutionary prototypes are the actual finished product in process. The first
prototype that is reviewed is the earliest workable version of the final product. With
each successive prototyping session, more functionality is added or the existing
functionality is modified to achieve a higher level of quality.

Note: With agile project teams, evolutionary development is how the product is built. The
work is not considered to be a prototype but is an actual slice of the product itself.
 Prototyping
Two examples of prototyping techniques are:
• Storyboarding. Storyboarding is a prototyping technique showing sequence
or navigation through a series of images or illustrations. Storyboards are
graphical representations that represent the sequence of events. Storyboards
are typically static and thrown away. Prototypes focus on what the product
will look and feel like, while storyboards focus on the experience.

• Wireframes. A wireframe is a diagram representing a static blueprint or

schematic of a user interface and is used to identify basic functionality. A
wireframe separates the look and feel of a site from its function. It presents a
stripped-down, simplified version of the page, devoid of distractions. The
purpose of the wireframe is to illustrate the flow of specific logical and
business functions by identifying all entry and exit points or actions the users
will experience.
Difference between Wireframe, Mockup
and Prototype
Wireframe Example
Mockup Example
Prototype Example
Design Process Example
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Document Outputs
from Elicitation
Activities

Complete Elicitation

Elicitation Issues and

Challenges
 REQUIREMENTS ELICITATION
AND ANALYSIS
Non
accessibility
to
appropriate
stakeholders
Stakeholders
not providing Stakeholders
sufficient ELICITATION not knowing
detail to CHALLENGES what they
develop the want
solution
Stakeholders
having
difficulties
expressing their
requirements
clearly
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:
Analyze requirements
Model and refine
requirements
Document the solution
requirements
Validate Requirements
Verify Requirements
Approval Sessions
Resolving
Requirements-related
conflicts
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Analyze Requirements
- Plan for Analysis (Analysis
Defined, Thinking Ahead
about Analysis and What to
Analyze)
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Model and refine requirements

- Description of Models
- Purpose of Models
- Categories of Models
- Selection of Models
- Use of models to refine requirements
- Modelling Languages
- Scope Models (Goal Model and Business
Objective Model, Ecosystem Map, Context
Diagram, Feature Model and Use Case Diagram)
 Description and Purpose of Models
Description
The model refers to a visual representation of information, both
abstract and specific, that operates under a set of guidelines in order
to efficiently arrange and convey a lot of information in a concise
manner. In its simplest form, a business analysis model is a structured
representation of information.

Purpose
Business analysis models are helpful to find gaps in information and to
identify extraneous information. Models provide context to better
understand and more clearly convey information. Requirements are
modeled and refined to achieve further clarity, correctness, and to
elicit additional information to define the details necessary for the
product to be built.
 Categories of Models
Model and
refine
requirements

Models are visual representations of abstract &

specific information which help refine requirements

Rule Interface
Scope Process
models Data models models
models models
(e.g. (e.g. Entity (e.g.
(e.g. (e.g.
Decision relationship User
Ecosystem Process
tree and diagram) interface
maps) flow)
tables) flow)
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Model and refine requirements

- Process Models (Process Flow, Use Case and User
Story)
- Rule Models (Business Rules Catalogue, Decision Tree
and Decision Table)
- Data Models (Entity Relationship Diagram, Data Flow
Diagrams, Data Dictionary, State Table and State
Diagram)
- Interface Models (Report Table, System Interface
Table, User Interface Flow, Wireframes and Display-
Action-Response
Models Organized by Category
Modeling Languages and Usage
Scope Model
Goal Model and Business Objective
Model
Ecosystem Map
Context Diagram
Feature Model
Use Case Diagram
Process Model
Process Flow
Use Case
User Story
Rule Model
Business Rules Catalog
Decision Tree
Decision Table
Data Model
Entity Relationship Diagram

Crows’ Foot and 1 to N notation

Data Flow Diagrams
Data Dictionary
State Table
State Diagram
Interface Model
Report Prototype
Top-Level Elements in a Report Table
Field Elements in a Report Table
System Interface Table
User Interface Flow
Wireframe
Display-Action Response
Model
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Document the solution requirements

- Why Documentation is Important
- Business Requirements Document
- The Solution Documentation
(Requirements and Categorization)
- Requirements Specification (Documenting
Assumptions and Documenting Constraints)
_ Guidelines for Writing Requirements
(Functional Requirements)
 Why Documentation is Important
Documented requirements serve a multitude of purposes, such as the following:
• Baseline to validate the stakeholder needs;
• Baseline definition of the solution for the business problem or opportunity;
• Primary input to the design team, the developers, testers, and quality
assurance;
• Basis for user manuals and other documentation whether written or
embedded;
• Supporting detail for contractual agreements, when applicable (e.g., the
requirements are a core input to a statement of work (SOW) for a request for
proposal (RFP));
• Starting point for the evolution of the solution;
• Foundation for reusability by other project teams who need an understanding
of the project details while it is in process or after implementation; and
• Baseline for an audit of regulated industries and high-risk projects that are
required to have documented requirements.
 Business Requirement and Solution Document

Business requirements are the goals, objectives, and higher-level needs of the organization
and provide the rationale for a new project. Business requirements recognize what is critical to
the business and why it is critical before defining a solution.

Solution documentation is the documentation that is comprised of the features, functions, and
characteristics of the product or service that will be built to meet the business and stakeholder
requirements. It serves as the blueprint for the product that the solution team is being asked
to build.

The solution documentation may be rendered in any number of forms. Some common forms
include:
• Requirements document, which may be a business requirements document and/or a
functional requirements specification and/or a system or software requirements specification,
etc.;
• Deck of user stories written;
• Set of use cases with accompanying nonfunctional requirements; or
• List of items on a product backlog.
 Product and Project Requirement

While product requirements describe what is being built or the

outcome of the project or solution to the business problem, project
requirements describe the constraints and necessities for successful
completion of the project.

For example, product requirements describe the length and width of

the sidewalk to be constructed in front of a building, along with such
aspects as color and texture. The project requirements for laying the
sidewalk could include the number of laborers required, qualifications
of the laborers to handle the equipment, size of the equipment, time
frame for usage, and any restrictions on labor hours.

• Product requirements are the responsibility of the business analyst.

Project requirements are the responsibility of the project manager.
 Categorization

Requirement categories are used to help group and structure requirements within
the documentation.
The process of categorization helps expose vague, misstated, ambiguous, or
otherwise poorly written requirements.
Categorization filters out the bad or poorly written requirements.
Examples of possible filters are:
• Scope filter. Determine whether a requirement or information is in scope, out of
scope, or unknown.
• Functional filter. Once the functional categories have been determined, any
defined functional requirement not fitting into one of the categories can be filtered
out, revised, or discarded.
• Prioritization filter. An arbitrary level of priority (e.g., needs, wants, and desires), is
defined and used as a filter to determine which requirements stay or are removed.
• Testability filter. All requirements need to be testable, and all requirements should
be examined to determine if they are testable. Any requirements that are not
testable are filtered out and need to be revised.
 Guidelines for Writing Requirements
Information needs to be transcribed into high-quality, well-formatted requirements.
Requirements that are well written are of higher value to the solution developer and
overall project team, because these will be clear, concise, and reduce conflict and
confusion on what needs to be delivered.
A well-formatted requirement consists of the following elements:
• Condition,
• Subject,
• Imperative,
• Active verb,
• Object,
• Business rule (optional), and
• Outcome (optional).
Example—A well-formed detail level requirement might be as follows: When the new
account button is pressed (condition), the system (subject) will (imperative) display
(active verb) the new account entry screen (object) allowing the creation of a new
account (outcome).
 Guidelines for Writing Requirements
The following characteristics serve as a checklist when reviewing requirements to
ensure they are of high quality.
1. Unambiguous
2. Precise
 Guidelines for Writing Requirements
The following characteristics serve as a checklist when reviewing requirements to
ensure they are of high quality.
1. Unambiguous 2. Precise 3. Consistent 4. Correct 5. Complete 6. Measurable 7.
Feasible 8. Traceable 9. Testable
Guidelines for Writing Requirements
Guidelines for Writing Requirements
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Document the solution requirements

- Why Documentation is Important
- Business Requirements Document
- Prioritizing Requirements (Prioritization
Schemes)
- Technical Requirements Specification
- Documenting with Use Cases
- Documenting with User Stories
- Backlog Items
 Prioritization Techniques

MoSCoW. MoSCow establishes a set of prioritization rules which are:

○ Must haves (fundamental to project success),
○ Should haves (important, but the project success does not rely on them),
○ Could haves (can easily be left out without impacting the project), and
○ Won’t haves (not delivered this time around).

Multivoting

Time-boxing

Weighted ranking
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Validate Requirements
- The Concept of Continual
Confirmation
- Requirements Walkthrough

Verify Requirements
- Peer Review
- Inspection
REQUIREMENTS ELICITATION
AND ANALYSIS
Validate Requirements process ensures
all requirements accurately reflect the
intent of the stakeholder.

It is usually performed via requirements

walkthrough or concept of continual
confirmation

Verify Requirements process reviews

the requirements for errors and quality
criteria

It is usually performed via peer review

or inspection.
 REQUIREMENTS ELICITATION
AND ANALYSIS
Eliciting requirements and analysis involves:

Approval Sessions

Resolving Requirements-related
conflicts
- Delphi
- Multivoting
- Weighted Ranking