Unlike vanilla TDD, the artifacts produced by BDD can and should be read by more than just developers. Most of us who practice TDD name our tests more or less like this:
MessageBoardControllerTests.Index_WithTenMessages_ReturnsFiveMostRecentFromRepository()
Shifting into Context/Specification style testing, one may be tempted to write specs like this:
MessageBoardController, when invoking index action when there are ten messages,
should return five most recent messages from the repository
The problem with this spec is subtle but important. You often want these specs to be readable and understandable by a normal person, someone in your business that can provide you feedback on your specs. Using words like "invoking", "index", "action" and "repository" are clear indicators that your audience is another developer. You should use the time writing specs to speak in the language of the business and to clarify your ubiquitous language. Here's how I'd rewrite this:
Message Board, when viewed
should show only the five most recent messages
Again, the difference is subtle, but notice how I could show this to anyone in the company and they would understand exactly what is happening.
There are times for developer speak in specs I believe. If you are specing an API to be consumed by other developers I think it's ok to use words like "throw" and "return" because that is what the developers care about when integrating with an API.
Most of the time however, especially when writing the more UI/System Behavior level specs, you should consider who your audience is and try to speak like them. The code itself will provide the detail a developer needs to understand it.
As an aside, this is one of the many reasons I prefer the Context/Specification style to Given/When/Then style of BDD. Because people already don't speak in Given/When/Then prose in real life, it makes it even more difficult to write your specs for the intended audience. It also leads you to use magic numbers and other magic state in your prose rather than formalizing business concepts and improving your ubiquitous language.