Asking users what they want is a terrible way to gather requirements. Yet I wager that 50% of the business analysts you ask will cite that as their approach, if only because they don’t know any other way.
Unfortunately, ‘gathering requirements’ isn’t a linear, straightforward process, nor is it something to be automated and done by machines. It is messy, chaotic, human, and more akin to art or craftsmanship than exact science.
Shipping new features that customers complain about or don’t work properly indicates that something is off with the requirements process.
Whilst the customer is always right, they don’t always know how to articulate their needs, nor do they necessarily know the best possible solutions. This is why asking them, “Tell me what you want”, is not an effective approach.
Here are some better ways to gather requirements:
- Spend time with users in their own working environment
- Observe users interacting with your software
- 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
- Examine KPI reports and MI dashboards
- Trawl service desk tickets and bug reports
- Ask for audit points and compliance logs
- Investigate system outages and their causes
- Go for lunch and openly ask about frustrations
- Look at competitor landscapes and technology trends
- Reach out to ex-employees and ex-customers
By understanding the problems and pain points first, documenting requirements will follow naturally in good time.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |