Get in touch
Fast, up-to-date, and stable. What do all of these adjectives have in common? They describe something, but they depend on context. Only their context provides them with their specific meaning.
If you’re talking about a bicycle, going 20 km/hr seems fast, however in a car not so much. On December 26, 1952, when the German news broadcast Tagesschau appeared on TV for the first time, the news was up-to-date. Today, news is only up-to-date when it’s updated every couple of minutes. An Internet provider calls the availability of a website stable when it is functional 96 to 98% of the time. But would you call the online platform Facebook stable if it were unavailable 7 days a year?
Working with requirements poses substantial challenges for all participants. In the beginning, the requirements must be recorded correctly. Then they must be passed on (correctly) to all participants so that everyone has the same level of knowledge. Even as the requirements are first passed along, initial errors can arise. We’ll examine here what the risks are and how they can be minimized.
Requirements are passed along in a communication process. As everybody knows, communication between parties often results in misunderstandings. This is due, among other things, to the experiences that we have gathered in our lives, whether because individuals come from different cultures or because they work in different specialized areas. Based on their knowledge, experiences, and the resulting assumptions, people perceive situations differently and interpret them subjectively.
Let’s take the following requirement as an example:
“Creation of a means to protect a small group of people against the hostile elements in their environment. [1]”
If I lived at the North Pole, I could interpret this as follows:
If I lived in the Middle Ages, however, things might look entirely different:
And if I were a sailor, surely things would look like this:
When passing along requirements (in the agile environment, these are summarized in “user stories”) to all participants, it is possible that the following errors will occur [2]:
The product owner presents the user stories in the backlog refinement. All the people participating in the meeting discuss the requirements. After that, the team discusses the information using different forms of communication. For the team members, this produces a huge quantity of information and raises many questions, some of which are quite detailed. The team consists of different personalities with different specialized roles. Each of these participants has their own specific previous knowledge and therefore has a different focus on the user story presented. If something is completely clear to the product owner, for example, this doesn’t necessarily mean that it will be just as clear to the other participants. The developer can skip over a piece of information or interpret it incorrectly. Things are observed incorrectly but not documented, which then causes people to remember things incorrectly, which can cause deviations in the implementation.
The sprint begins. The developer wants to implement a user story. In the process, someone notices that information is missing. In the backlog refinement, the user story was clear and thus it was also clear what had to be done. What happened? The backlog refinement was done two weeks ago, and in the meeting, additional information was exchanged verbally, information that no one documented. However, the user story only makes sense with the additional information.
If the developer notices that information is missing, there is still time to procure it. The situation is more serious if facts are interpreted incorrectly due to a lack of information and as a consequence, the requirements are implemented according to a different idea. This can be the beginning of a chain of errors.
Communication frequently leaves room for interpretation.
“I don’t know what I said before I didn’t hear the other person’s answer.”
This quote by Norbert Wiener puts things in a nutshell.
I know what information I wanted to communicate to my counterpart, however I don’t know how that person interpreted it in the end. Among other things, interpretation errors can arise for the following reasons:
In North America, it is common to maintain a distance of one-and-a-half arm’s length from one’s conversation partner on formal occasions. In Latin America, by contrast, this distance is cut in half. If a North American is talking to a Latin American, the North American always moves a step back from and the Latin American moves a step toward their conversation partner [3]. In addition to cultural differences, differences in the specialized areas can cause interpretation errors. The same terms may be used, but depending on the specialized area, they may mean different things. In addition, one and the same situation is perceived differently by each individual and thus subjectively.
Every software developer is familiar with the expression “code smells,” which was introduced by Martin Fowler in his book “Refactoring: Improving the Design of Existing Code.” Less familiar is the expression “requirements smells.” [4] “Requirements smells” refers to characteristics of imprecise language in the form of ambiguity, which often results in interpretation errors. Below we present two examples of “requirements smells”:
Can you still remember the requirement at the beginning of this article with regard to protecting a group, the one that caused an interpretation error? If so, then write it down now. Then check whether what you wrote matches what you remember. Even minimal deviations in the problem statement can lead to different solutions. If in the example “protect a small group of people” the requirement becomes “protect a group,” this can result in an entirely different solution that does not fit this group’s problem.
Precisely with agile procedural models, there are methods that the team can use optimally to minimize the risks presented. Let’s take the example of backlog refinement. Before backlog refinement, the team can distribute the individual stories that will be discussed in the meeting to individual “story heroes.” They can then analyze the stories purposefully for “requirements smells.” On the one hand, the advantage is that the developers familiarize themselves with the stories in advance; on the other hand, the developers can imagine the stories themselves in backlog refinement. As a result, the product owner can identify observation errors, memory errors, interpretation errors, and ambiguity in the problem statement fast(er) and clarify matters immediately.
The highest priority in software development is to avoid errors. Because the requirements form the basis of the software development process,
if
arise, these can persist throughout the software development process. The later the errors are discovered, the higher the costs to eliminate them. The optimal state is to identify and correct the risks presented before the implementation. Investing time in correction pays off since a common understanding of the requirements reduces the work time and costs during development and shortens the time to implementation. One possibility for doing this is the introduction of “story heroes” as suggested above.
Images: Unsplash
