An experience report on using architectural models

An experience report on using architectural models within distributed Scrum teams contexts Nuno Santos, Jaime Pereira, Francisco Morais, Júlio Barros CCG/ZGDV Institute Guimarães Portugal {nuno.santos, jaime.pereira, francisco.morais, julio.barros}@ccg.pt

ABSTRACT Model artifacts in agile software development (or agile modeling) are used to establish a shared understanding on the requirements that the items from the product backlog will address. A common challenge is to have a proper balance between the project’s agility and architecture. This shared understanding gains more importance in large-scale contexts composed by multiple agile teams. Teams must clearly define their work scope and interactions with other teams, and architects must design a proper amount of design. This paper describes the application of a process for modeling a candidate logical architecture to be used within a distributed Scrum teams context. The process encompasses agile modeling of a candidate architecture and traceability tools for delivering user stories in a team backlog and usage in inter-team coordination.

CCS CONCEPTS • Software and its engineering → System description languages; Unified Modeling Language (UML) • Software creation and management → Designing software → Requirements analysis; Software development process management → Software development methods → Agile software development

KEYWORDS User stories, models, distributed Scrum teams, UML, architecture. ACM Reference format: Nuno Santos, Jaime Pereira, Francisco Morais, Júlio Barros, Nuno Ferreira, and Ricardo J. Machado. 2018. An experience report on using architectural models within distributed Scrum teams contexts. XP’18 Companion Proceedings, May 21–25, 2018, Porto, Portugal. ACM. 5 pages. https://doi.org/10.1145/3234152.3234180 This work was developed within the project UH4SP: Unified Hub 4 Smart Plants (Project ID 017871), under Portuguese National Grants Program for R&D projects (P2020 – SI IDT), COMPETE: POCI-01-0145-FEDER-007043 and FCT – Fundação para a Ciência e Tecnologia within the Project Scope: UID/CEC/00319/2013. 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. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. XP '18 Companion, May 21–25, 2018, Porto, Portugal © 2018 Association for Computing Machinery. ACM ISBN 978-1-4503-6422-5/18/05…$15.00 https://doi.org/10.1145/3234152.3234180

Nuno Ferreira i2S Insurance Knowledge, S.A. Porto Portugal [email protected]

1

Ricardo J. Machado ALGORITMI Research Centre Guimarães Portugal [email protected]

INTRODUCTION

The use of models is argued when projects have well-stated requirements at the very beginning, which provide context for the solution design, thus performing the so-called “Big Design Up Front” (BDUF). The importance of requirements modeling and architecture-centric design methods in Agile software development (ASD) is acknowledged [1]. When developing large-scale applications, many have reported that agile methods must be adapted to include architectural information [1], and regards a keychallenge [2]. The term ‘large-scale agile development’ (LSA) has been used to describe agile development in everything from large teams to large multi-team projects to making use of agile development principles in a whole organization [3]. The performed architecture design should emerge gradually sprint after sprint, as a result of successive small refactoring [4] in order to prevent BDUF efforts to be afterwards disregarded due to “You Aren’t Going to Need It” (YAGNI) elements. This paper aims to describe an approach capable of deriving logical architectures in order to establish the initial requirements, that are passed on to agile development teams. Using logical architectures for establishing initial requirements allows to combine requirements from backlogs (that focus only on functional features) with the quality attributes of the software [5]. This research proposes including some upfront design in the set-up phase (e.g., Sprint 0, for Scrum projects) of the project (by some we do not mean BDUF, rather “just-enough” [6] for a candidate architecture) and to use the architecture as input for an ASD approach (back to requirements again) to build almost the totality of the Product Backlog (illustrated in Fig. 1). The Four-Step-Rule Set (4SRS) method [7] allows to derive logical architectures aligned with the corresponding, and previously elicited and modeled, user requirements. A logical architecture is a view that primarily supports the functional requirements, taken mainly from the problem domain [8]. The conventional version of the 4SRS method is typically applied in large-scale projects, but demands high quantity of information (use cases, textual descriptions), which is often time consuming and, in every way, misaligned with the general paradigm adopted by ASD. This approach is demonstrated within a research project called “Unified Hub for Smart Plants” (UH4SP), which acts within a complex ecosystem composed by IoT, cloud, sensors and embedded systems technologies. The UH4SP project aims developing a platform for integrating data from distributed

LargeScaleAgile’18, Porto, Portugal industrial unit plants, allowing the use of the data acquired from IoT systems for enterprise-level production management and collaborative processes between plants, suppliers, forwarders and clients, which are supported by software applications and services deployed in a cloud platform.

Fig. 1. Approach for delivering backlog items requirements This paper is structured as follows: section 2 presents related work on architectures in agile and large-scale agile; section 3 presents the modeling of the candidate architecture and its modularization; section 4 presents the transition for agile backlog items; section 5 describes how the architecture supports distributed Scrum teams coordination; and, 6, the conclusions.

2

3 REQUIREMENTS AND DESIGN MODELS AS INPUTS FOR SCRUM TEAMS In this section, the objective is to describe the elicitation of the core requirements, and additionally to include techniques for deciding that the “just-enough” requirements model is complete. This phase is inspired by the agile visions of “just barely good enough” (JBGE) of AMDD [6], Abrahamsson’s skeleton [4] and Kazman’s candidate architecture [12]. The goal is to model requirements in UML Use Case diagrams. Using functional decomposition techniques, use cases may be decomposed once or twice, however the main idea is to model “just-enough” requirements, hence one decomposition may be sufficient. The first-level Use Cases is depicted in Fig. 2. The Use Case model was globally composed by 37 use cases after the decomposition, with the following composition: Use case {UC.1} with five, {UC.2} with eight, {UC.3} with five, {UC.4} with three, {UC.5} with two, {UC.6} with five, and {UC.7} with ten. Almost the entire model was detailed in one lower-level (e.g., {UC5.1], {UC5.2], etc.). This shows the low effort in decomposing the use cases at this phase. The use of UML Use Case diagrams for specifying requirements is mandatory, since the 4SRS method for deriving the logical architecture uses use cases as input.

RELATED WORK

Modeling techniques, whether within requirements or design disciplines, is no longer performed only in the early phase of the project, but rather in a continuous way [9]. Even in agile software development (ASD) contexts, where widely known frameworks, such as Scrum, XP, Kanban, Crystal, etc. don’t use models (e.g., UML), modeling tasks are able to be included if performed continuously and incrementally, called “Agile Model-Driven Development” (AMDD) [6]. In this approach, the starting point is “just-enough” requirements and architecture, which are updated alongside implementation. Our proposed approach is aligned with this reasoning, however AMDD does not state any method for assuring the alignment of the architecture with the elicited needs, which is assured in our approach by the 4SRS method execution. Coplien and Bjørnvig present the concept of “Lean Architecture” [10], where the lean perspective focuses on how to develop the overall system form by drawing on experience and domain knowledge. One of the proposals for performing design as concepts and requirements emerge, included in the research of Abrahamsson [4] and Farhan [11] is the approach of a walking skeleton. Kazman proposes the design of a candidate architecture [12]. On larger projects with unstable requirements, start by quickly designing a candidate architecture even if it leaves out many details.” [13]. These works describe some strategies for using a candidate architecture approach and its evolution throughout the development process. There are not however any considerations on guiding the architecture design and evolution that assures the alignment with the gathered requirements. Architectural methods like the 4SRS have been used in deriving the architecture and refining some information with complete requirements model known upfront. The 4SRS method has been used in a large-scale agile project [14] as a tool for deriving large quantity of use stories statements compliant with INVEST criteria, however the method had not been used with a smaller number and high-level of requirements. 2

N. Santos et al.

Fig. 2. UH4SP first-level Use Cases The 4SRS method is composed by transformation steps that support mapping between the requirements models (using UML use cases) and architectural model composed by UML components [7] (Fig.3). It is composed by four steps: Component Creation; Component Elimination (divided in seven micro-steps); Packaging and Aggregation; and Component Associations. The method provides the traceability between components and the functional requirements, allowing an agile response to changing requirements. A full description of the 4SRS method is out of the scope of this paper due to paper size limitations. Like in most cases, the best approach to issue complex problems is to divide them into smaller ones and address them one by one, ultimately allowing to address the big solution. With the purpose of modularizing the architecture, the logical architecture may be partitioned into sub-systems (Fig.4). The sub-system border provides context for modeling more refined use cases, as well as context for making technical design decisions that in the initial phase were very difficult to make. The use cases may then be used for a new execution of the 4SRS, since they relate to “new” use cases that did not exist before the definition of the sub-systems.

An experience on using architectural models in distributed Scrum

Fig. 3. UH4SP logical architecture By modeling some processes to validate the flow between components (including components from different modules), e.g., using sequence diagrams as in [7], dependencies can be depicted, namely some functionalities that must be implemented and executable in order for other functionalities to proper execute. It must be assured that a module has composing software components that, together, deliver working software. Since at this point only the components from the module are considered, the outbound components were disregarded. Remote Assistance

Global UH4SP

{P4.1} Business Mgmt (Global)

{P1.1} Accounts

{C1.1.1.1.i} Manage user interface

{C1.2.i} Configure users profile interface

{C1.5.1.i} Manage business groups interface

{C1.5.2.1.i} Manage group companies interface

{C1.5.2.3.i} Manage client companies

{C7.2.7.i} Register remote operations

{C1.6.4.i} Request tokens interface

{C1.5.2.2.i} Manage forwarders companies {C1.4.1.i} Authentication interface

{C7.1.4.i} Perform business notifications interface

{C6.4.i} Users training interface

{C6.3.i} Perform interventions interface

{C7.1.1.i} Consults Information interface

{C1.6.5.i} Assign tokens interface {C6.5.i} Generate service templates interface

{C2.5.i} Define service level agreement interface

{C6.2.i} Schedule interventions interface

{C1.4.2.i} Recover password interface

{P1.2} Services

{C2.1.1.i} Manage service interface

{C1.5.2.4.i}Manage supplier companies

{C2.1.5.i} Assign services interface {C1.5.2.1.c} Manage companies processor

{C7.2.7.c} Register remote operations processor

{C1.5.3.i} Manage geographies interface

{P1.3} Security

{C7.1.4.c} Business notifications processor {P5.1} Integrator (Hub/Bus/Gateway)

{C7.1.3.i} Configure information access interface

{C4.1.i} Backups interface

{C2.1.1.c} Services deployment processor

{C4.1.c} Backups generator

{C6.5.c} Services templates processor

{C4.2.i} Configure data access interface

{C1.5.1.c} Manage business groups processor

{C1.4.1.c} Authentication processor

{C1.2.c} Profiles processor

{C1.4.2.c} Recover password processor {C3.1.i} Information systems integration interface

{C1.6.1.i} Manage tokens interface

{C7.1.3.c} Information access configuration processor

{C1.1.1.1.c} Manage User processor

{C1.5.3.c} Manage geographies processor

{C1.6.1.c} Configure tokens processor

{C2.4.c} Entities mapping processor

{C3.1.c} Information systems integration

{C3.2.c} Synchronize data processor

{P2} Monitoring {C1.3.i} Consult users SLA data interface

{C2.2.i} Generate cloud services reports interface

{C2.3.i} Measured values interface

{C2.3.c} Measure services utilization

{C2.2.c} Reports generator

{C4.3.i} Monitor activities interface

{C4.3.c} Monitor activities

{C6.1.i} Verify intervention or maintenance needs interface

{P6.1} DB

{C4.2.d} Access control data

{C4.1.d} Backups data

{C2.1.1.d} Services data

{C6.5.d} Services templates data

{C2.2.d} Reports data

{C7.1.3.d} Information access configurations

{C2.5.d} Service level aggrement data

{C4.3.d} Monitoring and audits data

{C3.2.d} Synchronized data

{C2.3.d} Measured values data

{C1.1.1.1.d} User data

{C1.5.1.d} Business Groups data

{C1.6.1.d} Tokens data

{C7.2.7.c} Remote operations data {C6.4.d} Users training data

{C.5.1.i} Catalog entities interface {C1.2.d} Profiles data

{C2.4.d} Entities mapping data

{C3.1.d} Global integration data

{C1.5.3.d} Geographies data

{C1.5.2.1.d} Companies data

{C7.1.3.d} Business notifications data

Azure

Local UH4SP

{P4.2} Business Mgmt (Local) {C6.7.i} Manage people's appearance templates interface

{U.C.7.2.5} Register in-plant operations

Team A

Team B

{U.C.7.2.6} Receive notifications

{C7.2.2.i} Consult operations interface

{C5.2.i} Configure tasks interface

{C7.2.1.i} Abort operations interface

Team C

Team D

{C6.6.i} Update simulation models data interface

{C7.2.3.i} Notifications interface

{C7.1.2.i} Consults driver guidance

{C7.3.i} Configure Driver guidance interface

{C7.3.c} Driver guidance processor

{C6.7.c} Users Appearance models processor

Route Simulation / Optimization

{P5.2} Integrator (Gateway)

{C7.2.4.1.c} Sensors integrator

{C7.2.3.c} Notifications processor

{C7.2.4.2.c} Mobile devices integrator

Team E

Driver Guidance

{C7.2.5.c} In-plant operations processor

{C7.2.4.3.c} Systems integrator

{P6.2} DB SLV {C6.3.d} Interventions and maintenance data

{C5.2.d} Configured tasks data

{C7.2.3.d} Notifications data

{C7.2.4.1.d} Sensors integration data

{C7.3.d} Driver guidance configurations data

{C7.2.4.2.d} Mobile devices integration data

{C7.2.5d} In-plant operations data

{C7.2.4.3.d} Systems integration data

4SRS address the functionalities to be implemented in the next Sprint or even more ahead Sprints. While this refined information is implemented, coded, tested and deployed, in parallel another module is refined within the same approach (i.e., use cases, 4SRS and architecture). This way, when the implementation of the previous module is finished (e.g., in Scrum, after the Sprint is finished), it is expectable that new sub-systems were refined and able for implementation. It must be pointed out that the 4SRS supports the logical view of the architecture, namely the identification and design of software components referring to functional requirements. Obviously that architecture should also address quality requirements. The 4SRS method is not able to address such requirements, but is able to coexist with other architecture-centric methods such as ATAM or QADA, which are also able for use within ASD [1]. The addressing of these requirements may be included in the backlog (sometimes referred as “Technical User Stories”), but their derivation is out of the scope of this paper. The information may now be gathered in a format that the team is familiar with, i.e., the set of stories and remaining items from the (Team) Product Backlog.

4 TRANSFORMATION RULES

Remote Check-in

{P1} Configurations {P3} Authentication

LargeScaleAgile’18, Porto, Portugal

{C6.6.d} Simulation models data IoT

{C6.7.d} Users Appearance models data

In this section is proposed a systematic transformation of modelbased requirements (UML Use Cases and Component diagrams) into ASD-oriented requirements, according to the backlog items. The backlog items decomposition follow the path of Themes, then Epics, then User stories, then finally tasks. Each User story has an associated Acceptance criteria (which gives the “Definition of Done” (DoD), and may have details that describe the requirements to implement the story in software. The backlog items are the following: Deriving Themes : A theme aggregates a group of requirements, as in agile it is realized by a set of Epics. A theme in a Backlog item relates to a generic concept. For that reason, a theme may be derived by the identified packages. In 4SRS, a package is identified for logically grouping a set of components from the architecture. Deriving Epics: An epic describes a requirement that further needs to be divided (in a User Story). A User Story is considered to be smaller than a Use Case. Additionally, it is discussed that a Use Case contains a set of interrelated User Stories. A commonly

Fig. 4. The architecture modularization

accepted proposal of such relationships is presented by Cohn [15]. For that reason, in our approach, this rule suggests that an

The process rationale is to first refine the architecture with 4SRS (starting with use cases from a given sub-system, performing 4SRS and deriving a refined version of the sub-system components) and deliver the architectural information to development teams, always synchronized with the development and deployment during the Sprints, in a sense that what is elicited, gathered and modeled during a cycle is then ready to be implemented in next cycles. These models require validation from customer before being ready to be included in the Team Backlog. The first time this requirements cycle is being performed, the development Sprint is not yet performed (or, at least, a Sprint 0 cycle is performed where, at this time, no executable software is delivered, but rather the development infrastructure is built). Then, requirements and the

epic is directly derived from a Use Case. Deriving User Stories: this rule proposes that the story creation should be based by each of the scenarios from a use case, which is in line with Cohn [15] and Jacobson [16], for instance. The scenarios are identified in the use case description, namely as main flow and alternate flow [17]. These flows in use case descriptions provide the business value of a given scenario from a use case, thus it related the requirements to the business value of the story. Deriving User Stories details: The inclusion of user stories in the backlog per se refers to “promises for a conversation” and not as actual requirements specifications. These specifications are commonly included separately within their ‘details’. The functional

3

LargeScaleAgile’18, Porto, Portugal (and some of the non-functional) behavior of the story is depicted by the software components responsible for executing the given functionality. These software components are identified by the 4SRS method execution, by tracing back to the use cases, which relate to user stories, as proposed in the previous rule. Another important aspect of the detail may be the context of use, which is depicted by scenarios, modeled in sequence diagrams as suggested during the modularization. Deriving Acceptance Criteria: The expected behavior after performing the use case scenario is described in the use case description, namely the post condition [17].

5 DISCUSSION 5.1 Backlog analysis By the time of the refinement process, the total of Use cases after refinement was 96. Relating to the total of logical architecture components after the refinement, only two modules could be measured, due to the fact that the remaining teams decided to go for implementation without performing the 4SRS method. These measures are presented in Table 1. When analyzing Team B module, the subset more than doubled after the refinement, as presented in Table 2. Table 1. Analysis on the product backlog Candidate Arch Before refinement After refinement Use cases 37 96 Components 77 94* *only measured for two modules Table 2. Analysis on the Team B backlog Team B module Before refinement After refinement Use cases 11 29 Components 15 39 The user stories were then derived and specified. A subset of the stories that compose Team B’s Team Backlog is presented in Table 3. The stories details are defined by input of the components from the 4SRS method execution, depicted in Table 4. Table 3. A subset of the team backlog Epic: Account Management Use Case: {UC1.1} Configure users account User As a SysAdmin, I want to Acceptance Criteria: Story create a user account in order SysAdmin is able to to configure user accounts. create user User As a SysAdmin, I want to Acceptance Criteria: Story change a user account in order changed information to configure user accounts. is stored. Table 4. Traceability between use cases / user stories and the components from the 4SRS Use Case Component {U1.1.1} Create user {C1.1.1.d} User data account {C1.1.1.i} Create user interface 4

N. Santos et al. The application of the transformation rules resulted in a Team Backlog composed by 61 user stories, which were implemented in four Sprints. Among them, only two stories were considered incomplete, i.e., required additional knowledge acquisition from the developers besides the components and sequence diagrams. All stories were foreseen and clear after the transformation rules. Regarding dependencies, no user stories were identified out of order. It must be also pointed out that, among the 61 user stories, 2 of them relate to stories with interactions with other team’s stories, and were immediately identified within the modularization. Table 5. Analysis on Team B Sprints 4 Sprints Team B Sprints Nr. Success stories 59 Nr. New stories 2 Nr. Unforeseen stories 0 Nr. Incomplete stories 2 Nr. Unclear stories 0 Nr. Out of order stories 0 Nr. Interface stories 2

5.2 Team coordination In these contexts, involving multiple Scrum teams, each team operates independently on the same product, but in different modules of logical architecture. The architecture modularization allows identifying interface components between modules, thus identifying connection points between the distributed developments. Additionally, there may be cases of overlapped architectural elements, which relates to dependencies between the distributed teams [14]. By assigning a module of the architecture to a given team, we are basically defining a subset of the backlog, i.e., a Team Backlog. Hence, it is assumed that each team is responsible for developing a set of connected features. Distributed teams (geographical distributed or not) work in parallel in order to develop increments on the same product, reflected in the modules of the logical architecture. In order to coordinate these teams and integrating their efforts, it is necessary to perform Scrum of Scrums (SoS) meetings with representatives of each team. In this meeting, integration scenarios are represented in a sequence diagram that uses the architectural components. The example illustrated in Fig. 5 relates to the development efforts between three teams, where each team works independently in their modules of logical architecture. However, the scenario requires the integration between three modules in order to be performed.

5.3 Applicability within the Scrum framework Although this paper relates to the application of the method in Scrum teams, the authors believe that it is generic for being applied in other ASD methods, like XP or Kanban. Also, it is perceived that such an approach is more helpful in LSA contexts, especially the sub-system partitioning and its further refinement. This approach is planned to be experimented in the future within LSA contexts. The derivation of the candidate logical architecture and architecture refinement are performed before the Sprints cycles. Only then there is context for deriving backlog items. The transformation of the artifacts in backlog items may be performed before or during a Sprint 0 cycle, where no software was delivered.

An experience on using architectural models in distributed Scrum Remote Equipment Analysis sequence diagram

Team A backlog

«Mobile/Web App»

{C7.2.1.i} Remote Equipment Analysis

Factory IT manager

Team B backlog

«Microservice»

{C2.1.1.i} Authentication Service

Team C backlog

«Microservice»

{C2.2.1.i} Authorization Service

«API»

{C6.1.3.i} Equipment management service

Get_authen(user, password) Authentication web token

Get_authorization(consult equipment service, authen_token) Authorized service

Fig. 5. Dependency between different teams Then, the process is then structured in Scrum Sprints. The main difference is that, in parallel with carrying out typical disciplines within the Sprints (Implementation, Testing and Deploy) that result in the delivery of a software increment, other team members are responsible for refining requirements not yet included in the Backlog, and that are planned to be implemented in further Sprints. Requirements and Analysis tasks are performed in iterative cycles and incrementally, always synchronized with the development and deployment during the Sprints, in a sense that what is elicited, gathered and modeled in use cases during a cycle is then ready to be implemented in next cycles. They originate a new increment of the 4SRS method, deriving additional components to the logical architecture under refinement. These models require validation from customer before being ready to be included in the Team Backlog. Then, requirements and the 4SRS address the functionalities to be implemented in the next or in ahead Sprints. By assigning a module of the architecture to a given team, we are basically defining a subset of the backlog, i.e., a Team Backlog. Hence, it is assumed that each team is responsible for developing a set of connected features. The predefinition of a subset (or a given feature) of the backlog is also present in approaches like Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Enterprise Scrum, and Spotify model (or Squads/Tribes).

5.4 Lessons learned In the UH4SP project, the fact that it aimed to act within a complex ecosystem was taken in consideration for applying the 4SRS method. The 4SRS is a tool for tracing components and functional requirements models, moreover in large-scale contexts. We believe that the inclusion of modeling tasks in parallel with Sprints strengthened the Scrum process in the project. The entire research was a learning process, with advantages and disadvantages. The advantages relate to the traceability between architecture and requirements, especially when changes occurred during Sprints. Previous experiences in using 4SRS and delivery of work items to Scrum teams [14] were performed in BDUF contexts, which required around 9 months to derive a logical architecture composed

LargeScaleAgile’18, Porto, Portugal with 107 components, which then were used to derive user stories. The emerging approach within this research allowed to first propose a candidate architecture after 2 months. The architectural model was used as a shared understanding and also provided a clear view of each entity’s role within the project. When incrementally modeling the UML Use Cases in Sprints, the requirements package was also composed with wireframes, to enrich the discussion and benefited of user feedback. The components supported the project’s pilot scenarios. However, the candidate architecture encompasses next releases in order to follow the product roadmap. As a disadvantage, it is difficult to commit the entire consortium towards the approach. The candidate architecture was proposed and the sub-systems delivered to all entities, however it was not possible to compare the approach within all teams. Other teams used Scrum for their sub-systems but did not follow the approach for implementing their backlog, or did not used an ASD approach.

7 Conclusions This paper presents an approach for modeling a small set of requirements and a candidate architecture in UML, that afterwards originate ASD-oriented backlog items. The complexity is addressed by scaling the development, namely by distributed Scrum teams. The candidate architecture is designed by using the 4SRS method for deriving a logical architecture, which is then modularized, refined, and used as input for backlog structure, namely themes, epics, user stories and acceptance criteria.

References [1] R. L. Nord and J. E. Tomayko, “Software architecture-centric methods and agile development,” IEEE Softw., vol. 23, no. 2, pp. 47–53, 2006. [2] T. Dingsøyr and N. B. Moe, “Towards Principles of Large-Scale Agile Development: A Summary of the workshop at XP2014 and a revised research agenda,” 2014. [3] T. Dingsøyr, T. E. Fægri, and J. Itkonen, “What is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development,” in Product-Focused Software Process Improvement, Springer, 2014, pp. 273–276. [4] P. Abrahamsson, M. A. Babar, and P. Kruchten, “Agility and architecture: Can they coexist?,” IEEE Softw., vol. 27, no. 2, pp. 16–22, 2010. [5] S. Jeon, M. Han, E. Lee, and K. Lee, “Quality attribute driven agile development,” in 9th International Conference on Software Engineering Research, Management and Applications (SERA), 2011, pp. 203–210. [6] S. Ambler, “Agile Model Driven Development (AMDD),” XOOTIC Mag., 2007. [7] N. Ferreira, N. Santos, R. Machado, J. E. Fernandes, and D. Gasević, “A V-Model Approach for Business Process Requirements Elicitation in Cloud Design,” in Advanced Web Services, Springer New York, 2014. [8] P. Kruchten, “The 4+1 View Model of Architecture,” IEEE Softw. , 1995. [9] IIBA, Agile Extension to the BABOK Guide. 2017. [10] J. O. Coplien and G. Bjørnvig, Lean architecture: for agile software development. John Wiley & Sons, 2011. [11] S. Farhan, H. Tauseef, and M. A. Fahiem, “Adding agility to architecture tradeoff analysis method for mapping on crystal,” in Software Engineering, 2009. WCSE’09. WRI World Congress on, 2009, vol. 4, pp. 121–125. [12] Rick Kazman, “Foreword - Bringing the Two Together: Agile Architecting or Architecting for Agile?,” in Agile Software Architecture: Aligning Agile Processes and Software Architectures, 2013, pp. xxix–xxx. [13] A. Cockburn, Agile software development: the cooperative game. Pearson Education, 2006. [14] N. Costa, N. Santos, N. Ferreira, and R. J. Machado, “Delivering User Stories for Implementing Logical Software Architectures by Multiple Scrum Teams,” in Computational Science and Its Applications–ICCSA 2014, Springer, 2014. [15] M. Cohn, “Advantages of user stories for requirements,” InformIT Netw., 2004. [16] I. Jacobson, I. Spence, and K. Bittner, Use case 2.0: The Definite Guide. Ivar Jacobson International, 2011. [17] A. Cockburn, Writing effective use cases, The crystal collection for software professionals. Addison-Wesley Professional Reading, 2001.

5