We are all familiar with the idea of requirements for software. Developers rarely have direct contact with the one who wants to solve some problem. Usually, some dedicated people such as requirements analysts, business analysis, or product managers, talk to customers and generalize outcomes of such conversations in the form of functional requirements.

Requirements can have different forms, from large documents called requirements specification to more agile means like user stories. Let's have a look at this example:

As you can see, this statement only describes the solution. We cannot possibly know what the user is doing and what problem out system will be solving. Additional requirements might be specified, further refining the solution, but the problem description is never included in functional requirements.

In contrast, with user stories, we have more insight into what our user wants. Let's review this real-life user story: As a warehouse manager; I need to be able to print a stock level report; So I can order items when they are out of stock. In this case, we have some thoughtful insight on what our user wants. However, this user story already dictates what developers need to do. It is describing the solution. The real problem is probably that the customer needs a more efficient procurement process, so they never run out of stock. Or, they need an advanced purchase forecasting system, so they can improve throughput without piling additional inventory in their warehouse.

Requirements became so notorious that if you search for an image using keywords software requirements, the second result in Google Images would be this picture:

We shall not think that requirements are waste. There are many excellent analysts out there, who produce high-quality requirements specifications. However, it is vital to understand, that these requirements are almost always, represent the understanding of the actual problem, of a person who wrote these requirements. A misconception that spending more and more time and money on writing higher quality requirements prevails in the industry.

However, lean and agile methodologies embrace more direct communication between developers and end users. Understanding the problem by everyone involved in building software, from end users to developers and testers, finding solutions together, eliminating assumptions, building prototypes for end users to evaluate—these things are being adopted by successful teams, and as we will see later in the book, they are also closely related to DDD.