Quotes that inform on starting the process in terms of the challenge and the work required to enable successful communication, from BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle, by John Ferguson Smart (Shelter Island, NY: Manning, 2015):
Page 10: “Users and stakeholders will usually know what high-level goals they want to achieve and can be coaxed into revealing these goals if you take the time to ask. They’ll be able to tell you that they need an online ticketing system or a payroll solution that caters to 85,000 different employees. And you can get a feel for the scope of the application you might need to build early on in the project. But the details are another matter entirely. Although users are quick to ask for specific technical solutions to their problems, they’re not usually the best-placed to know what solution would serve them best, or even, for that matter, what solutions exist.”
Page 17: “If you ask users to write up what they want, they’ll typically give you a set of detailed requirements that matches how they envisage the solultion. In other words, users will not tell you what they need; rather, they’ll design a solution for you. I’ve seen many business analysts fall into the same trap, simply because they’ve been trained to write specifications that way. The problem with this approach is twofold: not only will they fail to benefit from the development team’s expertise in software design, but they’re effectively binding the development team to a particular solution, which may not be the optimal one in business or technical terms.”