Cognitive Engineering meets Requirements Engineering Bridging the Traceability Gap Alexandra Mazak Junior Research Studio Cognitive Engineering (CoE) Research Studios Austria Forschungsgesellschaft Vienna, Austria alexandra.mazak@researchstudios.at Horst Kargl SparxSystems Software GmbH Vienna, Austria horst.kargl@sparxsystems.eu Abstract—Support for various stakeholders (customer, project manager, system architect, requirements engineer) involved in the design and management of large software systems is needed since frequently, misinterpretations occur already when specifying customer requirements into system requirements. This problem is mainly caused by the various perspectives and intentions of the involved parties that may lead to diverging interpretations during said process. Therefore, the focus of our work in progress is on the requirements engineers when transforming customer requirements into system requirements. There is still a gap to trace design decisions especially at this early stage of the system development life cycle. We introduce a heuristic-based approach in order to make a contribution to bridge this gap. We propose to consider the requirements engineer’s “cognitive perspective” on traceability links by a heuristic-based weighting procedure that can be performed during the design process. We enhance the established relationship or traceability matrix to make it possible for requirements engineers to annotate their informal knowledge to the linkage (i.e., visualized realizations) in that matrix. Keywords-Requirements management; requirements traceability; cognitive engineering; traceability matrix; design decisions. I. INTRODUCTION There is a variety of stakeholders involved in large software projects, each having a different set of goals and priorities [9]. Generally, requirements are prioritized by stakeholders (e.g., based on the software projects’ purpose, certain functionalities which should be targeted by the system). Various methods and supporting tools exist for guiding this process of requirements’ prioritization. What we are missing is another prioritization when linking customer requirements to system requirements and system requirements to design artifacts (i.e., model components) in the specification task. Misinterpretations at this stage of a software project are resulting from misconceived or misvalued linking. Validation continues to be a “big pain” due to the lack of trusted documentation of traceability drives validation teams to leave no doubt (aka double or triple effort). There is a multitude of tools (e.g., Rational DOORS [12]) by which requirement lifecycle management is supported. Often, tools produce non- or less compelling documentation [13]. However, experience has shown that a “distributed traceability of requirements” guided by external tools or methods, which means that it is not integrated in the system’s architecture design process itself, is often error- prone [13]. We propose focusing on the requirements engineers’ informal knowledge when design decisions are made during the specification task of customer requirements. According to the used modeling language a certain traceability link can be used (realization in UML [2], satisfy in SysML [3]). Generally, a trace chain is constructed through linking by which an impact analysis can be made. Mainly, such information is presented in form of a matrix called relationship matrix. In Fig. 1, which represents an excerpt of a relationship matrix from the tool Enterprise Architect (EA) [13], the linkage is visualized in form of arrows in the cells. This type of linking merely express for instance that Receive Orders is realized by two system artifacts REQ019 and REQ032 (e.g., Fig. 1). It cannot be derived to what extent the realization is proceeded, or the system requirements’ level of utility to fulfill this customer requirement. Generally, a certain customer requirement is covered by more than a single system component and not each component has the same relevance to realize that requirement within the system’s architecture; just as customer requirements do not have equal prioritizations. Thus, each system component has a different level of utility (relevance). Figure 1. Relationship matrix in EA. 512 Copyright (c) IARIA, 2012. ISBN: 978-1-61208-230-1 ICSEA 2012 : The Seventh International Conference on Software Engineering Advances