Requirements definition, prototyping, and modeling
Requirements engineering is more difficult now, because all systems that were easy to specify have been built some time ago.
T. DeMarco [DeMa01]
In this chapter, we explain why the definition of requirements can be a very critical aspect of any project. Recognizing its limitations and pitfalls, and taking the proper precautions, can reduce the risks of any development project. For this, more than any other activity, a purely technical view is not sufficient.
2.1 Definitions and importance
Requirements definition is the process that determines the properties a particular system should have. The requirements process generates the information on which the design will be based. For this, you have to know where a system is to be used, by whom, and what services it should provide.
It is also important to determine what trade-offs can be made in case of conflicting requirements. We assume that each system has a set of useful functions that are crucial for its success.
The concern for the importance of requirements definition arose rather late in our industry. Firstly, there was the concern for implementation languages, then for verification and testing, and finally for design and requirements definition. This corresponds to the personal evolution of most people. Only after they feel that they have the final activities under control do they look for potential problems in the early activities. As biologists say,
‘Ontogeny repeats phylogeny’, the development of the individual repeats that of the species.
The parties participating in the requirements definition process are collectively referred to as stakeholders. If the system is being built for a known customer, requirements may be the basis for a development contract. If the customer is initially unknown, the marketing organization may assume this function. At first, requirements are discussed at the application level. It is