The Journal of Systems and Software 96 (2014) 152–171 Contents lists available at ScienceDirect The Journal of Systems and Software j our na l ho me page: www.elsevier.com/locate/jss Transforming an enterprise model into a use case model in business process systems Fábio Levy Siqueira ∗,1 , Paulo Sérgio Muniz Silva Departamento de Engenharia de Computac ¸ ão e Sistemas Digitais, Escola Politécnica da Universidade de São Paulo, Av. Prof. Luciano Gualberto, trav.3, no 158, 05508-900 São Paulo, SP, Brazil a r t i c l e i n f o Article history: Received 28 June 2013 Received in revised form 27 December 2013 Accepted 4 June 2014 Available online 10 June 2014 Keywords: Stakeholder requirement Transformation Use case a b s t r a c t One of the responsibilities of requirements engineering is to transform stakeholder requirements into system and software requirements. For enterprise systems, this transformation must consider the enter- prise context where the system will be deployed. Although there are some approaches for detailing stakeholder requirements, some of them even considering the enterprise context, this task is executed manually. Based on model-driven engineering concepts, this study proposes a semi-automatic trans- formation from an enterprise model to a use case model. The enterprise model is used as a source of information about the stakeholder requirements and domain knowledge, while the use case model is used as software requirements model. This study presents the source and target metamodels, a set of transformation rules, and a tool to support the transformation. An experiment analyzes the use of the proposed transformation to investigate its benefits and if it can be used in practice, from the point of view of students in the context of a requirements refinement. The results indicate that the approach can be used in practice, as it did not influence the quality of the generated use cases. However, the empir- ical analysis does not indicate benefits of using the transformation, even if the qualitative results were positive. © 2014 Elsevier Inc. All rights reserved. 1. Introduction A key activity in requirements engineering is to discover what the stakeholders want from the system, i.e., to elicit the requirements. Stakeholder intentions, describing needs, goals, and objectives, must be formalized into stakeholder requirements, representing the requirements from a business and organiza- tional perspective (ISO, 2011). These requirements represent “the intended interaction the system will have with its operational environment” (ISO, 2011; p. 19), considering the needs of users, operators, maintainers, and other stakeholders. However, these requirements may not be sufficiently detailed to be used during the development activities (Zave and Jackson, 1997). They must be analyzed and transformed into system requirements, which represents a technical specification for the system (ISO, 2011). These requirements must consider implementation constraints, ∗ Corresponding author. Tel.: +55 11 3091 5583. E-mail addresses: fabio@levysiqueira.com.br (F.L. Siqueira), paulo.muniz@poli.usp.br (P.S. Muniz Silva). 1 Present address: Programa de Educac ¸ ão Continuada da Escola Politécnica da Universidade de São Paulo, Av. Prof. Mello Moraes, n◦ 2373, 1o. andar, 05508-900 São Paulo, SP, Brazil. required functions, quality attributes, assumptions, and other information. As system requirements represent a specification, they must be measurable and yet they should not describe imple- mentation details. Some system requirements may be further detailed in order to be allocated into a software element of the system, resulting in software requirements. This terminology is defined by the ISO 29148 standard (ISO, 2011), but authors may use other terms to differentiate between stakeholder requirements, and system and software requirements. For example, Jackson and Zave (Jackson, 1995; Zave and Jackson, 1997) use the term “requirement” and “specification”, van Lamsweerde (2009) uses “goals” and “requirements” (even though goals can also represent stakeholder intentions), and Sommerville (2010) and Maiden (2008) use “user requirements” and “system requirements”. Normally, there are more than one possible alternative to detail stakeholder requirements into system and software requirements. Each alternative can impact differently on the proposed system, influencing desired business or technical results (Mylopoulos et al., 2001), or even the project itself (time, cost, or the size of the team needed). Nonetheless, the transformation from stakeholder requirements to system and software requirements is not a design activity, as it does not result in a specific system solution. It results in requirements specified more precisely. A simple example of this transformation is presented by Maiden (2008; p. 90), using http://dx.doi.org/10.1016/j.jss.2014.06.007 0164-1212/© 2014 Elsevier Inc. All rights reserved.