Article Preview
TopIntroduction
The initial phases of software product development require a careful analysis of the business to which the application is addressed. In particular, the analysis will identify information such as the goals and processes of the business. This information will then form the basis on which to identify and specify the requirements, both functional and non-functional, of the system to develop (Grau, Franch, & Maiden, 2008; Cardoso, Almeida, & Guizzardi, 2009; Traetteberg & Krogstie, 2009).
The information generated from such analyses is detailed in specific artefacts. For example, the business goals are documented in a Goal Model, and the business processes in a Business Process Model (Ullah & Lai, 2011). The same applies to the system requirements (Chung & do Prado Leite, 2009). The functional requirements are documented in the Use Case Model and the non-functional in the Supplementary Specification Document (OpenUP, 2013). In this way the characteristics of each type of information are detailed in a specific artefact without interfering with other elements.
Later, at the system design phase, all this information must be analysed and consolidated. The architect must know how non-functional requirements influence the functional ones in order to make the architectural decisions that best facilitate the fulfilment of both requirements (Capilla, Ali Babar, & Pastor, 2012).
The consolidation of this information is complicated and costly. Firstly, the architect has to know the content of every artefact and, secondly, he or she has to identify the relationships between the elements. Because each document is focused on specific types of elements, their interdependencies are usually detailed implicitly, leaving the architect the task of discovering and inferring the network of relationships. Thus, for example, in the Business Process Model the Goals that impose restrictions or limitations that affect some of the modelled tasks are not detailed. Instead, it is the architect who, depending on his or her experience and ability, has to detect this kind of information. If the architect misunderstand or misinterpret the requirements and/or their interdependencies, it is highly likely that he or she will end up making an architectural decision that will hinder, or even prevent, some of the requirements being met, thus jeopardizing the project’s success.
There have been various studies aimed at making these relationships explicit. In Pavlovski and Zou (2008), the authors define how to model business operational restrictions in business processes in order to define controls to handle these restrictions. In Dörr (2011), the authors add notes to the use case diagrams, detailing in natural language the non-functional requirements that each use case must satisfy. In the present work, we examine how to document these relationships so that they can be reused in subsequent phases of development.
In particular, we define how to make explicit the relationships both between elements of the business and between the requirements, the objective being that the architect can subsequently use them for designing the system. To that end, we have defined an extension of BPMN 2.0 (2013), to support the modeling of relationships between business elements, and a set of profiles for UML 2 Use Case, Activity, and Sequence Diagrams (UML, 2013), to support the modeling of relationships between functional and non-functional requirements. In addition, we have also defined a model for documenting the system architectural views and how each non-functional requirement impacts on each view. Thus, more information on the relationships is transmitted to the architect, reducing the chances of their misinterpretation. These annotations and models are also used to preselect the architectural patterns that can be applied to meet the requirements. This is possible thanks to the definition of a set of rules which, when applied to the models and annotations, facilitate this selection. The result is to narrow down the solution space that the architect has to explore.