Whilst not every team needs software requirements, there are some that would really benefit. Developers who don’t speak to end users, are distanced from the business stakeholders, and who work in remote, outsourced and offshore teams are ideal candidates.
Having a business analyst gather your software requirements, write user stories and validate their acceptance criteria, would really be most valuable in the following situations:
- Concerns for end-user safety and risk of adverse effects
- Regulated environments with heavy compliance
- Moderate to large number of developers
- Developers who prefer to cut code rather than speaking to users
- Junior or inexperienced developers
- Working across several timezones
- Complicated backend systems and data stores to integrate with
- Multiple channels of customer feedback and insight
- Busy, absent or otherwise non-engaged product owner
- Product owner who doesnโt have the time to write user stories
- Pixel-perfect designs produced ahead of developer involvement
- Outsourced development of core business capabilities
- Long-cycle times for customer feedback
- When the technical team has partial visibility of the end product
- Having a 5-year product vision but not a 3-month delivery plan
- An organisation struggling to adopt agile working
A catalogue of software development anti-patterns perhaps, but also an honest account of what many software development teams look like, particularly within large enterprise settings.
Focusing on the software development process would improve things over time; however, stakeholders often demand an urgent need for software delivery and tangible progress, above all else.
Software requirements will mitigate short-term delivery pressures, whilst allowing longer-term improvements and best practices to be implemented over time.
If your developers are struggling, perhaps they need better guidance?
Our Software Requirements can help with that.