Project managers, product owners and most people who are NOT developers struggle with defining a heavily technical solution... And business analysts of the traditional nature have this technical nous, but struggle to make the transition to using agile frameworks because of the lingering hangover of BDUF/BRUF. If your product owner is out of their depth in a technical sense, then the whole project/area of development and system architecture is placed greatly at risk from creeping bugs, unknown dependencies, and missing stories. Simply adding a BA to your team will likely create more problems than solutions without re-engineering the need to know all the facts into something that fits "just enough and Just in time".
But it doesn't have to be this way.
In this case study based presentation I explore exact the exact methods we used to upskill a Business analyst or requirements engineer, and massage their skillset into a key role that can insure that quality, detail rich stories go into any agile process, while bridging the communication gap and bringing a wealth of "Big Picture" thinking to the bite sized chunks of Scrum development.