Bring forth the requirements!

Non-business analyst’s often look at me funny when I use the term ‘Elicit’, I can see the “why can’t you BA’s just use a normal word like ‘gathering’?” look in their eyes.

Well, as you asked.

Words like ‘collect’ and ‘gather’ conjure up images of squirrels foraging for nuts or Goldilocks picking flowers, both happily going about their fairy tale day with blissful ease. Life for the Business Analyst is not as straightforward because requirements, despite popular belief, are not just sat there waiting to be plucked.

Let’s consider the definition of ‘elicit’:

to draw or bring out or forth; educe; evoke: to elicit the truth; to elicit a response with a question

Not being a non-BA, I can’t think of a better word than ‘Elicit’ to describe the activity, although the term ‘extract’ can be apt, as it can feel like I’m pulling teeth sometimes given the minefield that projects are.

To a lesser trained eye it may look like a flower ready for picking, but I assure you it is a minefield

To the untrained eye it may look like a flower ready for picking, but I assure you it is a minefield

Thus, there is significant proactive elicitation by the analyst to draw and bring forth true requirements from the stakeholders. To help navigate through this difficult terrain, we have a variety of techniques at our disposal, each one with their own pros and cons.

Elicitation techniques and their pros and cons

Elicitation techniques, their pros and cons

When used appropriately, these techniques help users to understand the situation and visualize the possibilities, consequently the requirements emerge and are articulated.  However, people typically pass on their explicit knowledge: “we know more than we can tell” (sig. Polanyi), and a major problem is that of tacit knowledge. We must include practices aimed at identifying actions and skills for those aspects that we are unable to articulate.

Moreover, should we approach a new project and an enhancement with the same strategy and tactics? No, we should not. Don’t default a technique because “I have done it before”, or because “it worked for me last time”. Each project is unique and the chosen elicitation approach should reflect the job in hand.

Project versus Knowledge Type Matrix

Project versus knowledge type matrix

That said, don’t be constrained by the above matrix. Document analysis may be irrelevant for a greenfield project, but prototyping could be great for gaining explicit knowledge also.

Remember, Business Analysis is an art not a science.

Advertisement

One Response

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.