1

Copyright © 2015 by Business Analyst Learnings

All rights reserved.

No part of this publication may be reproduced, distributed, or transmitted in any form or

by any means, including photocopying, recording, or other electronic or mechanical

methods, without the prior written permission of the publisher, except in the case of brief

quotations embodied in critical reviews and other non-commercial uses permitted by

copyright law.

2

Dedication

To my daughter, Michelle, who inspires me to believe that anything and everything is

possible.

3

Table of Contents

Preface................................................................................................................................6

1. Understanding What It Means To Elicit.......................................................................71.1 Overview of requirements elicitation....................................................................................................................... 81.2 Why requirements elicitation is important and why you should plan for it............................................ 81.3 The inherent difficulties of requirements elicitation....................................................................................... 111.4 A deeper look at requirements elicitation........................................................................................................... 131.5 Where does requirements elicitation begin and end?................................................................................. 161.6 Is requirements elicitation science or art?......................................................................................................... 171.7 From gathering to eliciting requirements............................................................................................................ 171.8 The role of trust in requirements elicitation....................................................................................................... 181.9 What are event-based elicitation techniques and why are they necessary?....................................19

2. Look Inside...................................................................................................................212.1 What do I know?............................................................................................................................................................ 222.2 What do I not know?.................................................................................................................................................... 222.3 What do I need to know?........................................................................................................................................... 232.4 What information do I need help obtaining?..................................................................................................... 232.5 What don’t I need to know?...................................................................................................................................... 24

3. Look Outside................................................................................................................273.1 Look at business objectives...................................................................................................................................... 273.2 Look at data requirements........................................................................................................................................ 283.3 Look at scope.................................................................................................................................................................. 283.4 Look at similar systems in other organizations............................................................................................... 293.5 Look at standard systems......................................................................................................................................... 293.6 Look at the description of similar systems in books and other publications..................................... 293.7 Look at existing systems within the organization........................................................................................... 30

4. Begin With The End In Mind.......................................................................................314.1 Explore the power of visualization......................................................................................................................... 314.2 Identify your objective.................................................................................................................................................. 32

5. Visualize The Participants.......................................................................................... 345.1 Identify the participants............................................................................................................................................... 345.2 Design the participant mix......................................................................................................................................... 345.3 Define the role of each participant........................................................................................................................ 355.4 Design materials that cater to different learning styles............................................................................... 365.5 Draw up a schedule...................................................................................................................................................... 36

6. Visualize The Venue And The Materials You Need..................................................386.1 Decide on venue............................................................................................................................................................ 386.2 Identify the necessary software tools................................................................................................................... 406.3 Identify the necessary hardware tools................................................................................................................. 406.4 Identify the required networking resources....................................................................................................... 416.5 Identify the supplementary materials and equipment you need at the venue..................................416.6 Confirm if the venue will support the arrangement you need...................................................................426.7 Key options to consider.............................................................................................................................................. 43

7. Visualize The Event.....................................................................................................467.1 Identify the most appropriate technique to use............................................................................................... 467.2 Map out the activities................................................................................................................................................... 467.3 Identify the sequence of activities over the course of the day................................................................. 477.4 Map out the timing of each event activity........................................................................................................... 477.5 Identify complementary techniques...................................................................................................................... 48

4

8. Visualize The Human Resources...............................................................................508.1 Will you need someone to bring in refreshments?........................................................................................ 508.2 Will you need technical staff in case something goes wrong?................................................................ 508.3 Will you need other support staff?......................................................................................................................... 518.4 Will you need someone to take minutes?.......................................................................................................... 518.5 Will you need a timekeeper?.................................................................................................................................... 528.6 Will you need a translator?....................................................................................................................................... 528.7 Are there going to be multiple presenters or facilitators?........................................................................... 52

9. Get Ready.....................................................................................................................549.1 Confirm your venue reservation............................................................................................................................. 549.2 Book the equipment..................................................................................................................................................... 549.3 Send out invitations...................................................................................................................................................... 54

10. Execute.......................................................................................................................56

5

1. Understanding What It Means To Elicit

Elicitation, though seemingly straightforward on the surface, is one of the most

complex activities in systems development. The following quote succinctly captures this

complexity:

The outcome of any elicitation event, whatever its objective, is largely determined by

a complex interplay of various unpredictable factors. Achieving the best possible

outcome requires identifying the variables that have a high potential to influence the

outcome of your event and planning for them.

6

1.1 Overview of requirements elicitation

While in some cases, requirements are obvious, especially where stakeholders

specifically request certain features, it is the job of the business analyst to resist taking

requirements as given. The business analyst should explore the facts that may lie

beneath the surface, and produce those requirements that, when satisfied, fulfil

stakeholders’ unexpressed present and future needs.

Requirements are generally LATENT.

In an ideal world, stakeholders would explicitly state what they want. In reality, however,

the latent nature of requirements means that they are usually implicit, not explicit, and

consequently, need to be ELICITED and not simply copied off the pages of a change

request form or taken verbatim as stated by the stakeholder.

1.2 Why requirements elicitation is important and why you should plan for it

Apart from the obvious benefit of understanding stakeholder requirements, requirements

elicitation exploits the tendency of stakeholders to feel valued, understood, and well

informed in their professional specialties. Elicitation also requires stakeholder

participation, which is a critical step to gaining input and cooperation throughout the

project.

Consequently, as analysts improve upon their ability to perform elicitation, they increase

the probability of delivering correct specifications, which, in turn, leads to the

implementation of successful systems. Elicitation requires effective planning to get the

7

most out of stakeholder engagements.

When elicitation sessions are not properly planned, it may result in a loss of trust and

confidence in the project, missing requirements, and incorrect specifications.

Strategies for Project Recovery, a 2011 research by PM Solutions on 163 companies

split into small, medium, and large organizations across different industries, identifies one

of the top causes of troubled projects as “Requirements: Unclear, conflicting,

contradictory, ambiguous, and imprecise.” According to this study, firms on average

manage $200 million in projects each year. During that time, these organizations will

realize that $74 million of their projects are at risk of failing.

According to an interview-based study of software projects from 2010 – 2011 by the

software development company, Geneca, up to 75% of project participants lack

confidence that their projects will succeed. Common problems identified include fuzzy

business objectives, out-of-sync stakeholders, excessive rework, and requirements

definition not reflecting real business needs. These studies strongly underscore the need

to address the potential pitfalls of projects, especially in terms of requirements elicitation

and stakeholder engagement.

Planning requirements elicitation effectively reduces the risks associated with business

projects. Unfortunately, some business analysts dive into requirements elicitation

sessions without a plan or with one that fails to cover all of the necessary bases. They

place more emphasis on what happens during the event and less on what happens

before. This can be likened to going to war without understanding the strengths and

weaknesses of your enemy. If you know what to do before, during, and after an elicitation

8

event, you will be better positioned to elicit accurate requirements and solve business

problems.

9

1.3 The inherent difficulties of requirements elicitation

Academic literature is rife with reasons for the failure of software projects. Frederick P.

Brooks (No Silver Bullet: Essence and Accidents of Software Engineering, 1987)

concisely described the requirements dilemma as follows:

The hardest single part of building a software system is deciding what to build. No

other part of the conceptual work is as difficult as establishing the detailed

technical requirements, including the interfaces to people, machines, and other

software systems. No other part of the work so cripples the results if done wrong.

No other part is more difficult to rectify later. Therefore, the most important

function to perform for the client is the iterative extraction and refinement of

product requirements.

Decades later, this pronouncement still rings true.

The diagram below represents a snapshot of some of the difficulties inherent in eliciting

requirements from the perspective of stakeholders and analysts.

10

1.4 A deeper look at requirements elicitation

Requirements elicitation can be described as a process that involves:

Discovering,

Uncovering,

Revealing,

Articulating,

Describing, and

Understanding requirements through regular and insightful interactions with

stakeholders.

Requirements should be discovered through a dynamic interplay of questioning, feedback,

and interaction. Requirements elicitation is an exploratory activity, one in which the

facilitator should be willing to start from the beginning with a blank slate. The objective of

requirements elicitation is to understand stakeholders’ needs and produce a set of

requirements that, if fulfilled, can lead to the achievement of business objectives.

The term elicit, can be interpreted in two ways, as follows:

1. To call forth emotions, feelings, and responses - When you elicit requirements from

stakeholders, you are calling on them to verbalize how they feel and respond to you. You

cause them to feel and think so that they can express their facts, opinions, and emotions.

An elicitation session is not a monologue in which one person rules the conversation. The

stakeholder should not take over the conversation; neither should the analyst. The

objective is for the analyst to place incentives along the way that allow requirements to

flow out, like a river from its source.

2. To construe meaning

The word elicit becomes more powerful when you think of it as “construing meaning.” In

some cases, your response to stakeholders will be to clarify construed meaning.

Communication, simple as it seems, can get quite complex. You should not only listen to

and understand stakeholders, but also be able to construct intelligent responses that

clarify your understanding (or confusion) of facts. A huge part of effective communication is

feedback, which should be reciprocal between stakeholders and analysts.

Business analysts may hesitate to show confusion because they believe it casts doubt on

their competence and undermines their positions. Successful analysts, however,

understand that the questions they ask are just as important as how they ask them. Thus,

these BAs are able to come up with questions that need to be answered, from the basic to

the complex.

The main objective of involving BAs in projects is not to have them appear universally

knowledgeable, but rather to produce an inventory of requirements that reflects the real

needs of the business. Such positioning can be difficult for BAs, especially since their

perceived strength famously lies in their knowledge of the business.

Whenever asking tough questions allows you to learn more, give yourself permission to

ask them without fear. There will be plenty of time to score points further down the road.

Elicitation can be viewed as a cyclical process of:

1) Evoking (reaction/response/emotion),

2) Construing, and

3) Clarifying meaning