## 3 State of the Art
### Requirements Management
#### 3.1.3 Requirements Management in Industry  
Today, elaborate software packages for requirements management are available; best known are the products Teamcenter Systems Engineering [27], Rational DOORS [28], and Serena Dimensions RM [29]. A profound overview of requirements engineering tools is given by [PERSON] et al. [30]. These systems share the objective to support requirements management in distributed environments. Meanwhile, the exchange format ReqIF (an XML file format) is a widely accepted standard for the lossless exchange of requirements between different systems. Further information about ReqIF can be found in the OMG specification [31] or in [3]. For some years now, open source tools for requirements management have been made available, e.g., \"RMF/ProR\" [32] or the Requirements Editor RED ([33]--download under DTU [34]). Figure 6 shows the requirements of a gear system for light trains modelled in the Requirements Editor RED. Additionally, in industrial practice, classical office tools, such as Microsoft Word(r) and Excel(r), are used in order to support requirements management. Figure 6: Requirements of a light train gear system modelled in the Requirements Editor RED. In the last decade, several research projects analyzed the reality of requirements management in industrial practice. [PERSON] and [PERSON] [PERSON] and [PERSON] (2007) conducted a study in three diverse engineering companies. They formulated three key insights:  
* Two fundamentally different types of \"customers\" need to be distinguished: the \"real\" customer and the \"virtual\" customer. The virtual customer is a representative class of individuals \"who might be satisfied by some product whose design will satisfy a collection of design requirements\" [PERSON] and [PERSON] (2007). * Two principal identifiable roles of design requirements exist: serving as an agreement that is desired in an end product, and providing a basis from which the designer can proceed in synthesizing a solution. * A problem/solution bias of requirements exists: the extent to which the solution itself plays a part in the expression of the design requirement can be represented in a continuum between \"only problem\" and \"strongly solution-influenced\". [PERSON] et al. [PERSON] et al. (2010) studied the development of a passenger car cockpit. They were able to condense a number of concrete recommendations such as to \"elaborate a concise, over-arching cross-system requirements specification providing a summary of the most important requirements\". In the analyzed project, a standardized design prerequisites document was used and perceived as a well-functioning document to present important issues for the development. A case study carried out by [PERSON] et al. [PERSON] et al. (2010) underlines that specifications represent a central element in the product development process because they provide vital information for design engineers. It also became apparent that specifications could be developed in response to the product's usage. The vision would be a method that will identify requirements that design engineers really need to execute their task. [PERSON] and [PERSON] [PERSON] and [PERSON] (2007) report from a case study and a large-scale survey. They found out that:  
* design requirements require comprehensive information from multiple sources,
* requirements for users and from users are always mixed up,
* end user requirements are critical and crucial to the success of product development,
* user sources for requirements are very complex, and
* user identification is necessary. [PERSON] and [PERSON] [PERSON] and [PERSON] (2007) were investigating amongst other facets of requirements management in the application of the Kano model for this purpose, and found out that it can shed light on divergences between different stakeholders. In the presented studies, no special focus on the digital mapping of requirements to the product model was given.