Dan North coined the term BDD for behaviour-driven development. Initially he was considering it extends test-driven development. After further consideration, it became obvious it was a way to view both analysis and acceptance testing as well. Put simply, defining and verifying behaviour is far more powerful than creating and running tests.
Dan recognised the value of ubiquitous language as described in the book Domain Driven Design. His choice of As a … // I want … // so that … is valuable in analysis and design in providing focus.
He then hooks the world of words with that of code with scenarios – given … // when… then … These are domain language //natural language statements that are interpreted by the system to interact with the system under development. Confirming behaviour – or running a test under the old parlance.
Dan defines BDD from a software developer perspective, with a focus on features and scenarios to close the gap between design and development. To help span the requirements, design, development and testing, uSDLC uses the breakdown documented by Elizabeth Keogh in her blog on BDD in the large. She attributes the structure to Chris Matts, a business analyst who worked with Dan North extending BDD beyond the development tier. It is a part of feature injection.
This allows for a deeper structure with layers for project, vision, goals, capabilities, features and scenarios. For smaller projects, project, vision, features and scenarios prove an adequate breakdown. It appears that the same ubiquitous language (As a … // I want … // so that …) works for the earlier breakdown as well as for features.