Requirements engineering
![]() |
It has been suggested that Software requirements be merged into this article. (Discuss) Proposed since February 2015. |
Requirements engineering (RE)[1] refers to the process of defining, documenting and maintaining requirements[2][3] to the sub-fields of systems engineering and software engineering concerned with this process.
The first use of the term requirements engineering was probably in 1979 in a TRW technical report[4] but did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial[5] and the establishment of a conference series on requirements engineering that has evolved into the current International Requirements Engineering Conference.
In the waterfall model,[6] requirements engineering is presented as the first phase of the development process. Later software development methods, including the Rational Unified Process (RUP), assume that requirements engineering continues through the lifetime of a system.
Requirement management, which is a sub-function of Systems Engineering practices, is also indexed in the INCOSE (International Council on Systems Engineering) manuals.
Contents
Requirements engineering activities[edit]
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.[7] These may include:
- Requirements inception or requirements elicitation -
- Requirements identification - identifying new requirements
- Requirements analysis and negotiation - checking requirements and resolving stakeholder conflicts
- Requirements specification (e.g., software requirements specification; SRS) - documenting the requirements in a requirements document
- Systems modeling - deriving models of the system, often using a notation such as the Unified Modeling Language (UML) or the Lifecycle Modeling Language (LML)
- Requirements validation - checking that the documented requirements and models are consistent and meet stakeholder needs
- Requirements management - managing changes to the requirements as the system is developed and put into use
These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities.
Problems[edit]
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.[8]
Criticism[edit]
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. [9] Some research suggests that software requirements are often an illusion misrepresenting design decisions as requirements in situations where no real requirements are evident.[10]
See also[edit]
- Alan M. Davis's extensive bibliography of requirements engineering.
- Requirements Engineering Specialist Group (RESG)
- International Requirements Engineering Board (IREB)
- IEEE 12207 "Systems and software engineering – Software life cycle processes"
- TOGAF (Chapter 17)
- Concept of operations (ConOps)
- Operations management
- Software requirements
- Software requirements specification
- Software Engineering Body of Knowledge (SWEBOK)
- Design specification
- Specification (technical standard)
- Formal specification
References[edit]
- ^ Nuseibeh, B.; Easterbrook, S. (2000). Requirements engineering: a roadmap (PDF). ICSE'00. Proceedings of the conference on the future of Software engineering. pp. 35–46. CiteSeerX 10.1.1.131.3116
. doi:10.1145/336512.336523. ISBN 1-58113-253-0.
- ^ Kotonya, Gerald; Sommerville, Ian (September 1998). Requirements Engineering: Processes and Techniques. John Wiley & Sons. ISBN 0-471-97208-8.
- ^ Chemuturi, M. (2013). Requirements Engineering and Management for Software Development Projects. doi:10.1007/978-1-4614-5377-2. ISBN 978-1-4614-5376-5.
- ^ Software Requirements Engineering Methodology (Development) Alford, M. W. and Lawson,J. T. TRW Defense and Space Systems Group. 1979.
- ^ Thayer, Richard H.; Dorfman, Merlin, eds. (March 1997). Software Requirements Engineering (2nd ed.). IEEE Computer Society Press. ISBN 0-8186-7738-4.
- ^ Royce, W. W. (1970). Managing the Development of Large Software Systems: Concepts and Techniques (PDF). ICSE'87. Proceedings of the 9th international conference on Software Engineering. pp. 1–9.
- ^ Sommerville, Ian (2009). Software Engineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
- ^ Méndez Fernández, Daniel; Wagner, Stefan (2015). "Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany". Information and Software Technology. 57: 616–643. doi:10.1016/j.infsof.2014.05.008.
- ^ Ralph, Paul; Mohanani, Rahul (May 2015). "Is Requirements Engineering Inherently Counterproductive?". IEEE.
- ^ Ralph, P. (September 2013). "The illusion of requirements in software development". Requirements Engineering. 18 (3): 293–296. doi:10.1007/s00766-012-0161-4.
External links[edit]
- 29148-2011 - Systems and software engineering — Life cycle processes — Requirements engineering. 2011. pp. 1–94. doi:10.1109/IEEESTD.2011.6146379. ISBN 978-0-7381-6591-2.("This standard replaces IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998 - http://standards.ieee.org/findstds/standard/29148-2011.html")
- Systems Engineering Body of Knowledge