My first year in business as a software requirements analyst has now successfully completed and I’m looking forward to having some time off for the summer.
I wasn’t sure about moving on from ‘generalist business analyst’ roles at the time, but I’m glad I did, as it’s allowed me to avoid low-value tasks and work I’m not particularly good at.
Instead, focusing only on software requirements has brought more professionally interesting and challenging work, and allowed me to better leverage my technical expertise and background as a software developer. Clients seem pretty happy too.
However, the year wasn’t without its challenges and in true agile style, here’s an open and honest retrospective.
- Without developers and testers in place, you can only work on requirements for so long before it becomes a questionable, usually wasteful activity. Get a development team or move on at that point.
- Most people don’t really understand how good quality requirements come into existence. The language used in team meetings and project plans implies a mindset of ‘asking users what they want’ before writing it down in some system.
- Software requirements exist as a hierarchy of increasing levels of granularity and detail, from single-sentence epics all the way to field-level specifications. Use the right level at the right time, and factor in successive ‘passes’ of the same requirement in the lead-up to development.
- The software development process that requirements live within is just as important as the requirements themselves. Bad practices and behaviours can render otherwise excellent requirements useless. Appropriately tailoring the SDLC is the antidote.
- Developers and testers are human, each with their own individual working style and preferences. Never forget this. Software requirements shouldn’t be approached as a ‘one size fits all’ activity. Instead, accommodate individual needs where possible.
- Educate clients on how software requirements gathering and management will be performed. Don’t accept existing practices as something to necessarily adopt. Point this out in interviews, remind clients when necessary, and avoid being normalised to their existing capability. Continually striving for excellence is better.
- Remote, offshore, and outsourced development teams benefit from better software requirements. Struggling teams almost always have a requirements problem, among other things. Improving requirements practices is a simple way to quickly get results.
- I still believe specialising as a Business Analyst is the way to go, and a technical background is very beneficial for software requirements. However, I’m not able to 100% make a credible case for this (yet).
2023/2024 has been a real cracker and who knew that software requirements, often seen as boring and stuffy, could actually be so exciting? 😉