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.