 |
This article contains close paraphrasing of non-free copyrighted sources. Relevant discussion may be found on the talk page. Please help rewriting it with your own words. (September 2020) (Learn how and when to remove this message)
|
Requirements engineering (RE)[1] is the process of defining, documenting, and maintaining requirements[2] in the engineering design process. It is a common role in systems engineering and software engineering.
The first use of the term requirements engineering was probably in 1964 in the conference paper "Maintenance, Maintainability, and System Requirements Engineering",[3] but it did not come into general use until the late 1990s with the publication of an IEEE Computer Society tutorial[4] in March 1997 and the establishment of a conference series on requirements engineering that has evolved into the International Requirements Engineering Conference.
In the waterfall model,[5] requirements engineering is presented as the first phase of the development process. Later development methods, including the Rational Unified Process (RUP) for software, assume that requirements engineering continues through a system's lifetime.
Requirements management, which is a sub-function of Systems Engineering practices, is also indexed in the International Council on Systems Engineering (INCOSE) manuals.
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the organization's specific practice(s) involved.[6] These may include:
These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities.
Requirements engineering has been shown to clearly contribute to software project successes.[8]
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.[9]
Problem structuring, a key aspect of requirements engineering, has been speculated to reduce design performance.[10] Some research suggests that it is possible if there are deficiencies in the requirements engineering process resulting in a situation where requirements do not exist, software requirements may be created regardless as an illusion misrepresenting design decisions as requirements [11]
{{cite journal}}: Cite journal requires |journal= (help)
{{cite book}}: |journal= ignored (help)("This standard replaces IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 - http://standards.ieee.org/findstds/standard/29148-2011.html")|
ISO standards by standard number
| |
|---|---|
List of ISO standards – ISO romanizations – IEC standards | |
| 1–9999 |
|
| 10000–19999 |
|
| 20000–29999 |
|
| 30000+ |
|
| |
