In Chapter 1, The Requirements Domain, we learned how to identify stakeholders and goals. This is a crucial step in our analysis process, but in order to store and share our analytical findings, we must be able to represent these entities and their associations in a simple yet understandable manner. In other words, we want to model our requirement entities, and a great way of doing that is by using impact maps.

Introduction to impact mapping

Back in 2012, Gojko Adjiz defined the concept of impact maps, a technique that he evolved from UX-based effect-mapping methods in order to improve communication, collaboration, and interaction in teams and organizations.

Simply put, an impact map is a tree graph with four levels, where each level of the tree represents an answer to some fundamental questions about our system:

• Why are we building the system?
• Who benefits from it?
• How can the stakeholders achieve their goals?
...

In Chapter 1, The Requirements Domain, we identified two of the main entities in the requirements domain: stakeholders and goals. In the previous section about impact mapping, we saw how these entities slot perfectly into an impact map. It's time now to look at the other two main entities that constitute the requirements domain and how they are all represented within an impact map.

In the Introduction to impact mapping section earlier in this chapter, we saw how the third and fourth levels of an impact map correspond to the business and system impacts of a stakeholder's effort to accomplish their goal, respectively. We shall define the business impact as a capability. A capability is a stakeholder's required ability to do something with our system in order to reach their goal. We shall define the system impact as a feature. A feature is a system functionality or behavior required in order to support a capability. Let's now...

In this section, we will be introduced to BDD, as it forms an essential part of the methodology described in this book. BDD was first introduced as a concept by Dan North back in 2006 (refer to Further reading link #2), as a way to improve communication and collaboration and to facilitate behavior-based automated testing. BDD is often referred to as an outside-in development methodology, as it focuses on system behavior required by the stakeholders as the driving mechanism for developing software. This well-defined system behavior is referred to as a feature in BDD parlance.

Since North's original article, BDD has matured and evolved and now has a rich ecosystem supporting it, with tools such as Cucumber, SpecFlow, and JBehave appearing in many a developer's tool-belt. Gojko Adjiz (yes, him again) helped solidify BDD principles in his book Specification by Example (refer to Further reading link #4). As a result, some people actually use the terms BDD and...

Let's now take a look at the main type of requirements we are going to encounter and how we will be dealing with them. In the use cases and examples we have used so far, we have encountered requirements that influence what the system should do or how it should behave. In our pizza example, we talked about the actors selecting toppings for the pizza, choosing a delivery slot, and other such functionalities or behaviors. These are commonly known as functional requirements and we've already seen how we can represent these in a requirements model by identifying goals, stakeholders, capabilities, and features. But let's now consider some different requirements that don't focus on interactions between the system and its actors but on internal system operations instead: Non-Functional Requirements (NFRs).

Let's suppose that the pizza company wants our system to display all 50 available toppings...

In this chapter, we defined and distilled two more requirement domain entities: capabilities and features. We learned how to use them alongside goals and stakeholders in order to model our requirements in a requirements model, using impact mapping. Knowing what these four entities are about and how they are related is the first step in the requirements management workflow that we'll be detailing in this book. We already started exploring the mental process we'll be using to analyze requirements and break them down into these four entities. We'll be delving in greater detail into how this mental process works in Chapter 5, Discovering and Analyzing Requirements, in the Discovering Requirements section, where we will also be applying effective techniques to help us discover and analyze requirements.

This chapter also introduced BDD. BDD is what we do after we have discovered and analyzed our requirements. Specifically, BDD will help us refine our requirements...

1. Gojko Adzic, Impact Mapping: Making a Big Impact with Software Products and Projects, ISBN-10: 0955683645
2. Dan North, Introducing BDD: https://dannorth.net/introducing-bdd
3. John Ferguson Smart, BDD in Action: Behavior-driven development for the whole software lifecycle, Manning Publications, 1st edition, ISBN-10: 161729165X
4. Gojko Adzic, Specification by Example: How Successful Teams Deliver the Right Software, Manning Publications, 1st edition, ISBN-10: 1617290084

   Mike Cohn, User Stories: https://www.mountaingoatsoftware.com/agile/user-stories