Editing Requirements engineering

{{Short description|Defining and maintaining requirements in systems engineering}}
{{Close paraphrasing|source=|date=September 2020}}
{{Use American English|date = March 2019}}
{{Use mdy dates|date = March 2019}}

'''Requirements engineering''' ('''RE''')<ref>{{Cite conference | doi = 10.1145/336512.336523| title = Requirements engineering: a roadmap| work = Proceedings of the conference on the future of Software engineering| conference= [[International Conference on Software Engineering|ICSE]]'00| pages = 35–46| year = 2000| last1 = Nuseibeh | first1 = B. | last2 = Easterbrook | first2 = S. | isbn = 1-58113-253-0| citeseerx = 10.1.1.131.3116| url = http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf}}</ref> is the process of defining, documenting, and maintaining [[requirement]]s<ref>
*{{cite book |last1=Kotonya |first1=Gerald |last2=Sommerville |first2=Ian |author-link2=Ian Sommerville (academic) |title=Requirements Engineering: Processes and Techniques |date=September 1998 |publisher=[[John Wiley & Sons]] |isbn=978-0-471-97208-2 |url-access=registration |url=https://archive.org/details/requirementsengi1998koto }}
*{{Cite book | doi = 10.1007/978-1-4614-5377-2| title = Requirements Engineering and Management for Software Development Projects| year = 2013| last1 = Chemuturi | first1 = M. | author-link1 = Murali Chemuturi| isbn = 978-1-4614-5376-5| s2cid = 19818654}}</ref> 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",<ref>{{cite conference |last1=Dresner |first1=K. H. Borchers  |title=Maintenance, maintainability, and system requirements engineering |work=SAE Technical Paper 640591 |conference=[[SAE International|SAE World Congress & Exhibition]] 1964 |year=1964 |doi=10.4271/640591 }}</ref> but it did not come into general use until the late 1990s with the publication of an [[IEEE Computer Society]] tutorial<ref>{{cite book |editor-last1=Thayer |editor-first1=Richard H. |editor-last2=Dorfman |editor-first2=Merlin |title=Software Requirements Engineering |edition=2nd |publisher=[[IEEE Computer Society Press]] |date=March 1997 |isbn=978-0-8186-7738-0 |url-access=registration |url=https://archive.org/details/softwarerequirem2000unse }}</ref> 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]],<ref>{{cite conference |last1=Royce |first1=W. W. |author-link1=Winston W. Royce |title=Managing the Development of Large Software Systems: Concepts and Techniques |work=Proceedings of the 9th international conference on Software Engineering |conference=[[International Conference on Software Engineering|ICSE]]'87 |pages=1–9 |year=1970 |url=http://www.serena.com/docs/agile/papers/Managing-The-Development-of-Large-Software-Systems.pdf}}</ref> 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.

== Activities ==
The activities involved in requirements engineering vary widely, depending on the type of system being developed and the organization's specific practice(s) involved.<ref>{{cite book |last1=Sommerville |first1=Ian |author-link1=Ian Sommerville (academic) | title=Software Engineering | edition=9th |year=2009 |publisher=[[Addison-Wesley]] |isbn=978-0-13-703515-1}}</ref> These may include:

#[[Requirements inception]] or [[requirements elicitation]] – Developers and stakeholders meet; the latter are inquired concerning their needs and wants regarding the software product.
#[[Requirements analysis]] and negotiation – Requirements are identified (including new ones if the development is iterative), and conflicts with stakeholders are solved. Both written and graphical tools (the latter commonly used in the design phase, but some find them helpful at this stage, too) are successfully used as aids. Examples of written analysis tools: [[use case]]s and [[user story|user stories]]. Examples of graphical tools: [[Unified Modeling Language]]<ref>{{cite web|url=http://tynerblain.com/blog/2008/03/06/requirements-class-diagrams-1/|title=Uncovering Requirements With UML Class Diagrams Part 1|date=7 March 2008|website=tynerblain.com|access-date=14 March 2018}}</ref> (UML) and [[Lifecycle Modeling Language]] (LML).
#[[System modeling]] – Some engineering fields (or specific situations) require the product to be completely designed and modeled before its construction or fabrication starts.  Therefore, the design phase must be performed in advance. For instance, blueprints for a building must be elaborated before any contract can be approved and signed. Many fields might derive models of the system with the [[Lifecycle Modeling Language|LML]], whereas others, might use [[Unified Modeling Language|UML]]. Note: In many fields, such as software engineering, most modeling activities are classified as design activities and not as requirement engineering activities.
#[[Requirements specification]] – Requirements are documented in a formal artifact called a Requirements Specification (RS), which will become official only after validation. A RS can contain both written and graphical (models) information if necessary. Example: [[Software requirements specification]] (SRS).
#[[Requirements validation]] – Checking that the documented requirements and models are consistent and meet the stakeholder's needs. Only if the final draft passes the validation process, the RS becomes official.
#[[Requirements management]] – Managing all the activities related to the requirements since inception, supervising as the system is developed, and even until after it is put into use (e. g., changes, extensions, etc.)

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.<ref name="HofmannLehner2001">{{cite journal|last1=Hofmann|first1=H.F.|last2=Lehner|first2=F.|title=Requirements engineering as a success factor in software projects|journal=IEEE Software|volume=18|issue=4|year=2001|pages=58–66|issn=0740-7459|doi=10.1109/MS.2001.936219}}</ref>

==Problems==
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.<ref>{{Cite journal| title=Naming the pain in requirements engineering: A design for a global family of surveys and first results from Germany| journal=[[Information and Software Technology]] | date=2015 | pages=616–643 | volume=57 | doi=10.1016/j.infsof.2014.05.008 | first1=Daniel | last1=Méndez Fernández | first2=Stefan | last2=Wagner | arxiv=1611.04976 | s2cid=1924926 }}</ref>

==Criticism==
Problem structuring, a key aspect of requirements engineering, has been speculated to reduce design performance.<ref>{{cite journal|last1=Ralph|first1=Paul|last2=Mohanani|first2=Rahul|title=Is Requirements Engineering Inherently Counterproductive?|date=May 2015|publisher=IEEE|url=https://www.researchgate.net/publication/272793687|doi=10.13140/2.1.3831.6321}}</ref> 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 <ref>{{Cite journal| doi=10.1007/s00766-012-0161-4 | title=The illusion of requirements in software development| journal=Requirements Engineering | volume=18 | issue=3 | pages=293–296| date=September 2013| last=Ralph | first=P. | arxiv=1304.0116| bibcode=2013AIPC.1516..293R| s2cid=11499083}}</ref>

==See also==
*[[List of requirements engineering tools]]
*[[Requirements analysis]], requirements engineering focused in software engineering.
*[[Requirements Engineering Specialist Group]] (RESG)
*[[International Requirements Engineering Board]] (IREB)
*[[International Council on Systems Engineering]] (INCOSE)
*[[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]]
*[[Software quality|Software Quality]]
*[[Quality management|Quality Management]]
*[[Scope (project management)|Scope Management]]

==References ==
{{reflist}}

==External links==
* {{cite book | year = 2011 | journal = Iso/Iec/IEEE 29148:2011(E) | pages = 1–94 | isbn = 978-0-7381-6591-2  | doi = 10.1109/IEEESTD.2011.6146379 | url = https://ieeexplore.ieee.org/document/6146379 | title = Systems and software engineering -- Life cycle processes --Requirements engineering }}("This standard replaces IEEE 830–1998, IEEE 1233–1998, IEEE 1362-1998 - https://standards.ieee.org/ieee/29148/5289/")
* [http://sebokwiki.org/ Systems Engineering Body of Knowledge]
* [https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/AR-08-32.pdf Requirements Engineering Management Handbook] by FAA
*[https://ireb.org International Requirements Engineering Board (IREB)]
*[https://web.archive.org/web/20140310072616/http://spectrum.ieee.org/static/ibm-rational-resource-library IBM Rational Resource Library] by [[IEEE Spectrum]]

{{Systems engineering}}
{{Software engineering}}
{{IEEE standards}}
{{ISO standards}}

{{Authority control}}

[[Category:Systems engineering]]
[[Category:Software requirements]]
[[Category:IEEE standards]]
[[Category:ISO/IEC standards]]