i think this (the parent post) is truth: i've had conversations a/b behavior specification where edge cases simply aren't taken into account. so the specification would say, for example
"it does this when anyone clicks a button."
whereas there's often some implicit question, like
"what happens when two people click the button at the same time?"
and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.
In general, BAs should not be writing the stories, but they should be able to read them together with the developers.
I find that it helps, but it doesn't solve the whole problem. The most useful bit is the stories with examples, as those are what are so often missing from specs.
The problem with edge cases is that they are infinite. If there's an edge case that's likely to happen (ideally based on evidence of past behaviour), then it can either be in the spec or just in functional tests.
I like to think that BDD is like writing the documentation first. Would you put the edge case in the documentation? If not, it probably isn't the BA's responsibility to decide what should happen, and it shouldn't have a Gherkin-style story.
But it's not a silver bullet. It's a tool that helps solve some problems on some projects in some teams. Usually, it helps in cases where the domain experts are not very technical and where the domain problem is a fairly simple set of business rules.
"it does this when anyone clicks a button."
whereas there's often some implicit question, like
"what happens when two people click the button at the same time?"
and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.