Behavior driven Development
Many of those who attempt to use BDD as part of their story writing capabilities end up only scratching the surface of what it can do. Leveraging a deceptively simple construct:
Given <some precondition>
When <an action occurs>
Then <some post condition occurs>
If this seems like a use case it kind of is, just without all of the confusing symbols, arrows and lines. BDD's strength is that we use the language of our business to write our BDD steps and conditions. This is the key element to understand, we talk in the domain of the business, NOT technology.
I say that it's deceptively simple, because it actually takes some time to master this format, but if you do it will change the way that you think about requirements, helping everyone on the team to ask good questions about the expected behavior of the feature. We are often very good at the happy path, but there is always so much more than that. BDD provides the framework to build out what we can an Example table which identifies individual 'tests' that identify different outcomes for a particular story.