So I've decided to skip right to reading about the Gherkin Method because the more I read about testing the more this seems immediately applicable to making the full circle from user requirements to--business translation--tests--code and back to requirements. I will write more of a summary later.
So I read about the Gherkin method and realized that most of spec writing is actually about modeling requirements in such a way that they are accessible for non-tech people within a business to work with. So the idea is for everyone in your software team to have some degree of autonomy in the contribution process and this includes business analysts, end users etc, and so you need a model for accepting their contributions that will also be conducive to writing code. And this is where the Gherkin method comes in.
Scenario: Bad mouthed leslie should be slapped when she speaks bad words
given: leslie previously spoke bad words
And: she is about to speak more bad words
When: she speaks bad words
Then: she should be slapped
This is an example of the given, and, when, then structure. This allows everyone to write stories about the process and you can actually translate this structure direction into java code using programs like cucumber.
I would like to give cucumber a try next, they have something called "cucumber-ruby" that would be good to play around with. I checked out some examples of how Gherkin can be translated into code here and it would be great for the cohesiveness of so software dev team to be well-versed in translating these business needs in such a way that the unit tests are easy to write.