1 Introduction

Requirements for a system are a collection of needs expressed by stakeholders respecting some constraints under which the system must operate. Requirements engineering is the process by which requirements for systems and software are elicited, documented, analyzed and managed throughout the development life cycle [33], including activities of tracing requirements. Requirements engineering can be divided into two main groups of activities [32]. First group is the development of requirements, which includes eliciting, documenting, analyzing and validating requirements. Second group is requirements management, which includes tracing and change management of requirements.

Among many other modeling languages, UML [31] has traditionally been applied to document requirements through Use Case diagrams [46, 50]. Requirements are then organized into stories of using the system that acts as an organization between users, technical and business stakeholders [18, 48] and [17]. There are some issues involved with using Use Case diagrams for modeling real-time requirements. Use Case diagrams are most often used to describe scenarios of requirements, not individual requirements. Besides, Use Cases are informal and can be misinterpreted when too many details are included in the models [1, 43]. Proposals to address problems of UML in relation to modeling real-time software were introduced, including new UML profiles which add elements to model time requirements, system requirements and non-functional properties. These include MARTE [29] and SysML [30].

SysML Requirements diagram shows explicitly relationships between requirements, increasing the spectrum of understanding and defining real-time system requirements. However, the SysML profile by itself does not provide concepts for representing temporal, behavioral and performance requirements, nor provide elements for explicit representation of system configurations. MARTE profile provides key resources to specify non-functional requirements for real-time systems, generally time requirements.

MARTE and SysML profiles have been applied in past years in various domains, such as railway control [5], concurrent systems [40], design of distributed embedded systems [12], and in many other industrial environments [20, 34] and [21]. However, few approaches were proposed with focus on applying MARTE and SysML together to design RTS, and even less with focus on requirements modeling, which is the purpose of this article.

One of these approaches [35] defined a systems modeling language based on subsets of MARTE and SysML, allowing iterative refinement from high-level specification to its implementation. Another approach [36] does not have focus on requirements. In other approach, described in [14], the authors assess possible strategies for combining SysML and MARTE in a common modeling framework, while avoiding specification conflicts. Although the authors came to the conclusion that the two are highly complementary for specifying embedded systems at different abstraction levels, they also found that a convergence agenda is highly desirable to align some key language features.

The work presented in [26] proposes a model-driven approach for requirement engineering targeted to the embedded software domain, named MDEReq (Model-Driven Engineering for Requirement Management). The approach integrates UML, MARTE and SysML models to improve and facilitate requirements specification. This is similar to the work presented in [10], in which the authors propose a metamodel for requirement traceability and establishes a link between requirement model, solution model and V&V model flows and affords full traceability of requirements, including those set for heterogeneous models. The focus of these two works is most on traceability matrixes between models, and not on MARTE stereotypes for requirements specification.

Model-based approaches are often applied to contribute to handle complexity of RTS development. Research presented in this article is about requirements development, mainly the activities of documenting and analyzing user requirements for software systems. In this article, the proposal is to combine UML, SysML Requirements diagram and MARTE stereotypes to improve activities of requirements specification for RTS. Among the objectives of this research is the representation, in a single metamodel, of an appropriate model to create requirements specifications for RTS with additional attributes included in the SysML Requirements diagram. The MARTE profile provides key resources to specify non-functional requirements for RTS, as for instance, temporal aspects and constraints. The SysML profile alone does not present the representation of temporal, behavioral and performance requirements. Therefore, we propose to combine SysML models with MARTE stereotypes. Thus, in addition to the factors mentioned above, we can say that the proposed approach has an important role to specify RTS at different levels of detail and levels of abstraction. The main focus is to show how these profiles can be combined and applied for modeling time, performance, system configuration, and of course, the functional and non-functional requirements of RTS. Improved tracing between requirements is proposed with new relationships between requirements. A road traffic control system is used as case study to demonstrate the applicability of the proposed approach.

2 Theoretical background on MARTE and SysML

Among the proposed UML profiles, two are used in this article. SysML, because of its Requirements diagram, and MARTE, due to its several stereotypes used to specify non-functional properties. Both profiles are briefly described in this section.

2.1 MARTE

Architecture of the MARTE profile, depicted in Fig. 1, consists of three main packages. MARTE Foundations aims at defining fundamental concepts for embedded RTS, including concepts that are useful as a general basis for the description of most of the elements. MARTE Analysis Model provides concepts for model verification and validation [22]. MARTE Design Model provides support to conduct a detailed specification of a RTS.

Fig. 1
figure 1

MARTE profile [29]

Full size image

In addition to these packages, the MARTE profile proposes numerous other subpackages. MARTE Foundations relates to the scope of this work (more specifically the first three subpackages) and, for this reason, these are briefly described as follows.

  • Time Modeling—Time: allows modeling of time and related structures, including concepts related to logical time, physical time, representation of instants representing time bases and occurrences of events over time.

  • Non-Functional Properties Modeling—NFPs: offers paths to specify non-functional properties of RTS, such as memory usage and power consumption.

  • Core Elements: provides basic elements for behavioral modeling and semantic representation of its running time.

  • Allocation Modeling—Alloc: an application element in MARTE can be a service, computation or a function of the operating system. An execution platform is a collection of connected resources representing the hardware architecture. It consists of hardware resources such as memory resources, communication devices and computing resources.

  • Generic Resource Modeling—GRM: provides stereotypes and tagged values to represent features such as communication means, computing resources and storage resources. It also includes resources that are needed to deal with the modeling of execution platforms at different levels of abstraction and modeling.

2.2 SysML

Although UML lacks important modeling characteristics for systems and is considered to be more adequate to modeling software elements, it appeared as a good candidate to be extended with elements that could meet the most important requirements and characteristics for modeling systems that involves not only software, but also elements such as mechanical components, hardware and electronic parts.

SysML is a UML profile [30] applicable to various types of engineering applications, enabling specification, analysis, design, verification and validation of complex systems. Results from article [41] describes SysML as a suitable modeling language for systems architecture. SysML profile is supported by OMG (Object Management Group) and by INCOSE (International Council on Systems Engineering) [30].

Fig. 2
figure 2

Basic node for SysML Requirements diagrams

Full size image

SysML Requirements diagrams provide support for modeling individual requirements and their relationships. The basic graphical node to design requirements diagrams is depicted in Fig. 2. SysML Requirements diagram allows to model requirements relationships in various manners. These relationships are briefly described as follows.

A requirement that is contained within another requirement is described by the Hierarchy Requirement Relationship. This element means the relationship allows relating requirements in different hierarchical levels. A common example is the hierarchical gradual specification of requirements, from high-level business requirements into more detailed software requirements. This relationship is represented by a circle with a plus sign inside (\(\bigoplus \)).

Each design element of the model has as purpose, directly or indirectly, to satisfy a requirement of the system. The Satisfy Relationship describes these situations, by modeling design elements that performs/satisfies a specific requirement.

Copy Relationship, denoted as a dotted arrow pointing from the copy to the original and the stereotype \({\ll }{\textit{copy}}{\gg }\), describes a requirement that is a copy of another requirement. This relationship is useful for reusing a particular requirement in another context.

Derive Requirement Relationship, represented by stereotype \({\ll }{\textit{deriveReqt}}{\gg }\), describes a requirement that was derived from another requirement. This relationship explicitly shows when a requirement can result in other requirements.

Verify Relationship, denoted with a dashed arrow, pointing from the test case in the direction of a requirement, with stereotype \({\ll }{\textit{verify}}{\gg }\), connects a test case with the requirement that is verified by this test case. A test model usually defines a large number of test cases that test whether requirements are properly implemented in the system.

Refine Relationship specifies that one model element describes properties of a requirement into more detail. For example, a functional requirement can be refined by one or more use cases.

Trace Relationship is a relationship between a requirement and an arbitrary model element. It describes a general relationship for traceability reasons.

Fig. 3
figure 3

Metamodel for SysML and MARTE

Full size image

3 Combining SysML and MARTE in a metamodel

The metamodel proposed in [37] is extended in this article, as presented in Fig. 3. SysML Requirements diagram has been extended with additional relationships to allow a new representation for software requirements. New attributes for extended requirements take into consideration specifications of the IEEE 830-1998 standard for documenting software requirements [19].

An extended requirement, represented by stereotype \({\ll }{\textit{ExtRequirement}}{\gg }\) is proposed here. In addition, derived from this extended requirement, an extended requirement for non-functional requirements is proposed, represented by \({\ll }{\textit{ExtRequirementNFR}}{\gg }\), with additional attributes. Three types of non-functional requirements are proposed in the metamodel, as depicted in Fig. 3.

Original attributes of SysML Requirements are ID (title) and text. Title is unique and briefly indicates the requirement context, and the text attribute is a short explanation of the requirement. New defined attributes for ExtRequirement are classification, type, priority, abstractLevel, constraint, scenario, creationDate, modificationDate, versionNumber and stakeholder. They are all optional in a model.

Attribute classification describes whether the requirement is functional or non-functional.

Attribute type indicates special features of a requirement, as for instance, if it represents a special state, if it relates to events, or if it represents timed elements (clocks). In order to model SysML Requirements diagram with MARTE stereotypes, it is mandatory to import packages from MARTE Foundations that relate to the behavior of an element of the domain (CoreElements package), including non-functional properties (NFPs) and elements that relate to the time structure (package Time).

Attribute priority defines the relevance of a requirement in relation to the other, i.e., indicating the order in which requirements should be addressed.

Attribute constraint, of type boolean, shows requirements that have some type of restriction. If it is set to true, the identifier (ID) and the detailed description of this restriction are contained in a table of restrictions.

Attribute level indicates the classification level of each requirement in the hierarchy.

Scenario is an attribute of type String which basically identifies the scenario to which the requirement is related.

Attributes creationDate and modificationDate are of type string with the purpose to annotate creation date of the requirement and date on which it was modified.

Attribute versionNumber is useful to keep track of multiple versions of the requirement. This is important when a stakeholder changes the requirement. In this case, everyone knows how many times the requirement has been changed.

Attribute stakeholder, of type string, relates directly to attributes modificationDate and versionNumber since it defines the responsible for every possible change requested for a requirement, on a given date, including its creation.

Stereotype ExtRequirementNFR is used to describe non-functional requirements. Proposed attributes are environmentFactor, cost and levelQoS.

Attribute environmentFactor determines whether a requirement is dependent on an external factor to be implemented. In general, this attribute allows anticipate external features to the system, in development, and that has an impact on the development/design of it. It is an attribute of type string and brings a brief description of the dependency factor. Attribute cost is an enumeration type that defines Strings used for specifying the possible values for the development of a system requirement. The enumerations are the type high, medium or low and allows for the establishment of criteria of costs to satisfy a requirement that influences directly in those decisions concerning the viability of its development. Attribute qualitylevel indicates the level of quality required for the requirement, and cal also assume values high, medium or low. With this semantics, for the attribute qualitylevel, it becomes possible to predict whether standardization strategies should be taken/established during system development activities.

Performance type has three attributes. Attribute respTime indicates the maximum response time associated with a requirement. Its value allows for establishment of which performance level is to be associated or is to be guaranteed by the requirement. Attribute capacityOp indicates the number of simultaneous operations that are allowed on a given time period (e.g., number of reports generated for storage, operations per second). Attribute recoveryTime describes the maximum time required for recovery from a failure.

Timing type of non-functional requirement relates to the description of time in software. Its attributes are typeTime, which can assume values such as physical time or logical time, minResponseTime and maxResponseTime, which are used to describe timing constraints of a requirement.

Safety type of non-functional requirement has attributes integrity (level of integrity that must be guaranteed), accessLevel (establish the level of access of stakeholders to a function) and limitedC, which enables demonstration of whether communication should be limited between this requirement and other functions/modules of the system.

Fig. 4
figure 4

Metamodel of extended relationships

Full size image

3.1 Extended relationships to the SysML Requirements diagram

SysML Requirements diagram allows several ways to represent requirements relationships, as previously described. In this work, three new stereotypes are proposed. The extended model and the new developed relationships, from the extensions to the basic relationships of SysML, are able to represent requirements at different levels of abstraction, correlated requirements at the same level and, also, synchronism between requirements to be implemented as depicted in Fig. 4.

Stereotype \({\ll }{\textit{linkage}}{\gg }\) (Fig. 5), represented by an arrow and a dotted circle with an internal dotted cross on both ends (graphical notation this becomes necessary for differentiating the new established relationship to the UML nesting relationship), has the purpose of improving the activity of tracing requirements. The linkage relationship explicitly shows, in the created models, the interconnections of a requirement at any level of the requirements hierarchy. Thus, it is possible, for example, to determine trace of a requirement in high level toward their functional and/or non-functional requirements.

Fig. 5
figure 5

Relationship linkage

Full size image
Fig. 6
figure 6

Relationship \({\ll }{\textit{Aggregate}}{\gg }\)

Full size image

Stereotype \({\ll }{\textit{aggregate}}{\gg }\) (Fig. 6) is proposed in order to explicitly demonstrate correlated requirements (in the same classification level) with a requirement one level up; i.e., requirements that are represented with this stereotype will together provide functionality expected by a higher requirement and are strongly bonded together. Therefore, requirements connected through the \({\ll }{\textit{aggregate}}{\gg }\) relationship are strongly integrated and supply, together, a functionality proposal by a higher-level requirement. This relationship allows to represent the decomposition of requirements and/or its grouping to compose subsystems. Thus, the \({\ll }{\textit{aggregate}}{\gg }\) relationship allows, for analysis and study, the modeling of functionalities of a system in an aggregated manner.

Finally, new stereotype \({\ll }{\textit{synchronized}}{\gg }\) is designed to be used by non-functional requirements that need to describe in addition to performance constraints, the ability to be processed/executed concurrently. Its graphical representation is depicted in Fig. 7.

Fig. 7
figure 7

Relationship \({\ll }{\textit{Synchronized}}{\gg }\)

Full size image

3.2 MARTE stereotypes

In most cases, concepts defined in the domain for subpackage CoreElements, subpackage Non-Functional Properties and subpackage Time presented in the last section are represented in MARTE through a stereotype that extends a UML modeling element. Thus, the UML extensions required for supporting the concepts defined in MARTE and the stereotypes are described in this subsection.

Table 1 Package MARTE Foundations: stereotypes of CoreElements
Full size table
Table 2 Package MARTE Foundations: stereotypes of non-functional properties
Full size table

The set of extensions used to support Core Elements (Table 1), NFPs (Table 2) and Time (Table 3) for UML modeling is organized and addressed according to the application context of domain concepts. In Sect. 4, only elements relating to the requirements specification of RTS are discussed.

4 A case study on road traffic systems control

In this section, a subset of a list of user requirements for a road traffic management system (RTMS) is first presented using natural language and is further modeled with the proposed approach.

Table 3 Package MARTE Foundations: stereotypes of time
Full size table
Table 4 A subset of requirements for a road traffic control system
Full size table

4.1 Background on road traffic control systems

Current control equipment for traffic signals can provide a wide variety of resource capabilities usually organized in fixed time, actuated time and adaptive time [23, 39].

Within Fixed-Time Signals, values of the cycle time, duration and sequence of phases have fixed calculated values based on historical intersection data flow. According to [39], traffic signals that use fixed time are more affordable to purchase, install and maintain than actuated time. However, this type of control does not allow a proper reaction to the fluctuation of traffic during the day.

Actuated Traffic Signals vary the green phase based on traffic demands measured by road sensors.

For an actuated control, there are three time parameters: the minimum time for the green phase, the extension of green phase and the maximum time for the green phase. Independent of demand, the green phase is defined for the minimum time. Depending on the flow of vehicles, and if the maximum duration of the green phase is not achieved, then the green phase time can be extended.

This example focuses on the requirements needed to provide control capability for actuated intersections with interconnection of traffic signals, i.e., the operation of traffic signals in a network. The set of requirements for the design of a coordinated traffic control system is presented in Sect. 4.2.

4.2 Systems requirements

A subset of a list of requirements for a road traffic management system (RTMS) is used as input document in this case study. Requirements are written exclusively using natural language to be further modeled and analyzed. The list of requirements presented in Table 4 is a subset from a document which contains 137 atomic requirements for a RTMS. This subset of requirements focuses on capabilities of an actuated controller and, also, the functional and non-functional requirements involved with synchronization of actuated controllers in a road network.

4.3 Proposed scenarios

SysML Use Case diagram describes the usage of a system by its actors in order to achieve a goal. Figure 8 presents major functions for the proposed system and allows for the representation of external entities exercising influence in a scenario (which describes a set of requirements).

It is possible to represent the interconnection of a Use Case with a SysML Requirements diagram by using the relationship refine (Fig. 9). This relationship provides the capability for reducing ambiguity in requirements since it can show the relationship of a requirement with scenarios.

Figure 10 depicts an example in which a Use Case proposed in Fig. 8 is refined to a set of requirements described in the SysML Requirements diagram. In this case, the scenario Synchronized Semaphore is interconnected, through the refine relationship, with requirements greenSych, synchronizationState, miniBlockage and greenSychMM.

Table 5 describes a proposal for tracing all scenarios of Fig. 8. Table 5 is prepared based on the analysis of natural language specified in Table 4, through the description of the use cases performed in Fig. 8 and also from the drawdown of stakeholders that interact with each scenario of the system. After this analysis it was possible to conceive manually the tracking all use cases that relate to the overall requirements of the system.

Classification proposed in Table 5 improves the representativeness of the SysML Refine relationship (in this table, TS stands for traffic signals, OP for operator, EV for emergency vehicle, MA for maintainer and S for sensor). Thus, the relationships between requirements are documented since establishment of initial phases of the system development and can be validated and traced along the development process.

5 Modeling requirements for a road traffic control system

Figure 11 depicts how to apply the SysML Requirements diagram with MARTE stereotypes for modeling non-functional properties, runtime semantics that are suitable for real-time and embedded systems, more specifically to the proposed requirements for a traffic control system as specified in Table 4.

Main requirements and the respective modeling using the SysML Requirements diagram extended with MARTE stereotypes are presented in Fig. 11.

Fig. 8
figure 8

SysML Use Case diagram for the traffic control system

Full size image
Fig. 9
figure 9

Refine relationship

Full size image

In order to improve model understandability, two groups of requirements (Table 4) are grouped into packages in Fig. 11. Package P1, depicted in Fig. 12, models in detail requirements TM3, TM4, TM7, TM8, TM9, TM11, TM13, TM15 and TM16 and represents scenario which has as purpose to define basic properties to traffic control. Package P2, depicted in Fig. 13), is composed of requirements TM12, T19 and TM20 which, when grouped, establishes the traffic signal phases, its synchronization and performance criteria.

Fig. 10
figure 10

Synchronizing semaphores and its requirements

Full size image

Requirement TM1 has as type stereotype Mode (of Causality::ModalBehavior), indicating the necessary logic to represent and to control an operating segment as, for instance, a traffic control system for all active entities/elements of the operational fragment. This requirement has a SysML relationship \({\ll }{\textit{hierarchy}}{\gg }\) with the basic requirements for a traffic control system, including requirements TM3, TM4, TM5 TM7, TM8, TM9, TM11, TM15 and TM17.

Table 5 Tracing scenarios
Full size table
Fig. 11
figure 11

Complete model

Full size image

Requirement TM7, of type TimedEvent (of TimedRelatedEntities:: TimedEventsModels), relates to an event whose start and end are not defined a priori. However, the decision to attend this occurrence is directly linked to a Clock. The modePreemp requirement (TM7) has a constraint represented by the \({\ll }{\textit{nfp}}\_{\textit{Constraint}}{\gg }\) stereotype (from NFPs:: Nfp_Constraint) which applies a temporal restriction to “ensure performance” of a critical requirement. For instance, the priority passage of emergency vehicles is indicated by attribute kind \(=\) offered, which indicates the value space to support/restrict this requirement.

Fig. 12
figure 12

P1 package in detail

Full size image
Fig. 13
figure 13

P2 package in detail

Full size image

Requirement TM1 is related to requirement Chronometric using stereotype \({\ll }{\textit{TimedElement}}{\gg }\) (of Time::TimedRelatedEntities) which is a specialization of ClockType, both belonging to package Time::TimeAcess. Stereotype \({\ll }{\textit{TimedElement}}{\gg }\) is important in this context, as it should be used whenever it is necessary to associate a (few) Clock(s) to a model element (in this case the TM1 requirement). Requirement TM1 should be elaborated within time constraints to ensure several important non-functional requirements for traffic control systems. Thus, it is necessary to create a \({\ll }{\textit{clock}} Chronometric {\gg }\) stereotype enabling the TM1 access to time structure. Attributes of this clock are nature, an enumeration of TimeNatureKind::TimeTypesLibrary, which serves to specify the discrete or dense nature of a time value (in this case time is discrete), unitType, a TimeUnitKind dimension imported from modelLibrary::MARTE_Library::MeasuremenUnits, which defines the supported unit type (in this case the unit is ms), and the resolution which expresses clock granularity (in this case by default it was set to 1.0).

Control logic of the controller is of type actuated time. Requirement TM5 relates hierarchically to TM1 in order to define the configuration of the control system. This is represented through stereotype \({\ll }{\textit{Configuration}}{\gg }\) (of CoreElements::Causality::ModalBehavior). This stereotype shows the system configuration that can be defined by a set of active elements from the system. Type attribute of requirement TM5 is ModeBehavior (of CoreElements::Causality::ModalBehavior), because the actuated control mode is unique to the control system; i.e., it is the only one considered at the intersections of this case study.

Requirement TM5 derives from TM10, which is responsible for controlling the control plans for signaling the intersections. Signaling plan changes depending on volume of road traffic. Thus, through an association with TM14 with \({\ll }{\textit{modeTransition}}{\gg }\) stereotype (of CoreElements::Causality::ModalBehavior), the signaling plan transitions to a certain state of the signals (red, green, yellow, green expanded and so on) specified at TM14.

Requirements TM19 and TM20 are stereotyped with \({\ll }{\textit{Chronometric}}{\gg }\) characterizing them as requirements that exist in a physical time. These requirements will work with physical time to configure the green time of a phase (TM19) and, also, coordinate this time with high performance (TM20) in order to ensure fluid traffic flow. Requirements TM19 and TM20 are linked to TM14 (by hierarchy relationship of SysML).

Requirement TM14 is stereotyped as TimedEvent (of CoreElements::Time::TimedRelatedEntitiesTimedEventsModels), since it describes events that force change and the state controller processing, whose occurrences are directly linked to a Clock (in this case Clock Chronometric).

Requirement TM14, of type TimeProcessing (of Time::TimedRelated Entities::TimedProcessing), is important to clarify that the change of states signaled is an activity where there is great importance in knowing the initial time and finish time for each state, as well as creating strategies to ensure/get higher performance. Timing restriction for this requirement precisely demonstrates that the same processing must have a minimum quantitative level (specified with kind = required) to run with at most 150ms.

Requirement TM12, of type TimeProcessing (because its processing time instant refers explicitly to clocks), refers to a structure of physical time. It is through this requirement that the delay (delay/offset) is acknowledged between a controller of an intersection and the subsequent intersections.

Requirement TM2 was stereotyped as a TimedEvent by presenting a situation or criterion of the controller that should trigger/capture events that synchronize the traffic plans of different interconnections actuated form (note TM5).

MARTE enables both logical time and physical clocks modeling. For this reason, a structure of time that specializes \({\ll }{\textit{clockType}}{\gg }\) and sets the logical time necessary to demonstrate that the TM2 requirement relates to synchronizing semaphores is created at an intersection network. It does not carry a long presigned physical time; it can only be seen as reading and detecting the flow of the processing approaches, the setting of the control plan strategy and so on. Therefore, it is not explicitly a physical time, and processing logic depends on several other elements.

6 Extending a tool for requirements modeling with SysML

ArgoUML (available in [3]) is a software tool used for activities of analysis and design of Object-Oriented software systems using UML. ArgoUML is an open source software, multiplatform, based on GTK\(+\) (one multiplatform tool kit for creating graphical user interfaces) for creating diagrams and released under the license BSB (Berkeley Software Distribution). It was developed using the Java language and is composed of approximately 2.000 class and 15.000 methods [3].

Fig. 14
figure 14

Interface of extended ArgoUML tool

Full size image

To facilitate the analysis and understanding of code, enabling the modification and adaptation of the tool for modeling proposed in this article, Software Reconnaissance techniques [49] were applied, in addition to analysis of the documentation of ArgoUML, including available tutorials and examination of the source code. Techniques of Software Reconnaissance were used to analyze execution traces to find components of interest [38]. This technique makes it easy to find in the program the locations in which a particular function of interest is implemented.

In order to implement new functions in the ArgoUML tool, the technique code clone [9] was applied. Code clones are a portion of the source code reused in another part of a program. A SysML Requirements diagram is an extension of the UML Class diagram. In this context, the adaptation of the source code of ArgoUML was performed, in particular the class diagram (package UMLClassDiagram of the ArgoUML), to make possible modeling requirements of SysML diagram.

Changes in ArgoUML tool, highlighted in Fig. 14, were performed by adding a new button to the toolbar. This button generates a command that is sent to a controller (CoreFactoryMDRImpl) which effectively creates the SysML Requirements diagram on ArgoUML.

7 Comparison with related work

After an extensive literature review about the use of profiles SysML, MARTE, and profiles SysML and MARTE together, 21 works regarding requirements engineering were found from 2007 to 2014. These works are listed below: 1. [44], 2. [25], 3. [45], 4. [7], 5. [47], 6. [43], 7. [24], 8. [8], 9. [13], 10. [34] , 11. [6], 12. [51], 13. [11], 14. [21], 15. [42], 16. [2], 17. [28], 18. [14], 19. [36], 20. [16] and 21. [26].

The 21 papers previously listed were selected studies that addressed modeling strategies similar to the proposed in this work, that is, works describing the application of a methodology using profiles SysML and MARTE. Works that are most easily compared with the strategy proposed in this article are, respectively, [2, 14, 16, 26, 28, 36].

Table 6 Comparison of approaches for modeling requirements
Full size table

A set of comparison criteria was designed to evaluate the approaches already described in the literature review. Comparison criteria, mentioned above, were chosen based on the specifications of the standard [19] for modeling software requirements. Comparison of works listed previously to the approach proposed in this article is shown in Table 6. Symbols used in Table 6 are as follows:

\(\blacksquare \)—means the evaluated criterion is fully satisfied;

\(\boxdot \)—means the evaluated criterion is partially satisfied;

\(\square \)—means the criterion evaluated is not satisfied.

Table 6 presents strong points in favor of the approach proposed in this work that utilizes profiles SysML and MARTE in conjunction for describing requirements of RTS.

The nearest researches which can be compared with this article are presented in [14, 26]. However, the first article presents a broad theoretical discussion of the use and adequacy of profiles MARTE and SysML to deal with multidisciplinary aspects in the field of embedded systems. It is worth mentioning that the fields, in Table 6, labeled with “*” are justified by the fact that despite being marked as partially satisfied criteria this research relates to a theoretical study about the use and applicability of these profiles. Our proposal specifically made suggestions regarding the applicability of SysML and MARTE in a single framework.

In [26], one can observe the application of SysML and MARTE in the context of the elicitation, analysis and specification, validation and management requirements in the approach named MDEReq. In this case, designers have an effective control of requirement changes and its impacts on other requirements or other design artifacts. In the proposed approach, traceability matrixes and SysML Requirements diagram are created for managing requirements process. In this research, the SysML Requirements diagram was used as designed in SysML (no extension or detail). Time and GRM packages of MARTE Foundations were applied to design definitions only in three of its constructors and stereotypes. Therefore, in this work, elements that define/establish events, performance, constraints and so on were overlooked.

Project MADES is described in [35, 36]. This methodology was developed after current practices for developing embedded real-time systems and are applied to aviation industries and surveillance. A major contribution relates to the presentation of a complete methodology based on the combined use of SysML and MARTE for design, validation, simulation and automatic code generation while integrating aspects such as component reuse. The approach proposed in MADES [36] differs from our proposal, first by contemplating a comprehensive methodology for developing embedded systems, and second, by joining a consistent set of diagrams for specification of system requirements, initial behavior specification, functional specification, refined functional specification, specification of hardware/software, detailed specification of hardware/software and specification of allocation.

The approach proposed by [16] demonstrates the use of SysML Parametric diagram and some MARTE packages. Thus, the concepts and diagrams of SysML/MARTE complement the methodology and are not utilized in a grouped way as proposed in our article. In [16], each domain can be treated separately in different views while maintaining strong connections toward other views. MARTE profile is used to define the model of hardware architecture. In addition, the MARTE package of non-functional properties is used for setting properties such as power, voltage and frequency. SysML is used to specify, through the parametric model, the equations that define mathematical relationships between non-functional interests of different views.

8 Discussion

According to the extensive bibliographic research conducted until the present moment, there are few studies in scientific literature which focuses on the applicability of UML and SysML with MARTE stereotypes for documentation, classification and modeling of software requirements for RTS. Despite the existence of several approaches for modeling software requirements and for modeling specific requirements of real time, as described in previous sections, requirements engineering for RTS still lacks representative models that are expressive, complete and correct. As described by [14], a single profile may not be adequate to cover all required aspects as, for example, the multidisciplinary aspects in the field of RTS.

In this article, the proposed approach shows the applicability of the MARTE profile, with its stereotypes and restrictions, with the SysML profile for requirements described in greater level of detail and at different levels of abstraction, as well as classifying and tracing requirements. Thus, MARTE stereotypes specifies the notion of time in a better manner than the way presented in UML. Within the application of the proposed metamodel, in Sect. 5, it is possible to observe the contributions of this work to improve representation and documentation of requirements. The proposed metamodel is complementary to other methods of modeling software and are not intended to replace them (such as Use Cases and respective scenarios).

Among the related criteria which can be highlighted as strong points of this work are the following: clustering of requirements (through the new relationship \({\ll }{\textit{aggregate}}{\gg }\)), the classification of requirements (by adding a set of key attributes to the SysML Requirements diagram), the expressive modeling of functional requirements and partial modeling non-functional requirements (through extended SysML Requirements diagram and by using MARTE profile), the definition (or redefinition from extension of SysML relationships and extension of SysML Tables), issues of traceability between requirements and between requirements and design and, yet, the development of a specific methodology for requirements, what is considered an advantage, since it specializes and defines described domain-specific criteria.

Although the proposed approach has used packages CoreElements, Time and NFP for modeling real-time elements, the representation of non-functional requirements and the representation of time are not covered in completeness. The reason is because even being possible to model restrictions, clocks, performance and safety, this work still lacks greater level of formalism for modeling non-functional requirements.

Finally, one can observe in Table 6 that the proposed approach is relevant in the context of requirements specification of RTS. Importance of modeling in industry and education has been emphasized, for instance, in [15]. In Software Engineering, using models at the design phase of a software system is becoming more frequent. However, on early stages of software development, as for instance, requirements engineering activities, modeling is still not common.

Future work will focus on using SysML Activity diagrams for modeling and simulation [27] in order to provide frames of reference for models validation [4].

9 Conclusions

As previously reported, SysML Requirements diagram shows explicitly various types of relationships between different requirements, increasing the spectrum of understanding and defining the requirements of a real-time system. However, the SysML profile by itself does not present the representation of temporal, behavioral and performance requirements, nor provides elements for explicit representation of system configurations.

MARTE profile provides key resources to specify non-functional requirements for RTS, generally time requirements. In this article, these features were made explicit by means of classification and use of MARTE stereotypes. Thus, the combination of these profiles in the presented approach indicates the complete and expressive nature of the representation of various requirements. SysML contributes with constructors to define requirements and their relationships. Besides, MARTE completes the precision of the scenario with well-formed non-functional annotations. Concepts of SysML and MARTE articulated in the SysML Requirements diagram are highly complementary covering many of the purposes of specifying requirements for RTS.

As discussed along this article, the main goal of the proposed approach is to combine and to apply SysML Requirements diagram with MARTE stereotypes, which enables modeling of individual software requirements for RTS. This article addresses this gap, as few approaches were proposed with focus on applying MARTE and SysML together to design RTS, and even less with the purpose of applying to requirements modeling. The focus is to create an approach for modeling specific software requirements which allows the representation of the necessary features of RTS (based on research demonstrating the specific requirements) and, also, timing requirements and performance requirements. A tool was developed to support the design of models. As SysML Requirements diagram is an extension of the UML Class diagram, the tool is an extension of the ArgoUML tool by using code clone techniques.

Expressing each requirement separately is highly desirable. This feature is addressed in this article by modeling requirements using the SysML Requirements diagram and by organizing the relationships between requirements. As each requirement is described separately, the complexity of changes is minimized, since a change in any requirement can be made completely and consistently maintaining the structure and style of the set of requirements.

MARTE profile provides, in the proposed representation, a clear description of the various relevant aspects of requirements definition of RTS, as for instance, temporal aspects and constraints. Thus, in addition to the factors mentioned above, we can say that the proposed approach has an important role in approaches that specify RTS at different levels of detail and levels of abstraction.