I've found that wireframing dispels many issues with ambiguous requirements - my team usually goes about it by first having an open ended conversation about wha

I've found that wireframing dispels many issues with ambiguous requirements - my team usually goes about it by first having an open ended conversation about what we want to achieve, with both engineers who are not part of the target industry and a team stakeholder who is; then try to come up with a list of requirements like the list of shalls the author describes; and then if it's a visual task at all, make a wireframe describing the functionality, which we first review internally and then review with customers who will use the product. We find that Whimsical is a pretty nice tool for doing this, as it is a nice level of "low res" enough to not stress about the details, but "high res" enough to be able to imagine the real deal. After some cycles of iteration we're usually pretty well aligned about what we're building, and only then do we start coding. Engineering teams sometimes go too fast to punching out code when figuring out requirements could save enormous amount of time, effort, and stress.