Keywords

1 Introduction

Software systems, one of the most complicated things developed by humankind, became an essential part of our everyday lives and from which we are completely dependent on. Their existence is so pervasive that, nowadays, society expects them to assist us either in critical activities or in our everyday activities, to have high quality, to provide exciting functionalities, to be reliable, and to be produced at low cost.

Given the increasing demand and complexity of software systems, the software engineering discipline has accumulated, over the last years, an extensive scientific body of knowledge related to theories, methods, approaches, and tools needed to construct software systems [1]. To cope with the growing complexity and diversity of engineering problems, the adoption of systematic and disciplined approaches to deal with requirements and their problems has become crucial [1]. The study and research about requirements is extensive in literature, covering diverse areas, such as the design of requirements modeling languages [2] or model transformation techniques and code generation [3]. Recently, Fernandes and Machado [1] addressed the essence, issues, and techniques for requirements in engineering projects. Requirements engineering, in the context of the development of a system through an engineering project, embodies a set of activities that permits eliciting, negotiating, and documenting the functionalities and the restrictions of that system [1]. As an engineering discipline, is closely related to the concept of project; it is throughout the project that the engineer applies his technical and scientific knowledge, to solve the problems and to achieve the objectives which he is confronted with [1]. In turn, the concept of project is closely related to the concept of process.

Most individual requirements developed during the requirements engineering process relate to and affect each other in different ways and thus cannot be treated in isolation [4, 5]. The fact that the requirements relate to and affect each other makes it necessary to identify and manage the requirements interdependencies in order to avoid potentially costly mistakes during the system development.

Requirements interdependencies are not a problem by themselves, but they influence the number of development activities and decisions made during the software engineering process [6]. Traceability is the basis for studying the requirements inter-dependencies during the development process [7] since it allows identifying and justifying the artifacts that implement the requirements initially formalized.

Software development produces various kinds of artifacts. The artifacts, such as requirements, do not exist in isolation; instead they relate to and affect each other [8]. During the development of solutions and also during the exploration phase for maintenance issues, frequently arises the need to introduce several changes to the project decisions previously established. These changes should be clearly identified to ensure the complete identification of the artifacts involved in the changes. To this end, it is necessary to have knowledge about how the different artifacts relate among them since it facilitates the identification of the artifacts affected.

RUP is a process that provides the best practices and guidelines for successful software development [9]. This work, in the context of Business Modeling and Requirements disciplines of RUP, analyzes and systematizes the traceability and the interdependencies that may occur between the various elements during software development projects.

This paper has the following structure: Sect. 2 presents the importance of dealing with the interdependencies and the traceability during the software development; Sect. 3 describes the interdependencies and the traceability between the different elements of the RUP; Sect. 4 presents the conclusions.

2 Interdependencies and Traceability

Requirements traceability is an issue that for long time is investigated and discussed, such as in [10]. Dahlstedt and Persson [7] refer to traceability as “a basis for addressing the requirements interdependencies”. According to Genvigir [11] and Zou et al. [12], traceability is intimately associated to the software production process, specifically to the requirements and to the ability to establish links between these requirements and other artifacts that satisfy them.

Sánchez et al. [13] mention that the requirements traceability aims to help determine the impact of changes in the conception phase of software, to support their integration, preserve the knowledge and assure the quality and correction of the global system.

Requirements traceability is as a quality factor [6, 14–16]. Actively supporting traceability in a software development project can help ensuring other qualities of software, such as adequacy and understandability [15].

On the other hand, neglecting the traceability can lead to less maintainable software and to failures due to inconsistencies and omissions [15]. Dömges and Pohl [17] refer to neglecting the traceability or capture insufficient and/or unstructured traces leads to decrease in system quality, causes revisions, and hence, increases project costs and time.

Aizenbud-Reshef et al. [18] refer that, from the perspective of requirements management, traceability facilitates the interconnection of requirements to their origins and reasons. Additionally, it allows capturing the information needed for understanding the evolution of requirements and for verification of requirements fulfillment. Complete traceability allows calculate more accurately the costs, as well as to determine lists of changes, without depending on the programmer knowledge of all the areas that these changes affect [18]. All these reasons make crucial to implement traceability practices throughout the software development.

It is essential to identify and manage the interdependencies that occur throughout the system development in order to, if needed, in any context, to properly consider related artifacts and as such, to avoid potentially costly mistakes by neglecting either those relations or eventually relevant artifacts As mentioned earlier, through traceability, it is possible to manage these interdependencies; hence, traceability is fundamental to the development process.

Several works further develop traceability practices and theories [19, 20]. Marques et al. propose a traceability representation language [21] that provides “abstractions to requirements, artifacts and trace links as well as queries, through which trace links can be searched, retrieved and filtered”. In addition, they also propose a requirement traceability process [22] specifying its workflow, actors, responsibilities and inputs/outputs. Rempel and Mäder [23] review the elements involved in establishing traceability in a development project and derive a quality model for the systematic assessment of requirements traceability. To facilitate traceability in the model centric paradigm, Badreddin and Sturm [24] call for representing requirements as first class entities aiming to enable software developers, modelers, and business analysts to manipulate requirements entities as textual model and code elements. In this context, they propose a Requirement-Oriented Modeling and Programming Language (ROMPL). Soonsongtanee and Limpiyakorn [25] present an approach to enhancing the requirements traceability matrix with UML state diagrams to describe the traceability states of associated requirements or life-cycle work products. Regarding requirements interdependencies, Berrocal et al. [26] present a set of profiles to allow designers to explicitly model interdependencies between elements in BPMN 2 and UML 2 Use Case diagrams. They also define ATL transformations to automatically derive these relationships from the business specification to the requirements models.

The purpose of dealing, systematically, with requirements interdependencies improves the decisions made during software development as well as to detect the potential problems that may arise because of the requirements interdependencies [6]. Managing requirements interdependencies consists in identify, store and maintain information about how the requirements relate to and affect each other [6].

Maintain traceability of the requirements interdependencies is essential in order to support various situations and activities in the system development process [7]. Traceability should be included and treated along the development projects, thus representing, an asset to their success. Knowing the whole story of the artifacts, as well as their interdependencies, will enable easier identification and management of existing interdependencies from the early stages of development. Therefore, this knowledge minimizes problems that may arise during the software development process.

3 Interdependencies and Traceability in RUP

RUP aims to ensure the production of quality software that meets the needs and expectations of its users in a predictable schedule and cost [9]. RUP guidelines entail several elements such as activities, tasks, roles and work products. Throughout the development process, at several moments, RUP elements become interconnected; by this way, a simple change in an element causes various subsequent adjustments in others. Therefore, the knowledge of existing interdependencies between the various elements is particularly useful since it allows easier identification of elements affected during a change.

As Dahlstedt and Persson [7] refer, is essential to maintain the traceability of interdependencies since it allows to know, in detail, how the elements relate, as well as to support various situations and activities in the software development. Through the traceability of various elements of RUP, it is possible to easier identify and manage the interdependencies that may occur between elements. For those practitioners that adopt RUP guidelines, it is useful to understand the interdependencies that may exist between the various RUP elements.

3.1 Dependency Analysis of Activities and Tasks

RUP is organized in various disciplines and phases. However, the study mentioned in this paper focuses in two transitions (see Fig. 1): (1) from the Business Modeling discipline to the Requirements discipline, at Inception phase; (2) from the Inception to the Elaboration phase, within the Requirements discipline.

Fig. 1.
figure 1

Positioning of the study in the RUP (Based on [27]) (Color figure online)

Full size image

To facilitate an overview and analysis of all tasks of RUP (for Business Modeling and Requirements disciplines), the conduction of an initial RUP review allowed the construction of information presented in Tables 1 and 2.

Table 1. Activities, tasks, phases and roles of the business modeling discipline.
Full size table
Table 2. Activities, tasks, phases and roles of the Requirements discipline.
Full size table

These tables show the different tasks of the disciplines of Business Modeling and Requirements, the activities associated with these tasks, the phase where they are performed, and the roles responsible for them. Table 1 details the activities, tasks, phases, and roles of the Business Modeling discipline considering both processes of Classic RUP Lifecycle and Business Modeling Lifecycle.

The column Activities presents the five activities performed in this discipline. The activities performed in the Classic RUP Lifecycle process are signaled in the table by an α, the activities performed in the Business Modeling Lifecycle process are signaled by an β and the activities performed in both processes are signaled in the table by αβ.

Column Tasks exposes all tasks practiced in the Business Modeling discipline. Only the tasks with a gray background were studied, since the other stand in phases that are outside the scope of our study. The intersection of column Activities with the lines of column Tasks indicates (through an ‘x’) the tasks included in the activities.

Column Phases presents which phases include the different tasks and activities. The abbreviations B1, B2, B3, B4 and B5 (for the various activities) associate tasks and their activities to the several phases. Column Role main refers which are the roles responsible for performing the different tasks. The activities with blue background (Assess Business Status, Describe Current Business and Develop Domain Model) and the phase (Inception) refer to the activities and the phase studied in Business Modeling discipline.

Table 2 presents the activities, tasks, phases, and roles of the Requirements discipline. Column Activities presents the six activities practiced in this discipline. As before, in the table, α signals activities performed in the Classic RUP Lifecycle process, β signals activities executed in the Business Modeling Lifecycle process, and αβ signals the activities performed in both processes.

Column Tasks exposes all tasks practiced in the Requirements discipline. In this discipline, all tasks have a gray background since they are in the phases of the scope of this study and as such, covered by this study. An ‘x’ at the intersection of column Activities with the lines of column Tasks indicates the tasks practiced in the activities.

Column Phases presents tasks and activities performed in the different phases. Abbreviations R1, R2, R3, R4, R5 and R6 (for the various activities) associate the tasks and their activities to phases where they are performed. In the intersections, we use α for Classic RUP Lifecycle, β for Business Modeling Lifecycle and αβ for both processes. The intersections show the process where the tasks and their activities are performed.

As in the previous table, the column Role main refers to the roles responsible for performing the different tasks.

The activities with blue background (Analyze the Problem, Understand Stakeholder Needs, Define the System, Manage the Scope of the System, Refine the System Definition and Manage Changing Requirements) and the phases (Inception and Elaboration) refer to the activities and the phases studied in Requirements discipline.

The information provided in these tables is useful throughout the software development because it allows to perceive how activities, tasks, and roles relate in a particular discipline and phase.

3.2 Dependency Analysis of Work Products and Tasks

The elaboration of the previous two tables allowed to perceive the tasks and activities covered in the disciplines and phases considered in this study. Tables 3 and 4 have the purpose of clarifying the interconnection of all work products of both disciplines to their respective tasks.

Table 3. Work products of the tasks of the Business Modeling discipline.
Full size table
Table 4. Work products of the tasks of the Requirements discipline.
Full size table

The first column of Table 3 shows all the work products of the Business Modeling discipline and the second column presents all the tasks. Only the tasks with a gray background were analyzed because the other tasks are in phases that are not within the scope our study.

The intersection of these two columns depicts the work products consumed and produced in the various tasks. These intersections use the terms IN, OUT and I/O: the term IN is used to refer work products consumed by the associated task; the term OUT represents the work products produced by the task in question; the term I/O represents that the work products are both consumed and produced by the task in question. Besides these terms, the term IN* refers to work products that are an optional entry of the associated task; these work products are not necessarily consumed in the task. In the tables, the use of colors facilitate the identification of terms IN, OUT, and I/O: the term IN is represented by the green color, the term OUT by the red color and the term I/O by the yellow color.

The first column, Table 4 shows all the work products of the Requirements discipline and in the second column presents all the tasks. All the tasks of this discipline were analyzed because all the tasks are in phases that are within the scope our study. The intersection of these two columns depicts which work products are consumed and produced in the various associated tasks. These intersections use the terms IN, OUT and I/O, which were previously defined.

Tables 3 and 4 show the work products produced and consumed by the different tasks. The information available in these tables allows the identification of existing interdependencies between tasks and work products that are produced and consumed.

Figures 2 and 3 present two graphical representations that were developed to enhance the perception of the information contained in the previous tables; i.e., all the existing interdependencies between the activities and the tasks and work products of a given phase and discipline. This visualization facilitates the analysis of the existing interdependencies along the development process, thus allowing for a better understanding and management.

Fig. 2.
figure 2

Scheme Business Modeling@Inception (Color figure online)

Full size image
Fig. 3.
figure 3

Scheme Requirements@Inception, Elaboration

Full size image

The representation of the Tables 1 and 3. This representation refers to the Business Modeling discipline in the Inception phase. It presents the five activities belonging to this discipline. These activities interconnect to their tasks; two of these activities have no associated tasks because they are outside the scope of this study.

Each task has its associated work products. These work products may be consumed in the associated task (inputs, graphically represented by arrow green) or may be produced by that task (outputs, graphically represented by arrow red). The work products represented in yellow refers to work products belonging to the Business Modeling discipline.

The work products, represented in orange, despite being work products produced and consumed in this discipline|phase, do not belong directly to work products defined by RUP for this discipline. For these work products (in orange), a description below them indicates the discipline and the phase to which they belong; some of those do not have associated discipline because, in concrete, they do not belong to any.

The representation of the Fig. 2 is based on information gathered in the Tables 2 and 4. This representation refers to the Requirements discipline in the Inception and Elaboration phases. It presents the six activities belonging to this discipline, as well as its interconnected tasks. All these activities have associated tasks because all of them are within the scope of this study. Each task has its associated work products. These work products may be consumed in the associated task (inputs, graphically represented by arrow green) or may be produced by that same task (outputs, graphically represented by arrow red). The work products represented in yellow refers to work products belonging to the Requirements discipline.

The colored background areas allow perceiving that two tasks are handled in both phases, thus verifying that there are interdependencies between the phases. The tables built facilitate the identification of interdependencies, not only among activities, tasks, phases and the roles, but also among tasks and work products, of the disciplines under consideration.

These tables, as well as the graphical representations allow analyzing the traceability of various elements of RUP, as well as easily identifying all the existing interdependencies between those elements. This becomes particularly useful since it allows knowing in detail how the various elements of the RUP process are related.

The information provided in these tables and representations, improve the practitioner’s capacity in dealing with the impact of changes and in supporting better development decisions.

This systematization of the interdependencies is also useful to compare a particular method/process model with the RUP since it allows knowing in detail how the RUP is organized. The study of traceability and of the interdependencies between the various elements of the RUP may be extended to all disciplines and phases that compose this process. The expansion of the study will allow detailing how the various elements are related throughout the whole RUP process.

4 Conclusions

RUP is a process that provides best practices and guidelines for successful software development. However, this does not provide any information that enables for easy identification of traceability and existing interdependencies between the various elements that constitute it. Throughout the software development, this can become a problem since there is no explicit native information on RUP documentation on the inter-relation of RUP elements.

Our work produced several tables and graphical representations in order to highlight how the various RUP elements are related. These tables and graphical representations allow, from the initial phases of development, an easier identification of the various interdependencies and the traceability among elements, as well as to provide a deeper knowledge about the organization of RUP. This is quite advantageous since it is possible to avoid unconscious decisions during the development process as well as to detect early potential problems due to the existing interdependencies.