bCMS Requirements Modelling using RELAX/SysML/KAOS
Manzoor Ahmad and Jean-Michel Bruel IRIT/U. of Toulouse
Toulouse, France Email: {ahmad,bruel}@irit.fr Abstract—In this paper we have modelled an illustrative
subset of the requirements of the bCMS case study using a com- bined approached called RELAX/SYSML/KAOS. This submission is part of a broader effort that aim to compare three specific requirements modelling techniques (see [1], [2], [3], [4]).
I. INTRODUCTION
Self adaptive systems modify their behaviour at run-time in response to changing environmental conditions. For these systems, Non Functional Requirements (NFRs) play an im- portant role and one has to identify those requirements that are adaptable as early as possible in the software development life cycle. Our proposed approach; RELAX/SYSML/KAOS is based on this assumption i.e. to consider these adaptable re- quirements as early as possible while specifying these systems.
We have modeled the bCMS requirements using our proposed approach.
RELAX [7] is a requirements engineering language for Dynamic Adaptive Systems (DAS), where explicit constructs are included to handle uncertainty. The RELAX vocabulary helps in relaxing requirements when environment changes so it enables the analysts to identify the point of flexibility in their requirements which is achieved using the RELAX process [7].
The SYSML/KAOS[11] model is an extension of the SYSML1 requirements model with concepts of the KAOSgoal model [9].
In section II we describe the context in which this study has been conducted, the bCMS case study, as well as the minimum of background needed to understand the models, in section III we put forward our combined approach for modeling the bCMS requirements, in section IV we provide the requirements models we have developed for the bCMS case study using our approach, in section V we conclude this study. In section VI we provide the required statements about the approach and finally the detailed requirements are provided in section VII.
II. CONTEXT
In this section, we give a brief description of the bCMS case study and the concepts that form our integrated approach.
A. The bCMS Case Study
In this paper we model an illustrative subset of the bCMS case study2. Here is an excerpt of the case study.
1http://www.omgsysml.org/
2Available at http://cserg0.site.uottawa.ca/cma2013re/CaseStudy.pdf
The bCMS is a distributed crash management system that is responsible for coordinating the communication between a Fire Station Coordinator (FSC) and a Police Station Coordinator (PSC) to handle a crisis in a timely manner. Information regarding the crisis as it pertains to the tasks of the co- ordinators is updated and maintained during and after the crisis. There are two collaborative sub-systems. Thus, the global coordination is the result of the parallel composition of the (software) coordination processes controlled by the two (human) distributed coordinators. There is no central database; fire and police stations maintain separate databases and may only access information from the other database through the bCMS system. Each coordination process is hence in charge of adding and updating information in its respective database. Fig. 1 shows the overall view of the bCMS case study.
Fig. 1. bCMS Case Study Overall View
B. SysML
SYSML (System Modelling Language) is a general pur- pose modeling language for systems engineering applications.
It supports the specification, analysis, design, verification and validation of a broad range of systems and systems-of-systems.
These systems may include hardware, software, information, processes, personnel, and facilities. It includes a graphical construct to represent text based requirements and relate them to other model elements.
SYSML was created in 2001. Its first official Object Management Group (OMG) specification has been released in September 2007. The current version is 1.3 [6]. Its initiators were the OMG and the International Council on Systems
Engineering (INCOSE). Its main authors were Conrad Bock, Cris Kobryn and Sanford Friedenthal.
SYSML provides graphical representations with a seman- tic foundation for modelling system requirements, behavior, structure, and parametrics. The requirements diagram captures requirements hierarchies and requirements derivation (e.g. the
<<satisfy>> and <<verify>> relationships allow a modeler to relate a requirement to a model element, e.g.
<<block>>, that satisfies or verifies the requirements. The requirement diagram provides a bridge between typical re- quirements management tools and system models. The readers are referred to [1] for the bCMS requirements modeling using SYSML.
C. RELAX
RELAX [7] is a requirements engineering language for DAS, where explicit constructs are included to handle uncer- tainty. RELAX takes the form of structured natural language, including operators designed specifically to capture uncertainty [15], their semantics is also defined. Uncertainty can be en- vironmental and behavioral; environmental uncertainty is due to changing environmental conditions such as sensor failure, noisy networks, malicious threats and unexpected human input.
Here uncertainty refers to maintaining the same requirements in unknown contexts. Behavioral uncertainty refers to situ- ations where requirements themselves need to change. For example, the requirements of a space probe may change mid- flight in order to pursue science opportunities not foreseen by the designers. It is difficult to know all requirements changes at design time and, in particular, it may not be possible to enumerate all possible alternatives. Behavioral uncertainty refers to the need to change system behavior at run time in response to the environmental uncertainty.
The RELAX vocabulary helps in relaxing requirements when environment changes so it enables the analysts to identify the point of flexibility in their requirements. For this pur- pose, RELAX process [7] is used which divides requirements into two types: variant or RELAX-ed requirements that can be RELAX-ed when the environment changes, and invariant requirements that are fixed and cannot be changed since they represent the main functionality of the system. In RELAX
the conventional modal verb SHALL is retained and RELAX
operators (e.g. AS CLOSE AS POSSIBLE TO, AS EARLY AS POSSIBLE etc., [7]) are introduced to provide more flexibility in how and when that functionality may be delivered. More specifically, for requirements that are left partially unsatisfied, the introduction of an alternative, temporal or ordinal RELAX- ation modifier will define the requirement as RELAX-able.
These operators define constraints on how a requirement can be RELAX-ed at run-time. In addition, it is important to indicate what uncertainty factors warrant a RELAX-ation of these requirements, thereby requiring adaptive behavior.
This information is specified using the MON (monitor), ENV (environment), REL (relationship) and DEP (dependency) keywords.
We have developed a Domain Specific Language (DSL) which links SYSML and RELAX [16]. SYSML provides a development environment and a graphical support for express- ing all the variables of RELAX and helps in bridging the gap between requirements and the overall system model.
D. SysML/Kaos
The SYSML/KAOS language [11] is an extension of the SYSML requirements language [6] with the most relevant concepts of the KAOS goal model [9] and NFR Framework [8], two goal based approaches largely recognized and used in requirements engineering over the past decade. The main idea is to introduce the concept of goals in a SYSML requirements model, which would help to take advantage of the contribution of SYSML while providing a clear definition of requirements and relationships between them. For that, we combine the concepts of KAOSthat are better suited to represent functional requirements with concepts of the NFR model which are most relevant to specify non-functional requirements. This allows the integration of non-functional requirements much earlier and at the same level of abstraction than functional require- ments. As SYSML/KAOS is a goal based approach, it allows detection and resolution of conflicts among requirements and it helps reasoning about alternative configurations. In addition, it specifically allows the detection and analysis of impact of non-functional requirements on functional requirements.
Indeed, non-functional requirements may have an impact on the choices and decisions taken when refining functional requirements. It can lead to the identification of new functional requirements that must be integrated with the initial functional goal model. The instantiation of the SYSML/KAOS meta- model allows us to obtain a hierarchy of requirements in the form of goals. In a first step, functional and non-functional requirements are specified at the same level of abstraction, but in two separate goal models. A final integrated goal model is then built. The latter reflects the impact of non-functional requirements on functional ones.
Non Functional Goals (NFG) in SYSML/KAOSare orga- nized in refinement hierarchies. An NFG is either an abstract NFG or an elementary NFG. A goal that cannot be further refined is an elementary goal. An elementary goal can be satisfied by a contribution goal. A contribution goal contributes positively/negatively and directly/indirectly towards the sat- isfaction of an elementary goal. An NFG can be written in the form of: NFGType [Topic] where the attribute NFGType specify the type of NFR and the attribute Topic represent the domain element effected by this type of requirement.
The refinement of an NFG can be either refinement by type (NFGType) or refinement by subject (Topic). SYSML/KAOS
has the concept of Impact which shows the impact of an NFG on a Functional Goal (FG). Fig. 2 shows the extended SYSML/KAOSmeta-model. The readers are referred to [2] for the bCMS requirements modeling using SYSML/KAOS.
III. RELAX/SYSML/KAOSAPPROACH
Our proposition is based on the fact that both RELAXand SYSML/KAOSare complementary for each other [5]. RELAX
can take benefit from the direct/indirect and positive/negative Contribution and Impacts of the SYSML/KAOSapproach. To find a correlation between the two approaches, we have come up with a correspondence table [5] as shown in Table I, which shows how the two approaches deals with different concepts.
We have shown how several key concepts are taken into account in the selected models. Most of the time, the concepts are not fully covered (e.g. <<satisfy>> for monitoring in SYSML, this stereotype is used between a block and a
Fig. 2. SysML/Kaos Meta Model
requirement), but we have indicated in the Table I, the closest mechanism that supports the concepts. In SYSML/KAOS, requirements are described in the form of goals, SYSML describes requirements in textual form while RELAXrequire- ments are also in textual form with an enhanced version i.e. re- quirements divided into invariant and RELAX-ed requirements with uncertainty factors added to it. To deal with monitoring, SYSML/KAOS has the Contribution Goal concept, which is used to satisfy an NFG, SYSML has <<satisfy>> which is used when a <<block>> satisfies a <<requirement>>
while for RELAX, we have the concept of MON which is used to measure the environment i.e. ENV. For relationship, SYSML/KAOS has the concept of AND/OR relationship and Contribution. Contribution describes the characteristics of the contribution, it provides two properties: ContributionNature and ContributionType. The first one specifies whether the contribution is positive or negative, whereas the second one specifies whether the contribution is direct or indirect, SYSML has <<verify>> and <<refine>> relationships while for RELAX, we have REL variable which identifies the rela- tionship between ENV and MON. For Dependency/Impact, SYSML/KAOS describes it as an Impact of an NFG on Functional Goal (FG); this Impact can be positive or negative.
In SYSML/KAOS meta-model (see [11]), the Impact is an Association Class between Contribution Goal and an FG. It captures the fact that a Contribution Goal has an impact on an FG which in turn shows it as an Impact of an NFG on an FG.
While for SYSML, we have the concept of <<derive>>
which shows the dependency between requirements, RELAX
has positive and negative dependency. SYSML/KAOS has a tool called SYSML/KAOS editor, SYSML has a number of tools e.g. eclipse3, papyrus4, topcased5 etc. and for RELAX, we have eclipse based COOL RELAX editor [14].
Based on the mentioned correlation between different con- cepts of RELAXand SYSML/KAOS, a RELAX-ed requirement in RELAXserves as an Abstract Goal in SYSML/KAOS, ENV becomes Elementary Goal, MON serves as Contribution Goal, REL becomes AND/OR relationship and direct/indirect posi- tive/negative Contribution, and DEP becomes positive/negative
3http://www.eclipse.org/
4http://www.papyrusuml.org
5http://www.topcased.org/
Impacts. Based on the correlation, we are working on the transformation of RELAX requirements into SYSML/KAOS
goals (Work in progress) [13]. For this, we are using Atlas Transformation Language (ATL)6 where we define rules to transform each concept of RELAX into the corresponding SYSML/KAOS concept.
TABLE I. CORRESPONDENCE B/WRELAXANDSYSML/KAOS
IV. BCMSREQUIREMENTS MODEL
We have chosen an (illustrative) subset of the bCMS requirements. The requirements were shared and numbered in a shared document7 (see Fig. 3). The list of the requirements we have taken into account is provided in appendix VII.
Fig. 3. bCMS Requirements
We have first applied the RELAX process on the bCMS requirements to get invariant and RELAX-ed requirements. For RELAX-ed requirements, all the uncertainty factors were iden- tified. Then using the correlation in [5] we have modelled the bCMS system requirements with the SYSML/KAOSapproach.
Following are the invariant and RELAX-ed requirements that were identified (see section VII):
• Invariant requirements: R1, R2, R3.
• Relax-ed Requirements: R4, R8.
6http://www.eclipse.org/atl/
7Available at http://goo.gl/uscP5.
TABLE II. RELAX-EDREQUIREMENTR4 UNCERTAINTYFACTORS Uncertainty
Factors Details
ENV
integrity of the communication between coordinators, the authenticity of the coordinators to avoid the communication compromiser
MON use secure communication channel, use PIN code, use ad- ditional information, communication compromiser
REL
secure communication channel ensures the integrity of the communication between coordinators, PIN code and Ad- ditional information ensures that the authenticity of the coordinator is in place, The communication compromiser compromises the integrity of coordinators
TABLE III. RELAX-EDREQUIREMENTR8 UNCERTAINTYFACTORS Uncertainty
Factors Details
ENV
The crisis details and route plan of the fire station shall be available, the crisis details and route plan of the police station shall be available
MON Fire Station Coordinator, Police Station Coordinator, Com- munication Compromiser
REL
Fire Station Coordinator updates the crisis details and route plan of the fire station, Police Station Coordinator updates the crisis details and route plan of the police station, The Communication Compromiser compromises the availability of data
Here is the RELAX-ed version of R4 (The system shall ensure that the integrity of the communication between coor- dinators regarding crisis location, vehicle number, and vehicle location is preserved AS CLOSE AS POSSIBLE TO 99.99% of the time.see Table II):
Here is the RELAX-ed version of R8 (The crisis details and route plan of the fire station and the police station shall be available with the exception of AS CLOSE AS POSSIBLE TO 30 minutes for every 48 hours when no crisis is active.see Table III):
A. High Level Goal Model
The goal at the highest level is identified as Security[bCMS System], which is an abstract NFG and is AND refined into two sub goals using refinement by type: (i) Integrity[bCMS System] and (ii) Availability[bCMS System]. The goal Avail- ability[bCMS System]is an abstract NFG and is AND refined into three sub goals using refinement by type: (i) “The crisis details and route plan of the fire station and the police station shall be available with the exception of a total of 30 minutes for every 48 hours when no crisis is active[bCMS System]”, (ii) “The crisis details and route plan of the fire station and the police station shall be available with the exception of a total of 5 minutes during the time period when at least one crisis is active. [bCMS System]” and (iii) “The information related to the identification of the coordinators shall be available with the exception of a total of 5 minutes during the time period when at least one crisis is active[bCMS System]”. The goal “The crisis details and route plan of the fire station and the police station shall be available with the exception of a total of 30 minutes for every 48 hours when no crisis is active[bCMS System]”is an abstract NFG and is AND refined into two elementary goals using refinement by type: (i) “The crisis details and route plan of the fire station shall be available[bCMS System]” and (ii)
“The crisis details and route plan of the police station shall be available[bCMS System]”. The goal “The crisis details and route plan of the fire station shall be available[bCMS System]”
is satisfied by the contribution goal Fire Station Coordinator having a direct and positive contribution on it and the goal
“The crisis details and route plan of the police station shall be available[bCMS System]” is satisfied by the contribution goal Police Station Coordinator which also has a direct and positive contribution on its accomplishment. The contribution goal Communication Compromiser contributes directly and negatively towards the satisfaction of the two elementary goals whose objective is to disrupt the response to the crisis for some personal gain. Fig. 4 shows the high level goal model of the bCMS case study.
The SYSML/KAOSapproach helps in modeling the impact of a NFG on a FG. In SYSML/KAOS meta-model [11], the contribution goal has an impact on a FG. A FG express a requirement that the future system will exhibit and a NFG is the quality to be achieved in the future system which is satisfied by a contribution goal. The concept of Impact is represented as an Association Class between a contribution goal and a FG which in turn helps to show the impact of a NFG on a FG. In Fig. 4, the abstract functional goal “A FSC maintains control over a crisis situation by communicating with the police station coordinator (PSC) as well as firemen”
is refined into three sub goals: (i) To get resources to the crisis location, (ii) To handle crisis related information and (iii) To provide executable instructions to staff. The contribution goal Fire Station Coordinator has a direct and positive impact on each of the three functional sub goals.
B. Low Level Goal Model
To continue further with modelling, another goal “Ensure the integrity of communications b/w coordinators[bCMS]” is identified which is an abstract non-functional goal and is AND refined into two sub goals using refinement by type:
(i) Integrity of communication b/w coordinators[bCMS] and (ii) Authenticity of coordinators[bCMS]. The goal Integrity of communication b/w coordinators[bCMS]is satisfied by the contribution goal Secure communication channel. Considering the goal Authenticity of coordinators[bCMS], one possible way to achieve this goal is to use PIN code, another solution is to use additional information. The contribution goal Commu- nication Compromiser has a direct and negative impact on the goal Integrity of communication b/w coordinators[bCMS].
The contribution goal Communication Compromiser has an indirect and negative impact on the functional goal To estimate resources. Fig. 5 shows the low level goal model of the bCMS case study.
V. CONCLUSION
The proposed RELAXand SYSML/KAOSapproach models the non functional requirements of self adaptive systems. RE-
LAX is a requirements engineering language for self adaptive systems and allows requirements to temporarily RELAX to adapt to changing environmental conditions. SYSML/KAOS
extends the SYSML meta-model with goal concepts. Both these approaches treat non functional requirements at the high level of abstraction. A correspondence table is used which shows the correlation between different concepts treated by each approach. First of all, non functional RELAX-ed require- ments with uncertainty factors are identified in the bCMS case study and based on the correlation table, they are mapped to
Fig. 4. High level goal model
Fig. 5. Low level goal model
SYSML/KAOSconcepts. SYSML/KAOSis then used to model these non functional RELAX-ed requirements. In this paper we have modelled the NFGs of the bCMS case study while the concept of Impact is used to show the impact of an NFG on an FG. We have modelled a subset of the requirements of the bCMS case study.
REFERENCES
[1] N. Belloir and J.-M. Bruel, bCMS requirements modelling using SysML, submitted to the 3rd CMA workshop at RE’2013.
[2] R. Laleau, C. Gnaho, F. Semmak and J.-M. Bruel, bCMS requirements modelling using SysML/KAOS, submitted to the 3rd CMA workshop at RE’2013.
[3] J. Ara´ujo and J.-M. Bruel, bCMS requirements modelling using KAOS, submitted to the 3rd CMA workshop at RE’2013.
[4] J.-M. Bruel, Self-Adaptive Systems Requirements Modelling: four re- lated approaches comparison, submitted to the 3rd CMA workshop at RE’2013.
[5] M. Ahmad, J.-M. Bruel, R. Laleau and C. Gnaho, Using RELAX, SysML and KAOS for Ambient Systems Requirements Modeling, 3rd Int. Conf.
on Ambient Systems, Networks and Technologies (ANT) proceedings.
Elsevier, Vol 10, p. 474-481, 2012.
[6] OMG. SysML specification. v1.3, 12/06/2012. Available at http://www.
sysml.org/docs/specs/OMGSysML-v1.3-12-06-02.pdf.
[7] Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty H.C. Cheng, and Jean- Michel Bruel. RELAX: Incorporating Uncertainty into the Specification of Self-Adaptive systems, Proceedings of the 2009, 17th IEEE Interna- tional Requirements Engineering Conference, Pages: 79-88.
[8] Lawrence Chung, Julio Cesar and Sampaio Prado Leite. Non Functional Requirements in Software Engineering. Kluwer, 1999.
[9] Axel Van Lamsweerde. Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley, 2009.
[10] Annie I. Anton. Goal based requirements analysis. In Proceedings of Int. Conf. on Requirements Engineering, 1996.
[11] Christophe Gnaho, Farida Semmak. Une extension SYSML pour l’ing´enierie des exigences non-fonctionnelles orient´ee but. Revue Ing´enierie des Syst`emes d’Information, Vol 16/1, 23 pages, 2011.
[12] Christophe Gnaho, Farida Semmak, R´egine Laleau. An overview of a SysML extension for goal-oriented NFR modelling. Seventh IEEE International Conference on Research Challenges in Information Science, May 29-31 2013, Paris, France.
[13] J´er´emy Bascans, J´er´emy Walczak, J´erome Zeghoudi, Manzoor Ahmad, Jacob Geisel, Jean Michel Bruel. RELAX/SysML/Kaos Editor. M2ICE Project, Universit´e de Toulouse le Mirail.
[14] J´er´emy Bascans, J´er´emy Walczak, J´erome Zeghoudi, Manzoor Ahmad, Jacob Geisel, Jean Michel Bruel. COOL RELAX Editor, M2ICE Project, Universit´e de Toulouse le Mirail.
[15] Jon Whittle, Pete Sawyer, Nelly Bencomo and Betty H. C. Cheng. A Language for Self-Adaptive System Requirements. International Work- shop on Service-Oriented Computing: Consequences for Engineering Requirements, 2008. SOCCER ’08.
[16] Manzoor Ahmad. First step towards a domain specific language for self-adaptive systems. 10th Annual International Conference on New Technologies of Distributed Systems (NOTERE’10) IEEE, 285-290.
APPENDICES
VI. STATEMENTS
Classification of the approach
The integrated approach is feature-oriented, object- oriented, and goal-oriented.
Software development phases
The integrated approach addresses mainly the early require- ments specification and analysis, high-level and architectural design
What is modelled
The system in its environment (links between requirements, environment, and systems parts).
The modeling approach See section III.
References
For more on the integrated approach see [5] or the URL:
http://fr.linkedin.com/in/manzoorahmad1.
Relation between submodels See section IV.
VII. REQUIREMENTS STUDIED
Req. ID Text
R1
A FSC maintains control over a crisis situation by communicating with the po- lice station coordinator (PSC) as well as firemen.
R2
To resolve a crisis situation as quickly and cost-effectively as possible in cooperation with other coordinator.
R3
A PSC maintains control over a crisis situation by communicating with the fire station coordinator (FSC) as well as po- licemen.
R4
The system shall ensure that the integrity of the communication between coordi- nators regarding crisis location, vehicle number, and vehicle location is preserved 99.99% of the time.
R5
The systems shall ensure that the integrity of all other data transmitted between the coordinators is preserved 95% of the time.
R6 The system shall respond to user requests within 5 seconds 95% of the time.
R7 The system shall respond to user requests within 30 seconds 99.99% of the time.
R8
The crisis details and route plan of the fire station and the police station shall be available with the exception of a total of 30 minutes for every 48 hours when no crisis is active.
R9
The crisis details and route plan of the fire station and the police station shall be available with the exception of a total of 5 minutes during the time period when at least one crisis is active.
R10
The information related to the identifica- tion of the coordinators shall be available with the exception of a total of 5 minutes during the time period when at least one crisis is active.
R11 To get resources to the crisis location.
R12 To handle crisis related information.
R13 To provide a strategy for handling the crisis.
R14 To estimate resources.
R15 To collect crisis related information.
R16 To transmit crisis related information.
R17 To provide coordinated route plan.
R18 To provide executable instructions to staff.
