Requirements and Story Writing

Learn what ubiquitous language is and how it translates to efficient task documentation.

In this lesson, I will refer to a story and a requirement interchangeably since they both denote an “ask” that the software development team needs to implement. While Agile practitioners create stories and non-iterative processes call them “requirements,” this lesson does not aim to emphasize process differences but rather focus on techniques for writing effective asks for engineering groups.

Ubiquitous language - What is it, and why is it important?

Before we go any further, I encourage you to become familiar with the concept of ubiquitous language; otherwise, some pieces of advice that I give below may be hard to understand.

Usually, writing a program is like dealing with a foreign language; developers write code, and non-technical people (e.g., domain experts) have a hard time understanding it. At first sight, everything seems as it is supposed to be; we have domain experts on one side and engineers on the other. They all do what they are good at. Domain experts know the problem that needs to be solved, and engineers can come up with a solution. If you follow this process, as simple as it sounds, you will describe a problem in one language and solve it in another. Maybe this outcome seems fine to you because we compared programming to a foreign language above, but consider complications that it causes:

  • When a domain expert speaks, engineers need to deal with a constant mental overhead to translate from business into technical terms to implement a new requirement or change existing behavior in the program. This burden causes a slight slowdown throughout the entire process and, thus, incurs costs. Furthermore, since it is ...