Editing Requirements engineering (section)

== 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>