Post on 22-Feb-2018
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