Software systems are built to satisfy some kind of need to a group of consumers (final users or customer). Understanding those needs is one of most challenging problems in software engineering due to the fact that it is quite common that consumer needs are nebulous (especially in the early stages of the project). Moreover, it is also common that these needs can be deeply changed throughout the project lifetime. Fred Brooks, a well-known software engineer, and computer scientist, defines this problem in his seminal book The Mythical Man-Month (1975):

In any case, consumer's needs are the touchstone for any software project. From these needs, a list of features can emerge. We define a feature as a high-level description of a software system functionality. From each feature, one or more requirements (functional and non-functional) should be derived. A requirement is everything that be true about the software, in order to meet the consumer's expectations. Scenarios (real-life examples rather than abstract descriptions) can be useful for adding details to the requirements description. The group of requirements and/or list of features of the software system are often known as specification.

In software engineering, the stage of defining the requirements is called requirements elicitation. In this stage, software engineers need to clarify what problem they are trying to solve. At the end of this phase, it is a common practice to start the modeling of the system. To that aim, a modeling language (typically UML) is employed to create a group of diagrams. The UML diagrams, which typically fits in the elicitation stage is the use case diagram (model of the functionality of the system and its relationship with the involved actors).

After elicitation, requirements should be refined in the analysis stage. In this phase, the stated requirements are analysed in order to resolve incomplete, ambiguous of contradictory issues. As a result, in this stage it is likely to continue modeling, using for example high-level class diagrams not linked to any specific technology yet. Once the analysis is clear (that is, the what of the system), we need to find out how to implement it. This stage is known as design. In the design phase, the guidelines of the project should be established. To that aim, an architecture of the software system is typically derived from the requirements. Again, the modeling techniques are broadly employed to carry out different aspects of the design. There is a bunch of UML diagrams that can be used at this point, including structural diagrams (component, deployment, object, package, and profile diagram) and behavioral diagrams (activity, communication, sequence, or state diagram). From the design, the actual implementation (that is, coding) can start.

The amount of modeling carried out in the design stage varies significantly depending on different factors, including the type and size of the company producing the software (multinationals, SMEs, governmental, and so on), the development process (waterfall, spiral, prototyping, agile, and so on), the type of project (enterprise, open source, and so on), the type of software (custom made software, commercial off-the-shelf, and so on), and even the background of the people involved (experience, career, and so on). All in all, the designs need to be understood as a way of communication between the different roles of software engineers participating in the project. Typically, the bigger the project, the more necessary a fine-grained design based on different modeling diagrams is.

Concerning tests, in order to make a proper test plan (see next section for further details), again we need to use the requirements elicitation data, that is, the list of requirements and/or features. In other words, in order to verify our system, we need to to know beforehand what we expect from it. Using the classic definition proposed by Barry Boehm (see chapter 1, Retrospective On Software Quality And Java Testing), verification is used to answer the question Are we building the product right? To that, we need to know the requirements, or at least, the desired features. In addition to verification, it would be desirable to carry out some validation (according to Boehm: Are we building the right product?). This is necessary since sometimes there is a gap between what has been specified (the features and requirements) and the real needs of the consumer. Therefore, validation is a high-level assessment method, and to carry out it, the final consumer can be involved (validating the software system once it is deployed). All these ideas are depicted in the following picture:

To illustrate the potential problems involved in the different phases in software engineer (analysis, design, implementation, and so on), it is worth to review the classical cartoon How project really works? The original source of this picture is unknown (there are versions dating back to the 1960s). In 2007, a site called Project Cartoon emerged (http://www.projectcartoon.com/), allowing to customize the original cartoon with new scenes. The following chart is the version 1.5 of the cartoon provided on that site:

If we think about this picture, we discover that the root of the problems comes from the requirements, badly explained by the customer at the beginning, and worst understood by the project leader. From that point, the whole software engineering process turns into the Chinese whispers children game. To solve all these problems is out of the scope of this book, but as a good start, we need to take special care in the requirements, which guide the whole process, including, of course, the tests.