Extending SysML to explore Non-FunctionalRequirements: The Case of Information System Design

Anargyros Tsadimas, Mara Nikolaidou, Dimosthenis AnagnostopoulosDepartment of Informatics & Telematics, Harokopio University of Athens

70 El. Venizelou Str, 176 71 Athens, Greece{tsadimas, mara, dimosthe}@hua.gr

ABSTRACTModel-driven system design is facilitated by SysML lan-guage, which provides distinct diagrams to describe sys-tem structure and components, explore allocation policiesand identify system requirements. While non-functional re-quirements play a significant role in system design, their arenot effectively supported by SysML. This paper emphasizeson a SysML extension to facilitate the effective descriptionand verification of non-functional quantitative requirements.The introduction of a distinct SysML diagram to exploreevaluation results enhances requirement verification capa-bilities, while the visualization of verification process helpssystem engineers to explore design decisions and properlyadjust system design. Based on the proposed SysML exten-sion, a profile for Enterprise Information System architec-ture design was developed. To demonstrate the potentialof the proposed approach, the description and verificationof software performance requirements using this profile arediscussed, as an example.

Categories and Subject DescriptorsH.1 [Information Systems Applications]: Models andPrinciples; D.2.1 [Software Engineering]: Requirements/Specifications

KeywordsNon-functional Requirements, Requirement Verification, SysML,Model-based System Design, Information System Architec-ture

1. INTRODUCTIONSystem design is an important phase of system engineer-

ing, determining system architecture (i.e., the way systemcomponents should be synthesized) to satisfy specific re-quirements. It is commonly performed in a model-basedfashion, where activities constituting the design process areaccomplished by developing models of increasing detail [2,

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’12 March 25-29, 2012, Riva del Garda, Italy.Copyright 2011 ACM 978-1-4503-0857-1/12/03 ...$10.00.

11] and can be effectively accommodated by Systems Mod-eling Language (SysML) [5], defined as an extension of theUML metamodel [3].

Non-functional requirements (NFRs) [10] play a signifi-cant role during system design, since they depict the con-ditions under which specific system components should op-erate, leading to alternative design decisions [14]. Further-more, proposed design decisions should be evaluated [7] andproperly adjusted until all imposed requirements are veri-fied. SysML provides a discrete diagram to define require-ments and the relations between them in a qualitative fash-ion. Non-functional requirements are also described in aquantitative fashion using for example non-functional prop-erties as defined in ([4]). Furthermore, their verificationmust be performed using quantitative methods, for exam-ple simulation.

The description of non-functional requirements is a quan-titative fashion was explored in UML profiles proposed forspecific domains. In [6], performance characteristics are de-fined as discrete entities, associated to information systemelements, and described using qualitative parameters. InMARTE, a UML profile supporting the specification of real-time and embedded systems [4], Non-Functional Properties(NFPs) are introduced to specify semantically well-formednon-functional quantitative properties (e.g., throughputs, band-widths, delays, memory usage), combined through ValueSpecification Language (VSL) to formulate algebraic andtime expressions. MARTE profile, which is based in UML,does not support the notion of requirement introduced inSysML. Instead, non-functional annotations are associatedto system design entities to indicate non-functional char-acteristics. Non-functional annotations defined using VSLenables their automated validation, verification and trace-ability, using external tools. In [1] strategies to apply SysMLand MARTE profile in a complementary manner to modelembedded systems were suggested in a high-level fashion, in-dicating the potential to combine non-functional propertiesand VSL expressions define in MARTE with SysML require-ments for the description of non-functional system charac-teristics. As far as NFRs are concerned, MARTE profilefocuses on performance and scheduling properties of systemcomponents. Their verification can be explored using exter-nal tools.

To explore quantitative NFRS, a SysML extension to ef-fectively depict and verify them is needed. In this paper, wepropose the extension of basic SysML concepts to:

a) describe, manage and verify non-functional require-ments, vital for system design and

b) include a discrete diagram serving system evaluationand requirement verification.The proposed extensions are applied in designing the ar-

chitecture of enterprise information systems (EISs). For thispurpose a SysML profile was implemented as a plugin to theMagicDraw modeling tool [9]. To explain the proposed con-cepts software performance requirements are discussed, asan example.The rest of the paper is organized as follows: In section 2,

the extension of basic SysML concepts to explore NFR quan-titative description and verification is discussed. In section3, the EIS Architecture Design SysML profile based on theproposed extensions is briefly presented, emphasizing soft-ware performance requirements as an example. Conclusionsand future work reside in section 4.

2. SYSML EXTENSION TO SUPPORT NFRSRequirements in SysML are described, as class stereo-

types, in an abstract, qualitative manner, since they arespecified by two properties, id and text, corresponding to asimple description. However, SysML specification suggeststo use the stereotype mechanism to define additional prop-erties for specific requirement types. Requirements can begrouped in packages based on common characteristics, astheir category (for example functional or non-functional) orthe activities they are related to (for example software orhardware requirements) forming a multi-level hierarchy.SysML includes specific relationships to relate require-

ments with other requirements (indicating the way they af-fect each other) or other model elements. The containmentrelationship, defined between requirements, indicates thatthe composite requirement is realized if and only if all thecontained ones are realized. In this way, an abstract require-ment may be composed of more specific ones, or a complexrequirement may be described in a more detail fashion. Inthe case of system design, the notion of composite require-ments is essential to indicate the way a requirement definedfor the system as whole may be described in terms of thedetailed requirements defined for system components. ThederiveReqt relationship indicates that a specific requirementis derived by others. Since relationships do not have prop-erties, the way requirements are specified is not depicted.Requirements should be satisfied by model elements be-

longing to other diagrams (SysML satisfy relationship). Forthis purpose, requirements may participate into other dia-grams, enabling the exploration of the relationship betweenrequirements and design decisions.SysML provides the means to describe a set of tests, which

should be performed to verify whether a requirement is sat-isfied by system components. To depict such an activity, thetest case entity, included in Requirement diagrams, is intro-duced. A test case is related o one or a set of requirementsfor their verification, while it is described through a behav-ior diagram (for example activity or state machine diagram)corresponding to the activity (as a set of tests) performedto verify related requirements. The way requirements arehandled in SysML is summarized in figure 1.Since non-functional requirements (for example perfor-

mance requirements) are described using both qualitativeand quantitative properties, a quantitative method, suchas simulation, should be employed to produce the neces-sary data for their verification. There are many tools andmethods suggested to simulate SysML models and integrate

Figure 1: SysML Requirement representation

SysML with different simulation languages either for contin-uous or discrete event simulation [12, 8, 13]. The conceptof the test case is not supported by any of them. In suchcase, the way system evaluation is performed, conforms tothe corresponding simulation method. Thus, the definitionof test cases is of less importance, since they could onlybe used to specify the conditions under which the systemshould be evaluated and not the evaluation method itself.Furthermore, the results of the tests performed either by atest case or using simulation to verify requirement satisfac-tion are not included in SysML models. Such informationis crucial for the system engineer to adjust system design orrelax imposed requirements.

When SysML is used for system design, as for examplein EIS architecture model-based design, non-functional re-quirements are emphasized. To be accurately defined, non-functional requirements should be described using quanti-tative properties, in a similar fashion as the non-functionalproperties defined in MARTE UML profile [4]. Since, non-functional requirements may not always be described in anexact fashion, value deviation of quantitative properties shouldbe allowed, to indicate for example that the response timefor a specific service should be 4 to 5 seconds. In the samerational, maximum, minimum or average values should bedescribed. Thus, more than one properties should be avail-able for its description.

Furthermore, derived quantitative properties of non-functionalrequirements should be automatically computed. The de-riveRqt relationship indicates only the fact that the derivedrequirement is related to one or more others. It does not pro-vide any information about the way the requirement maybe derived, which may be depicted by indicating the wayits quantitative properties are computed based on proper-ties of the requirements it is derived from. Thus, a com-putation formula property should be defined for derived re-quirements. The computation formulas may involve heuris-tics and become complicated. SysML requirement entitymust be extended to a) effectively represent the quantita-tive aspects of requirements and b) the way derived require-ments should be computed. Constraints, specific purposelanguages as VSL [1] or scripts can be applied to derived re-quirements to enforce the automatic computation of derivedproperties, while computation algorithms must also be in-tegrated in the SysML model. It should be noted that thespecification of computation formulas is meaningfull only ifit is actually executed and quantitative properties are cal-culated.

Non-functional requirements must be satisfied by systemcomponents included in any of the system design diagrams.

Figure 2: Extending SysML to explore NFRs

In such case, in order to decide whether a non-functionalrequirement is verified, the designer may have to explore ifthe value of a quantitative property is satisfied by the relatedsystem components. To perform such a task, the comparisonof specific evaluation results for each system component andrelated requirements properties should be performed, whichleads to the need to integrate evaluation data into the systemmodel.The SysML test case, as a concept, is focused on depict-

ing how to evaluate model element satisfying a specific re-quirement, while integrating evaluation results into the sys-tem model is not considered. In the case of system design,non-functional requirements are verified in a quantitativefashion by evaluation scenarios instead of test cases. Anevaluation scenario should facilitate both a) the definitionof the conditions under which the system will be evaluated(probably using simulation) and b) the depiction of the eval-uation results, so that the system engineer may be directlyinformed of requirement verification. An evaluation scenariocomprises of evaluation entities, used to evaluate model el-ements, to verify the corresponding requirement or require-ments and can be described with block definition diagrams.Since an evaluation scenario is introduced to specify the con-ditions under which the system design should be explored,it involves the evaluation of all model elements, thus it isused to verify a composite, abstract NFR (for example thesystem performance must be high), constituting of more spe-cific ones (for example service time should be between 3 to 5seconds). When an evaluation scenario verifies a compositerequirement or a set of requirements, it should be used toverify all the included requirements.System design evaluation is usually performed via simu-

lation. Regardless of the method used to perform systemevaluation, evaluation elements have input properties, re-lated to evaluated model elements, and output properties,depicting evaluation data. Based on the value of outputproperties, requirements are verified. In the case of non-functional requirements described in a quantitative fashion,an appropriate comparison method should be defined forthe specific requirement, based on the output properties ofall related evaluation entities. Such a method could be de-fined for example using a Parametric Diagram or executablescripts, associating requirement quantitative properties to

evaluation entity output properties.As already mentioned, to simulate a SysML model using

a specific simulation method, simulation-specific character-istics should be included in the model. Such properties maybe incorporated into evaluation entities, thus evaluation spe-cific information does not have to be included in a systemmodel designed by the system engineer, promoting discreteactivity independence.

During system design, NFRs may also used to depict spe-cific behavior forced on system components (for example theway a traffic generator may behave under heavy traffic con-ditions). In such a case, there is no point in verifying therequirements. The corresponding evaluation entity may con-form to them, since they specify conditions under which thesystem design should be evaluated. The same requirementor requirements may be verified more than once, by evolv-ing evaluation scenarios, as the system design is re-adjusted.Evaluation data and conditions included in them should beintegrated in the SysML model. Thus, evaluation scenariosshould be grouped into a distinct diagram, named Evalua-tion Diagram.The way basic SysML concepts are extendedto handled non-functional requirements for system design issummarized in figure 2.

3. EIS ARCHITECTURE DESIGN SYSMLPROFILE

The proposed SysML extensions were applied in a SysMLProfile for the design of Enterprise Information System Ar-chitecture. It has been implemented using the MagicDraw[9] modeling tool. Along with the profile, a java plugin wasimplemented, called EIS Architecture Design plugin, respon-sible to impose model constraints and embed the desiredfunctionality in MagicDraw.

As an example of NFR management supported by theprofile, software performance requirements are discussed.Defined stereotypes, additional qualitative and quantitativeproperties and related constraints are presented in figure 3.Three groups of stereotypes are defined, indicated by dif-ferent colors: design stereotypes, describing software struc-ture, NFR stereotypes, describing performance requirementsand evaluation stereotypes, describing corrsponding evalua-tion entities. Stereotypes are associated between them usingthe relations defined in figure 2. In this example, require-ments happen to be verified by a simple evaluation entitywhich evaluates the corresponding design entity satisfyingthe requirement. Stereotype constraints indicated in figure3, ensure compatibility between design decisions and indi-cate which NFRs each software component must satisfy.

3.1 Defining Software Performance Require-ments

Software architecture is explored using a discrete compo-nent diagram named Functional View. To explore softwareperformance, desired performance measurements and corre-sponding component behavior should be defined in a quan-titative fashion. Both of them are defined as performancerequirements. Software components are defined as services,grouped in Modules (client & server), representing softwaretiers. Though, services are invoked by other services de-pending on software functionality, modules are allocated tohardware components. Roles represent different user groupsinitiating services that belong to client-Modules.

Figure 3: NFRs and Evaluation entities for software performance exploitation

The performance of services is measured by the desiredresponse time, depicted as a ResponseTime requirement,which indicates the time frame in which the service shouldreturn an answer to the calling service or role. An averageand maximum value and measurement unit, are defined asquantitative properties. The requirement is verified based onEval-Service evaluation entity corresponding output prop-erties. The deviation property indicates acceptable valuedeviation between corresponding properties.Services, when executed, consume network, processing-

power and storage resources. These parameters describethe service behavior in a quantitative fashion and must bedefined by the software architect. They are defined using aService-QoS requirement that the service satisfies. For eachof them, values of three different types: traffic, processingand storage must be defined. Since Service-QoS require-ment indicates the resources consumed within the desiredresponse time, these requirements are interrelated.To explore the performance of software components, the

behavior of the users initiating them should be specified bydefining a behavior requirement for each role, indicating howfrequent a role is activated, described by an activation dis-tribution function (e.g., Binomial, Poisson, Normal) and itsinitialization parameters. To describe alternative user be-havior on specific occasions, for example a heavier work-load, a different behavior requirement can be defined. Bothbehavior and Servive-QoS requirements are used during sys-tem evaluation to properly initiate evaluation scenarios, thuscorresponding evaluation entities (e.g., Eval-Role and Eval-Service) conform to them. Corresponding model elementsare expected to conform to these requirements.Module-QoS-req indicates the resources consumed by soft-

ware tiers and are described by quantitative properties in asimilar fashion as responseTime-req (see figure 3). Theyare derived from Service-QoS-reqs of services belonging tothem. In such case, a computation formula must be defined,as indicated by the corresponding property of Module-QoS-req. Processing and storage Module-QoS requirements are

computed for each module, while a traffic Module-QoS re-quirement is computed for each Module-Invoke relationship,indicating the information exchange between modules.

The computation of the processing Module-QoS require-ment is briefly discussed in the following as an example.It consists of the estimation of avg-value and max-valueproperties (indicating the average and maximum process-ing power required by the hardware node the module willoperate on). Their values are estimated based on the valueproperty of the processing Service-QoS requirement of allServices belonging to that Module and the properties ofRoles initiating them (either directly or indirectly). Thecalculation formula is presented in algorithm 1 and is basedon heuristics.

for j = 1 to s dofor k = 1 to r do

for t = 0 to 23 doif k.StartT ime ≤ t ≤ k.EndTime then

SRmaxj [k, t] = k.numOfOccursSRavgj [k, t] = k.numbOfOccrs ∗ percentagek→j

elseSRmaxj [k, t] = 0SRavgj [k, t] = 0

end ifend for

end forfor t = 0 to 23 do

Smaxj [t] =∑r

k=1 SRmaxj [k, t]Savgj [t] =

∑rk=1 SRavgj [k, t]

end forfor t = 0 to 23 do

Smaxprocj [t] = Smaxj [t] ∗ s.procSavgprocj [t] = Savgj [t] ∗ s.proc

end forend forfor t = 0 to 23 do

Mmaxproc[t] =∑s

j=1 Smaxprocj [t]

Mavgproc[t] =∑s

j=1 Savgprocj [t]

end formaxproc = max23

t=0 Mmaxproc[t]

avgproc =∑23

t=0 Mavgproc[t]

x , where x the number ofMavgproci[t] = 0

Algorithm 1: Calculating the max-value and avg-valueattributes of the processing Module-QoS-requirement

Figure 4: Functional View excerpt: defining perfor-mance requirements

According to the algorithm, for each Module, a set namedSRV is defined, so as to include all services that belong toa module mod. Each set contains s elements. A set namedROL(i) is defined for each element srv(i) of set SRV, soas to include all roles that initiate directly or indirectly aservice srv. Each set contains r elements. For each ser-vice srv(i) that belongs to a module mod and is initiatedby a set of roles ROL(i), a matrix is defined, having 24columns (the hours of a day) and r rows. This matrix iscalled SRmaxsrv. Each row of the matrix has as valuesthe instances (numOfOccurs) of that role that initiate di-rectly or indirectly the service in the specific time intervaldefined by the StartT ime and EndTime properties of theRole. SRavgsrv matrix is defined in a similar fashion to in-dicate the average number of roles that initiate the service.Maximum and average concurrent role instances initiatingthe service, called Smaxsrv and Savgsrv, are estimated foreach time-interval.The maximun and average processing requirement for each

Module for each time interval indicated by Mmaxproc andMavgproc matrices are estimated based on Smaxsrv andSavgsrv matrices and the value attribute of correspondingService-QoS requirement (indicated as proc) of all the ser-vices belonging to the Module.Maximum processing Module-QoS requirement, calledmax-

proc, is estimated as the maximum value of Mmaxproc ma-trix. Average processing Module-QoS requirement, calledavgproc, is estimated as the average value of Mavgproc ma-trix.Figure 4 presents a part of a Functional view diagram,

where two roles (officer-1 and manager) initiate services be-longing to a Client Module (accounting app). For each ser-vice, for example edit employee data service, a response timerequirement has been defined (s1-RT ). Processing, storageand traffic Service-QoS requirements have also been defined.The accounting app Module-QoS-reqs are calculated by thetool.

3.2 Verifying Software Performance Require-ments

As indicated in figure 3 evaluation entities are used toevaluate software performance. Their input properties are

initialised by the corresponding software entity properties.In the case of EIS Architecture design, evaluation scenar-ios are explored using an external simulator, build for thispurpose.

The evaluation entities’ input properties are used to ini-tialize the simulation model and the output properties areused to store simulation output. To verify a performancerequirement, the system engineer should be informed of anyconflicts between evaluation entities output properties andcorresponding requirement properties. For example, themax and average ResponseTime output properties of Eval-Service entity are compared to ResponseTime requirementproperties, to verify if the requirement is satisfied. The valueof derived requirements calculated for Module and Module-Invoke entities are also verified using Eval-Module entity.However, not all requirements related to a software compo-nent have to be verified. For example, the input propertiesof Eval-Service entity include the Service-QoS requirementsthat the corresponding service satisfies, and indicate the con-ditions under which the evaluation should be performed. Insuch case, the Eval-Service entity conforms to the Service-QoS requirement, defined for service component behavior ina quantitative fashion (figure 3).

Through performance evaluation scenarios, the conflictsin performance requirement verification should be visuallypresented to the system engineer. Services and modules,failed to satisfy related performance measures, are visuallyidentified, while the system engineer is the one responsible toadjust EIS architecture design and initiate another evalua-tion scenario. Since evaluation scenarios become part of thesystem model, he/she may refer to them to realize the effectof specific architecture decisions on the EIS architecture.

Figure 5 includes a part of the Evaluation diagram cor-responding to the entities defined in figure 4. Evaluationentities are automatically added in the diagram by the tool,while the system engineer adds the requirements they mustconform to.

After the completion of the simulation experiment of thisscenario, output parameters of all evaluation entities arefilled. Constraint validation rules are utilized to indicatethe evaluation entities associated to non-verified require-ments. Evaluation entities not verifying a model constraintare marked with red color, and the designer is able, by click-ing on them, to identify the non-verified requirement. Forexample, as shown in the figure, the s1-RT Response Timerequirement is not verified by edit employee data service;thus the corresponding evaluation entity is marked with redcolor. The system engineer may view output properties andrealize the conflict. In this case, the estimated maximum re-sponse time is outside the limits of the value interval for theResponse Time requirement. The system engineer shoulddecide whether this requirement will be relaxed or the nec-cessary actions in order to improve software architecture per-formance.

The existence of the Evaluation diagram helps the systemdesigner to better realize the affect of his/her redesign de-cisions. System designers that tested the tool, appreciatedthe fact that all the information related to requirement ver-ification was presented in a single diagram. They also founduseful that all different experiments results were maintainedand could be used when making modification in architecturedesign.

Figure 5: Evaluation diagram excerpt: response time requirement verification

4. CONCLUSIONSSysML provides distinct diagrams to describe system struc-

ture and components, explore allocation policies and iden-tify system requirements. However, during system design,non-functional requirements (for example performance re-quirements) affecting efficient system operation should beeffectively explored. Proposed system designs should be val-idated and properly adjusted until an acceptable architec-ture is defined. SysML provides for requirements descriptionin an abstract fashion. To support non-functional require-ments, the SysML requirement entity must be extended.The integration of an Evaluation diagram consisting of eval-uation scenarios, facilitates system design validation and re-quirement verification, while evaluation results are includedin the system model.The proposed profile is currently tested using real-world

case studies to identify limitations of the proposed approach.The way the exploration of complex models may affect theperformance of EIS Architecture Design MagicDraw plugin,especially during derived requirement computation and eval-uation scenario creation is also under investigation.

5. REFERENCES[1] H. Espinoza, D. Cancila, B. Selic, and S. Gerard.

Challenges in combining sysML and MARTE formodel-based design of embedded systems. InECMDA-FA, volume 5562 of Lecture Notes inComputer Science, pages 98–113. Springer, 2009.

[2] J. A. Estefan. Survey of Model-based SystemsEngineering (MBSE) Methodologies. INCOSE MBSEFocus Group, May 2007.

[3] O. M. G. Inc. UML Superstructure Specification,Version 2.1.2, November 2007.

[4] O. M. G. Inc. UML profile for MARTE: Modeling andanalysis of real-time embedded systems specification,

version 1.0, November 2009.

[5] O. M. G. Inc. Systems Modeling Language (SYSML)Specification, Version 1.2, June 2010.

[6] ITU. User requirements notation URN - languagedefinition. ITU-T Reccomendation Z.151, ITU, Nov.2008.

[7] M. H. Kacem, M. Jmaiel, A. H. Kacem, and K. Drira.A uml-based approach for validation of softwarearchitecture descriptions. In TEAA, pages 158–171,2006.

[8] L. F. McGinnis and V. Ustun. A simple example ofSysML-driven simulation. In Winter SimulationConference, pages 1703–1710. WSC, 2009.

[9] MagicDraw UML. http://www.magicdraw.com/.

[10] J. Mylopoulos, L. Chung, and B. Nixon. Representingand using non-functional requirements: Aprocess-oriented approach. IEEE Transactions onSoftware Engineering, 18:483–497, 1992.

[11] M. Nikolaidou, A. Tsadimas, N. Alexopoulou, andD. Anagnostopoulos. Employing Zachman EnterpriseArchitecture Framework to systematically performModel-Based System Engineering Activities. InHICSS-42, pages 1–10, 2009.

[12] R. Peak, R. Burkhart, S. Friedenthal, M. Wilson,M. Bajaj, and I. Kim. Simulation-based design usingsysml part 1: A parametrics primer. San Diego, CA,USA, 2009. INCOSE Intl. Symposium.

[13] R. Wang and C. Dagli. An executable systemarchitecture approach to discrete events systemmodeling using SysML in conjunction with coloredpetri nets. In IEEE Systems Conference 2008.

[14] L. Zhu and I. Gorton. Uml profiles for design decisionsand non-functional requirements. In SHARK-ADI ’07,page 8, Washington, DC, USA, 2007. IEEE ComputerSociety.