From a deck of Business requirements to Automation testing

Lately I have been heavily involved with preparing BDDs with BIAs and then entering them to Fitnesse as Scenarios with testers. For both teams, these concepts are new.
BIAs, in some cases, are taking BDDs as "Forget what you have learned so far on how to do your work and start doing them in BDD format". In some other cases, they see them as "too technical" when combined with scenarios (test cases). Then, in some other cases, they are saying that all they have to do is "small enhancements" so writing BDDs is not necessary. I had the chance to run a session with them and explain this. I started with the Story Map and explained that as "10K feet view". Then, we zoom in to "1K feet view" and look at MMF (Minimum Marketable Feature). Then we zoom again to "100 feet view" which is one of the stories and finally, zoom really close to a Feature. How do we explain what this feature is? We write requirements! How do we write requirements? In a way that everyone in the team (BIA, Developer, Tester and Client) understand. What would that be? As simple as possible, make it a picture, a drawing, a sentence,  whatever helps you explain but keep it simple and meaningful. Suggested: BDD.
Why BDD? Well, one benefit is that it can become executable, testable. There are different apps for that. One easy to grip on is Fitnesse. Others are more advanced but even more complicated to setup. Since we have a lot of Web testing to do, Selenium was a must. So found a way to connect Fitnesse and Selenium and have one entry point, Fitnesse.
Now we had to prove that a BDD can be executable. So we created some Fitnesse pages for different test cases and tried to "sell" it to BIAs. That didn't go very well. It felt like they had to write scripts, program, develop. It also felt very technical in the sense that they had to put together numbers and create cases of what to enter and what to expect, something that usually is done by testers.
We learned that our BIAs are not ready to write anything that is not pure English (wiki language that Fitnesse uses does not fall in pure English). We learned that our testers at the beginning were scared that Fitnesse will replace them, but after, they didn't like it that they had to write test cases and then change them when ideas were changed.

One thing we won, is a place where we can send testers and BIAs to see how requirements look like when they are done well, with testing in mind and when people work together. All I can hope is that now that they know how the end looks like, they can start a new project in the right way, they can do the right thing at the beginning.