Specification by Example Workshop
Specification by Example is a collaborative approach to software requirements gathering and documentation that focuses on defining and clarifying the desired behavior of a system or feature using concrete examples. It is also known as Behavior-Driven Development (BDD) or Acceptance Test-Driven Development (ATDD).
The key idea behind Specification by Example is to use real-life scenarios, often referred to as “examples” or “user stories,” to communicate and validate the requirements of a system. These examples are typically written in a specific format that captures the expected inputs, actions, and outcomes for a given functionality or feature.
Here are some key elements and characteristics of Specification by Example:
Collaborative Process: Specification by Example involves close collaboration between business stakeholders, domain experts, developers, and testers. It encourages frequent and open communication to ensure a shared understanding of the desired system behavior.
Concrete Examples: Rather than relying on abstract or ambiguous requirements, Specification by Example emphasizes the use of concrete examples that illustrate the expected behavior of the system. These examples are typically written in a structured format that captures the preconditions, inputs, actions, and expected outcomes.
Shared Understanding: By using examples, Specification by Example helps in bridging the gap between business stakeholders and technical teams. It promotes a shared understanding of the system behavior and ensures that everyone involved has a clear and consistent view of the desired outcomes.
Validation and Automated Testing: The examples written during the Specification by Example process serve as the basis for acceptance criteria and automated tests. These examples are used to validate that the implemented system meets the expected behavior and can be automated to serve as regression tests.
Living Documentation: The examples and associated tests created during the Specification by Example process serve as living documentation that evolves alongside the system. They provide a clear and up-to-date understanding of the system behavior and can be used to onboard new team members or as a reference for future enhancements.
By adopting Specification by Example, teams can improve the clarity and completeness of requirements, foster collaboration and shared understanding, and ensure that the implemented system meets the desired behavior. This approach helps in reducing misunderstanding, rework, and the risk of delivering software that does not meet the stakeholders’ expectations.
In the world of software development, effective communication and collaboration between stakeholders and development teams are crucial for project success. Misunderstandings, misinterpretations, and lack of clarity can lead to expensive rework, delays, and unsatisfied end-users.
This is where Specification by Example (SBE) comes into play.
SBE is a collaborative approach that aims to bridge the gap between stakeholders and development teams by using concrete examples to define and validate requirements. In this article, we will explore the concept of Specification by Example and its benefits in modern software development.
Specification by Example, also known as “Example-Driven Development” or “Acceptance Test-Driven Development,” is an agile technique that emphasizes the use of concrete examples to specify software requirements. It shifts the focus from traditional textual requirements documents to executable examples that serve as living documentation and acceptance criteria for the software.
***
“Specification by Example” by Gojko Adzic is a well-known book that provides guidance on implementing Specification by Example practices. The book introduces several key process patterns that help teams effectively use examples to drive the development and refinement of software requirements. Here are some of the key process patterns highlighted in the book:
Real-World Examples: The book emphasizes the importance of using real-world examples that reflect the actual needs and behaviors of end users. Realistic examples help in creating a shared understanding of the system’s requirements and facilitate effective communication between stakeholders and development teams.
Collaborative Discovery: The collaborative discovery pattern encourages cross-functional collaboration among stakeholders, developers, and testers to explore and discover requirements together. This pattern emphasizes the importance of actively involving all relevant parties in the process of identifying examples, discussing scenarios, and refining the requirements.
Domain Language: The book emphasizes the use of a common domain language to bridge the gap between business and technical teams. Developing a shared language helps in aligning the understanding of requirements, reducing misunderstandings, and enabling effective collaboration throughout the development process.
Building a Glossary: The book suggests creating a glossary of key domain terms and concepts to ensure consistent and unambiguous communication. The glossary helps in establishing a common understanding of terminology, reducing confusion, and facilitating effective collaboration.
Example Mapping: Example Mapping is a technique introduced in the book to structure and refine examples during requirements gathering. It involves visualizing examples on a physical or digital board, using index cards or sticky notes. Example Mapping helps in organizing examples, identifying missing or redundant scenarios, and fostering collaboration among team members.
Automated Acceptance Tests: The book emphasizes the importance of using automated acceptance tests based on the examples and acceptance criteria. Automation ensures that the system continues to meet the desired behavior and provides fast feedback on any regressions or deviations from the expected outcomes.
Living Documentation: The concept of living documentation refers to maintaining the examples, acceptance criteria, and associated tests as living artifacts that evolve alongside the system. Living documentation provides up-to-date and easily accessible information about the desired behavior, making it easier for stakeholders and team members to understand and validate the system’s functionality.
These process patterns, as outlined in the “Specification by Example” book, provide practical guidance for implementing Specification by Example practices. They promote collaboration, shared understanding, and effective communication, enabling teams to deliver software that meets the desired behavior and aligns with the needs of the stakeholders. The process typically involves collaboration between stakeholders, business analysts, developers, testers, and other project members. They work together to identify, define, and refine examples that illustrate the desired behavior of the software from various perspectives.

Business Goal: The process starts with identifying and aligning the business goals or objectives that the software system aims to achieve. It is crucial to have a clear understanding of the desired outcomes and the value the system should provide to the business or end users.
Scope: Defining the scope involves determining the boundaries and context of the system or feature being developed. This helps in understanding what needs to be included or excluded from the solution and provides clarity on the specific functionality or behavior that should be addressed.
Key Examples: Key examples are concrete scenarios that capture the essential aspects of the desired system behavior. These examples are selected based on their significance in illustrating the core functionality or critical business rules. They serve as focal points for discussion, refinement, and validation throughout the development process.
Specification with Examples: Specification with examples refers to the process of collaboratively defining the requirements using the selected key examples. The examples are used to illustrate and clarify the expected behavior of the system. This process involves discussing and refining the examples to ensure a shared understanding among all stakeholders.
Executable Specification: An executable specification is an automated test suite that validates the behavior of the system against the defined examples and acceptance criteria. These tests serve as executable documentation and can be run repeatedly to ensure that the system remains aligned with the desired behavior.
Living Documentation: Living documentation refers to maintaining the examples, acceptance criteria, and associated tests as living artifacts that evolve alongside the system. This documentation serves as a valuable resource for understanding the system’s behavior, onboarding new team members, and facilitating ongoing collaboration and refinement.
These key process patterns, as outlined in the “Specification by Example” book, provide a structured approach to capturing, validating, and documenting the desired behavior of the software system. They foster collaboration, ensure a shared understanding, and help deliver software that meets the intended business goals and user needs.



Specification with Examples: During a collaborative session, the team discusses and refines the key example. They may identify additional details, such as the ability to include emojis in the comment replies and displaying the reply hierarchy in the user interface.

Executable Specification: The team creates an automated acceptance test that simulates the scenario described in the key example. The test checks if the notification is sent to the original commenter when a user replies to their comment.
[Theory]
public void when_a_user_replies_to_a_comment_the_original_commenter_should_be_notified()
{
// TODO
}

Living Documentation: The automated acceptance test becomes part of the living documentation. It is regularly executed, providing ongoing assurance that the desired behavior is maintained. The test serves as documentation and can be used to validate the system’s behavior during development and regression testing.
These examples illustrate how each process pattern can be applied in the context of developing and refining software requirements using Specification by Example practices.
The power of Specification by Example as you can see, is based on merging the people, and taking the power of collaborative modelling.
Merge the People
Split the Software
Collaborative modeling is a practice that involves a group of stakeholders, typically representing different roles and perspectives, coming together to collaboratively create models that represent various aspects of a system or problem domain. It is a participatory approach that encourages active engagement, shared understanding, and collective decision-making.

In collaborative modeling, stakeholders work together in real-time or through facilitated sessions to create visual representations, diagrams, or models that capture and communicate important concepts, relationships, and requirements of the system. The focus is on fostering collaboration, knowledge sharing, and eliciting diverse viewpoints to create a more comprehensive and accurate representation of the system.
The benefits of collaborative modeling include:
Shared Understanding: Collaborative modeling helps stakeholders develop a shared understanding of the system, its components, and their interdependencies. By involving different perspectives and expertise, it ensures that everyone has a voice and contributes to the model.
Improved Communication: Visual models generated through collaborative modeling provide a common language that facilitates effective communication among stakeholders. Models can help clarify complex ideas, highlight key relationships, and reduce ambiguity.
Early Validation: Collaborative modeling allows stakeholders to validate and refine their understanding of the system early in the development process. By working together, potential misunderstandings or gaps can be identified and addressed, ensuring that requirements are accurately captured.
Consensus Building: Through collaborative modeling, stakeholders have the opportunity to discuss, debate, and reach consensus on various aspects of the system. This collaborative decision-making process helps build alignment and reduces the risk of miscommunication or conflicting expectations.
Iterative Refinement: Collaborative modeling promotes an iterative approach, allowing models to evolve over time. As stakeholders gain more insights and information, they can update and refine the models to reflect the changing understanding of the system.
Collaborative modeling techniques can include various visual modeling tools, such as diagrams, mind maps, user story maps, or impact maps. The specific techniques used may vary depending on the context, the nature of the system being modeled, and the preferences of the stakeholders involved.
Overall, collaborative modeling fosters collaboration, enhances communication, and enables stakeholders to collectively create models that capture and represent the system’s requirements, behavior, and structure.
A value proposition is a statement or proposition that explains the unique value and benefits that a product, service, or solution offers to its customers or target audience. It articulates why customers should choose a particular offering over alternatives available in the market. A strong value proposition effectively communicates the value, differentiation, and relevance of a product or service to its intended audience.
Start with value proposition statement of your desire domain.
The key components of a value proposition include:
Target Audience: Clearly identifying the specific group of customers or market segment that the offering is designed to serve. Understanding the needs, preferences, and pain points of the target audience is crucial for developing a compelling value proposition.
Value or Benefits: Articulating the specific value, benefits, or outcomes that the offering provides to the customer. This can include cost savings, increased efficiency, improved performance, enhanced user experience, time savings, convenience, or any other significant advantages.
Differentiation: Highlighting the unique features, capabilities, or qualities that set the offering apart from competitors. This could be based on technology, quality, design, customer service, expertise, or any other aspect that provides a competitive advantage.
Relevance: Demonstrating how the offering addresses the specific needs, challenges, or aspirations of the target audience. Showing a deep understanding of customer pain points and aligning the value proposition with their requirements enhances its relevance and resonance.
Proof or Evidence: Providing evidence, testimonials, case studies, or data that supports the claims made in the value proposition. This helps build trust and credibility, assuring customers that the promised value is backed by real-world results or customer experiences.
Clear and Concise: Expressing the value proposition in a clear, concise, and easily understandable manner. Avoiding jargon and using simple language helps ensure that the value proposition is quickly grasped and resonates with the target audience.

A well-crafted value proposition effectively communicates why customers should choose a particular offering and how it addresses their needs or solves their problems. It helps in attracting and engaging the target audience, differentiating the offering from competitors, and ultimately driving customer acquisition and retention.
The Business Model Canvas is a strategic tool used to visualize and describe the key components of a business model. It provides a framework for analyzing and designing business models in a concise and structured way. The canvas consists of nine essential building blocks that capture the key aspects of a business:
https://merlin-ict.eu/what-is-a-business-model-canvas/
Customer Segments: Identifies the specific customer groups or market segments that the business aims to serve.
Value Proposition: Describes the unique value, benefits, or solutions that the business offers to its target customers. It articulates why customers would choose the business’s products or services over alternatives.
Channels: Specifies the distribution channels and touchpoints used to reach and interact with the target customers. It includes both physical and digital channels through which products or services are delivered.
Customer Relationships: Defines the types of relationships established and maintained with customers. This can include personal assistance, self-service, community building, or automated interactions.
Revenue Streams: Outlines the various sources of revenue generation for the business. It includes pricing models, revenue streams, and monetization strategies.
Key Resources: Identifies the critical resources required to deliver the value proposition. This can include physical assets, intellectual property, human resources, or strategic partnerships.
Key Activities: Specifies the key activities and processes that are essential to the business’s operations. It includes activities related to production, marketing, distribution, customer support, and more.
Key Partnerships: Describes the strategic alliances and partnerships that contribute to the success of the business. This can include suppliers, distributors, technology providers, or co-creation partnerships.
Cost Structure: Outlines the costs and expenses associated with running the business. It includes both fixed and variable costs, such as production costs, marketing expenses, personnel costs, and overheads.
By visually representing these nine building blocks, the Business Model Canvas helps entrepreneurs, startups, and established businesses gain a holistic understanding of their business model and identify areas for improvement or innovation. It encourages strategic thinking, value creation, and the exploration of new business opportunities.
https://learnwardleymapping.com/landscape/
Wardley Mapping is a strategic mapping technique developed by Simon Wardley that helps organizations understand and navigate the landscape of their business environment. It provides a visual representation of the evolution and interdependencies of various components within a business ecosystem.
Wardley Mapping involves the following key elements:
Value Chain: The technique begins by identifying the value chain of a business, which represents the sequence of activities that create value for customers. This typically starts with the user needs and progresses through various stages, including components like supply chains, processes, and supporting technologies.
Evolution: Wardley Mapping emphasizes the evolution of components within the value chain. It categorizes them into different stages based on their maturity, predictability, and availability. The common stages include genesis (new and uncertain), custom-built (bespoke solutions), product (commodity solutions), and utility (mature and widely available).
Dependency Mapping: Wardley Mapping focuses on understanding the dependencies between different components and how they interact with each other. By mapping these dependencies, organizations can identify critical dependencies, potential risks, and areas for improvement.
User Needs: The technique highlights the importance of understanding user needs and aligning the value chain components accordingly. By keeping user needs in focus, organizations can better prioritize and adapt their strategies.
Strategic Positioning: By plotting the components on a map based on their evolution and dependencies, Wardley Mapping enables organizations to analyze their strategic positioning. It helps identify areas where they can differentiate themselves, focus on core competencies, or leverage external services.
Wardley Mapping provides a visual framework that facilitates discussions, aligns stakeholders, and supports the development of a strategic roadmap. It helps organizations make informed decisions, identify areas for innovation, and anticipate future trends within their business ecosystem.
The technique has gained popularity in strategic planning, technology management, and business transformation efforts, as it provides a structured and visual approach to analyzing and strategizing within complex and dynamic environments.
Impact mapping is a strategic planning technique that helps organizations align their activities and projects with desired business outcomes. It provides a visual framework for defining and communicating the intended impact of initiatives and identifying the necessary steps to achieve those outcomes.
https://www.impactmapping.org/example.html
The key elements of impact mapping include:
Goal: The starting point of impact mapping is to define the overarching business goal or objective. This represents the desired outcome or impact that the organization wants to achieve.
Stakeholders: Identifying the key stakeholders who are impacted by or have an influence on the goal. Stakeholders can include customers, users, internal teams, external partners, and regulatory bodies.
Impacts: Identifying the specific impacts or changes that need to occur to reach the goal. These impacts can be tangible outcomes such as increased revenue, improved customer satisfaction, or reduced costs. They can also be intangible outcomes like increased awareness, enhanced reputation, or improved employee morale.
Deliverables: Determining the deliverables or outputs that can contribute to each impact. These are the tangible artifacts, products, or services that need to be created or delivered to bring about the desired impacts.
Activities: Identifying the activities or initiatives required to produce the deliverables. These are the specific actions, projects, or tasks that need to be undertaken to create the required outputs.
Dependencies: Exploring the dependencies between impacts, deliverables, and activities. This helps in understanding the relationships and dependencies between different elements and ensures a cohesive and coordinated approach.
Impact mapping helps organizations prioritize their efforts by focusing on the outcomes and impacts that are most important. It encourages a shift from a feature-centric mindset to a value-centric mindset, ensuring that activities and projects are aligned with the desired business results.
The visual nature of impact mapping facilitates communication and collaboration among stakeholders, enabling a shared understanding of the goals, impacts, and necessary actions. It helps uncover assumptions, clarify expectations, and promote a more strategic and outcome-driven approach to planning and decision-making.
Overall, impact mapping is a valuable technique for organizations seeking to align their initiatives with business outcomes, enhance stakeholder engagement, and maximize the value delivered through their projects and activities.
User story mapping is a technique used in agile software development to visually represent and organize user requirements or features in a user-centric manner. It helps teams gain a shared understanding of the product or project and facilitates effective prioritization and planning.
The process of user story mapping involves the following steps:
Identify User Roles and Goals: Start by identifying the different user roles or personas who will interact with the product or system. Understand their goals and objectives, as well as the tasks they need to accomplish.
Capture User Stories: User stories are short, simple descriptions of a user’s need or feature requirement. Capture user stories by focusing on the user’s perspective and the value they expect from the product. Each user story should be independent, actionable, and testable.
Arrange User Stories: Arrange the user stories on a horizontal axis in a logical sequence that represents the user’s journey or workflow. This helps create a high-level overview of the product’s functionality and how users will interact with it.
Identify User Flows and Dependencies: Identify the main user flows or pathways through the system and any dependencies between user stories. This helps identify the critical paths and potential bottlenecks in the user experience.
Prioritize and Slice: Prioritize the user stories based on their importance and value to the user. This helps determine the order in which they will be implemented. Additionally, consider slicing user stories into smaller, manageable pieces that can be delivered incrementally.
Add Details: Add additional details, such as acceptance criteria, technical considerations, and design elements, to each user story. This provides clarity and context for implementation.
User story mapping helps teams visualize the user journey and identify the minimum viable product (MVP) or the most valuable features to deliver early. It encourages collaboration and alignment among team members and stakeholders, leading to a shared understanding of the product’s scope and objectives. Additionally, it facilitates incremental delivery and allows for adaptation as user feedback is gathered throughout the development process.
Overall, user story mapping is a valuable technique in agile development that promotes user-centric thinking, effective prioritization, and iterative product development.
http://www.extremeprogramming.org/
Extreme Programming (XP) is an agile software development methodology that emphasizes close collaboration, adaptability, and delivering high-quality software. It is known for its focus on customer satisfaction, continuous feedback, and iterative development. XP is designed to enable teams to respond quickly to changing requirements and deliver valuable software in a highly collaborative and flexible manner.
Key principles and practices of Extreme Programming include:
Customer Collaboration: XP promotes active customer involvement throughout the development process. Customers work closely with the development team, providing feedback, clarifying requirements, and making priority decisions.
Iterative and Incremental Development: XP follows an iterative and incremental approach, breaking the development process into small, manageable cycles called iterations or sprints. Each iteration includes requirements gathering, design, coding, testing, and customer feedback.
Small, Empowered Teams: XP advocates for small, self-organizing teams that have the autonomy to make decisions and take ownership of their work. The team members collaborate closely, share knowledge, and collectively take responsibility for the quality and success of the software.
Continuous Integration: XP emphasizes frequent integration of code changes into a shared codebase. Developers integrate their code multiple times a day, enabling early detection and resolution of integration issues.
Test-Driven Development (TDD): Test-Driven Development is a core practice in XP. Developers write automated tests before writing the corresponding code. This approach helps drive the development process, ensures code quality, and supports refactoring.
Pair Programming: XP encourages pair programming, where two developers work together at a single workstation. One developer writes the code while the other reviews it in real-time. This practice fosters knowledge sharing, improves code quality, and reduces the risk of mistakes.
Continuous Delivery: XP promotes the continuous delivery of working software. The goal is to have a production-ready software system at the end of each iteration, allowing for frequent releases and faster feedback from customers.
Refactoring: XP recognizes the importance of refactoring code to improve its design, maintainability, and performance. Refactoring is an ongoing activity that ensures the codebase remains clean and adaptable.
Sustainable Pace: XP emphasizes maintaining a sustainable pace of work. It encourages realistic work hours, avoiding overwork, and ensuring a healthy work-life balance for team members.
By embracing these principles and practices, XP enables teams to deliver high-quality software that meets customer needs in a dynamic and collaborative environment. It fosters adaptability, transparency, and continuous improvement throughout the development process.