The first use of the term requirements engineering was probably in 1964 in the conference paper "Maintenance, Maintainability, and System Requirements Engineering" but did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial, in March 1997, and the establishment of a conference series on requirements engineering that has evolved into the current International Requirements Engineering Conference.
Requirement management, which is a sub-function of Systems Engineering practices, is also indexed in the INCOSE (International Council on Systems Engineering) manuals.
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved. These may include:
These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities.
One limited study in Germany presented possible problems in implementing requirements engineering and asked respondents whether they agreed that they were actual problems. The results were not presented as being generalizable but suggested that the principal perceived problems were incomplete requirements, moving targets, and time boxing, with lesser problems being communications flaws, lack of traceability, terminological problems, and unclear responsibilities.
There is no evidence that requirements engineering contributes to the success of software projects or systems. Problem structuring, a key aspect of requirements engineering, decreases design performance. Some research suggests that software requirements are often an illusion misrepresenting design decisions as requirements in situations where no real requirements are evident.