applied sciences

Article Model-Based Requirements Management in Gear Systems Design Based On Graph-Based Design Languages

Kevin Holder 1, Andreas Zech 2, Manuel Ramsaier 2 ID , Ralf Stetter 2,*, Hans-Peter Niedermeier 1, Stephan Rudolph 3 and Markus Till 2

1 ZF Friedrichshafen AG, 88046 Friedrichshafen, Germany; [email protected] (K.H.); [email protected] (H.-P.N.) 2 Fakultät Maschinenbau, Hochschule Ravensburg-Weingarten, 88250 Weingarten, Germany; [email protected] (A.Z.); [email protected] (M.R.); [email protected] (M.T.) 3 Statik und Dynamik der Luft- und Raumfahrtkonstruktionen, Universität Stuttgart, 70569 Stuttgart, Germany; [email protected] * Correspondence: [email protected]; Tel.: +49-751-501-9822

Received: 30 August 2017; Accepted: 25 October 2017; Published: 27 October 2017

Abstract: For several decades, a wide-spread consensus concerning the enormous importance of an in-depth clarification of the specifications of a product has been observed. A weak clarification of specifications is repeatedly listed as a main cause for the failure of product development projects. Requirements, which can be defined as the purpose, goals, constraints, and criteria associated with a product development project, play a central role in the clarification of specifications. The collection of activities which ensure that requirements are identified, documented, maintained, communicated, and traced throughout the life cycle of a system, product, or service can be referred to as “requirements engineering”. These activities can be supported by a collection and combination of strategies, methods, and tools which are appropriate for the clarification of specifications. Numerous publications describe the strategy and the components of requirements management. Furthermore, recent research investigates its industrial application. Simultaneously, promising developments of graph-based design languages for a holistic digital representation of the product life cycle are presented. Current developments realize graph-based languages by the diagrams of the Unified Modelling Language (UML), and allow the automatic generation and evaluation of multiple product variants. The research presented in this paper seeks to present a method in order to combine the advantages of a conscious requirements management process and graph-based design languages. Consequently, the main objective of this paper is the investigation of a model-based integration of requirements in a product development process by means of graph-based design languages. The research method is based on an in-depth analysis of an exemplary industrial product development, a gear system for so-called “Electrical Multiple Units” (EMU). Important requirements were abstracted from a gear system specification list and were analyzed in detail. As a second basis, the research method uses a conscious expansion of graph-based design languages towards their applicability for requirements management. This expansion allows the handling of requirements through a graph-based design language model. The first two results of the presented research consist of a model of the gear system and a detailed model of requirements, both modelled in a graph-based design language. Further results are generated by a combination of the two models into one holistic model.

Keywords: graph-based design language; requirements engineering; life-cycle engineering; gear systems design; digital product development

Appl. Sci. 2017, 7, 1112; doi:10.3390/app7111112 www.mdpi.com/journal/applsci Appl. Sci. 2017, 7, 1112 2 of 24

1. IntroductionAppl. Sci. 2017, 7, 1112 2 of 24

Requirements1. Introduction are a decisive factor in industrial product development (compare e.g., [1]). Four of ten top risks in projects are connected with requirements [2]. Analyses of industrial product Requirements are a decisive factor in industrial product development (compare e.g., [1]). Four developmentof ten top projects risks in showed projects that are only connected 52 percent with ofre thequirements originally [2]. allocated Analyses requirements of industrial appearproduct in the finaldevelopment released version projects of showed the product that only [3]. 52 Obviously, percent of product the originally development allocated engineers requirements are challengedappear in with managingthe final released the requirements version of ofthe their product products, [3]. Obviously, as the described product research development is mainly engineers motivated are by thischallenged challenge. with There managing is a prominent the requirements need inof industrytheir products, for efficient as the described and effective research requirements is mainly managementmotivated methods by this and challenge. tools. However,There is a the prominent complicatedness need in andindustry complexity for efficient of current and effective products aggravaterequirements such approaches. management Therefore, methods and an importanttools. However, research the questioncomplicatedness arises: and How complexity can product of developmentcurrent products engineers aggravate efficiently such and approaches. effectively Therefore, manage theiran important requirements? research One question possible arises: approach How can becan through product graph-based development design engineers languages. efficiently The an uniqued effectively contribution manage of their the presentedrequirements? research One is the in-depthpossible investigation approach can of be the through feasibility graph-based and the advantagesdesign languages. of this Th kinde unique of approach. contribution of the Graph-basedpresented research languages is the havein-depth gained investigation rising attention of the feasibility in the past and years. the advantages Graph-based of this means kind thatof approach. the nodes of a graph are used as an abstract placeholder for real objects and that, instead of the design Graph-based languages have gained rising attention in the past years. Graph-based means that object, a graph representation is processed by machines (i.e., computers). Central approaches use the nodes of a graph are used as an abstract placeholder for real objects and that, instead of the design visual,object, graph-based a graph design representation languages is processed formulated by in ma UMLchines (Unified (i.e., computers). Modelling Central Language), approaches which allowuse both thevisual, creation graph-based of new engineeringdesign langua modelsges formulated and the in reuse UML of (Unified pre-existing Modelling engineering Language), models which and know-how.allow both The the use creation of the UMLof new as engineering an abstract models representation and the reuse of theof pre-existing future product engineering to be designedmodels allowsand for know-how. the consistent The use integration of the UML of as various an abstract disciplinary representation domain of the models. future product The state to be of designed the art of graph-basedallows for design the consistent languages integration is described of various in Section disciplinary 3.2. The researchdomain models. presented The in state this of paper the art is leadof on thegraph-based example of andesign industrial languages product, is described a gear in system Section for 3.2. so-called The research “Electrical presented Multiple in this Units”paper is (EMU), lead whichon are the commonly example appliedof an industrial in trams, product, suburban a gear trains, system or high-speed for so-called railway “Electrical vehicles. Multiple In accordance Units” with the(EMU), product which development are commonly process applied stage in trams, of the suburb samplean trains, project, or thehigh-speed research railway is mainly vehicles. focused In on stagesaccordance of the product with the developmentproduct development process process in which stag importante of the sample requirements project, the are research already is mainly defined. focused on stages of the product development process in which important requirements are already For the sake of clarifying the scope of the research, the product development process can be described defined. For the sake of clarifying the scope of the research, the product development process can be by the model in Figure1. described by the model in Figure 1.

Figure 1. Clarification of the scope of the research. Figure 1. Clarification of the scope of the research. This model consists of an illustration of five main process steps. In the first step, “Customer ThisNeeds” model are consists collected of and an illustration clarified. These of five can main be processtransformed steps. into In thea product first step, specification “Customer that Needs” is are collectedgenerated and in clarified.a second Thesestep, “Requirements”. can be transformed Based intoon specific a product “Requirements”, specification a that specific is generated design in a secondapproach step, (“Geometry “Requirements”. Synthesis”) Based can onbe specificcarried out. “Requirements”, A further step a of specific the design design process approach is (“Geometry“Simulation”, Synthesis”) and within can be this carried step, product out. A furtheranalysis stepprocesses of the are design carried process out by means is “Simulation”, of simulation and Appl. Sci. 2017, 7, 1112 3 of 24 withinAppl. this Sci. step, 2017, product7, 1112 analysis processes are carried out by means of simulation preprocessor,3 of 24 solver, Appl. Sci. 2017, 7, 1112 3 of 24 and postprocessor, such as the Finite Element Methods (FEM) or Computational Fluid Dynamics (CFD). preprocessor, solver, and postprocessor, such as the Finite Element Methods (FEM) or Computational It is important to note that further steps of the product life cycle are not shown in this simple model. Fluidpreprocessor, Dynamics solver, (CFD). and It ispostprocessor, important to notesuch thatas the further Finite steps Element of the Methods product (FEM) life cycle or Computational are not shown In theinFluid presented this Dynamics simple research, model. (CFD). In the It the is scope important presented was onto research, note the processthat the further scope steps steps was “Requirement” of on the the product process and life steps cycle “Geometry “Requirement” are not shown Synthesis”. Thereandin is this no “Geometry doubtsimple thatmodel. Synthesis”. strategies, In the presentedThere methods, is research,no and doubt tools the th whichatscope strategies, was help on determine methods,the process and steps clarifytools “Requirement” which the “end-user” help customerdetermineand “Geometry needs and are clarify alsoSynthesis”. a promisingthe “end-user” There fieldis nocustomer for doubt research. thneedsat strategies, However, are also methods,a due promising to the and nature fieldtools for ofwhich theresearch. analyzedhelp productHowever,determine development dueand toclarify the processes, nature the “end-user” of the the later analyzed stepscustomer prod were uctneeds chosen development are as also a focus a processes,promising of the presentedthe field later for steps research.research. were However, due to the nature of the analyzed product development processes, the later steps were Thechosen rest as of a focus this paperof the presented is structured research. as follows (compare Figure2): The research method for the chosen as a focus of the presented research. investigationThe ofrest the of feasibilitythis paper andis structured the advantages as follows of (compare a model-based Figure approach2): The research is described method infor Section the 2. The rest of this paper is structured as follows (compare Figure 2): The research method for the Sectioninvestigation3 contains the of the state feasibility of the art and in the the advantages scientific fields of a model-based “requirements approach management” is described and in “graph-based Section 2.investigation Section 3 contains of the feasibility the state and of the advantagesart in the scientific of a model-based fields “requirements approach is described management” in Section and design languages”. The main analytical part in the investigation, the analysis of an industrial product “graph-based2. Section 3 contains design languages”.the state of Thethe artmain in analyticalthe scientific part fields in the “requirements investigation, management”the analysis of and an development process, is reported in Section4. Section5 describes the first research result, a model of industrial“graph-based product design development languages”. process, The main is reported analytical in Section part in 4. the Section investigation, 5 describes the the analysis first research of an the sampleresult,industrial producta model product of in the development a graph-based sample product process, design in ais graph- language.reportedbased in TheSectiondesign second 4.language. Section research 5 The describes second result, the research a generalfirst research result, model of requirements,aresult, general a model ismodel explained of of the requirements, sample in Section product 6is. explained A in validation a graph- in Sebasedction is achieved design6. A validation language. by combining is Theachieved second the by model research combining of theresult, the sample productmodela general and of the modelthe general sample of requirements, modelproduct of and requirements; is the explained general inmodel this Section combination of requirements6. A validation is described; this is achieved combination in Section by combining is7 described. In Section the 8, ; the researchinmodel Section of results the 7. Insample Section are discussed product 8, the andresearch and the an general results initial model validationare discussed of requirements in and industry an initial this is reported. combinationvalidation in is industry described is reported.in Section 7. In Section 8, the research results are discussed and an initial validation in industry is reported.

FigureFigure 2. 2.Structure Structure of the the paper. paper. Figure 2. Structure of the paper. 2. Research Method 2. Research2. Research Method Method The described research is generally based on the Design Research Methodology (DRM) Theframework describedThe described as presented research research isby generally Blessing is generally and based Chakrabarti based on the on Design [4].the InDesign Research this framework, Research Methodology fourMethodology general (DRM) stages (DRM) framework of as presentedresearchframework bycan Blessingas be presented distinguished and by Chakrabarti Blessing (compare and [Figure4 ].Chakrabarti In this3). framework, [4]. In this four framework, general four stages general of research stages of can be distinguishedresearch can (compare be distinguished Figure3). (compare Figure 3).

Figure 3. Four stages of the design research methodology (compare [4] and [5]). FigureFigure 3. Four 3. Four stages stages of of the the design design researchresearch methodology (compare (compare [4] [and4] and [5]). [ 5]). Appl. Sci. 2017, 7, 1112 4 of 24

Appl. Sci. 2017, 7, 1112 4 of 24 The presented research focuses on an investigation of a novel approach (graph-based design languagesThe forpresented requirements research management). focuses on an Thisinvestig canation be characterized of a novel approach as a research (graph-based project typedesign five (comparelanguages [4] for and requirements [5]). Here, management). product development This can be support characterized is created as a research on the basis project of type a detailed five generation(compareof [4] product and [5]). development Here, product process development understanding, support andis created is initially on the evaluated. basis of Thea detailed research clarificationgeneration is of based product on development the state of the process art (compare understanding, Section 3and). This is initially analysis evaluated. led to the The formulation research of theclarification central researchis based thesis:on the state It is possibleof the art to (compare enable effective Section 3). and This efficient analysis requirements led to the formulation engineering inof industrial the central companies research thesis: by means It is possible of the applicationto enable effective of graph-based and efficient design requirements languages. engineering The first descriptivein industrial study companies is carried by out means by a detailedof the application analysis of of an graph-based industrial productdesign languages. development The process first (comparedescriptive Section study4). is The carried prescriptive out by a detailed study is analys carriedis of out an intensively industrial product and results development in two models process in graph-based(compare Section design 4). languages The prescriptive and their study combination is carried (compare out intensively Section 5and to Sectionresults 7in). two The models evaluation in andgraph-based validation design by means languages of a second and their descriptive combination study (compare is performed Section 5 to in Section an initial 7). The manner evaluation for this and validation by means of a second descriptive study is performed in an initial manner for this kind kind of research project, and consists of a test of the general applicability of the approach and expert of research project, and consists of a test of the general applicability of the approach and expert interviews in the concerned industrial company (compare Section8). Obviously, the research type interviews in the concerned industrial company (compare Section 8). Obviously, the research type five (compare [4] and [5]) cannot really prove a research thesis, but it can indicate that the application five (compare [4] and [5]) cannot really prove a research thesis, but it can indicate that the application of product development support is logically sound and carries some process improvement potential. of product development support is logically sound and carries some process improvement potential. A reflection of the research structure in the structure of this paper is shown in Figure4. A reflection of the research structure in the structure of this paper is shown in Figure 4.

FigureFigure 4. 4.Research Research structurestructure and structure structure of of this this paper. paper.

3. State of the Art 3. State of the Art This section presents the state of the art in two scientific fields, which were combined in the This section presents the state of the art in two scientific fields, which were combined in the presented research: requirements management and graph-based design languages. presented research: requirements management and graph-based design languages. 3.1. Requirements Management 3.1. Requirements Management 3.1.1. Research Activities Concerning Requirements Management 3.1.1. Research Activities Concerning Requirements Management An overwhelming amount of literature describing requirements management and requirements An overwhelming amount of literature describing requirements management and requirements engineering can be found; it is therefore impossible to present a complete picture. A very good engineering can be found; it is therefore impossible to present a complete picture. A very good overview of earlier research can be found in Darlington and Culley [6] and Jiao and Chen [7]; current overview of earlier research can be found in Darlington and Culley [6] and Jiao and Chen [7]; current additions are shown, e.g., by Zhang et al. [8]. It is important to note that international standards which additionsare concerned are shown, with requirements e.g., by Zhang management et al. [8]. Italso is importantexist: most tonotable note thatare the international ISO standard standards 29148 which“Systems are concerned and software with engineering—Life requirements management cycle processes—Requirements also exist: most notable engineering” are the ISO[9] and standard the 29148ISO “Systemsstandard 15288 and software [10] “Systems engineering—Life and softwarecycle engineering—Systems processes—Requirements life cycle engineering”processes”, as [well9] and theas ISO the standard recently 15288revised [ 10quality] “Systems management and software norm engineering—SystemsISO 9001 [11]. Furthermore, life cycle current processes”, research as welladdresses as the recently frameworks revised for qualityproduct managementlifecycle integration norm ISO[8], requirements 9001 [11]. Furthermore, change prediction current models research addresses[12], systematic frameworks determinati for producton of lifecycleproduct properties integration [13], [8], and requirements requirements change checklists prediction [14]. More models and [12 ], more research is concerned with requirements management in industrial settings. Appl. Sci. 2017, 7, 1112 5 of 24 systematic determination of product properties [13], and requirements checklists [14]. More and more research is concerned with requirements management in industrial settings. Requirements can be defined as the purpose, goals, constraints, and criteria associated with a product development project [12]. These requirements may range from the initial functional requirements to the detailed specifications [15]. Several classification schemes for requirements were proposed in literature (compare Bühne and Herrmann [16]). Zhang et al. [8] propose a lifecycle-view-based classification in only three categories: (1) BOL—Beginning of Life, including planning, design, and production) related requirement; (2) MOL—(Middle of Life, including use, service and maintenance) related requirement; and (3) EOL—(End of Life, including reuse, material reclamation and disposal) related requirements. A large body of research is concerned with the fuzzy front-end of product development: the transformation of the customer needs into requirements. Closely connected are approaches of qualitative and quantitative market research, which are often referred to as voice of the customer (VOC) studies. Early research reports in the 1990s [17] already identify four main aspects: customer needs, a hierarchical structure of the needs, priorities of the needs, and customer perceptions of performance. Several research studies are concerned with the integration of the voice of the customer into the subsequent processes of product development. For this integration, a number of models, methods, and tools were analyzed, such as the Kano model [18], CAD, and TRIZ [19], as well as virtual customer environments [20]. A focus on Collaborative Product Development/Definition and Management (CPDM) solutions for sharing, archiving, and managing customer needs (amongst other product information) can be identified as well (compare e.g., [21]). Salado and Nilchiani [22] were able to establish categorization models of requirements which are based on a well-known model of human needs. The proposed categorization model supports elicitation of requirements and facilitates the detection of requirements that are not relevant to the system and of constraints that limit the solution trade-space without supporting the satisfaction of new needs. Several authors use the notion “requirements engineering”. A number of different definitions exist which try to distinguish the notions of “requirements engineering” and “requirements management”, but these terms can be used synonymously [17]. In this paper, requirements management and requirements engineering are understood in a holistic sense as a systematic and disciplined approach for specifying and managing requirements with the following objectives:

• to identify the relevant requirements, achieve consensus between the stakeholders, document the requirements in accordance with given standards, and manage the requirements in an systematic manner; • to understand and document the wishes and needs of the stakeholders; and • to specify and manage requirements in order to minimize the risk that a system will not correspond to the wishes and needs of the stakeholders (compare Bühne and Herrmann [16]).

Similarly, the ISO standard 29148 [9] defines requirements management as “activities that ensure requirements are identified, documented, maintained, communicated, and traced throughout the life cycle of a system, product, or service”.

3.1.2. Stages in Requirements Management In order to structure the later discussion in this paper, a model was developed on the basis of requirements engineering process models (compare e.g., [23,24]), which allows for distinguishing different stages in requirements management (Figure5). Appl. Sci. 2017, 7, 1112 6 of 24 Appl. Sci. 2017, 7, 1112 6 of 24

documentation of collection of requirements requirements

testing of structuring of requirements requirements requirements management tracking of classification of requirements requirements

prioritizing of assuring the requirements consistency of requirements

Figure 5.5. Stages in the requirements managementmanagement processprocess cycle.cycle.

TheThe mainmain stagesstages areare brieflybriefly explainedexplained inin remainingremaining partpart ofof thisthis sub-section.sub-section.

CollectionCollection ofof RequirementsRequirements AA startingstarting point point of theof requirementsthe requirements management manage processment mightprocess be themight collection be the of requirements,collection of thoughrequirements, this step though may bethis repeated step may again be repeated and again again during and theagain process during of the product process development. of product Thedevelopment. collection The of requirementscollection of requirements may include may an applicationinclude an application of methods of such methods as user such surveys, as user benchmarking,surveys, benchmarking, or quality functionor quality deployment function (QFD).deploy Inment this (QFD). stage, the In voicethis ofstage, the customerthe voice plays of the an extremelycustomer importantplays an extremely role (compare important e.g., [19 ]).role It is(compa importantre e.g., to note[19]). that It requirementsis important specificationsto note that canrequirements never fully specifications cover all aspects can ofnever an envisaged fully cover product all aspects [25]. of an envisaged product [25].

StructuringStructuring ofof RequirementsRequirements TheThe notionnotion “structuring“structuring ofof requirements”requirements” maymay includeinclude activitiesactivities whichwhich areare intendedintended toto arrangearrange largerlarger listslists ofof requirementsrequirements intointo somesome kindkind ofof sensiblesensible structure.structure. The structuring of requirementsrequirements isis important,important, becausebecause thethe collectioncollection ofof requirementsrequirements forfor complexcomplex systemssystems maymay bebe vast,vast, andand anan overviewoverview andand handlinghandling of of the the large large set ofset requirements of requirements usually usually requires requires some structure,some structure, e.g., the producte.g., the structure product. structure. Classification of Requirements ClassificationSeveral literature of Requirements sources recommend a classification of requirements; important aspects maySeveral be the general literature type sources (functional recommend requirement, a classifica qualitytion of requirement, requirements; or important structural aspects requirement), may be thethe solutiongeneral dependencetype (functional (goal requirement, oriented requirements, quality requirement, scenario-oriented or struct requirementsural requirement), or solution the orientedsolution requirements),dependence (goal or the oriented abstraction requirements level (compare, scenario-oriented Bühne and Herrmann requirements [16]). Furthermore, or solution Becattinioriented etrequirements), al. [14] and Salado or the andabstraction Nilchiani level [22] (compare also present Bühne structures and Herrma for classification.nn [16]). Furthermore, Becattini et al. [14] and Salado and Nilchiani [22] also present structures for classification. Assuring the Consistency of Requirements AssuringAssuring the Consiste the consistencyncy of Requirements of requirements includes activities which are intended to find contradictionsAssuring betweenthe consistency requirements of requirements (these contradictions includes activities need to bewhich resolved) are intended and to identifyto find competitivecontradictions requirements. between requirements In industrial (these practice, contra thesedictions activities need areto be extremely resolved) important and to identify [1] and shouldcompetitive be started requirements. early. In industrial practice, these activities are extremely important [1] and should be started early. Prioritizing Requirements

PrioritizingIn the case Requirements of competitive requirements, a prioritization of requirements is necessary. Here, it is crucially important to bring up conflicts and to find and document compromises, especially with In the case of competitive requirements, a prioritization of requirements is necessary. Here, it is respect to industrial practice [1]. crucially important to bring up conflicts and to find and document compromises, especially with respect to industrial practice [1]. Appl. Sci. 2017, 7, 1112 7 of 24 Appl. Sci. 2017, 7, 1112 7 of 24 Tracking of Requirements

TrackingThe oftracking Requirements of requirements (compare requirements traceability [26]) is a central element of requirements management. It is immensely important that the requirements can be clearly identified The tracking of requirements (compare requirements traceability [26]) is a central element of during the whole product development process, and that a version and change management process requirements management. It is immensely important that the requirements can be clearly identified for requirements is in place [16]. during the whole product development process, and that a version and change management process Testingfor requirements of Requirements is in place [16]. TestingOne of might Requirements argue that the testing of requirements is a major part of a product development project and cannot be seen as part of the requirements management. It is, however, a very important One might argue that the testing of requirements is a major part of a product development project aspect of requirements management that these crucial activities are supported in an optimum and cannot be seen as part of the requirements management. It is, however, a very important aspect of manner, and that the requirements are readily available in a consistent, plausible form for the analysis requirements management that these crucial activities are supported in an optimum manner, and that activities. the requirements are readily available in a consistent, plausible form for the analysis activities.

Documentation of Requirements The structured documentation of requirements is a main challenge because usual requirements management systems lack an updated representationrepresentation of thethe productproduct structure.structure.

3.1.3. Requirements Management in Industry Today, elaborateelaborate softwaresoftware packagespackages for requirements management are available; best known are the products Teamcenter Systems Engineering [27] [27],, Rational DOORS [28], [28], and Serena Dimensions RM [[29].29]. A profoundprofound overviewoverview of of requirements requirements engineering engineering tools tools is givenis given by Carrilloby Carrillo de Geade Gea et al. et [30 al.]. [30].These These systems systems sharethe share objective the ob tojective support to requirements support requirements management management in distributed in environments. distributed environments.Meanwhile, the Meanwhile, exchange formatthe exch ReqIFange (anformat XML ReqIF file format)(an XML is file a widelyformat) accepted is a widely standard accepted for standardthe lossless for exchange the lossless of requirementsexchange of requiremen between differentts between systems. different Further systems. information Further aboutinformation ReqIF aboutcan be ReqIF found can in be the found OMG in specification the OMG specification [31] or in [ 3[3].1] For or in some [3]. For years some now, years open now, source open tools source for toolsrequirements for requirements management management have been madehave been available, made e.g., available, “RMF/ProR” e.g., “RMF/ProR” [32] or the Requirements [32] or the RequirementsEditor RED ([33 Editor]—download RED ([33]—do under DTUwnload [34 under]). Figure DTU6 shows [34]). Figure the requirements 6 shows the of requirements a gear system of for a gearlight system trains modelled for light trains in the modelled Requirements in the Editor Requirements RED. Editor RED.

Figure 6. RequirementsRequirements of a light trai trainn gear system modelled in the Requirements Editor RED.

® ® Additionally, inin industrialindustrial practice, practice, classical classical office office tools, tools, such such as Microsoftas Microsoft Word Word® and and Excel Excel®, are, areused used in order in order to support to support requirements requirements management. management. Appl. Sci. 2017, 7, 1112 8 of 24

In the last decade, several research projects analyzed the reality of requirements management in industrial practice. Darlington and Culley [6] 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” [6]. • 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”.

Almefelt et al. [25] 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 Sudin et al. [35] 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. Li and Ahmed-Kristensen [36] 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.

Borgianni and Rotini [37] 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. This aspect will be addressed with an analysis of the situation in an industrial company (compare next section) and the proposal of model-based requirements management (Section5).

3.2. Graph-Based Design Languages The authors are working on a superordinate research project. The aim of the research is the holistic integrated digital description of the product life cycle. The product life cycle includes many technical disciplines (e.g., requirement management, design, engineering, simulation, production, costing, maintenance, etc.) and therefore requires cooperation from many people and the interaction with many software tools. On the technical side, this integration process is currently focusing on complex PLM software systems which aim to achieve the integration. In some partial technical disciplines, immense efforts are realized by research and industry on the part of software development in order to promote this integration. These immense efforts result in numerous publications addressing the product modelling issues. Even graph-based approaches were analyzed since the early nineties (compare Finger and Rinderle [38]). Several research publications focus on product life cycles, such as Le Duigou and Bernard [39], and on integrated product and process models (for an excellent overview, see Eckert et al. [40]). The distinctive approach in this project is the application of an engineering Appl. Sci. 2017, 7, 1112 9 of 24 framework of graph-based design languages, which allows the reuse of pre-existing engineering Appl. Sci. 2017, 7, 1112 9 of 24 models and know-how. Thethe application concept of of graph-based an engineering design framework languages of graph-based (see e.g., Rudolph design languages, [41]) has evolvedwhich allows over the the last ten yearsreuse intoof pre-existing a generic engineering framework models for the and definition know-how. of computerized design processes. Generally, a graph isThe a representationconcept of graph-based of a set design of objects languages where (see some e.g., Rudolph pairs of [41]) objects has evolved are connected over the bylastlinks. The interconnectedten years into a generic objects framework are represented for the bydefinition mathematical of computerized abstractions design that processes. can be Generally, called “nodes”, a and thegraph connections is a representation are as well of a set represented of objects wher by abstractionse some pairs thatof objects can beare called connected “edges”, by links. which The may be directedinterconnected or undirected. objects are On represented the basis of by prior mathematic work,al Rudolph abstractions [42] that developed can be called a consistent “nodes”, system and to representthe connections geometry andare as other well formsrepresented of information by abstractions using that graphs, can be and called has built“edges”, a graph-based which may be design directed or undirected. On the basis of prior work, Rudolph [42] developed a consistent system to language. In principle, design languages consist of a meta-model that stores all relevant parametrical represent geometry and other forms of information using graphs, and has built a graph-based design and topologicallanguage. Indesign principle, information design languages and acts consist as a of centralized a meta-model model that repositorystores all relevant [42]. parametrical Theseand topological graph-based design design information languages and acts are as a realized centralized with model UML repository (Unified [42]. Modelling Language). UML is theThese primary graph-based modelling design language languages in computer are realized science. with UML Computer (Unified science Modelling is known Language). for its very fast developmentUML is the primary cycles, modelling which require language very in computer powerful science. abstract Computer description science forms is known (modern for its graphicalvery modellingfast development languages) cycles, for the which software require development very powerful process abstract and description highly automated forms (modern development graphical tools to achievemodelling these languages) extremely for short the innovationsoftware developme cycles.nt UML process has beenand highly developed automated by software development engineers and providestools to achieve many features these extremely to model short data innovati in orderon to cycles. describe UML object-oriented has been developed software by [43 software]. The latest versionengineers of UML and 2.5 provides was released many infeatures June 2015.to model data in order to describe object-oriented software [43]. The latest version of UML 2.5 was released in June 2015. It is one main hypothesis in this project that the product development processes for conventional It is one main hypothesis in this project that the product development processes for conventional projectsprojects can greatlycan greatly profit profit from from the basicthe basic ideas ideas and and theories theories behind behind these these automated automated development development tools. The basictools. structureThe basic ofstructure the application of the application of the graph-based of the graph-based design design language language selected selected in this in researchthis projectresearch is illustrated project is in illustrated Figure7. in Figure 7.

FigureFigure 7. Application 7. Application of of a a graph-based graph-based design language language (compare (compare Rudolph Rudolph [44]). [44 ]).

In this graph-based design language, the engineering objects are represented by UML classes In(the this vocabulary graph-based of a design design language), language, and the model engineering transformations objects are are represented represented by rules, by UML i.e., the classes (the vocabularygrammar of ofthe a design design language. language), In a and so-called model “pro transformationsduction system”, are the represented rules are specified by rules, by the i.e., the grammarengineer of theand designlater executed language. in order In ato so-calledinstantiate “production the vocabulary system”, classes. Whereas the rules the are UML specified class by the engineerdiagram can and be later seen executedas a blueprint in orderof all possible to instantiate products the (e.g., vocabulary all multi-stage classes. planar Whereas gear systems), the UML classthe diagram design cangraph be resulting seen as from a blueprint the execution of all of possiblethe production products system (e.g., represents all multi-stage a specific product planar gear systems),(e.g., thegear design system graph for customer resulting x with from two the gear execution stages). ofThis the execution production process system builds represents up the central a specific data model, also referenced as the “Design Graph”. From this high-level central data model, different product (e.g., gear system for customer x with two gear stages). This execution process builds up interfaces generate domain-specific models, such as geometry models or simulation models (CAD, the centralCFD, FEM, data etc.) model, fully alsoautomated referenced with no as user the inte “Designraction. Graph”. One main From advantag thise high-level of this central central data data model,model different consists interfaces in the information generate domain-specificcontent, which is not models, limited such to geometry as geometry definition, models but or can simulation also modelsinclude (CAD, abstract CFD, information FEM, etc.) concerning fully automated physical with loads, no materials, user interaction. functions, One or other main aspects. advantage By this of this centralapproach, data model it is possible consists to in address the information a multitude content, of programs which in isengineering not limited product to geometry development definition, but can also include abstract information concerning physical loads, materials, functions, or other Appl. Sci. 2017, 7, 1112 10 of 24 aspects. By this approach, it is possible to address a multitude of programs in engineering product Appl. Sci. 2017, 7, 1112 10 of 24 development processes. The central benefit of graph-based requirements management based on UML is theprocesses. consistent The interconnectioncentral benefit betweenof graph-based structural, requirements geometric, management functional, andbased physical on UML information. is the consistentOne important interconnection advantage between in structural, this project geom isetric, the functional, availability and of physical the “DesignCompiler43”. information. This compilerOne important is developed advantage by the in IILS this mbH project (http://www.iils.de is the availability) in of cooperation the “DesignCompiler43”. with the University This of Stuttgart,compiler which is developed is one of by the the cooperation IILS mbH partners (http://www.ii in this project.ls.de) in DesignCompiler43cooperation with the is anUniversity eclipse-based of softwareStuttgart, tool which for the is one compilation of the cooperation of design partners languages in formulatedthis project. inDesignCompiler43 UML. The design is compileran eclipse- can processbased designsoftware languages tool for the on compilation all abstraction of desig levelsn languages to the full detailformulated of the in simulation UML. The models.design compiler This leads tocan a fully process automated design languages process within on all a abstraction unified framework. levels to the The full work detail on of DesignCompiler43 the simulation models. is ongoing, This butleads many to importanta fully automate functionalitiesd process arewithin already a unified available framework. in the current The work version. on DesignCompiler43 is ongoing,The application but many ofimportant a graph-based functionalities design languageare already and available the usage in the of UMLcurrent diagrams version. in this process is explainedThe application in Figure8 .of a graph-based design language and the usage of UML diagrams in this process is explained in Figure 8.

Figure 8. Application of a graph-based design language and usage of Unified Modelling Language Figure 8. Application of a graph-based design language and usage of Unified Modelling Language (UML) diagrams. (UML) diagrams. As stated above, the main elements of a graph-based design language are vocabulary and rules. VocabularyAs stated are above, UML-based the main components, elements of e.g., a graph-based the Gearbox designitself or languageone of its areshafts vocabulary (Shaft). Rules and are rules. VocabularyUML model are transformations: UML-based components, these show e.g., the theinput Gearbox status (only itself orcar) one on ofthe its left shafts side (Shaft).(LHS) and Rules the are UMLoutput model state transformations: on the right side these (LHS—Gearbox show the input with statusconnected (only Shaft—see car) on the Figure left side1). The (LHS) engineer and the outputcreates state the UML on the model, right which side (LHS—Gearbox compiles the program with connectedinto a design Shaft—see graph, from Figure which,1). for The example, engineer createsthe geometry the UML of model, the product which compilescan be derived. the program Vocabulary into a designand rules graph, are from linked which, in a forso-called example, the“production geometry of system” the product (UML can activity be derived. diagram). Vocabulary Through and the rulesdesign are compiler, linked in the a so-called rules are “production executed system”to instantiate (UML activitythe class/vocabulary. diagram). Through This compilation the design process compiler, builds the rulesthe central are executed data model. to instantiate From this the class/vocabulary.central data model, This different compilation interfaces process generate builds domain-specific, the central data model.generic Frommodels, this such central as geometry data model, models or simulation models. This application of graph-based languages allows for the automatic Appl. Sci. 2017, 7, 1112 11 of 24

Appl. Sci. 2017, 7, 1112 11 of 24 different interfaces generate domain-specific, generic models, such as geometry models or simulation models.generation This applicationand evaluation of graph-based of multiple product languages vari allowsants and for is the currently automatic being generation introduced and in evaluation several ofindustrial multipleproduct companies. variants and is currently being introduced in several industrial companies.

4. Analysis4. Analysis of of an an Industrial Industrial Product Product DevelopmentDevelopment Process ThisThis section section presents presents the the results results ofof thethe firstfirst descriptivedescriptive study study in in the the research, research, the the analysis analysis of ofan an industrialindustrial product product development development process. process.

4.1.4.1. Example Example Product: Product: Railway Railway Vehicle Vehicle GearboxesGearboxes The The sample sample product product is is a a gearbox gearbox for for electrical electrical railwayrailway vehicles (Figure (Figure 9).9). Such Such gearboxes gearboxes are are mountedmounted in (pivoted)in (pivoted) bogies bogies of railof rail vehicles vehicles (compare (compa alsore also a 3D a view3D view in [45 in]); [45]); typically typically there there are several are drivenseveral axles driven per axles vehicle. per vehicle.

(a) (b)

Figure 9. (a) Schematic top view of a bogie, main components of railway vehicle gear system; (b) Figure 9. (a) Schematic top view of a bogie, main components of railway vehicle gear system; (b) picture picture of a bogie; photographer: Coronium. of a bogie; photographer: Coronium. The gearboxes are “single-speed reducers” with no possibility to interrupt the powertrain and areThe developed gearboxes for aredifferent “single-speed categories reducers” of EMU. withThe gearboxes no possibility are equipped to interrupt with the typically powertrain 1 up and to 2 are developedgear stages for of different steel gear categories wheels if ofthe EMU. input Theand gearboxesoutput shafts are are equipped on one plane, with typically and up to 1 up3 or to more 2 gear stagesstages of if steel the gearinput wheels and output if the inputshafts andare outputnot on on shaftse plane, are onwhere one plane,the directional and up todeflection 3 or more is stagesdone if thewith input a bevel and output gear or shafts a hypoid are notgear on stage. one plane,Further where subdivision the directional can be done deflection according is done to the with type a bevelof gearmounting or a hypoid in the gear bogie. stage. Either Further a fixed subdivision connection can to bethe done wheel according axle and toa flexible the type coupling of mounting with inthe the bogie.electrical Either motor a fixed shaft connection is possible, to the or wheela fixed axle connect and aion flexible to the coupling electrical with motor the shaft electrical and a motor flexible shaft is possible,coupling to or the a fixed wheel connection axle. On top to of the that, electrical special motor solutions shaft and and mixing a flexible of both coupling types are to implemented the wheel axle. Onin top real of that,products. special In solutionsFigure 8, and a two-stage mixing of gear bothbox types suspended are implemented on the wheel in real axle products. with a In flexible Figure 8, a two-stagecoupling to gearbox the motor suspended shaft is shown. on the wheel axle with a flexible coupling to the motor shaft is shown. InIn the the respective respective company company (ZF(ZF FriedrichshafenFriedrichshafen AG), AG), the the entire entire development development process process with with its its sub-steps is defined, therefore several company-specific instructions and templates are available. For sub-steps is defined, therefore several company-specific instructions and templates are available. the development process, state of the art development tools (CAD, FEM, …) are applied. The main For the development process, state of the art development tools (CAD, FEM, ... ) are applied. The main focus of this investigation was the early process part, which takes place before an actual order or a focus of this investigation was the early process part, which takes place before an actual order or a “Letter of Intent” (LoI) is issued by the customer of the gear system (“Offer to Order process” (OtO)). “Letter of Intent” (LoI) is issued by the customer of the gear system (“Offer to Order process” (OtO)). After the order or LoI, a well-structured stage-gate process is carried out, but even before the product Afterconcept the order has to or be LoI, developed a well-structured in a considerate stage-gate level process of detail. is carriedThis stage out, is butespecially even before challenging, the product as conceptthe basic has decisions to be developed in this stage in a can considerate influence level the whole of detail. success This of stage the development is especially challenging,project. as the basic decisions in this stage can influence the whole success of the development project. Appl. Sci. 2017, 7, 1112 12 of 24

4.2. Requirements Management in the Industrial Company The described research project presented in this paper started with an in-depth analysis of the requirements management process of the company that develops and produces the sample product. At the beginning of the OtO, a technical questionnaire can be used, which helps to define the basic parameters for a customer project. On this basis, the design process can start and an offer can be created and submitted. On the technical side, function parameters in industrial practice can be listed as a basic specification. These parameters can be gear ratio, maximum weight, and geometrical dimensions. In the case of an order or further development, this kind of specification can be used for project planning. The specification is a textual description of the requirements, which concern the environmental conditions of the product and product properties. In addition to the textual descriptions, the environment or interfaces are supplemented by non-textual descriptions, such as drawings and sketches or 3D models of interfering contours. The specifications often include explicitly or implicitly the definition of solving principles or product details. This restriction on certain solutions is mostly based on the experience of predecessors or similar products. The analysis of the specification is done by engineering knowledge (experience). Each related individual clause (each sentence) is evaluated. The evaluation is carried out by a “Clause by Clause” (CbC) analysis in categories, such as “accepted”, “not accepted”, “partly accepted”, “non-applicable”, or additional comments for information. Based on the CbC analysis, a coordination and negotiation process with the vehicle manufacturer (customers) can take place. A scope statement is created and a “project drawing” can be generated. For the customer, the technical solution “transmission with gear wheels” is usually out of the question, so the scope statement contains only the main technical parameters of the transmission (as design criteria e.g., standards and design torque, ... ) and the installation drawing (or/and 3D installation model) which contains e.g., materials or the rough housing shape. The configured gearbox in combination with the experience of previous products is used to calculate the product quotation. The development process with its gates and milestones starts during that part of the initial stage. The analysis of this industrial product development process was concluded with the creation of a requirements database, which can be one initial condition for the development of models for requirements management with graph-based design languages (compare Section 6.1). The content of the database was entirely extracted through CbC analysis from a textual description provided by a customer.

5. Development of a Gear System with a Graph-Based Design Language This section describes the first core result of the research: the composition of a model of the gear system variants during the OtO in a graph-based design language. The first main condition for the approach to connect requirements with the product is a product model with all domains, which are directly specified or necessary to reach the specified target. In this case, it is a product model created by a graph-based design language. At the current stage of research, the development of this model of gear systems is still ongoing. Figure 10 shows a scheme of the creation process of the model. Each model that is modelled in the graph-based design language consists of various classes that are determined by decomposition of a given product model. Based on the UML notation for object-oriented systems, all derived classes can be connected to each other through utilization of association or generalization (compare Figure4). The linked classes form a class diagram (synonymous for vocabulary in Figure7), which represents the product architecture. Consequently, the class diagram shown in Figure 11 is valid for single-speed reducers, as they are common in EMU. Appl. Sci. 2017, 7, 1112 13 of 24 Appl. Sci. 2017, 7, 1112 13 of 24 Appl. Sci. 2017, 7, 1112 13 of 24

Figure 10. Scheme of the development process of a graph-based model for gear systems design Figure 10. Scheme of the development process of a graph-based model for gear systems design variants. Figurevariants. 10. Scheme of the development process of a graph-based model for gear systems design variants.

FigureFigure 11. 11.Simplified Simplified class class diagram diagram ofof aa modelmodel for generating gear gear systems systems design design variants. variants. Figure 11. Simplified class diagram of a model for generating gear systems design variants. For this early phase, only the architecture of the basic components is defined. In this case, it is For this early phase, only the architecture of the basic components is defined. In this case, it is the combinationFor this early of phase, the gear only set the and architecture the gearbox of ho theusing basic into components a whole “Gearbox”, is defined. whereas In this case, the gearit is thetheset combination cancombination be composed of of the the of gear gearany setnumber set and and the ofthe stages, gearboxgearbox each housingho consistingusing into into of a a twowhole whole gearwheels. “Gearbox”, “Gearbox”, For whereas whereasthe gearwheels, the the gear gear setseta can specialization can be be composed composed into of ofa any drivingany number number wheel ofof marked stages,stages, eachwith consisting “GearWheelA” of of two two and gearwheels. gearwheels. driving wheelFor For the themarked gearwheels, gearwheels, with a specializationa“GearWheelB” specialization into isinto implemented. a a driving driving wheel wheel The markedwheelsmarked are withwith moun “GearWheelA”ted on shafts and and(“Shaft”); driving driving the wheel wheel connection marked marked to with the with “GearWheelB”“GearWheelB”“Housing” is isdone is implemented. implemented. by the rolling TheThe “Bearing”. wheelswheels areIn a mountedmounddition,ted a on onspecialization shafts shafts (“Shaft”); (“Shaft”); of shafts the the connectionfor connection the input to and tothe the “Housing”“Housing”output shafts is is done doneis also by by the carriedthe rolling rolling ou “Bearing”.t “Bearing”. (“InputShaft” InIn addition,a ddition,and “WheelSetAxl a a specialization specializatione”). Classesof of shafts shafts which for for the therepresent input input and anda outputoutput shafts shafts is alsois also carried carried out (“InputShaft”out (“InputShaft” and “WheelSetAxle”).and “WheelSetAxl Classese”). Classes which which represent represent a gearbox a component inherit properties of the abstract class “PhysicalComponent” for a geometric representation. Appl. Sci. 2017, 7, 1112 14 of 24 gearboxAppl. Sci. 2017 component, 7, 1112 inherit properties of the abstract class “PhysicalComponent” for a geometric14 of 24 representation. Combined with the class diagram shown, the separate root program (synonymous for rules in FigureCombined 7) leads to with a virtual the class model. diagram The root shown, program the separate contains root the programsteps necessary (synonymous to build for a detailed rules in variantFigure7 of) leads a gear to system a virtual and model. to check The rootthis soluti programons containson the basis the stepsof the necessary collected torequirements. build a detailed The rulesvariant lead of ato gear the systeminstantiation and to checkof classes, this solutions which gi onve thethe basis expression of the collected of various requirements. variants of Thethe rulesgear system.lead to theIn general, instantiation the class of classes, diagram which becomes give prov the expressionided with logic of various through variants the rules of the within gear the system. root program.In general, the class diagram becomes provided with logic through the rules within the root program. InIn Figure Figure 12,12, instances instances of of one one typical typical variant variant of of gear gear system system (depending (depending on on requirement requirement inputs) inputs) are displayed geometrically (on the left left side) side) and and represented represented by a a pronounced pronounced design graph (on (on the the rightright side). side).

Figure 12. Graph of instances which represent the components of one typical variant of gear system Figure(Instance 12. attributes: Graph of instances z = number which of teeth; represent mn = normalthe compon modul;ents b of = width).one typical variant of gear system (Instance attributes: z = number of teeth; mn = normal modul; b = width). 6. Requirements Management with a Graph-Based Design Language 6. Requirements Management with a Graph-Based Design Language This section presents the second core result of the described research: the description of the innovativeThis section approach presents towards the model-based second core requirements result of the management. described research: It describes the description the composition of the of innovativea design language approach for towards requirements model-based management. requirements management. It describes the composition of a design language for requirements management. 6.1. A General Model of Requirements in a Graph-Based Design Language 6.1. A General Model of Requirements in a Graph-Based Design Language One main condition for the approach to connect requirements with the product, which is shown here,One is a main requirement condition model. for the In approach this case, to it isconnect a requirement requirements model with created the product, by a graph-based which is shown design here,language is a requirement (Figure 13). model. In this case, it is a requirement model created by a graph-based design languageThe (Figure class diagram 13). shown in Figure 13 consists of a main class named “Requirement” that includesThe attributesclass diagram ID, Name,shown Description,in Figure 13 Version, consists Status, of a main Unit, class Value, named Comment, “Requirement” RelatedToPart, that includesand RelatedToRequirement attributes ID, Name, (will Description, be used for Versio structuringn, Status, requirements). Unit, Value, Comment, Each of the RelatedToPart, requirements andin the RelatedToRequirement database that was created (will be from used requirementsfor structuring in requirements). the company Each (compare of the Sectionrequirements 4.2) was in thetaken database into account that was and created was illustrated from requirements by model in in the the graph-based company (compare design language. Section 4.2) Consequently, was taken intothese account requirements and was could illustrated be shown by model as “Requirement” in the graph-based instances design within language. the design Consequently, graph after these the requirementscompilation of could the model be shown (compare as Figures“Requirement” 10 and 12 ).instances According within to Ammenwerth the design [46graph], requirements after the compilationare supposed ofto the have model further (compare attributes Figure such 10 as and “evaluation Figure 12). criterion”, According “possible to Ammenwerth characteristics”, [46], “desiredrequirements characteristics”, are supposed “weighting” to have (prioritization),further attributes and such “actual as characteristics”.“evaluation criterion”, Assigning “possible content characteristics”,values to these attributes “desired has characteristics”, to be done by engineering“weighting” knowledge (prioritization), (experience) and “actual during characteristics”. the requirement Assigningcollection phase.content values to these attributes has to be done by engineering knowledge (experience) during the requirement collection phase.

Appl. Sci. 2017, 7, 1112 15 of 24 Appl. Sci. 2017, 7, 1112 15 of 24

Figure 13. Implemented class diagram for classificationclassification andand structuringstructuring ofof databasedatabase requirements.requirements.

Furthermore, FigureFigure 13 contains13 contains a class a “Mission”class “Mission” that has anthat association has an toassociation class “Requirement”. to class “Requirement”“Requirement”. is associated“Requirement” to “Stakeholder” is associated with to classes “Stakeholder” “Contractor” with and classes “Customer”. “Contractor” Both inherit and from“Customer”. “Stakeholder” Both inherit by specialization. from “Stakeholder” by specialization. InIn contrastcontrast toto thethe modelmodel forfor geargear systems, systems, in in which which classes classes are are determined determined by by decomposition decomposition of of a givena given product product model model (compare (compare Section Section5), 5), the the classes classes for for requirements requirements management management are are determined determined according to taxonomies which can can be be derived derived from from literature literature (compare (compare Section Section 4.1). 4.1). That That leads leads to to a aclass class diagram diagram which which contains contains several several approaches approaches for for classifying classifying requirements requirements (Figure 1313;; colorscolors representrepresent taxonomies)taxonomies) additional additional to to the the general general description description of of requirement requirement entities. entities. The The classification classification of requirementsof requirements in model-based in model-based requirements requirements management management is in general is in similar general to existing similar requirements to existing managementrequirements systems.management systems. Until now, fourfour differentdifferent taxonomiestaxonomies areare implementedimplemented (compare(compare FigureFigure 1313).). The firstfirst taxonomy considersconsiders the aspectaspect ofof generalgeneral type,type, implementedimplemented by thethe yellowyellow classesclasses “FunctionalRequirement”,“FunctionalRequirement”, “QualityRequirement”,“QualityRequirement”, andand “StructuralRequirement”.“StructuralRequirement”. The The second second taxonomy takes the solutionsolution dependence into account byby implementationimplementation of greengreen domainsdomains “GoalOrientedRequirement”,“GoalOrientedRequirement”, “ScenarioOrientedRequirement”,“ScenarioOrientedRequirement”, andand “SolutionOrientedRequirement”.“SolutionOrientedRequirement”. According According to to Figure Figure 88,, requirementsrequirements can be classifiedclassified by aa thirdthird taxonomy,taxonomy, whichwhich isis shownshown byby orangeorange coloredcolored domainsdomains (“OnlyTechnicalRequirement”,(“OnlyTechnicalRequirement”, “TechnicalSurrounding”,“TechnicalSurrounding”, “HumanSocietyEnvironment”,“HumanSocietyEnvironment”, “Costs”, “LawsNormsPatentsWarranties”,“LawsNormsPatentsWarranties”, “Time”, “Time”, “Staff”, “Staff”, and and “Aids”). “Aids”). Becattini etet al. al. [14 ][14] propose propose a further a further taxonomy taxonomy (“Geometry-”, (“Geometry-”, “Kinematics-”, “Kinematics-”, “Forces-”, “Energy-”,“Forces-”, “Production-”,“Energy-”, “Production-”, “Material-”, “Signals-”,“Material-”, “Safety-”, “Signals-”, “Ergonomic-”, “Safety-”, “Ergonomic-”, “Qualitycontrol-”, “Qualitycontrol-”, “Assembly-”, “Transport-”,“Assembly-”, “Operation-”,“Transport-”, “Maintenance-”, “Operation-”, “Recycling-”. “Maintenance-”, “Cost-”, and“Recycling-”. “SchedulesRequirement”), “Cost-”, and which“SchedulesRequirement”), is mostly utilized in checklistswhich is mostly for conceptual utilized designin checklists (highlighted for conceptual by red color design in Figure(highlighted 12). by redThe color vocabulary in Figure in12). Figure 13 includes all four taxonomies. However, the experience during the modelingThe vocabulary of the in gear Figure system 13 includes (compare all four Section taxonomies.7) shows However, that the taxonomy the experience introduced during bythe Becattinimodeling et of al. the [14 gear] seems system to be (compare most appropriate Section 7) forshows classification that the taxonomy within the introduced described designby Becattini context. et Furtheral. [14] seems work willto be also most look appropriate into further for taxonomies, classification such within as the the categorization described design model context. presented Further by Saladowork will and also Nichani look [into23]. further taxonomies, such as the categorization model presented by Salado and NichaniA further [23]. purpose of a model of requirements in a graph-based design language can be the structuringA further of requirements purpose of a (comparemodel of Sectionrequirements 4.1). In in order a graph-based to structure design requirements, language all can taxonomy be the classesstructuring are linked of requirements by specialization (compare with Section the main 4.1). classIn order “Requirement”. to structure requirements, Thus, all taxonomy all taxonomy classes inheritclasses theare attributeslinked by of specialization “Requirement”. with As the shown main in class Figure “Requirement”. 12, “Requirement” Thus, has all antaxonomy aggregation classes on itself.inherit Hence, the attributes the attribute of “Requirement”. “RelatedToRequirement” As shown in is ableFigure to be12, implemented“Requirement” as well.has an aggregation on itself. Hence, the attribute “RelatedToRequirement” is able to be implemented as well. Appl. Sci. 2017, 7, 1112 16 of 24 Appl. Sci. 2017, 7, 1112 16 of 24 In addition to structuring requirements according to attributes, requirements may also be structuredIn addition polyhierachically. to structuring A polyhierarchy requirements corre accordingsponds to to attributes, a general requirementsdetailing of requirements. may also be Basically,structured a polyhierarchical polyhierachically. requirements A polyhierarchy model correspondsis able to be torepresented a general by detailing a design of graph requirements. (Figure 14).Basically, a polyhierarchical requirements model is able to be represented by a design graph (Figure 14).

Figure 14. Polyhierarchy of requirements from the database. Figure 14. Polyhierarchy of requirements from the database.

TheThe polyhierarchical polyhierarchical requirements requirements model model may may be be objected objected to to the the application application of of structural structural and and content-relatedcontent-related qualityquality criteria,criteria, as as well well as subsequentas subsequent analyses analyses such assuch clustering, as clustering, dependency dependency analysis, analysis,or missing or requirementsmissing requirements analysis. analysis. TheThe general general purpose purpose of of polyhierarchical polyhierarchical requirements requirements structuring structuring already already was was declared declared by by BecattiniBecattini et et al. al. [10], [10], through through defining defining the the characteristics characteristics (in (in this this context context synonymous synonymous to to quality quality criteria)criteria) that that a a design design specification specification should should have. have. Th Theyey listed listed the the characteristics characteristics validity, validity, completeness, completeness, operationality,operationality, non-redundancy, non-redundancy, conciseness, and practicability. ToTo achieve achieve a a polyhierarchical polyhierarchical requirements requirements model model,, the the requirements requirements database database from from the the sample sample productproduct (compare (compare Section Section 4.2)4.2 )has has been been divided divided into into main-, main-, sub-, sub-, sub-sub-, sub-sub-, and and sub-sub-sub- sub-sub-sub- requirements.requirements. The The main main requirement requirement of a of gear a gear system, system, “transfer “transfer energy”, energy”, is located is located on the on top the layer top (comparelayer (compare Figure Figure14). In general,14). In general,the main therequirem mainent requirement equals the equals root of thethe rootgraph of which the graph represents which therepresents overall thestrategic overall goal; strategic Martin goal; [47] Martincalls it [47“Mission”.] calls it “Mission”.The second Thelayer second contains layer three contains sub- requirementsthree sub-requirements that describe that the describe “gear ratio”, the “gear “torqu ratio”,e conversion”, “torque conversion”, and “speed andconversion”. “speed conversion”. The lower twoThe layers, lower twosub-sub-requirements layers, sub-sub-requirements and sub-sub-sub-requirements, and sub-sub-sub-requirements, maintain the maintain remaining the remainingdatabase requirements.database requirements. Figure 14 shows Figure the po14 lyhierarchicalshows the polyhierarchical graph where, for graph instance, where, one of for the instance, instances one of databaseof the instances requirements of database is highlighted requirements (blue color) is highlighted. The requirement (blue color). with TheID #31 requirement was classified with as ID “KinematicsRequirement”#31 was classified as “KinematicsRequirement” and structured as sub-re andquirement. structured Furthermore, as sub-requirement. content Furthermore,values from requirementcontent values database from requirement are attached database to attributes are attached(e.g., Description to attributes = Gear (e.g., Ratio, Description Name = = Kinematics Gear Ratio, Characteristics,Name = Kinematics Value Characteristics, = 3.6, etc.). Value = 3.6, etc.). 6.2. Application Possibilities of the Model of Requirements 6.2. Application Possibilities of the Model of Requirements In this subsection, application possibilities of the general approach of a model-based requirements In this subsection, application possibilities of the general approach of a model-based management process are explained together with their potential advantages. The structure of the requirements management process are explained together with their potential advantages. The subsection follows the model shown in Figure5. structure of the subsection follows the model shown in Figure 5. Appl. Sci. 2017, 7, 1112 17 of 24

6.2.1. Application in the Collection of Requirements Becattini et al. [14], amongst others, point out that completeness is an important characteristic of sets of requirements for a product. Consequently, the collection of requirements is a crucial step in requirements management. As stated in Section 4.1, main sources for requirements are methods like marketing studies, product clinics, benchmarking, and quality function deployment (QFD). Additionally, earlier products are a main source for requirements, because many products are evolutionary improvements of earlier products, e.g., in automotive industry (compare Almefelt et al. [27]). The general approach of model-based requirements management allows to document the requirements in a strong relation to the sub-systems respective modules of the earlier product. Consequently, this approach can support the extraction of requirements from earlier products that can be reused because the same or similar modules will be used in a future design. Additionally, the stringent logic in model-based requirements management will ease the identification of the crucial requirements in the earlier product models. The developed requirement models of earlier products, which are formulated in graph-based design languages, can also be analyzed in multiple ways. Becattini et al. [14] were able to show that any tools which aim at stimulating reflections can support the generation of non-obvious requirements. Such human reflection can be fostered with requirement models of existing products, but they can also be analyzed by means of search algorithms.

6.2.2. Application in the Structuring of Requirements The handling of a large set of requirements usually requires some structure, e.g., the product structure. Model-based requirements management allows combining the requirements to the product structure, thus providing a straightforward way to structure requirements.

6.2.3. Application in the Classification of Requirements The taxonomies mentioned in the literature (compare Section3) were used as a basis for the class diagram of the design language for requirements management. Further work will also look into further taxonomies, such as the categorization model presented by Salado and Nichani [22].

6.2.4. Application for Assuring the Consistency of Requirements A requirements model, which is integrated in a graph-based life cycle spanning product model, can offer multiple ways for exploring the product and the consistency of requirements. One promising approach is a dependency analysis between the requirements themselves, and also between product and requirement. Firstly, such analyses may allow identifying interdependent requirements which may be contradicting or competitive. Secondly, such analyses may offer the possibility to identify central and isolated requirements as well as active and passive requirements.

6.2.5. Application for Prioritizing Requirements Bernard and Irlinger [1] were able to identify the activities which serve for prioritizing competitive requirements as crucial for the success of leading producing companies. Frequently, this prioritization requires detailed knowledge about rather concrete properties and performance parameters of the future product or system. Systems which are based on graph-based design languages can assist the generation of such knowledge, for instance, by means of sensitivity analyses. For instance, the system for the early phase of the development of gear systems (compare Section3) allows an automated or semi-automated generation of conceptual product variants and their analysis and evaluation by means of state-of-the-art simulation tools. Such simulation results for multiple solution variants can present an excellent basis for discussions leading to well-founded systems of priorities for product performance parameters and properties. Graph-based design languages can support preliminary studies to rather concrete levels of product descriptions, but still allow stepping back to the conceptual levels, because of the efficient model integration and efficient simulation processes of multiple solution variants. Appl. Sci. 2017, 7, 1112 18 of 24

6.2.6. Application for the Tracking of Requirements Morkos et al. [12] point out that requirement change propagation, if not managed, may even lead to product development project failure. They were able show that more than half of a system’s requirements will change before project completion and that they have a significant influence on the product development process. It can be concluded that for non-trivial product development processes, a conscious change management of requirements is mandatory. Similar to requirements management, this change management for requirements concerns people, processes, and systems. From the system viewpoint, a requirements management system must at least have unique identifiers for each requirement and must allow and ease the tracking at all phases of the product life cycle. The model-based approach that is integrated into a life cycle integrated model offers an optimal basis for this endeavor; the concrete implementation of a change management system for requirements will be an important topic for the next research steps.

6.2.7. Application in the Testing of Requirements The testing of the fulfilment of requirements is carried out by all kinds of analyses, which determine the product performance and is usually not considered to be an integral part of requirements management. However, strong logical interrelations can be observed. Frequently, analyses of central product performance indicators are needed in order to determine the general feasibility of important requirements. Such analyses can be referred to as preliminary studies, explain certain requirements, and may lead to new requirements. For nearly all simulations and tests, requirements are the basis for the evaluation of the performance of the product. Additionally, in the case of competitive requirements, certain kinds of analyses, which can be also referred to as detail studies, may be needed in order to determine the optimum trade-off between the competitive requirements (it is important to note that in most cases, no mathematical optimum can be achieved or proven). In such cases, sensitivity analyses can be carried out in order to gain knowledge which, consequently, certain shifts of requirement levels may have. A graph-based design language allows a logical depiction of these interconnections between product analyses and requirements, thus enhancing the transparency and consequently the stability of the product development process.

6.2.8. Application in the Documentation of Requirements The central element concerning the documentation of requirements equals the documentation in the digital product model, which is based on graph-based design languages. In the future, a link to function models can also be established. Furthermore, the possibility to link requirements to abstract physics, and thus allowing simulation processes to be connected to the question they seek to answer, can be achieved. The analysis reported in subchapter “Application in the documentation of requirements” also led to the insight that several requirements cannot be formulated with parameters (not-textual requirements) but consist of more or less detailed drawings, for instance of the possible installation space of the gear system. With current requirements management systems, these requirements can either be used as additional information without logical integration of the individual dimensions, or it can be attempted to create a number of descriptive parameters. Model-based requirements management can offer the possibility to create a requirements geometry which completely represents the given information and can be analyzed in depth (by using structural and content-related quality criteria). This requirement geometry, which may for instance allow comparisons with the product, is currently under development.

7. Combination of the Models This section deals with the core innovative approach of the described research. From the last two sections, both conditions for the approach to connect requirements with the product are satisfied, and a model for generating railway vehicle gear systems as well as an innovative model for requirements Appl. Sci. 2017, 7, 1112 19 of 24 management were developed. In these two sections, no special focus was on the explicit digital mappingAppl. Sci. of requirements2017, 7, 1112 to the product model. For this kind of mapping, the definition of an19 interfaceof 24 between both models (“requirements”–”geometry synthesis”, compare Section1) is needed. This aspect will beinterface addressed between in this both section. models (“requirements”–”geometry synthesis”, compare Section 1) is needed. TheThis termaspect “interface” will be addressed may also in this understood section. as “combination”. A combination of both models can The term “interface” may also understood as “combination”. A combination of both models can lead to model-based requirements management. The model-based requirements management has in lead to model-based requirements management. The model-based requirements management has in very generalvery general terms terms three three main main aspects aspects which which could could alsoalso be be understood understood asas dimensions dimensions (Figure (Figure 15). 15).

FigureFigure 15. 15.General General approach approachof of model-basedmodel-based requirements requirements management. management.

The first dimension equals the model for generating gear system design variants (compare TheSection first 5, dimensionFigure 15, right equals red theframe), model the forseco generatingnd dimension gear equals system the model design for variants requirements (compare Sectionmanagement5, Figure (compare15, right Section red frame), 6, Figure the 15, second left red dimensionframe), and the equals third thedimension model equals for requirements the main managementapproach (compare(objective) Sectionof this research,6, Figure the 15 linking, left red of frame),requirements and the to the third prod dimensionuct graph. equalsThis linking the main approachis represented (objective) by of a thisblue research, association the link linking (Figure of requirements15, between red to theframes, product Result) graph. that Thisforms linking the is representedconnection by abetween blue association both models. link (Figure 15, between red frames, Result) that forms the connection between bothRequirements models. can be linked to modules or components of the product or to the product as a Requirementswhole, regardless can of be the linked point toat which modules the orproduct components life cycle of is the situated. product That or leads to the to product an assignment as a whole, of gear system classes to requirements or vice versa (compare Figure 15, blue association between red regardless of the point at which the product life cycle is situated. That leads to an assignment of gear frames). Hence, attribute “RelatedToPart” is introduced within structuring of requirements, and a systemconcrete classes assignment to requirements from a or certain vice versa requirement (compare to Figureits related 15, blueproduct, association module, between or part redcan frames).be Hence,described. attribute “RelatedToPart” is introduced within structuring of requirements, and a concrete assignmentFigure from 16 a certainshows requirementan example tofor its the related general product, approach module, of ormodel-based part can be requirements described. Figuremanagement. 16 shows an example for the general approach of model-based requirements management. A connectionA connection exists exists for for an an instance instance of of the the classclass “requirement” “requirement” that that specifies specifies the thedistance distance between between axle centeraxle center and and center center of motorof motor shaft shaft (compare (compare FigureFigure 16,16 ,highlighted highlighted blue blue node) node) to the to therelated related part part of theof gear the gear system, system, instance instance of of class class “Housing”. “Housing”. Whereas the the instance instance of ofthe the class class “Housing” “Housing” has an has an influence on its underlying components/parts. influence on its underlying components/parts. Consequently, changes in the requirements entity (compare Figure 16, value in red) lead to changes of the product (here: causes topology changes of the resulting gearbox). The connection between requirements and the design process can be expanded. A more advanced mapping of requirements to components and assemblies will be implemented in near future. The assignment process (instances of “requirement” to “geometry synthesis” or vice versa) is currently carried out by using search words. This kind of search has been defined and programmed Appl. Sci. 2017, 7, 1112 20 of 24 for the case of rather obvious requirements. In order to achieve appropriate general validity, it is conceivable to use an intelligent search algorithm here. Also, the concrete value of the requirement is passed through the content of instances to which a connection exists. Thus, the requirements are used for the layout process of the product variant and furthermore to a consistency between product variantsAppl. Sci. and 2017 its, 7, requirements. 1112 20 of 24

Requirement24.0 :GeometricDimensions Comment = - Description = Distance between axle centre and centre of motor shaft ID = 24 Name = GeometricDimensions RelatedToPart = 1.0-140.0;1.0-110.0-110.0-250.0 RelatedToRequirement = - Status = open Unit = mm Value = 270 Version = 1.0

Requirement24.0 :GeometricDimensions Comment = - Description = Distance between axle centre and centre of motor shaft ID = 24 Name = GeometricDimensions RelatedToPart = 1.0-140.0;1.0-150.0;1.0-110.0-110.0-250.0 RelatedToRequirement = - Status = open Unit = mm Value = 450 Version = 1.0

FigureFigure 16. 16.Example Example for for a a mapping mapping process of of requir requirementsements to torelated related product product components/parts. components/parts.

Consequently, changes in the requirements entity (compare Figure 16, value in red) lead to changesSince that of the mapping product process (here: ofcauses requirements topology changes has happened of the resultinggradually gear in thebox). design The connection process, design decisionsbetween are requirements carried out based and the on design the requirements. process can As be expanded.an example, A the more gear advanced ratio has mapping an influence of on the topologyrequirements of theto components resulting gearbox. and assemblies One may will be note implemented that requirements in near future. can be mapped to all layers of the productThe assignment architecture. process Figure (instances 16 shows of “requirement an example” to of “ howgeometry requirements synthesis” can or vice be mapped versa) is to the productcurrently architecture. carried out The by using product search as words. a whole This consists kind of ofsearch five has layers been in defined the upper and programmed area of Figure 17. Thefor layers the case below of rather represent obvious the classificationrequirements. In of order a requirements to achieve appropriate collection bygeneral using validity, the taxonomy it is of conceivable to use an intelligent search algorithm here. Also, the concrete value of the requirement is BecattiniAppl. et Sci. al. 2017 [14,] 7, within 1112 Figure 13. 21 of 24 passed through the content of instances to which a connection exists. Thus, the requirements are used for the layout process of the product variant and furthermore to a consistency between product variants and its requirements. Since that mapping process of requirements has happened gradually in the design process, design decisions are carried out based on the requirements. As an example, the gear ratio has an influence on the topology of the resulting gearbox. One may note that requirements can be mapped to all layers of the product architecture. Figure 16 shows an example of how requirements can be mapped to the product architecture. The product as a whole consists of five layers in the upper area of Figure 17. The layers below represent the classification of a requirements collection by using the taxonomy of Becattini et al. [14] within Figure 13. This structure allows depicting the product logic in the abstract domain of requirements, thus improving the logical interconnection between product components and respective requirements.

Figure 17. Example for a design graph of instances of the product architecture and requirements Figure 17. Example for a design graph of instances of the product architecture and requirements classified by the fourth taxonomy of Figure 13. classified by the fourth taxonomy of Figure 13. 8. Discussion This paper aims at demonstrating a mapping of model-based requirements management to a development process of gear systems by means of applying graph-based design languages. The conscious connection of specific requirements to their related product components/parts can be considered as the main contribution of the presented research. The model for gear systems consists of a vocabulary that was determined by the decomposition of a given product structure. The use of design languages with their central data model enables generating various product designs (depending on different input requirement) in a short period of time in a fully automatic manner. Thus, the whole design space is not limited to a few, manually chosen by human, design configurations, but includes all possible variants. By downstream evaluation processes, e.g., pareto-optimal, the most suitable approach is able to be selected. The model-based requirements management is based on a textual requirements specification of an EMU from an industrial customer. The purpose of the model is the collection, structuring, classification, assuring of consistency, prioritization, tracking, testing, as well as documentation of these requirements. Therefore, they are captured and are transferred into an UML model which results are represented by a design graph. A further result of the research is the definition of an interface between both models. The three results were successfully used in order to model the requirements of a real gear system family by means of the application of graph-based design languages using UML. It was possible to compile the model in the design language and to achieve a geometrical configuration. Consequently, the general realization possibility of the presented approach could be shown in an industrial context. The results presented in Section 5 to Section 7 were discussed with development engineers in the cooperating industrial company. The general potential of the methods was assessed to be very high. It was possible to elaborate prominent advantages and disadvantages of the approach. Advantages of the described approach include assuring a consistency between the requirements themselves, as well as between product model and requirements. A quick response of the product layout for changing requirements may be achieved. Disadvantages, at the moment, are the missing implementation of remaining functions of requirements management (assuring consistency and prioritization). These disadvantages and the discussions themselves also lead to the formulation of further research and implementation activities (compare Section 9). Appl. Sci. 2017, 7, 1112 21 of 24

This structure allows depicting the product logic in the abstract domain of requirements, thus improving the logical interconnection between product components and respective requirements.

8. Discussion This paper aims at demonstrating a mapping of model-based requirements management to a development process of gear systems by means of applying graph-based design languages. The conscious connection of specific requirements to their related product components/parts can be considered as the main contribution of the presented research. The model for gear systems consists of a vocabulary that was determined by the decomposition of a given product structure. The use of design languages with their central data model enables generating various product designs (depending on different input requirement) in a short period of time in a fully automatic manner. Thus, the whole design space is not limited to a few, manually chosen by human, design configurations, but includes all possible variants. By downstream evaluation processes, e.g., pareto-optimal, the most suitable approach is able to be selected. The model-based requirements management is based on a textual requirements specification of an EMU from an industrial customer. The purpose of the model is the collection, structuring, classification, assuring of consistency, prioritization, tracking, testing, as well as documentation of these requirements. Therefore, they are captured and are transferred into an UML model which results are represented by a design graph. A further result of the research is the definition of an interface between both models. The three results were successfully used in order to model the requirements of a real gear system family by means of the application of graph-based design languages using UML. It was possible to compile the model in the design language and to achieve a geometrical configuration. Consequently, the general realization possibility of the presented approach could be shown in an industrial context. The results presented in Section5 to Section7 were discussed with development engineers in the cooperating industrial company. The general potential of the methods was assessed to be very high. It was possible to elaborate prominent advantages and disadvantages of the approach. Advantages of the described approach include assuring a consistency between the requirements themselves, as well as between product model and requirements. A quick response of the product layout for changing requirements may be achieved. Disadvantages, at the moment, are the missing implementation of remaining functions of requirements management (assuring consistency and prioritization). These disadvantages and the discussions themselves also lead to the formulation of further research and implementation activities (compare Section9).

9. Summary and Outlook The central objective of the research was to demonstrate an integration of model-based requirements management with a development process of gear systems, by means of applying graph-based design languages. For the innovative approach, two models were developed: one model for generating various gear system design variants for so-called “Electrical Multiple Units” (EMU), which are commonly applied in trams, suburban trains, or high-speed railway vehicles; and a second model for requirements management (RM), which includes state of the art RM-know-how. The RM-Model as well as the model for product design variants have been implemented by means of graph-based design languages that are based on UML (Unified Modelling Language). In a graph-based design language, the engineering objects represent the vocabulary and the required model transformations represent the rules. In a so-called “production system”, the rules are executed in order to instantiate the vocabulary classes. This compilation process builds up a central data model. The model instances are displayed by a design graph. Within the research project, an engineering framework called “DesignCompiler43”, an eclipse-based software tool, has been used for compilation of the design language models. Appl. Sci. 2017, 7, 1112 22 of 24

The combination of both design languages enables a linkage of requirements to modules or components of the product, or to the product as a whole, regardless of the point at which the product life cycle is situated. In addition to the current state, the approach is supposed to be expanded towards supporting the collection of requirements. A text-processing tool with word-analysis techniques can enable a fully automated transformation of textual requirements specification as a main input towards a composition of a class diagram based on specifications. This future process can lead to an instance graph of entered requirements. Further work is also planned in order to investigate analysis possibilities which are given by the polyhierarchical requirements model. Additionally, the implementation of remaining functions of requirements management (e.g., assuring consistency, ... ) is planned. In the future, the impact of agile and lean principles to model-based requirements engineering can also be a promising field for research.

Acknowledgments: The project “digital product life-cycle (ZaFH)” (information under: https://dip.reutlingen- university.de/) is supported by a grant from the European Regional Development Fund and the Ministry of Science, Research and the Arts of Baden-Württemberg, Germany (information under: www.rwb-efre.baden- wuerttemberg.de). Author Contributions: The research was carried out and the paper was written in a cooperative effort. Main research contributions concern the following points: Kevin Holder: descriptive study in the industrial company, generation of a graph-based model of a gear system; Andreas Zech: fundamentals of requirements engineering, generation of a general graph-based model of requirements engineering; Manuel Ramsaier: generation of graph-based models based on UML; Ralf Stetter: research methodology, fundamentals of requirements engineering; Hans-Peter Niedermeier: descriptive study in the industrial company, validation; Stephan Rudolph: fundamentals of graph-based languages; Markus Till: industrial application of graph-based languages, life-cycle issues. Conflicts of Interest: The authors declare no conflict of interest.

References

1. Bernard, R.; Irlinger, R. About watches and cars: Winning R&D strategies in two branches. In Proceedings of the Engineering Design—The Art of Building Networks, Garching, Germany, 4 April 2016. 2. Hruschka, P. Business Analysis und Requirements Engineering: Produkte und Prozesse Nachhaltig Verbessern; Hanser: München, Germany, 2014. 3. Ebert, C.; Jastram, M. ReqIF: Seamless Requirements Interchange Format between Business Partners. IEEE Softw. 2012, 29, 82–87. [CrossRef] 4. Blessing, L.T.M.; Chakrabarti, A. DRM, a Design Research Methodology; Springer: London, UK, 2009. 5. Kohn, A. Entwicklung einer Wissensbasis für die Arbeit mit Produktmodellen. Ph.D. Thesis, Lehrstuhl für Produktentwicklung der Technischen Universität München, Garching bei Muenchen, Germany, November 2013. 6. Darlington, M.J.; Culley, S.J. A model of factors influencing the design requirement. Des. Stud. 2004, 25, 329–350. [CrossRef] 7. Jiao, J.; Chen, C.H. Customer requirement management in product development: A review of research issues. Concurr. Eng. Res. Appl. 2006, 14, 173–185. [CrossRef] 8. Zhang, Z.; Li, X.; Liz, Z. A closed-loop based framework for design requirement management. In Proceedings of the 21st ISPE Inc. International Conference on Concurrent Engineering, Beijing, China, 8–11 September 2014. 9. ISO/IEC/IEEE 29148:2011: Systems and Software Engineering—Life Cycle Processes—Requirements Engineering. 2011. Available online: http://ieeexplore.ieee.org/document/6146379/ (accessed on 29 August 2017). 10. ISO/IEC 15288:2008 Systems and Software Engineering—System Life Cycle Processes. 2008. Available online: https://www.iso.org/standard/43564.html (accessed on 29 August 2017). 11. ISO 9001:2015: Quality Management Systems—Requirements. 2015. Available online: https://www.iso.org/ standard/62085.html (accessed on 29 August 2017). 12. Morkos, B.; Mathieson, J.; Summers, J.D. Comparative analysis of requirements change prediction models: Manual, linguistic, and neural network. Res. Eng. Des. 2014, 25, 139–156. [CrossRef] Appl. Sci. 2017, 7, 1112 23 of 24

13. Mattmann, I.; Gramlich, S.; Kloberdanz, H. The malicious labyrinth of requirements—Three types of requirements for a systematic determination of product properties. In Proceedings of the 20th International Conference on Engineering Design (ICED15), Milan, Italy, 27–30 July 2015. 14. Becattini, N.; Cascini, G.; Rotini, F. Requirements checklists: Benchmarking the comprehensiveness of the design specification. In Proceedings of the 20th International Conference on Engineering Design (ICED15), Milan, Italy, 27–30 July 2015. 15. Chen, Z.Y.; Yao, S.; Lin, J.Q.; Zeng, Y.; Eberlein, A. Formalisation of product requirements: From natural language descriptions to formal specifications. Int. J. Manuf. Res. 2007, 2, 362–387. [CrossRef] 16. Bühne, S.; Herrmann, A. Handbuch Requirements Management nach IREB Standard. Aus- und Weiterbildung zum IREB Certified Professional for Requirements Engineering Advanced Level “Requirements Management”. IREB e.V.: 2015. Available online: https://www.ireb.org/content/downloads/14-handbook-cpre-advanced- level-requirements-modeling/ireb_cpre_handbuch_requirements_modeling_advanced_level_v1.3.pdf (accessed on 29 August 2017). 17. Griffin, A.; Hauser, J. The Voice of the Customer. Mark. Sci. 1993, 12, 1–27. [CrossRef] 18. Sharif Ullah, A.M.M.; Tamaki, J. Analysis of Kano-Model-Based Customer Needs for Product Development. Syst. Eng. 2011, 14, 154–172. [CrossRef] 19. Sharif Ullah, A.M.M.; Sato, M.; Watanabe, M.; Mamunur Rashid, M. Analysis of Kano-Model-Based Customer Needs for Product Development. Int. J. Autom. Technol. 2016, 10, 132–143. [CrossRef] 20. Nambisan, S. Designing Virtual Customer Environments for New Product Development: Toward a Theory. Acad. Manag. Rev. 2002, 27, 392–413. 21. Vezzetti, E.; Alemanni, M.; Morelli, B. New product development (NPD) of ‘family business’ dealing in the luxury industry: Evaluating maturity stage for implementing a PLM solution. Int. J. Fash. Des. Technol. Educ. 2016, 10, 219–229. [CrossRef] 22. Salado, A.; Nilchiani, R. A Categorization Model of Requirements Based on Max-Neef’s Model of Human Needs. Syst. Eng. 2014, 17, 348–360. [CrossRef] 23. Martin, S.; Aurum, A.; Jeffery, R.; Paech, B. Requirements Engineering Process Models in Practice. In Proceedings of the Seventh Australian Workshop on Requirements Engineering, AWRE 2002, Melbourne, Australia, 2–3 December 2002. 24. Batra, M.; Bhatnagar, A. A Comparative Study of Requirements Engineering Process Model. Int. J. Adv. Res. Comput. Sci. 2017, 8, 740–745. 25. Almefelt, L.; Berglund, F.; Nilsson, P.; Malmqvist, J. Requirements management in practice: Findings from an empirical study in the automotive industry. Res. Eng. Des. 2006, 17, 113. [CrossRef] 26. Ramesh, B.; Jarke, M. Towards Reference Models for Requirements Traceability. IEEE Trans. Softw. Eng. 2001, 27, 58–93. [CrossRef] 27. Siemens: Teamcenter Systems Engineering. Available online: https://www.plm.automation.siemens.com/ de/products/teamcenter/systems-engineering-software/ (accessed on 29 August 2017). 28. IBM: Rational DOORS. Available online: http://www-03.ibm.com/software/products/de/ratidoor (accessed on 29 August 2017). 29. Serena: Serena Dimensions RM. Available online: http://www.serena.com/index.php/de/products/more- products/dimensions-rm/ (accessed on 29 August 2017). 30. Carrillo de Gea, J.M.; Nicolas, J.; Fernandez Aleman, J.L.; Toval, A.; Ebert, C.; Vizca, A. Requirements engineering tools: Capabilities, survey and assessment. Inf. Softw. Technol. 2012, 54, 1142–1157. [CrossRef] 31. Object Management Group: Requirements Interchange Format (ReqIF) Version 1.2. Available online: http://www.omg.org/spec/ReqIF/1.2/PDF (accessed on 29 August 2017). 32. Eclipse: RMF/ProR. Available online: http://www.eclipse.org/rmf/ (accessed on 29 August 2017). 33. Störrle, H.; Kucharek, M. The requirements editor RED. In Proceedings of the European Conference on Modelling Foundations and Applications (ECMFA 2013), Montpellier, France, 1–5 July 2014. 34. DTU: RED. The Requirements Engineering Workplace. Available online: http://www2.compute.dtu.dk/ ~hsto/RED/index.html (accessed on 29 August 2017). 35. Sudin, M.N.; Ahmed-Kristensen, S.; Andreasen, M.M. The role of a specification in the design process: A case study. In Proceedings of the International Design Conference, Cavtat-Dubrovnik, Croatia, 17–20 May 2010. 36. Li, X.; Ahmed-Kristensen, S. Understand the design requirement in companies. In Proceedings of the 20th International Conference on Engineering Design (ICED15), Milan, Italy, 27–30 July 2015. Appl. Sci. 2017, 7, 1112 24 of 24

37. Borgianni, Y.; Rotini, F. Stakeholders’ diverging perceptions of product requirements: Implications in the design practice. In Proceedings of the 20th International Conference on Engineering Design (ICED15), Milan, Italy, 27–30 July 2015. 38. Finger, S.; Rinderle, J. A Transformational Approach to Mechanical Design Using a Bond Graph Grammer; Technical Report; Engineering Design Center of Carnegie Mellon University: Pittsburgh, PA, USA, January 1990. 39. Le Duigou, J.; Bernard, A. Product Lifecycle Management Model for Design Information Management in Mechanical Field. In Proceedings of the 21st CIRP Design Conference, Daejeon, Korea, 27–29 March 2011; pp. 207–213. 40. Eckert, C.; Albers, A.; Bursac, N.; Chen, H.X.; Clarkson, P.J.; Gericke, rel="tag">K.; Gladysz, B.; Maier, J.F.; Rachenkova, G.; Shapiro, D.; et al. Integrated Product and Process Models: Towards an Integrated Framework and Review. In Proceedings of the 20th International Conference on Engineering Design (ICED15), Milan, Italy, 27–30 July 2015. 41. Rudolph, S. Aufbau und Einsatz von Entwurfssprachen für den Ingenieurentwurf. In Forum Knowledge Based Engineering; CAT-PRO: Stuttgart, Germany, 2003. 42. Arnold, P.; Rudolph, S. Bridging the Gap between Product Design and Product Manufacturing by Means of Graph-Based Design Languages. In Proceedings of the TMCE, Karlsruhe, Germany, 7–11 May 2012. 43. Groß, J.; Rudolph, S. Generating simulation models from UML—A FireSat example. In Proceedings of the 2012 Symposium on Theory of Modeling and Simulation—DEVS Integrative M&S Symposium, Orlando, FL, USA, 26–29 March 2012. 44. Rudolph, S. On the problem of multi-disciplinary system design—And a solution approach using graph-based design languages. In Proceedings of the 1st ACCM Workshop on Mechatronic Design, Linz, Austria, 30 November 2012. 45. Eisenbahn-Kurier. Available online: http://www.eisenbahn-kurier.de/startbeitraege/126-startseite/1518- bombardier-veranstaltet-erstes-internationales-forum-fuer-betreiber-von-flexx-drehgestellen (accessed on 29 August 2017). 46. Ammenwerth, E. Die Modellierung von Anforderungen an die Informationsverarbeitung im Krankenhaus. Ph.D. Thesis, Medizinische Fakultät Heidelberg der Ruprecht-Karls-Universität, Heidelberg, Germany, May 2000. 47. Martin, J. Information Engineering. Book II: Planning & Analysis; Prentice Hall: Englewood Cliffs, NJ, USA, 1989.

© 2017 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).