On the Use of Metamodeling for Relating Requirements and Architectural Design Decisions Diego Dermeval 1,2 , Jaelson Castro 1 , Carla Silva 1 , João Pimentel 1 1 CIn, Universidade Federal de Pernambuco (UFPE). Recife, Pernambuco – Brazil {ddmcm, jbc, ctlls, jhcp}@cin.ufpe.br Ig Ibert Bittencourt 2 , Patrick Brito 2 , Endhe Elias 2 , Thyago Tenório 2 , Alan Pedro 2 2 IC, Universidade Federal de Alagoas (UFAL). Maceió, Alagoas – Brazil {ddmcm, ig.ibert, patrick, endhe.elias, ttmo, alanpedro}@ic.ufal.br ABSTRACT Requirements models can be used to describe what is expected from a software system. On the other hand, architectural models can describe the structure of a system in terms of its components and connectors. However, these models do not capture the rationale of the decisions made during architectural design. This knowledge is important throughout the maintenance and evolution of the system, as it allows a better understanding of the system as well as the impact of changes on it. In this paper, we consider existing proposals for architectural decisions documentation to define a template for recording the rationale of architectural design decisions. This template is based on a metamodel, which borrows concepts from the NFR Framework to express such rationale. Documenting decisions enables the evaluation of architectural design alternatives when requirements evolve or when new alternatives are devised. Moreover, the metamodel provides a relationship between requirements and architectural design fragments, facilitating the maintenance of traceability between the problem and the solution. We illustrate and discuss the use of this metamodel in the context of Acme architectural models and i* requirements models. Categories and Subject Descriptors D.2.1 [Software Engineering]: Requirements/Specifications D.2.2 [Software Engineering]: Design Tools and Techniques – Decision tables D.2.11 [Software Engineering]: Software Architecture General Terms Documentation, Design Keywords Requirements Engineering; Software Architecture; Architectural Design Decisions; 1. INTRODUCTION Requirements and architectural models are artifacts generated in connection with two strongly related and intertwined activities of a software development process, respectively, Requirements Engineering (RE) and Architectural Design (AD). Hence, it is critical to establish how these models are interconnected [1]. Indeed, some recent works, such as the STREAM (Strategy for Transition between REquirements and Architectural Models) process [2], present model-driven approaches for generating early architectural models – in Acme [7] – from i* requirements models [15]. However, specifying software architecture only in terms of architectural models (e.g., Acme models) is not enough. In order to allow a more effective integration between RE and AD activities, the software architecture community highlights the need to treat Architectural Design Decisions (ADD) and their rationale as first class citizens in the software architecture design specification [10] [14]. Explicit mechanisms to link the decision to both the requirements and architectural models are required. Establishing these relationships [6] are essential to answer questions such as “how (well) does the architecture support the satisfaction of this requirement?”, “why was this component created?”, “what were the architectural design alternatives considered regarding this model fragment?” In this paper, we present a metamodel that can be used as basis to build an ADD documentation template which can be used, for example, to record the rationale of the decisions taken, the requirements related to a specific decision as well as the alternatives that were considered during the decision-making process. Our metamodel covers twelve documentation elements (as proposed in [13]) and includes a contribution analysis model (based on the NFR Framework [3]) to analyze how the architectural alternatives contribute to the satisfaction of the system’s non-functional requirements. It also relates the requirements to the architectural design fragments responsible to address them. The expected benefits of using an ADD documentation template are threefold: (i) traceability between requirements models and architectural models is produced during the software lifecycle; (ii) more precise estimation of the impact of requirements and architecture changes; and (iii) better communication between the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SAC’13, March 18-22, 2013, Coimbra, Portugal. Copyright 2013 ACM 978-1-4503-1656-9/13/03…$10.00.