Specification by example (SBE) is a user-driven contextual approach to defining software requirements.
SBE requires business stakeholders to provide realistic scenarios for how the software will be used and those examples are used to determine the scope of the project. This approach has two major benefits -- it encourages communication between the business owners of a project and the software development team and it helps the developers align software specifications with user acceptance testing (UAT). When done right, the specifications can be validated through automated software tests that run frequently.
In order for SBE to succeed, it's important that the business owners provide the development team with precise examples that illustrate how slices of the system should behave. It's equally important for the development team to make sure each specification by example is testable. SBE may deliver less than optimal outcomes if examples focus on how the software works rather than on the business goals it seeks to achieve. This is where communication and collaboration become key. For example, if the business stakeholders spend too much time describing how they would like an online form to be formatted, it is up to the SBE project manager to bring the focus of the conversation back to how the data that is entered in the form will be used to drive productivity, profitability and business growth. When SBE is implemented appropriately, it can simplify design, reduce unnecessary code in development and speed deployment by shortening or eliminating feedback loops.
SBE is often used in iterative software development methodologies such as Agile, Scrum and Extreme Programming (XP). Depending upon the implementation, the examples that the business owners provide may also be referred to as executable requirements or use cases. What the team decides to call project artifacts is not important -- the only thing that matters is that the team agrees upon a common language and uses it consistently. It is equally important that documentation be created and updated throughout the project to ensure that code can be maintained or updated easily when the project is over. SBE project managers call this "living documentation." Whatever the team decides to call the project's documentation, it should serve as a way for the IT team to demonstrate additional business value when change is required.
As a concept, SBE is credited to Gojko Adzic, a software development consultant who wrote a book in 2011 entitled "Specification by Example: How Successful Teams Deliver the Right Software." In the real world, the concepts presented in the book may also be referred to as example-driven development (EDD) or behavior-driven development (BDD), two similar approaches that are also the subjects of books.
See also: functional specification