Tell me what you want

Simply asking users “Tell me what you want” is a pretty terrible way to go about requirements gathering. And yet I wager that 50% of the business analysts you ask may cite that as their chosen approach, if only because they don’t know any other way.

Unfortunately, ‘gathering requirements’ isn’t a linear, straightforward process, nor is it something that can be automated and done by machines. It is messy, chaotic and human, and more akin to an art form or craftsmanship than exact science.

Shipping new features that customers complain about or don’t work properly is a good sign that something is off with the software requirements.

Whilst the customer is always right, often they don’t always know how to articulate their needs, nor do they necessarily know the best possible solutions. Which is why simply asking them “Tell me what you want” is not an effective approach.

Here are some better ways to approach your requirements gathering:

• Spend time with end users in their own working environment
• Observe the users actually interacting with your systems
• Listen to their ‘under the breath’ mutterings
• Use screen recording and eye tracking software
• Go to staff meetings and listen intently
• Pay attention to the watercooler chatter
• Look at KPI and MI dashboards, what do they tell you?
• Trawl through the service desk looking at bug tickets
• Ask for audit points and compliance logs
• Investigate major system outages and their causes
• Go out for lunch and ask openly about frustrations
• Look at competitor landscapes and technology trends
• Reach out to ex-employees and ex-customers

Above all else, really seek to understand the problems and pain points of your users, the documenting of requirements will follow naturally in good time.