babok_v2_requirements_elicitation_re_overview

A Guide to the Business Analysis Body of Knowledge (BABoK®) – Knowledge Area

Requirements Elicitation

By – Amjad Shaikh

Enterprise

Analysis

Business Analysis

Planning &

Monitoring

Requirements

Elicitation

Requirements

Analysis

Solution

Assessment &

Validation

Underlying

Competency

Requirements

Management &

Communication

Techniques Concepts

(BABoK)

BA

Bo

K®

Vers

ion

2 R

ele

ase

2009

a recap…

A condition or capability needed by a stakeholder to solve a problem or achieve an objective

A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard specification or other formally imposed document

A documented representation of a condition or capability as in 1 or 2 above

Requirement

Business Requirement

Stakeholder Requirement

Solution Requirement

Transition Requirement

Classification of Requirement

Functional Requirement

Non-Functional Requirement

a classic…

Requirements Gathering Vs.

Requirements Elicitation

Going beyond just gathering

Active engagement of stakeholders to identify and understand their needs and the environment in which they work

WHAT?

Business Analyst & Stakeholders

WHO? To ensure that a stakeholders actual or underlying needs are understood, rather than their stated or superficial desires

WHY?

Iterative throughout elicitation, analysis, verification and validation activities

WHEN?

Prepare For Elicitation

The Purpose of the task

Ensure all needed resources are organized and scheduled for conducting the elicitation activities

Layout of the task

Business Need Business Scope Business Case Stakeholders List, Roles & Responsibilities

Input

Prepare for Elicitation

Task

Scheduled Resources Support Material

Output

Techniques

Brainstorming Document Analysis Focus Groups

Interface Analysis Interviews Observation

Prototyping Requirements Workshops Survey/Questionnaire

Stakeholders

All Stakeholders Project Manager

Key Elements

Level of details that should be considered

Resources Ground Rules

People

Facilities

Equipment

For event-based elicitation (brainstorming, focus group, interview, observation, prototyping, requirements workshop) ground rules must be established

Inform

Notify appropriate parties of the plan

Process

Agree on form and frequency of feedback during the elicitation process and the mechanism for verifying and signing off on the elicited results or at the beginning or during one specific phase

Conduct Elicitation


Meet with stakeholder(s) to elicit information regarding their needs

Layout of the task

Business Need Organizational Process Assets Requirement Management Plan Scheduled Resources Solution Scope Business Case Supporting Materials

Input

Conduct Elicitation Activity

Task

Elicitation Results

Output

Techniques




Stakeholders

All Stakeholders Project Manager

Key Elements


While eliciting the requirements it is important to guard against scope creep. Tracing requirements back to the business goals/objectives helps to validate whether a requirement should be included

Tracking

While eliciting the requirements, documenting requirements attributes such as the requirement’s source, value and priority will aid in managing each requirement throughout its life cycle

Attributes

Tracking the elicitation participants and the actual time spent eliciting the requirements provides a basis for future planning

Metrics

Document Elicitation Results


Record the information provided by stakeholders for use in analysis

Layout of the task

Elicitation Results

Input

Document Elicitation Results

Task

Requirement [Stated] Stakeholder Concerns

Output

Techniques




Stakeholders

Business Analyst

Key Elements


Documentation can take a number of forms

Minutes of meeting (MOM)

Visual or audio recordings

Whiteboards

Notes

Output Form

The form of output depends upon the technique used for elicitation

Confirm Elicitation Results


Validate that the stated requirements expressed by the stakeholder match the stakeholder’s understanding of the problem and the stakeholder’s needs

Layout of the task

Requirement [Stated, Unconfirmed] Stakeholder Concerns [Unconfirmed]

Input

Confirm Elicitation Results

Task

Requirement [Stated, Confirmed] Stakeholder Concerns [Confirmed]

Output

Techniques




Stakeholders

All Stakeholders

The complete picture

Clarify scope.

Schedule activities, resources and dates.

Publish the plan.

Prepare

Meet with stakeholders to elicit requirements

Capture requirements attribute & trace requirements

Conduct

Summarize output from elicitation

Document

Review the outcome with stakeholders & confirm

Confirm

Key Techniques

What impacts the choice of tools & techniques

Consider stakeholder needs when making decisions about tools or techniques

Stakeholder

To ensure that a stakeholders actual or underlying needs are understood, rather than their stated or superficial desires

Skills of Business Analyst Involved

Conflicts Rely on ground rules when conflicts arise

Some widely used techniques

Group Techniques

One on One Interview Observation

Collaborative Sessions Brainstorming Focus Group Requirements Workshop

Interface Prototyping Interface Analysis

Document Based Document Analysis Surveys / Questionnaire

Structured Interview – Interview that has defined set of questions, agenda & execution pattern Unstructured Interview – Interview which is free-flow and progression is based on information surfacing within the process of interview

Types of Interview

Closed Ended – Questions that results into objective responses (provide options for responses) Open Ended – Questions that results into subjective responses

Types of Questions

Interview techniques is the process of interacting with individual stakeholder to understand their need/s and perspective about the change/project

Positive Negative Cannot be used where there is a need to build consensus across a group of stakeholders

Interview techniques allows Business Analyst to confirm understanding by asking follow-up questions

Example from Web

BA: Why should the submit button be red? Client: Because we really want the user to press it? BA: Why do you think that the user will press it if it's red? Client: Because it will stand out on the page? BA: What if the user is color blind? Client: Hmm... I didn't think of that! Let's just make the text bold? BA: (thinking: we are getting nowhere) Why is it so important that the user clicks the submit

button? Client: Because currently it does important things and some users don't click it. BA: What is so important? Client: (getting annoyed, of course): Because it has logic which submits the new lead to the

marketing department which provides us lots of value. Many users click the cancel button by mistake.

BA: (a-ha) So the problem is that when the user clicks the cancel button my mistake they lose their data right away and they probably don't want to re-enter all the info.

Client: Exactly! Now can we just make the button bold! BA: What if we put a message box when clicking the "Cancel" button which asks the user

something like "Are you sure you want to cancel and lose all the data you just entered?" Client: Wow... that would be great!

Passive or invisible – Observe stakeholder without interruption to there work Active or visible – Observe with active feedback & questions

Study the stakeholder performing their job in order to document details about the current process

Positive Negative Suitable for AS-IS process only without identify infrequent exceptions

Can provide you un-documented process (Tacit knowledge)

Shadowing – Learning via observation Apprenticing – Learning via participating on job

Types of Observations

Using the creative powers of a group to generate many ideas quickly to help solve a problem or resolve an issue. Ideas generated need to undergo additional evaluation and analysis.

Feature of Brainstorming

Time limit and criteria for evaluating and rating the ideas is established in advance.

Do not debate the ideas during the brainstorming session.

Produce as many ideas as possible within time limit.

Typically last 20 minutes. Variation is anonymous brainstorming.

Visual representation of user interface

Horizontal prototype – covers a wide but shallow view of functionality.

Vertical prototype – covers a narrow but deep view of functionality.

Throw away prototype – uses simple tools e.g. whiteboard.

Evolutionary prototype – produces running software which will emerge as the actual system further downstream

Types of Prototyping

Study of the connection between components of a solution, generally system to system or hardware to hardware interfaces

Fundamentals of Interface Analysis

Identify system boundaries Identify dependencies within system Identify the inputs & outputs

transactions Identify key data elements

Example

Health Plan Management System

Consumer Portal Application

Consumer Requests

Plan Information

Provider CRM

Appointment Scheduling

Content Format and Subject Area [Content Format]

Message - ID Description Content format Subject Areas

Message-1 Plan Information Web Services Benefits

Message-2 Appointments Schedule Web Services Scheduling

BA

Bo

K®

Vers

ion

2 R

ele

ase

2009

BABOK V2 - Business Analysis Knowledge Areas & Tasks Layout

[2] Business Analysis Planning & Monitoring

[3] Elicitation [4] Requirements Management & Communication

[5] Enterprise Analysis [6] Requirement

Analysis

[7] Solution Assessment &

Validation

[2.1] Plan Business Analysis Approach

[3.1] Prepare for Elicitation

[4.1] Manage Solution Scope and Requirements

[5.1] Define Business Need [6.1] Prioritize Requirements

[7.1] Assess Proposed Solution

[2.2] Conduct Stakeholder Analysis

[3.2] Conduct Elicitation Activity

[4.2] Manage Requirement Traceability

[5.2] Assess Capability Gap [6.2] Organize Requirements

[7.2] Allocate Requirements

[2.3] Plan Business Analysis Activities

[3.3] Document Elicitation Results

[4.3] Maintain Requirement for Re

[5.3] Determine Solution Approach

[6.3] Specify and Model Requirements

[7.3] Assess Organization Readiness

[2.4] Plan Business Analysis Communication

[4.4] Prepare Requirement Package

[5.4] Define Solution Scope [6.4] Define Assumptions

& Constraints [7.4] Define Transition

Requirements

[2.5] Plan Requirement Management Process

[4.5] Communicate Requirements

[5.5] Define Business Case [6.5] Verify Requirements [7.5] Validate Solution

[2.6] Manage Business Analysis Performance

[6.6] Validate Requirements

[7.6] Evaluate Solution Performance

[3.4] Confirm Elicitation Results

babok_v2_requirements_elicitation_re_overview

Engineering