Neither Gathering Nor Eliciting, It is Discovering Requirements

Of course, a name is just a name, but it helps in explaining the tasks involved to clients. One of the most important foundational tasks of software development, or any development for that matter, is to understand the need. The software industry has kept changing the names given to these tasks – requirements gathering or data gathering or requirements elicitation. More recently I have been thinking a more suitable term is discovering requirements. It is quite possible that they are used as synonyms in multiple places, but I feel that the discovering activity conveys some things better.

Talking to users and stakeholders has always had high importance. However, it always took some form of interaction, like an interview. This usually means that one of the parties involved, usually the client, knows all the answers. However, my experience has shown me otherwise, which usually makes these interactions less effective.

Users are very good at pointing out the hindrances they face. That is what they are good at – pointing the pain points. But to identify the real problems a discussion between the client and the software developers is required. Our thoughts on building solutions to these problems is when discovery of the requirements begins. Why discovery? Because they exist, but none of the parties are aware of them. A lot of times, I have realized that I have worked as a catalyst for discovering these requirements. The client usually has most of the data and process information, but is too involved in the day-to-day activities to see the problems and requirements.

It is extremely important to make the client understand that discovering requirements is not a one-sided activity. It is important for both the parties to participate and contribute to it. And this is what the phrase discovering requirements conveys better than the other ones. The challenge is to give equal importance to constraints and business deadlines as these activities can end up in bottomless pits.

There is one more message that this phrase conveys. It tells everyone involved that we are not here to invent requirements, which is the best possible ingredient for a failure.

Discussion [Participate or Link]

  1. Techblissonline.com said:

    eliciting is just perfect…you arrive at those requirements, by logically thinking over the discussions that you had with your client.

    Eliciting does not mean that the client straight away lists you all the requirements.You need to arrive at what he needs, from discussions with him..

  2. Abhijit Nadgouda said:

    Yes, I agree with you that the phrase does not matter as much as what you really do. It is gold if the client understands what is meant by it. But I have found it difficult earlier to convey it to the non-IT people what their responsibility is in the elicitation process. Which the requirements discovery phrase seems to address better.

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.