The lost art of requirements elicitation

Agile methods have, rightly so, become the standard way of creating and delivering software systems. Most agile frameworks and methodologies do not prescribe any way of capturing requirements and translating them into specifications. To fill this gap, most analysts and developers resort to using user stories as the starting point for the analysis and development process. As alluded to in previous chapters, user stories are usually too wide in scope and context to serve a useful purpose without a huge amount of context-filtering and descoping. This leads to what is known as user-story hell, where our product backlog consists of dozens of different stories, describing everything from non-acting stakeholders' wishes to technical constraints. Such backlogs are extremely difficult to manage or prioritize.

So, when a stakeholder tells us they want something from our system, we have two options.

The first option is that we create a user...