Application of an Extended SysML

Requirements Diagram to Model Real-TimeControl Systems

Fabıola Goncalves C. Ribeiro1, Sanjay Misra2, and Michel S. Soares1

1 Federal University of Uberlandia, Uberlandia, Brazil2 Covenant University, Ota Nigeria

{fgcr.ufg,ssopam,mics.soares}@gmail.com

Abstract. Most techniques for modeling requirements present manyproblems and limitations, including modeling requirements at a singlelevel of abstraction, and are specific to model functional requirements.The objective of this article is to perform a study on modeling require-ments of Real-Time Systems through an extension of the SysML Re-quirements Diagram focusing on the traceability of non-functional andfunctional requirements. The proposed approach has demonstrated to beeffective for representing software requirements of real-time systems atmultiple levels of abstraction and classification. The proposed metamodelrepresents concisely the traceability of requirements in a high abstractionlevel.

Keywords: SysML, Requirements Engineering, Modeling of Software,Traceability of Requirements.

1 Introduction

Requirements Engineering is often characterized in the literature as the mostcritical and complex process of the software development life cycle [1]. The pro-cess of requirements engineering has dominant impact on the capabilities of theresulting product [2]. According to Brooks [3], knowing what to build, whichincludes requirements elicitation and technical specification, is the most difficultphase in the design of software.

The increasing complexity of software systems makes the Requirements En-gineering activities both more important and difficult. This assertion is easilyverifiable when developing Real-Time Systems (RTS) which are highly dependenton restricted timing requirements. Real-time systems must respond to externallygenerated stimulus within finite and specifiable period. Therefore, efforts mustbe expent to analyze, design and validate systems for real-time targeting, provid-ing greater reliability and security to them. In order to minimize the complexityof the development of RTS, graphical models can be applied. Modeling is an im-portant activity in the development of RTS, because it contributes to decreasethe complexity and to improve the understanding of these systems.

B. Murgante et al. (Eds.): ICCSA 2013, Part III, LNCS 7973, pp. 70–81, 2013.c© Springer-Verlag Berlin Heidelberg 2013

Application of an Extended SysML Requirements Diagram 71

UML has been frequently applied for modeling requirements in the RTS do-main. For instance, in [4], UML is used to represent the modeling of design deci-sions and non-functional requirements by extending the language with attributesof stimulus, source of stimulus, environment, artifact, response and responsefrom measures. These new attributes are incorporated into the class diagram formodeling non-functional requirements. In [5] a method for specifying softwarerequirements using UML with the addition of stereotypes is presented.

The shortcomings of UML are widely described in the literature. The lan-guage is considered too informal and ambiguous. Behavior diagrams, such asthe Sequence diagram, cannot represent time constraints effectively [6], as theyare essentially untimed, expressing only chronological order. As discussed in [7],UML presents difficulty in expressing non-functional properties of the system,very important requirements for real-time applications.

Proposals to address the problems of UML in relation to modeling real-timesoftware were created. These include the profiles SPT [8] and MARTE [9]. Theseprofiles extend UML and add elements that model time requirements, systemrequirements and non-functional properties. SysML (Systems Modeling Lan-guage), a new language derived from UML, was proposed recently. SysML [10]allows the modeling of various types of applications in systems engineering, en-abling the specification, analysis, design, verification and validation of complexsystems. The language has been successfully applied to model requirements. Thework presented in [11] refers to the application of the SysML Requirements di-agram for the specification of system requirements. In another article [12], thefocus is on user requirements.

The main aim of this article is to extend the metamodel of the SysML [10]Requirements diagram by adding new properties and relationships to enablethe representation of requirements of real-time software at different levels ofabstraction, and then demonstrating explicitly the tracing of each requirementin each level of representation.

This article is organized as follows. The proposed metamodel for representingrequirements at multiple levels of abstraction and classification, and to describetracing between requirements is presented in Section 2. Sections 3.1 and 3.2are about the set of requirements to be modeled in the case study. Finally, thediscussions are presented in Section 4 and the contributions and conclusions ofthis research are described in Section 5.

2 Metamodel for Requirements Modeling and Tracing

SysML is a highly customizable and extensible modeling language [10]. It allowsthe creation of domain-specific models through stereotypes and other exten-sions. Profiles may specialize language semantics, provide new graphical iconsand domain-specific model libraries. When creating profiles, it is not allowed tochange language semantics. The original SysML Requirements model is shownin Figure 1. The SysML Requirements diagram is a stereotype of the UML Classdiagram extended with new attributes. The SysML Requirements diagram can

72 F.G.C. Ribeiro, S. Misra, and M.S. Soares

Fig. 1. Basic node for SysML requirements diagrams

be used to standardize the requirements documents with a specific pattern to beused.

The SysML Requirements diagram allows several ways to represent require-ments relationships. These include relationships for defining requirements hi-erarchy, deriving requirements, satisfying requirements, verifying requirementsand refining requirements. The relationships can improve the specification ofsystems, as they can be used to model requirements. Additional relationshipswere proposed in this article and are briefly explained as follows.

SysML allows splitting complex requirements into more simple ones, as a hier-archy of requirements related to each other. The advantage is that the complexityof systems is treated from the early beginning of development, by decompos-ing complex requirements. For instance, high-level business requirements maybe gradually decomposed into more detailed software requirements, forming ahierarchy.

The derive relationship relates a derived requirement to its source require-ment. New requirements are often created from previous ones during the re-quirements engineering activities. The derived requirement is under a sourcerequirement in the hierarchy. In a Requirements diagram, the derive relation-ship is represented by the keyword deriveReqt.

The created attributes for the extended requirements take into account manyof the specifications contained in the IEEE 830-1998 standard for describingsoftware requirements [13]. An extended requirement (represented by the stereo-type << ExtRequirement >>) is proposed in this article, including addi-tional attributes. In addition, derived from this extended requirement, an ex-tended requirement for non-functional requirements is proposed (representedby << ExtRequirementNRF >>) with additional attributes. Three types ofnon-functional requirements were proposed in the metamodel, as can be seen inFigure 2.

The new defined attributes for ExtRequirement are: priority, abstractLevel,constraint, scenario, creationDate, modificationDate, and versionNumber.

The priority attribute defines the relevance of a requirement in relation to theother, i.e., indicating the order that the requirements should be addressed. Val-ues are of type String, including for instance, priority of type “must”, “should”,“could”, and “won’t”. The requirement level indicates classification level in thehierarchy. The constraint attribute enables to show requirements that have sometype of restriction. This attribute is of type Boolean. In case it is set to true, theidentifier (ID) and the detailed description of this restriction are contained in a

Application of an Extended SysML Requirements Diagram 73

Fig. 2. Metamodel for SysML Requirements Diagram

table of restrictions. Scenario is an attribute of type String which basically iden-tifies the scenario to which the requirement is related. The attributes creation-Date and modificationDate indicate the requirements version, which is useful tokeep track of multiple versions of the requirement. The attribute versionNumberallows to determine the version of creation/elaboration of a requirement.

The stereotype ExtRequirementNFR is used to describe non-functionalrequirements of software. The proposed attributes are externalFac, cost, andlevelQoS. ExternalFac determines whether a requirement is dependent on anexternal factor in order to be developed. The cost attribute allows to estab-lish criteria of costs to satisfy a requirement that infuences directly in decisionsabout the viability of its development. Possible values to be assigned includeHigh, Medium, or Low. The levelQos demonstrates the level of quality requiredfor the requirement.

The timing type of non-functional requirement relates to the description oftime of a software. Its attributes are typeTime, which can assume values phys-ical time or logical time, minResponseTime and maxResponseTime, which areused to describe timing constraints of a requirement. The performance type hasthree attributes. RespTime indicates the maximum response time associated

74 F.G.C. Ribeiro, S. Misra, and M.S. Soares

Fig. 3. Metamodel of Extended Relationship

with a requirement. Its value allows to establish which level of performance isassociated or is to be guaranteed by the requirement. The capacityOp attributeindicates the possible number of simultaneous operations that are allowed in agiven time period (e.g., number of reports generated for storage, operations persecond, and so on). The attribute recoveryTime describes the maximum time re-quired for recovery from a failure. The safety type of non-functional requirementhas attributes integrity (level of integrity that must be guaranteed), acessLevel(establish the level of access of stakeholders to a function), and limitedC (en-ables to demonstrate whether communication should be limited between thisrequirement and other functions/modules of the system.

The extended model is able to represent requirements at different levels ofabstraction, correlated requirements at the same level and, also, synchronismbetween requirements as shown in Figure 3. The << linkage >> stereotyperepresented by an arrow and a circle with an internal cross on both ends has thepurpose of improving the activity of tracing requirements to the design models.Its graphical representation can be visualized in Figure 6.

The << aggregate >> stereotype (Figure 5), was elaborated in order toexplicitly demonstrate correlated requirements (in the same classification level)with a requirement/function one level up, i.e., requirements that are representedwith this stereotype will together provide functionality expected by a higherrequirement and are strongly bonded together.

Finally, the new stereotype << synchronized >> should be used for non-functional requirements that in addition to performance constraints of non-functional requirements should be processed in parallel with other requirements.Its graphical representation is shown in Figure 4.

<<Synchronized>>

Fig. 4. The << Synchronized >> relationship

Application of an Extended SysML Requirements Diagram 75

<<aggregate>>

Fig. 5. Relationships << aggregate >>

<<linkage>>

Fig. 6. The linkage relationship

3 Case Study

In this section, a subset of a list of requirements for a Road Traffic ManagementSystem (RTMS) is presented, using natural language to be further modeled andanalyzed. The list of requirements given below is a subset from a document whichcontains 137 atomic requirements for a RTMS. The requirements were gatheredthrough an extensive search in the literature of RTMS [14] [15].

3.1 Requirements for the Case Study

The elaborated requirements document depicts requirements for a Control Sys-tem for a Road Traffic Intersection where the requirements are related to thetime control at the intersection, flow control of vehicles, configuration and controlof adaptive controllers, and receiving, storing and processing various data fromeach road approaches which interconnect the intersection, and also, controllingthe green time of the signal. The configuration of the document is described asfollows:

– Fourteen general purpose requirements as shown in Table 1.– Sixty one functional requirements. Given the space of this article, only non-

functional requirements modeled in this study were represented (Table 2).– Sixty two non-functional requirements. Some of the Non-functional require-

ments used in the case study can be seen in Table 3.

The requirements in each one of the different levels were presented in natu-ral language. However, the focus of this work is the use of graphical modelsfor improved representation of system requirements of the RTMS. The SysMLconstructions for modeling requirements are explained in detail in the followingsection.

3.2 Modeling the Case Study

It can be seen from Figure 7 that requirements TM5, TM6, TM8, TM9 andTM12 are related to the requirement TM1 through the derive relationship using<< deriveReqt >> and the hierarchical relationship. The derive relationshipis justified by the fact that the high-level requirements mentioned above are all

76 F.G.C. Ribeiro, S. Misra, and M.S. Soares

Table 1. High Level Requirements for a Road Traffic Management System

ID Requirement Name

TM1 The system must control the standard of vehicular traffic at the intersection.TM2 The system must allow synchronization of semaphores.TM3 The system must collect all kinds of information of the road approaches in order

to properly evaluate these data.TM4 The system must allow management of traffic history.TM5 The system must possess the adaptive control of schedules to the intersection

in response traffic flow.TM6 The system must actuate in response to intersection traffic flow.TM7 The system must have the emergency preemption mode, i.e., preferential

movement of emergency vehicles.TM8 The system must allow the control of the intersection in response to

manual commands.TM9 The system must allow control of intersection in response to replacement

of remote commands.TM10 The system must control incident management.TM11 The system of the intersection should be able to interact with the software

control panel.TM12 The system must allow the automatic operation of semaphores.TM13 The system must use TCP/IP SNMP interface for inter-communication system.TM14 The system could generate statistical data to assist decision making.

Table 2. Functional Requirements for a Road Traffic Management System

ID Requirement Name

TMFR5.1 The system must capture information of the approaches (detect volume)TMFR5.2 The system must store information sent from the vehicle detection loopTMFR5.3 The system must process traffic informationTMFR5.4 The system must trigger new state in sufficient time to

the reprogramming of intersection controllersTMFR5.5 The system must maintain statistics of counting vehicles

derived from the requirement that controls the traffic pattern of vehicles at theintersection.

The hierarchical relationship (represented by a circle with a cross inside)represents one stronger relationship between a more general requirement andthe more specific requirements.

Figure 8 demonstrates the use of the new created relationship (the <<aggregate >> relationship and its stereotype are shown in Figure 5). The rela-tionship << aggregate >> shows when two or more requirements at the samelevel are linked to a more general requirement. In Figure 8 the associations be-tween a requirement at the same level (in the same “branch” of the tree ofmodeling) with more than one requirement was suppressed due to readability.

The application of the metamodel to the case study is described in Figure 9. Itclearly demonstrates through the new stereotype << linkage >> which require-ment at any level of abstraction (at a high level as TM5, orTMRF5.3) is interlinked

Application of an Extended SysML Requirements Diagram 77

Table 3. Non-Functional Requirements for a Road Traffic Management System

ID Requirement Name

TMNFR5.1 The information of approaches (detection volume) must be capturedwith a maximum of 100ms.

TMNFR5.2 The storage of traffic information, sent by loop detection vehicle,must be done with maximum of 1000ms.

TMNFR5.3 The traffic information must be processed with a minimum of 150msand a maximum of 200ms.

TMNFR5.4 The system must trigger new state in sufficient time to program thecontrollers with a maximum of 100ms.

TMNFR5.5 The new state of the actuators should be modified in synchronizationwith the other controllers on the network.

TMNFR5.6 The controllers must receive their state safely.TMNFR5.7 The detection volume must be performed with maximum performance

and reliability.

Fig. 7. High Level Requirements and their relationships in SysML

with another one at Figure 10 where the hierarchy is clearly expressed among re-quirements. Figure 6 shows the relationship << linkage >>. Thus, the tree thatdemonstrates traceability of a requirement can be drawn from the<< linkage >>relationship. Any requirement that has in its two ends the << linkage >> re-lationship indicates a point of connection between a more abstract requirementwith another less abstract one. The requirements where parallel strategies shouldbe applied are expressed by the << synchronized >> relationship.

78 F.G.C. Ribeiro, S. Misra, and M.S. Soares

Fig. 8. High Level Requirements and their relationships with << aggregate >>

The linkage relationship, differently from the original SysML relationship oftrace, provides well-defined semantics, as it allows toclearly observe the hier-archy levels or trace of a set of requirements. The tracing is demonstrated byhyperlinks of a basic requirement, whether functional or non-functional, withothers in higher or lower levels. It is also possible to observe the classificationand organization of such requirements. The obvious advantage of these new rela-tionships and stereotypes is that complexity of the software design can be treatedfrom the beginning of development by classification (in which the functional re-quirements, for example, are easily identified and can be manipulated directly)through the detailing of the various attributes of requirements relevant to thedesign of a real-time system.

4 Discussion

The extension of the SysML Requirements diagram to modeling critical require-ments of RTS, the approach proposed in this article, is convenient to accomplishthe many characteristics relevant to a document of software requirements (assuggested in [13]).

Application of an Extended SysML Requirements Diagram 79

Fig. 9. Application of the metamodel

Fig. 10. Traceability between requirements of different levels

80 F.G.C. Ribeiro, S. Misra, and M.S. Soares

The completeness was demonstrated as all the general requirements, func-tional and non-functional ones may be related concisely to be further analyzed.The conflict between any requirements that are at the same level of the hierar-chy or between high-level requirements with their less abstract requirements canbe clearly visualized through the new relationships and the proposed modeling.The use of the new stereotype << aggregate >> also lists requirements on thesame level, and with that, conflicts in the same set of requirements are easilydiscovered.

The ranked by importance, proposed as an attribute, is useful to define thepriority attribute between requirements. This can be useful in order to clarifywhich requirements must be prioritized in phases of validation, testing or de-velopment. As each requirement is described separately the complexity of thesechanges is minimized, since a change in any requirement can be made completelyand consistently maintaining structure and style of requirements. Expressingeach requirement separately is highly desirable. This characteristic is addressedin this article by modeling requirements using a well-defined SysML Require-ments diagram, and by organizing the relationship between requirements.

5 Conclusion

The SysML is an interesting and reasonably modeling language for designingrequirements of RTS. However, the current state of the language is not completeenough to satisfy many of the needs of representation, description and manip-ulation of requirements for RTS. The language provides the representation of alimited number of concepts related to these systems as, for instance, elementsallowing the representation of time to build computing models with interpreta-tions of time. The proposal in this article is to create extensions to the SysMLRequirements diagram and adding new relationships which can express the clas-sification of requirements for modeling RTS at different levels of abstraction.The extensions to the basic metamodel of SysML aims for better identificationof software requirements at different abstraction levels, enabling the mapping ofrequirements relationships among themselves. In addition, the relationships be-tween requirements are shown together in order to make it easier to trace theserequirements in the many different levels of abstraction and thus facilitating theverification and the testing of a set of requirements in any phase of the life cycleof RTS. The proposed metamodel makes it possible to trace requirements, thusenabling the identification of their origin, detailing why and when they were in-cluded in the requirements document. This allows better care for many types ofconditions required for the development of RTS and also improves the supportof evaluation of the impact of requested changes. As a result, an improvementin the quality of software development is expected, as well as an improvementof the development process as a whole.

Application of an Extended SysML Requirements Diagram 81

References

1. Minor, O., Armarego, J.: Requirements Engineering: A Close Look at IndustryNeeds and Model Curricula. Australian Journal of Information Systems 13(1),192–208 (2005)

2. Parviainen, P., Tihinen, M., van Solingen, R.: Requirements Engineering: Deal-ing with the Complexity of Sociotechnical Systems Development. Idea Group Inc.(2005)

3. Brooks, F.P.: No Silver Bullet: Essence and Accidents of Software Engineering.Computer 20(4), 10–19 (1987)

4. Martin, G.: UML for Embedded Systems Specification and Design: Motivation andOverview. In: Design, Automation and Test in Europe Conference and Exhibition,pp. 773–775 (2002)

5. Cote, I., Heisel, M.: A UML Profile and Tool Support for Evolutionary Require-ments Engineering. In: 15th Software Maintenance and Reengineering, pp. 161–179(2011)

6. Soares, M.S., Julia, S., Vrancken, J.: Real-time Scheduling of Batch Systems usingPetri Nets and Linear Logic. Journal of Systems and Software 81(11), 1983–1996(2008)

7. Silvestre, E.A., Soares, M.S.: Multiple View Architecture Model for DistributedReal-Time Systems Using MARTE. In: 20th International Conference on Informa-tion Systems Development, pp. 98–113 (2011)

8. OMG: UML Profile for Schedulability, Performance, and Time, Version 1.1. Tech-nical report, OMG (2005)

9. OMG: UML Profile for MARTE: Modeling and Analysis of Real-time EmbeddedSystems Version, 1.1. Technical report, OMG (2011)

10. OMG, S.: Systems Modeling Language (SysML) Specification - version 1.1. (2010)11. Soares, M.S., Vrancken, J.: Requirements Specification and Modeling through

SysML. In: International Conference on Systems, Man and Cybernetics,pp. 1735–1740 (2007)

12. Soares, M.S., Vrancken, J.: Model-Driven User Requirements Specification UsingSysML. Journal of Software 3, 57–69 (2008)

13. IEEE: IEEE Recommended Practice for Software Requirements Specifications(1998)

14. Laplante, P.A.: Real-Time Systems Design and Analysis, 3rd edn. John Wiley &Sons, Piscataway (2004)

15. Klein, L.A.: Traffic Detector Handbook. 3 edn. Prentice Hall, USA (Departmentof Transportation - Federal Highway Administration)