RCM: Requirement Capturing Model for Automated Requirements

Formalisation

Aya Zaki-Ismail

1 a

, Mohamed Osama

1 b

, Mohamed Abdelrazek

1 c

, John Grundy

2 d

and Amani Ibrahim

1 e

Information Technology Institute, Deakin University, 3125 Burwood Hwy, VIC, Australia

Information Technology Institute, Monash University, 3800 Wellington Rd., VIC, Australia

Keywords:

Requirement Representation, Requirement Modeling, Requirement Engineering, Requirement Formalisation.

Abstract:

Most existing automated requirements formalisation techniques require system engineers to (re)write their

requirements using a set of predeﬁned requirement templates with a ﬁxed structure and known semantics to

simplify the formalisation process. However, these techniques require understanding and memorising require-

ment templates, which are usually ﬁxed format, limit requirements captured, and do not allow capture of more

diverse requirements. To address these limitations, we need a reference model that captures key requirement

details regardless of their structure, format or order. Then, using NLP techniques we can transform textual

requirements into the reference model. Finally, using a suite of transformation rules we can then convert

these requirements into formal notations. In this paper, we introduce the ﬁrst and key step in this process, a

Requirement Capturing Model (RCM) - as a reference model - to model the key elements of a system require-

ment regardless of their format, or order. We evaluated the robustness of the RCM model compared to 15

existing requirements representation approaches and a benchmark of 162 requirements. Our evaluation shows

that RCM breakdowns support a wider range of requirements formats compared to the existing approaches.

We also implemented a suite of transformation rules that transforms RCM-based requirements into temporal

logic(s). In the future, we will develop NLP-based RCM extraction technique to provide end-to-end solution.

1 INTRODUCTION

Formal veriﬁcation techniques requires system re-

quirements to be expressed in formal notations

(Buzhinsky, 2019). However, the majority of critical

system requirements are still predominantly written in

informal notations (textual or natural languages - NL),

which are inherently ambiguous and have incomplete

syntax and semantics (L

ucio et al., 2017b; Sl

adekov

2007). To automate the formalisation process, sev-

eral bodies of work within the literature focused

on proposing pre-deﬁned requirement templates, pat-

terns (Justice, 2013), boilerplates (Mavin et al., 2009),

and structured control English (R. S. Fuchs, 1996), to

express one system requirement sentence while elim-

inating the ambiguities. Such templates have com-

plete syntax to ensure the feasibility of transform-

https://orcid.org/0000-0002-1580-6619

https://orcid.org/0000-0002-6940-0833

https://orcid.org/0000-0003-3812-9785

https://orcid.org/0000-0003-4928-7076

https://orcid.org/0000-0001-8747-1419

ing textual requirements into formal notations using

a suite of manually crafted, template-speciﬁc trans-

formation rules (e.g., (Yan et al., 2015)). However,

some of the predeﬁned templates are domain depen-

dent and are hard to generalise (Rupp, 2009), or can

only capture limited subsets of requirements struc-

tures (R. S. Fuchs, 1996). In addition, most exist-

ing formalisation algorithms are customized for trans-

forming system requirements to one target formal lan-

guage. Thus, a need to transform the same require-

ments into different formal languages mandates sig-

niﬁcant rework of the formalisation algorithm.

Complementary to this research direction, in-

stead of considering introducing new sentence-based

templates covering a wider range of requirements

and complicating the requirements speciﬁcation pro-

cess, we introduce a Requirement Capturing Model

(RCM), as a reference model that deﬁnes the key

properties that make up a system behavioral require-

ment sentence, regardless of the syntactic structure of

these properties, lexical-words, or their order. RCM

separates the writing styles (format and structure)

110

Zaki-Ismail, A., Osama, M., Abdelrazek, M., Grundy, J. and Ibrahim, A.

RCM: Requirement Capturing Model for Automated Requirements Formalisation.

DOI: 10.5220/0010270401100121

In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2021), pages 110-121

ISBN: 978-989-758-487-9

from the abstract requirement properties and the for-

mal notations. Our new RCM model thus enables

us to: (1) represent a much wider range of require-

ments that have differing count, order or types of

properties, by identifying the speciﬁc properties in the

input requirement sentence to generic RCM deﬁned

properties; (2) specify requirements in a wide vari-

ety of different formats, extremely useful to avoid re-

writing existing requirements; (3) formalize require-

ments into different formal notations through map-

ping RCM properties to those of the target formal

notation; and (4) enable use of NLP-based require-

ments extraction techniques to transform textual re-

quirements into the RCM-based requirements model.

with the key elements to be extracted now clearly de-

ﬁned and known. Our key contributions in this paper

are:

• Introduce RCM as a reference model and interme-

diate representation between informal and formal

notations.

• A suite of transformation rules from RCM to Met-

ric Temporal Logic (MTL), to demonstrate how

an RCM-based requirements model can be trans-

formed into formal notations.

• Evaluating the RCM representation power by

comparing it to 15 other existing approaches us-

ing 162 behavioral requirements for critical sys-

tems. We provide the RCM representation and

corresponding automatically generated (MTL and

CTL) formal notations for the 162 requirements.

2 MOTIVATION

Jen is a system engineer working for an automotive

company. She wants to specify the requirements of

one of the system modules - a small excerpt is shown

in Table 1 - while making sure that these require-

ments can be easily transformed into formal notations

as a mandatory compliance requirement. Jen decided

to check the existing requirement speciﬁcation tech-

niques in the literature to choose which one covers

most of her requirements. Jen researched existing re-

quirements formalisation techniques, see the related

work section for these techniques, and outlined her

trials to use these techniques to model her require-

ments after rephrasing some of her requirements to

suit existing templates.

Jen found that none of the existing techniques

she found can be used to cover all her require-

ments. She then had to learn and use all these tem-

plates and have these tools all running. Further-

more, Jen found that the majority of these solutions

Table 1: Examples of critical system requirements and ap-

proaches to represent.

RQ1: R STATUS shall indicate the rain sensor. It shall be

ON, when the external environment is raining.

Techniques: Universal pattern (Teige et al., 2016), Struc-

tured English (Konrad and Cheng, 2005), Rup’s boilerplates

(Rupp, 2009), ACE(R. S. Fuchs, 1996), EARS(Mavin et al.,

2009), CFG(Sl

adekov

a, 2007) and BTC(Justice, 2013)

RQ2: When the external environment rains for 1 minute, the

wipers shall be activated within 30 seconds until the rain sen-

sor equals OFF.

Techniques: Universal pattern (Teige et al., 2016) and

BTC(Justice, 2013)

RQ3: While the wipers are active, the wipers speed shall be

readjusted every 20 seconds.

Techniques: Structured English (Konrad and Cheng, 2005)

rely on pre-deﬁned formats and structure of require-

ments boilerplates. This mandates (1) a ﬁxed or-

der of requirement components/sub-components, (2)

a ﬁxed English-syntax for a speciﬁc component/sub-

component, (3) a ﬁxed/small set of English verbs or

other lexical words. Thus, Jen needs to rewrite her re-

quirements to conﬁrm the deﬁned format which puts

more overhead on her especially if the deﬁned formats

are limited and cannot be extended to new scenarios.

Taking into consideration all combinations of

styling, ordering, and omission/existence of different

requirements model properties will increase the size

of the deﬁned formats. Consequently this will in-

crease the complexity of using them by system en-

gineers and the complexity of the parsing algorithms

needed to transform them to formal models. Fur-

thermore, most existing formalization techniques ap-

ply on-the ﬂy transformation on the given structured

requirement sentences to generate formal notations.

These transformations are hard-coded or tightly cus-

tomized according to the target formal notation prop-

erties and formats. It would be much more useful if

the common parts are computed once and transformed

to intended notations as needed.

3 RELATED WORK

Many requirements formalisation approaches assume

requirements are speciﬁed in a constrained natural

language (CNL) with speciﬁc style, format and struc-

ture to be able to transform into formal notations -

e.g. (Ghosh et al., 2016; Nelken and Francez, 1996;

Michael et al., 2001; Holt and Klein, 1999; Ambriola

and Gervasi, 1997; Sturla, 2017; Pease and Li, 2010).

These CNL are meant to avoid natural language re-

RCM: Requirement Capturing Model for Automated Requirements Formalisation

111

lated quality problems (e.g., ambiguity inconsistency,

etc.) and increase the viability of automating the for-

malisation process.

CNL is a restricted form of NL, created for writing

technical documents as deﬁned in (Kittredge, 2003)

with the aim to reduce/avoid NL problems (e.g., am-

biguity inconsistency, .etc). CNL typically has a de-

ﬁned sub-set of NL grammar, lexicon and/or sen-

tence structure (Kuhn, 2014). Different forms of CNL

are also provided as a reliable solution for require-

ments representation. Fuchs et al. (R. S. Fuchs,

1996) propose Attempto Controlled English (ACE)

with a restricted list of verbs, nouns and adjectives for

the requirement set in addition to restrictions on the

structure of the sentence. ACE can be transformed

into Prolog. It can handle requirements with con-

dition and action components. Multiple CNLs pro-

posed later inspired by ACE (e.g., Atomate language

(Van Kleek et al., 2010), PENG(Schwitter, 2002)) for

formal generation purposes and for other purposes

(e.g., BioQuery-CNL (Erdem and Yeniterzi, 2009)).

Similarly to ACE, Scott and Cook(Scott et al.,

2004) presented Context Free Grammars (CFGs) for

requirement speciﬁcation. Although the format of

the requirement components is more limited than

ACE with additional restrictions on words, it cov-

ers time-related properties. Yan et al. (Yan et al.,

2015) presented a more ﬂexible CNL with constraints

on the word set such that, a clause should con-

tain (1) single word noun as a subject and a verb

predicate with one of the following formats ”verb

| be+(gerund|participle) | be+complement”, (2) the

complement should be adjective or adverbial word,

(3) prepositional phrases are not allowed except ”in +

time point” at the end of the clause. The CNL does not

consider time information except pre-elapsed time.

Boilerplates are also widely used. These provide

a ﬁxed syntax and lexical words with replaceable at-

tributes. Boilerplates are more limited than CNL and

require adaptation to different domains. In (Rupp,

2009), the provided RUP’s boilerplate can handle a

limited range of requirements. EARS (Mavin et al.,

2009) boilerplates are less restricted and can support

a wider range of requirements. Esser et al. (Esser

and Struss, 2007) proposed a suite of requirement

templates (TBNLS) with support mapping to proposi-

tional logic with temporal relations. For validating the

conformity of the written requirement and the boil-

erplate, authors in (Arora et al., 2013; Arora et al.,

2014) provide checking techniques.

Requirement patterns provide a more ﬂexible so-

lution. However, When a new requirement struc-

ture is added, a new pattern should be created for

it, which increases the size of the patterns set. In

(Teige et al., 2016) a universal pattern was presented

to support many requirements formats (trigger, then

action). They then introduced additional time-based

kernel patterns in (Justice, 2013). Although these

patterns cover many requirement properties, they do

not still cover the possible combinations of the sup-

ported properties eligible to one requirement speciﬁ-

cation. In addition, the approach lack complex time

properties - e.g. In-between-time and pre-elapsed-

time properties. Dwyer et al. (Dwyer et al., 1999)

proposed several patterns applicable for non-real-time

requirement speciﬁcations. These patterns are cate-

gorized into two major groups: occurrence patterns

and order patterns, while considering scopes (e.g.,

globally, before R, after R) for a given speciﬁca-

tion pattern. The work is extended later in (Konrad

and Cheng, 2005) to cope with real-time requirement

speciﬁcations. The real time patterns considers ver-

sions of the pre-elapsed-time, in-between-time and

valid-time information for the action component.

Event-Condition-Action (ECA) was initially pro-

posed in active databases area to express behavioral

requirements. ECA became widely used by several

researchers in difﬁdent areas. An ECA rule assumes

that when an event E occurs, the condition C will be

evaluated, and if true, the action A will be executed.

ECA notations have been extended to capture time in-

formation (Qiao et al., 2007). However, ECA rules

do not support (e.g., factual rules), and do not con-

sider scopes for action and the time notations apply

on events.

4 REQUIREMENT CAPTURING

MODEL

In this section, ﬁrst, we explain the process we fol-

lowed to develop the RCM. Then, we describe the

RCM metamodel in details. Finally, we provide RCM

to formal notations transformation procedure.

4.1 RCM Development Process

To identify the key requirement properties we needed

to support in a generic reference model for safety-

critical requirements, we reviewed a large number of

natural language-based critical system requirements

collected from many sources: (Jeannet and Gaucher,

2016; Thyssen and Hummel, 2013; Fifarek et al.,

2017; L

ucio et al., 2017a; Dick et al., 2017; Bitsch,

2001; Teige et al., 2016; L

ucio et al., 2017b; Mavin

et al., 2009; R. S. Fuchs, 1996; Rolland and Proix,

1992; Macias and Pulman, 1995) and 15 requirement

representation approaches listed in Table.3.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

112

Table 2: A list of identiﬁed requirement properties from existing approaches.

Property Description

Trigger

is an event that initiates action(s) (e.g., ”when the system halts” in Figure 3). This component type is ubiquitous

throughout the requirements of most critical systems.

Condition

is a constraint that should be satisﬁed to allow a speciﬁc system action(s) to happen (e.g., ”if X is ON” in Figure

3). In contrast to triggers, the satisfaction of the condition should be checked explicitly by the system. The

system is not concerned with ”when the constraint is satisﬁed” but with ”is the constraint satisﬁed or not at the

checking time” to execute the action (e.g., in the previous example ”X” might remain ”ON” for a while and

have no effect on the system until checked for.

Component

Action

is a task that should be accomplished by the system in response to triggers and/or constrained by conditions

(e.g., ”M should be set to TRUE” in Figure 3). In case that, a primitive requirement consists of an action

component only, it would be marked as a factual rule expressing factual information about the system (e.g.,

The duration of a ﬂashing cycle is 1 second (Houdek, 2013)).

Req-scope

determines the context under which (i) ”condition(s) and trigger(s)” can be valid – called a pre-conditional

scope as it is linked to the condition or trigger; and (ii) ”action(s)” can occur – called an action scope, as it

applies only on the action. The scope may deﬁne the starting boundary or the ending one (e.g., ”after sailing

termination”, ”before <B sig> is True” in Figure 3).

Figure 3 presents the main variations for starting/ending a context (e.g., None, after operational con-

straint is true, until operational constraint becomes true or before operational constraint becomes true).

Other alternatives can be expressed by the main variation. For example, ”while R is true” can be

expressed by after and until as ”after R is true” and ”until not R”. It is worth noting that, ”Be-

fore” and ”Until” deﬁne the same end of the valid period which is ”R is true”. ”Until” mandates

the precondition(s)/action(s) to hold till ”R is true”, but ”Before” does not care about their status.

!!"#$%&'&#$(! )$%*#+!,+&--.+(!

/0'&#$(!

1')+'234

• 5#$.!

• /6'.+!

+.)%&$-!7!

1')+'234!

• 5#$.!

• /6'.+!

+.)%&$-!7!

8$%234!

• 5#$.!

• 9.6#+.!

+.)%&$-!7!

• :$'&;!

+.)%&$-!7!

8$%234!

• 5#$.!

• 9.6#+.!

+.)%&$-!7!

• :$'&;!

+.)%&$-!7!

<);&%!4.+&#%!6#+!6&+&$-!

<);&%!4.+&#%!6#+!0=.0>&$-!

?+.20#$%&'&#$);!(0#4.!

/0'&#$!(0#4.!

Valid-time

represent the valid time period of the given component (e.g., in ”the vehicle warns the driver by acoustical

signals < E > for 1 second” the action is hold for 1 second length of time (Houdek, 2013)). Valid-time can be

a part of any component.

Sub-Component

Pre-elapsed-time

is the consumed time length from an offset point –before an action to occur or a condition to be checked (e.g.,

”After less than 2 seconds” in Figure 3). This type is only eligible to action and condition components.

In-between-time

express the length of time between two consecutive events to occur in the repetition case (e.g., ”every 1 seconds”

in Figure 3). Such sub-component type is eligible to action and trigger components as indicated in Figure 2.

Hidden constraint

allows an explicit constraint to be deﬁned on a speciﬁc operand within a component. For example, in ”if the

camera recognizes the lights of an advancing vehicle, the high beam headlight that is activated is reduced

to low beam headlight within 5 second”(Houdek, 2013). The that is activated is a constraint deﬁned on the

operand the high beam headlight).

We identiﬁed 19 distinct properties that we grouped

into 8 abstract properties (4 components and 4 sub-

components). These are listed with their description

in Table.2. Figure 1 shows a manually crafted ex-

ample requirement that reﬂects most of these com-

ponents and sub-components used through the prop-

erties description for a better understanding.

REQ: After sailing termination, if X is ON for 1 second or (Y is ON and Z is ON), M

shall transition to TRUE after less than 2 seconds. When the acoustical signals <E>

turns to TRUE every 1 seconds, M shall transition to FALSE before <B_sig> is TRUE.

Figure 1: Crafted multi-sentence requirement ”REQ”.

We then analysed 15 of the existing approaches (out-

lined in the related work section) against these 19 re-

quirement properties as presented in Table.3. The ap-

proaches (rows) are encoded A1 to A15, and require-

ment properties are encoded as columns. An approach

can be represented in more than one row. This reﬂects

that some approaches might support multiple proper-

ties, but these properties cannot be used in the same

requirement – the template or pattern does not support

having certain properties in one requirement. The cell

value equals ”1” if the property is supported in this

template.

This table does not reﬂect the limita-

tions/restrictions that these approaches apply on

a given property formatting or order - i.e. condition

must come before action, or scope comes before

condition. Our analysis of this table illustrates that:

(1) no approach covers all requirement properties

possibly because this would make it too complex

to use; (2) almost all approaches support action

components as a core element; (3) approaches: A1

and A11 are the most expressive approaches as

they cover majority of the properties; and (4) the

valid-time property for the StartUp and the EndUP

RCM: Requirement Capturing Model for Automated Requirements Formalisation

113

Table 3: Exisiting approaches proposed properties and Supported formats.

Properties Codes → A:action / C:condtion / T:trigger / hidden:Hidden-constraint / SP:pre-cond Startup-phase / EP:pre-cond

Endup-Phase / SA:action Startup-phase / EA:action Endup-phase / vt:valid-time / pt:pre-elapsed-time / rt:in-between-time

Approach Requirement properties

Action Condition Trigger Req-Scope

Code Source A A-

A-

C C-

C-

T T-

T-

SP SP-

EP EP-

SA SA-

EA EA-

Hidden

A1 BTC (Justice, 2013; Teige

et al., 2016)

1 1 1 1 1 1 1 1 1 1

EARS (Mavin et al.,

2009)

1 1 1

A3 EARS-CTRL (L

ucio et al., 2017b) 1 1 1 1

A4 ECA (Van Kleek et al., 2010) 1 1 1 1 1 1 1 1 1

boilerplates (Rupp, 2009)

1 1

Safety templates (Fu

et al., 2017)

1 1 1 1 1

1 1 1 1 1 1

1 1 1 1 1

A7 Req Lang (Marko et al., 2015) 1 1 1 1 1 1

CFG (Scott et al.,

2004; Sl

adekov

a, 2007)

1 1 1

A9 ACE (R. S. Fuchs, 1996) 1 1 1

A10 PENG (Schwitter, 2002) 1 1 1 1 1 1 1 1

A11 Structured English (Yan et al., 2015) 1 1 1 1 1 1 1 1

A12 TBNLS (Esser and Struss, 2007) 1 1 1 1 1 1 1

A13

Real-time (Konrad and

Cheng, 2005)

1 1 1 1

1 1 1 1 1

A14 Dawyer (Dwyer et al., 1999) 1 1 1 1 1

A15 Pattern based(Berger et al., 2019) 1 1 1 1 1

phases of the pre-conditional scope is not supported

by any of these approaches although its appearance

in the analysed requirements.

4.2 RCM Domain Model

The RCM is designed to capture the requirements

properties listed above while relaxing the ordering

and formatting restrictions presented by the existing

techniques. In RCM, a system is represented as a set

of requirements R. Each requirement R

represented

by one RCM and may have one or more primitive

requirements PR where {R

= < PR

> and n>0}.

Each PR

represents only one requirement sentence,

and may include condition(s), trigger(s), action(s) and

requirement scope(s). The detailed meta-model of the

RCM to one requirement R

is presented in Figure 2.

The ﬁgure shows that a primitive requirement is

composed of four requirement component types: con-

dition, trigger, action and requirement scope. Except

for action(s), the existence of each of these compo-

nents is optional in a primitive requirement. A re-

quirement component has a component core-segment

that expresses the main portion of the component, and

optionally could also have a valid-time: the compo-

nent’s valid time-length. The pre-elapsed-time sub-

component can only appear with a condition or action

component. An in-between-time sub-component can

only appear with Trigger or Action components ac-

cording to the reviewed scenarios (e.g., requirements

and representation formats). A hidden-constraint is

an optional sub-component to an operand. To store

this information without loss, RCM stores the hidden

constraint inside the relevant operand object as indi-

cated in Figure 2. This structure is intrinsic to allow

the nested hidden constraints. For example, ”the entry

of A1 whose index is larger than the ﬁrst value in A2

that is larger than S1 shall be set to 0”.

All ﬁve sub-components are instances of either

Predicate or Time structure. The Predicate structure

consists of the operands, the operator and negation

ﬂag/property (e.g., in ”if X exceeds 1” the ”X” and

”1” are the operands and ”exceeds” is the operator

in the semi-formal semantic and ”>” is the operator

in the formal semantic). The Time structure stores

the unit, value and quantifying relation (e.g., ”for

less than 2 seconds”, ”2” and ”seconds” are the unit

and value respectively, ”less than” is the semi-formal

quantifying relation whose formal semantic is ”<”).

Since the Predicate and Time structures are the in-

frastructure of the entire properties, they are designed

to encapsulate the semi-formal and formal semantic

allowing mappability to multiple TL. The details of

formal semantic are described in section.4.3.2.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

114

Req

Ptim-Req

Condition

Action

Trigger

Pre-Conditional

Scope

Hidden Constraint

Valid-time

In-between-time

Argument

component

Req-scope

Pre-elapsed-time

Core-segment

Time

• Preposition

• Quantifying relation

• Value

• Unit

• Operator

• value

Formal Semantic

Process

• Process-Name

• Operands List

Relational

• LHS

• RHS

• Technical Operator

plain

• Operand

• Technical

Operator

RHS

Aggregated

• Operands List

• Aggregation Function

• Operands List

• Relation

• Formal Semantic

Predicate

1..*

0..*

1..*

0..*

0..1

1..*

Instance of Relation

Inheritance Relation

Aggregation Relation

Component

Sub-component

Semiformal Semantic

Formal Semantic

Action Scope

Figure 2: RCM meta-model (simpliﬁed).

Components with the same type can be stored as a

tree –the most suitable to keep nested relation appro-

priately, where leafs are the components, and inner

nodes are coordinating relationships (e.g., check the

conditions components of PR[1] in Figure 3).

Figure 3, shows the RCM representation of the

REQ example. It has two primitive requirements:

PR[1] and PR[2]. Components of each primitive re-

quirement are presented in separate blocks in the ﬁg-

ure. In each block, sub-components are separated by

horizontal line. Figure 3 highlights the encapsulation

of semi-formal semantic (in black) and formal seman-

tic (in red). Components with the same type (e.g.,

conditions in PR[1]) are represented by tree structure.

The ﬁgure also provides the the corresponding MTL

representation, see subSection.4.3.3.

4.3 RCM Transformation

In this section, we illustrate transformation into tem-

poral logic (TL)- as an example of formal notations.

We ﬁrst illustrate: (1) the mapping between the RCM

to TL, and (2) the formalization of the RCM infras-

tructure (i.e., Predicate and Time structures). Then,

we provide the transformation process.

4.3.1 RCM and Temporal Logic

In order to formally model a given requirement rep-

resented by RCM in temporal logic (TL), we have

to deﬁne a set of transformation rules. A TL for-

mula F

is built from a ﬁnite set of proposition vari-

ables AP by making use of boolean connectives (e.g.,

”AND”, ”OR”) and the temporal modalities (e.g., U

(until)) (Haider, 2015; Brunello et al., 2019). Within

such formula, each proposition letter is expressed by

a true/false statement and may be attached with time

notation in some versions of temporal logic (e.g.,

MTL). Consider the following sentence:”After the

button is pressed, the light will turn red until the ele-

vator arrives at the ﬂoor and the doors open(Brunello

et al., 2019)”. Such sentence can be captured by the

following TL formula:

p =⇒ (qU(s ∧v))

where p, q, s, and v are proposition variables cor-

responding to ”the button being pressed”, ”the light

turning red”, ”the elevator arriving”, and ”the doors

opening”, respectively.

We use the following to build the mapping be-

tween RCM and TL:

1. Propositions and Time Notations: Given that,

RCM components and sub-components are ex-

pressed as predicates or time structures as indi-

cated in Figure 2. These structures are eventually

mapped to proposition and time notations in the

corresponding temporal logic formula (e.g., the

action component ”M shall Transition to TRUE

after less than 2 seconds” mapped to ”F

t<2

(S)”,

where S and ”t<2” represent the predicate in bold

and time phrase underlined).

2. Coordinating Relations: The booleans connect-

ing propositions can be obtained from coordi-

nating relations connecting multiple components

with the same types. Such relations are repre-

sented by tree for each component type as dis-

cussed before (e.g., the condition components ”X

is ON for 1 second or (Y is ON and Z is ON)”

mapped to ”(G

t=2

(C1) ∨(C2 ∧C3))”.

3. Temporal Modality: The temporal modalities

can be identiﬁed based on the component type

(e.g., the type of the component ”After sailing

termination” is ”pre-conditional-scope startup-

phase” mapped to ”=⇒”

RCM: Requirement Capturing Model for Automated Requirements Formalisation

115

REQ

After sailing termination, if X is ON for 1 second or (Y is ON and Z is ON), M shall transition to TRUE after less than 2 sec

onds.

When

the acoustical signals <E> turns to TRUE every 1 seconds, M shall transition to FALSE before <B_sig> is TRUE.

RCM of REQ

PR[1]

Req

-Scope

Pre-conditional Scope

ØScopeType = StartUpPhase

ØTimekeyword = after

ØCompText = “After sailing termination ”

ØPredicate

Ø Relation = equals

Ø Op1

ü Text = sailing termination

Ø Op2

ü Text = TRUE

Ø neg_flag = false

Ø Formal Semantic

ü LHS

sailing termination

ü RHS

TRUE

ü Operator

“=“

Action

CompText = “M shall transition to

TRUE after less than 2 seconds

”

Predicate

Ø Relation = shall transition to

Ø Op1

ü Text = M

Ø Op2

ü Text = TRUE

Ø neg_flag = false

Ø Formal Semantic

ü LHS

ü RHS

TRUE

ü Operator

“=“

-----------------------------------------------------------------------------

Pre-Elapsed-time

Ø Preposition = “after”

Ø Value= 2

Ø Unit= second

Ø QR = less than

Ø Formal Semantic

ü Operator

“<“

ü Value = 2

PR[2]

Req

-Scope

Action Scope

ØScopeType = EndUpPhase

ØTimekeyword = Before

ØCompText = “before <B_sig

> is

TRUE”

ØPredicate

Ø Relation = is

Ø Op1

ü Text = <B_sig>

Ø Op2

ü Text = TRUE

Ø neg_flag = false

Ø Formal Semantic

ü LHS

<B_sig>

ü RHS

TRUE

ü Operator

“=“

Action

CompText = “M shall

transition to FALSE

”

Predicate

Ø Relation = shall transition

Ø Op1

ü Text = M

Ø Op2

ü Text = FALSE

Ø neg_flag = false

Ø Formal Semantic

ü LHS

ü RHS

FALSE

ü Operator

“=“

Conditions

Trigger

CompText

= “When the acoustical signals <E> turns to TRUE

every 1 seconds

”

Predicate

Ø Relation = turns to

Ø Op1

ü Text = the acoustical signals <E>

Ø Op2

ü Text = TRUE

Ø neg_flag = false

Ø Formal Semantic

ü LHS

<E>

ü RHS

TRUE

ü Operator

“=“

---------------------------------------------------------------------------------------------------------------------

In-Between-time

Ø Preposition = “every”

Ø Value= 1

Ø Unit= second

Ø QR = equal

Ø Formal Semantic

ü Operator

“=“

ü Value = 1

• G(P ⇒ F(G

t=2

(C1)

∨

⌃

) ⇒ F

t<2

(S))

• G(sailing_termination=TRUE ⇒ F(G

t=2

(X=ON)

∨

(Y=ON

⌃

Z=ON)

⇒ F

t<2

(M=TRUE))

• G(Ft=1(T)) ⇒(F(A) ⇒(F(Q∨A)UA))

• G(Ft=1(<E>=TRUE)) ⇒(F(<B_sig>=TRUE) ⇒

(F(M=FALSE

∨

<B_sig>=TRUE) U <B_sig>=TRUE))

Condition_3

CompText = “If Z is ON”

v Predicate

Ø Relation = is

Ø Op1

ü Text = Z

Ø Op2

ü Text = ON

Ø neg_flag = false

ØFormal Semantic

ü LHS

ü RHS

ü Operator

“=“

And

Condition_2

CompText = “If Y is ON”

v Predicate

ØRelation = is

ØOp1

ü Text = Y

ØOp2

ü Text = ON

Øneg_flag = false

ØFormal Semantic

ü LHS

ü RHS

ü Operator

“=“

Condition_1

CompText = “If X is ON for

1 second ”

v Predicate

ØRelation = is

ØOp1

ü Text = X

ØOp2

ü Text = ON

Øneg_flag = false

ØFormal semantic

ü LHS

ü RHS

ü Operator

“=“

--------------------------------

v Valid-time

ØValue= 2

ØUnit= second

ØQR = equal

ØFormal Semantic

ü Operator

“=“

ü Vlaue

P S

A Q

Figure 3: An example presents multi-sentence requirement ”REQ” and the corresponding RCM representation.

Table 4: RCM mapping to MTL & CTL.

RCM TL Mapping

Properties (component/ subcomponents) Versions Applicable on MTL CTL

Action 1 A: do something A A

Pre-

condition

Condition 2 If S

Action (P in

mapping)

G(S =⇒ P) AG(S =⇒ P)

Temporal Modality

Trigger 3 When S G(S =⇒ P) AG(S =⇒ P)

Conditions and

triggers

4 When S, IF Q G((S ∧ Q) =⇒ P) AG((S ∧ Q) =⇒ P)

Req-Scope:

(Preconditional-

Scope /

Action-Scope)

StartUP 5 After S

Precondition/

action (P in

mapping)

G(S =⇒ F(P))

AG(S =⇒

AG(AF(P)))

EndUP

6 Before S

F(S) =⇒ (F(P ∨

S)US)

A[((AF(P ∨ S)) ∨

AG(¬S))WS]

7 Until S F(P)U S AF(P)U S

StartUP and

EndUp

-After Q & Before S

-Between Q and S

G((Q ∧ ¬S ∧ F (S))

=⇒ F(P ∨ S)US))

AG((Q ∧ ¬S) =⇒

A[((AF(P ∨ S) ∨

AG(¬S))WS])

-After Q & Until S

- While Z {Q=Z&

S=¬ Z}

G((Q ∧ ¬S) =⇒

F(PUS))

AG((Q ∧ ¬S) =⇒

A[(AF(P ∨ S)WS])

Pre-elapsed-time

10 After c time Condition/

Action (P in

mapping)

t=c

(P)

Time notation

11 after at-most c time F

t≤c

(P)

12 after at-least c time F

t≥c

(P)

13 after less-than c time F

t<c

(P)

14 after greater-than c F

t>c

(P)

Validation-time

15 for c time Condition/

Trigger/ Action

(P in mapping)

t=c

(P)

16 for at-most c time G

t≤c

(P)

17 for at-least c time G

t≥c

(P)

18 for less-than c time G

t<c

(P)

19 for greater-than c G

t>c

(P)

In-between-time

20 every c time

Action/ Trigger

(P in mapping)

G(F

t=c

(P))

21 every at-most c time G(F

t≤c

(P))

22 every at-least c time G(F

t≥c

(P))

every less-than c

time

G(F

t<c

(P))

24 every greater-than c G(F

t>c

(P))

Hidden-Constraint 25 Whose S P is Any component AG(∃S =⇒ P) branching

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

116

To demonstrate the robustness of the RCM and ca-

pability to transform to different formal notations, we

provide here a mapping into two examples of tempo-

ral logic, MTL (Alur and Henzinger, 1993) and CTL

(Clarke and Emerson, 2008), as shown in Table 4 as

a proof of multiple map-ability. We chose these no-

tations as they are widely used in model checking

as indicated in (Konur, 2013) and (Haider, 2015) re-

spectively. We base our temporal-modality and time-

notation mapping on the mapping done in (Konrad

and Cheng, 2005).

The ﬁrst column in Table.4 shows the RCM prop-

erties (components and sub-components) employed in

formal roles, each attached with alternatives if any

(e.g., The pre-conditions may be conditions, triggers,

or both of them based on the given requirement). Pos-

sible structures corresponding to each property ver-

sion are listed in the third column (i.e., the used key-

words (e.g., when) are just examples, any replaceable

keyword could be used). The fourth column indi-

cates which components can be linked to each prop-

erty type. The MTL and CTL representations of each

property are presented in the ﬁfth and sixth columns

respectively, where these notations are grouped based

on their formal types in the last column.

4.3.2 RCM and Formal Semantics

Temporal logic has multiple versions exhibiting slight

differences. In order to support the transformation

to multiple versions with minimal adjustment in the

transformation technique, RCM encapsulates formal

semantics with semi-formal semantics. Design-wise,

RCM augments the formal semantic in the basic units,

predicate and time structures in Figure 2, that are ma-

pable to temporal logic, as indicated in the previous

subsubsection. The formal semantic of a predicate

covers three formats:

• Process Format: is suitable to predicates ex-

press functions or process (e.g., ”the monitor

sends a request REQ Sig to the station” −→

”send(the monitor, the station,REQ Sig)”).

• Relational Format with Plain RHS: the type is

suitable for assignment predicates (e.g., ”set X

to True” −→”X = True”), comparison predicates

(e.g., ”If X exceeds Y” −→”X > Y”) and chang-

ing state predicates (e.g., ”the window shall be

moving up” −→”the window = moving-UP”).

• Relational Format with Aggregated RHS: this

format is similar to the previous one but the RHS

is expressed with aggregating function (e.g., ”If

the fuel level is less than the min value of Thr1 and

Thr2” −→”the fuel level < ”min(Thr1, Thr2)”).

Similarly, the formal semantic is added to time

structure in which the technical time operator (e.g.,

{>, <, =, 6, >}) is identiﬁed (e.g., ”for at least 2 sec-

onds” −→ ”t > 2”).

4.3.3 RCM Transformation Algorithm

To accomplish the automatic transformation from

RCM-to-MTL, we use the mapping rules provided

in Table 4 on the obtained formal semantics of the

given primitive requirements. Algo.1 shows the auto-

matic transformation pseudo-code annotated in Fig-

ure 4 with each step output for PR[1] in the REQ Fig-

ure 3.

Algorithm 1: RCM-to-MTL Transformation.

1: Input:

R: RCM-to-MTL indexed Mapping Rules

PrimReq: primitive requirement of interest

2: procedure

3: Step 1: Prepare each component

4: for all comp ∈ PrimReq do

Comp.Formal← Comp.CoreSegment

.getFormalSemantic()

5: for all timeInfo ∈ comp do

Comp.Formal← comp.

AttachTimeSemantic(timeInfo, R{9:25})

6: end for

7: end for

8: Step 2: Aggregate components of the same type

9: for all compTree ∈ CompTypeTree do

aggVal ← aggRel(compTree)

10: procedure AGGREL(Tree compTree)

11: if compTree is leaf then

return compTree.data.Formal;

12: else

return ”(” + aggRel(compTree.Left)

+ compTree.data.LR() +

aggRel(CompTree.Right) ”)”

13: end if

14: end procedure

map.put(compTree.Type, aggVal)

15: end for

16: Step 3: Prepare Preconditions

preConds ← preparePrecond(map[Triggers],

map[Conditions], R{2:4})

17: Step 4: Prepare LHS and RHS

lHS ← prepareSide(preConds, R{5:9})

rHS ← prepareSide(Actions, R{5:9})

18: Step 5: Generate Formulat

19: if lHS 6= φ then

return lHS + ”−→” + rHS

20: else

return rHS

21: end if

22: end procedure

First, we get the formal semantics of each component

according to Subsection.4.3.2. Then, we compute the

RCM: Requirement Capturing Model for Automated Requirements Formalisation

117

Step1:

ü sailing_termination=TRUE

ü G

t=2

(X=ON)

ü Y=ON

ü Z=ON

ü F

t<2

(M=TRUE)

Step2:

ü sailing_termination=TRUE

ü G

t=2

(X=ON) ∨ (Y=ON

⌃

Z=ON)

ü F

t<2

(M=TRUE)

Step3:

ü preConds: G

t=2

(X=ON) ∨

(Y=ON

⌃

Z=ON)

Step4:

ü lHS: G( sailing_termination=TRUE

⇒ F(G

t=2

(X=ON) ∨ (Y=ON

⌃

Z=ON))

ü rHs: F

t<2

(M=TRUE)

Step5:

ü mTLFormula: G(sailing_termination=TRUE ⇒ F(G

t=2

(X=ON) ∨ (Y=ON

⌃

Z=ON) ⇒ F

t<2

(M=TRUE))

Figure 4: Step by Step generation of PR[1] from Figure 3.

formal semantics of the entire tree (i.e., leaf nodes

represent components and inner nodes represent log-

ical relations as discussed before) of each component

type through the recursive function aggRel. After

that, we construct the main parts of the formula (i.e.,

preCondtions, LHS and RHS) in Step3 and 4 with

the help of RCM-to-MTL mapping rules in Table 4.

Finally, we generate the entire formula based on the

bound sides either ”LHS −→ RHS” or ”RHS” as in

Step5.

5 EVALUATION

5.1 Dataset Description

We evaluate the coverage of our proposed RCM on

162 requirement sentences. These requirements were

extracted from existing case studies in the litera-

ture and grouped into three sub datasets as follows:

(1) expressiveness dataset (81 requirements): these

are requirements collected from papers that intro-

duced different requirement templates and formats

in different domains and considering different writ-

ing styles in (Justice, 2013) (Jeannet and Gaucher,

2016)(Thyssen and Hummel, 2013), (Fifarek et al.,

2017), (L

ucio et al., 2017a), (Dick et al., 2017),

(Bitsch, 2001), (Teige et al., 2016), (L

ucio et al.,

2017b), (Mavin et al., 2009), (R. S. Fuchs, 1996), (2)

formalisation dataset (28 requirements): these are re-

quirements extracted from papers that introduced re-

quirement formalisation techniques including (Ghosh

et al., 2016; Yan et al., 2015) with total of 28 re-

quirements and (3) online sources (43 requirements):

these are requirements extracted from an online avail-

able critical-system requirements including (Houdek,

2013). These requirements are available online in

Figure 5 presents the percentages of each of

the 19 requirement properties (components/sub-

components) within the entire dataset. The ﬁgure

shows that time-based and hidden constraints existed

Dataset:https://github.com/ABC-7/RCM-Model/tree/

master/dataSet

in a few requirements compared to the key require-

ment components such as action, trigger, and condi-

tion. Overall, the distribution of the properties is bi-

ased towards the popular properties that exist in most

approaches.

162

128

256

A-vt

A-rt

A-pt

C-vt

C-pt

T-vt

T-rt

SP- vt

EP-vt

SA-vt

EA- vt

hidden

frequency

properties

Properties Frequency wihtin the Entire

Requirements

A: action C: condtion T: trigger hidden: Hidden-constraint

SP: pre-cond Startup-phase EP: pre-cond Endup-Phase

SA: action Startup-phase EA: action Endup-phase

vt: valid-time pt: pre-elapsed-time rt: in-between-time

Figure 5: Properties Frequency wihtin the Entire Require-

ments.

Figure 6 shows the relative complexity of the 162 re-

quirements. We grouped the requirements based on

the count of their existing properties (i.e., number of

properties per requirement increases ↑, its complexity

increases ↑). The following examples show two re-

quirements with one and six properties respectively,

where each property is separately underlined: (1) ”the

monitor mode shall be initialized to INIT”, and (2)

”after X becomes TRUE for 2 seconds, when Z turns

to 1 for 1 second, Y shall be set to TRUE every 2 sec-

onds”. In Figure 6, each group represents the count

of properties regardless of the type of the property -

i.e., R1: requirement with condition and action, and

R2: requirement with trigger and action, both have 2

properties). For each group, we calculated the per-

centage of requirements. Figure 6 presents the prop-

erties count used for each requirements group on the

x-axis and the corresponding requirements percent-

age on the y-axis. This shows that a large portion of

the entire requirements sentences 9%, 49% and 22%,

only consist of one, two and three properties respec-

tively. On the other hand, 20% of the requirements

sentences consist of more than three properties.

49%

22%

12% 7% 1%

10%

20%

30%

40%

50%

1 2 3 4 5 6

FREQUENCY RATE

PROPERTIES COUNT/ REQUIREMENT

Figure 6: Frequency rate of Requirements per Properties

Count.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

118

5.2 Evaluation Experiments

Experiment1. RCM Expressiveness: We evaluated

our proposed RCM reference model’s ability to cap-

ture and represent the requirements in our test dataset

compared to 15 exiting approaches in Table.3. To do

this, we manually labelled all the requirements in the

dataset against the 19 requirement properties we iden-

tiﬁed in section 4. After that, we wrote a script to

check each requirement (identiﬁed properties) against

all existing approaches to assess if the approach pro-

vides a boilerplate or a template that supports repre-

senting the requirement or not. The results are avail-

able online

. Figure 7 summarises the results of our

analysis as percentage of the test requirements that

each approach supports.

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

A1 A2 A3 A4 A5 A6 A7 A8 A9 A1 0 A1 1 A12 A13 A14 A1 5 A1 6

Percentage of captured requirements

Approache

Percentage of Captured Requirements per Approach

Figure 7: Percentage of Captured Requirements per Ap-

proach (RCM represented by A16 and the other represent

by codes proposed in subsection4.2).

This shows that none of the existing 15 approaches

is able to represent the entire dataset of requirements.

This is mainly for two reasons: (1) missing proper-

ties in the used templates e.g., A1 does not support

StartUp-phase Pre-conditional scope (SP), or (2) re-

strictions on the included properties in a requirement

format e.g., A2:EARS does not support the existence

of the trigger (core-segment) and a ReqScope (core-

segments) using the same format. In addition, ≈4% of

the test requirements were not covered by any of these

approaches combined. An example is ”if the maxi-

mum deceleration is [insufﬁcient] before a collision

with the vehicle ahead, the vehicle warns the driver

by acoustical signals for 1 seconds every 2 seconds”,

where the existing properties are: condition (core-

segment), StatrtUp-phase Pre-conditional scope (SP

core-segment), action (core-segment), action valid-

time (Vt) , and action in-between-time (Rt). These

Approaches representations, and evaluation:

https://github.com/ABC-7/RCM-Model/blob/master/

Approaches-Evaluation.xlsx

properties do not exist together in the same represen-

tation of any of the 15 approaches, see Table 3.

In contrast, our proposed RCM requirements

model can represent all of the 162 requirements sen-

tences. This is because it covers all properties that ex-

ist in the other approaches and puts no restriction on

the included properties in one requirement (i.e., any

property could exist in the requirement format).

Existing approaches require extension in two

cases: (1) considering new requirement properties,

and (2) considering new formats i.e, deﬁning a set

of properties that can exist together in one format

regulated by customized grammatical rules. In con-

trast, since RCM covers all properties of the other ap-

proaches and more and puts no constraints on prop-

erties used in requirement, it is powerful enough to

represent all requirements that can be represented by

all the other approaches. It can also be used in other

scenarios not currently supported by any of the 15 ap-

proaches, due to the fact that it does not enforce any

restriction on the input requirement formats.

RCM encounters two main limitations: (1) it is

designed for behavioral requirements of critical sys-

tems, and (2) it requires complex NL-extraction tech-

niques i.e., the current NL-extraction processes prim-

itive requirements expressed in one sentence.

Experiment2: RCM to Formal Notations: We

applied our RCM-to-MTL and RCM-to-CTL trans-

formation rules to the dataset of the 162 requirements.

In this experiment, we used our NLP-approach to ex-

tract RCM from the 162 requirements(out of scope

of this paper). We then manually reviewed all the

extracted RCM models, ﬁxed all the broken RCM

extractions manually. Once we had the full list of

162 RCM models, we applied the automatic RCM-to-

Formal transformation as outlined in Sec.4.3.3. The

full list of RCMs representation and the correspond-

ing automatically generated MTL and CTL formulas

are available online

We successfully transformed 156 out of the 162

requirement RCM models into MTL notations. The

other 6 requirements were partially correct. These 6

requirements turned out to involve hidden constraints

expressed with ∃ and ∀ properties with a branching

structure that is not supported by MTL, since it is

linear. For example, the requirement ”the cognitive

threshold of a human observer shall be set to a devi-

ation that is less than 5. (Houdek, 2013)” was cor-

rectly represented in RCM, but the generated MTL is

partially correct ”G(the cognitive threshold of a hu-

man observer = the deviation)”. A correct generation

RCM-Representation and formal-notation:

https://github.com/ABC-7/RCM-Model/tree/master/

RCM-Auto-Transformation

RCM: Requirement Capturing Model for Automated Requirements Formalisation

119

could be ”AG((∃ deviation<5) =⇒ (the cognitive

threshold of a human observer = deviation))” in CTL.

Similarly, CTL could represent requirements with

hidden constraints correctly, but it provides partial

solutions for requirements with time notation e.g.,

validation-time, pre-elapsed-time and in-between-

time. In total, it is capable of representing 120 re-

quirements correctly and provides partial solutions

42 ones due the inclusion of time notation (e.g., the

requirement ”if air ok signal is low, auto control

mode is terminated within 3 sec” has a partially cor-

rect generated CTL formal ”AG([air ok signal = low]

=⇒ [auto control mode.crrStatus = terminated])”,

but a correct formula could be ”G([air ok signal =

low] =⇒ [Ft=3(auto control mode.crrStatus = ter-

minated)]” in MTL notation).

6 SUMMARY

We introduced a new requirements capturing model -

RCM - for representing safety-critical system require-

ments. RCM deﬁnes a wide range of key requirement

elements and attributes that may exist in an input re-

quirement. The model allows for standardising the

textual requirements extraction process and simpli-

ﬁes the transformation rules to convert requirements

to formal notations We compared the coverage of our

RCM model to 15 existing requirements modelling

approaches using 162 diverse requirements. Our re-

sults show that RCM can capture a wider range of

requirements compared to others due to the ﬂexibility

in including/excluding its properties conforming the

input requirement. In addition, we provided a suite

of RCM-to-MTL transformation rules and presented

the corresponding automatically generated MTL rep-

resentation of the evaluation dataset. For our fu-

ture work, we are developing an automated require-

ments extraction technique to populate RCM from

textual requirements in addition to requirements qual-

ity checking and visualising tool of the RCM model.

ACKNOWLEDGEMENTS

Grundy is supported by Australian Research Council

Laureate Fellowship FL190100035.

REFERENCES

Alur, R. and Henzinger, T. A. (1993). Real-time log-

ics: Complexity and expressiveness. Information and

Computation, 104(1):35–77.

Ambriola, V. and Gervasi, V. (1997). Processing natural

language requirements. In Automated Software Engi-

neering, 1997. Proceedings., 12th IEEE International

Conference, pages 36–45. IEEE.

Arora, C., Sabetzadeh, M., Briand, L., Zimmer, F., and

Gnaga, R. (2013). Rubric: A ﬂexible tool for auto-

mated checking of conformance to requirement boil-

erplates. In Proceedings of the 2013 9th Joint Meeting

on Foundations of Software Engineering, pages 599–

602. ACM.

Arora, C., Sabetzadeh, M., Briand, L. C., and Zimmer, F.

(2014). Requirement boilerplates: Transition from

manually-enforced to automatically-veriﬁable natural

language patterns. In Requirements Patterns (RePa),

2014 IEEE 4th International Workshop on, pages 1–8.

IEEE.

Berger, P., Nellen, J., Katoen, J.-P., Abraham, E., Waez, M.

T. B., and Rambow, T. (2019). Multiple analyses, re-

quirements once: simplifying testing & veriﬁcation in

automotive model-based development. arXiv preprint

arXiv:1906.07083.

Bitsch, F. (2001). Safety patterns—the key to formal speci-

ﬁcation of safety requirements. In International Con-

ference on Computer Safety, Reliability, and Security,

pages 176–189. Springer.

Brunello, A., Montanari, A., and Reynolds, M. (2019).

Synthesis of ltl formulas from natural language texts:

State of the art and research directions. In 26th Inter-

national Symposium on Temporal Representation and

Reasoning (TIME 2019). Schloss Dagstuhl-Leibniz-

Zentrum fuer Informatik.

Buzhinsky, I. (2019). Formalization of natural language re-

quirements into temporal logics: a survey. In 2019

IEEE 17th International Conference on Industrial In-

formatics (INDIN), volume 1, pages 400–406. IEEE.

Clarke, E. M. and Emerson, E. A. (2008). Design and syn-

thesis of synchronization skeletons using branching

time temporal logic. In 25 Years of Model Checking,

pages 196–215. Springer.

Dick, J., Hull, E., and Jackson, K. (2017). Requirements

engineering. Springer.

Dwyer, M. B., Avrunin, G. S., and Corbett, J. C. (1999).

Patterns in property speciﬁcations for ﬁnite-state veri-

ﬁcation. In Proceedings of the 21st international con-

ference on Software engineering, pages 411–420.

Erdem, E. and Yeniterzi, R. (2009). Transforming con-

trolled natural language biomedical queries into an-

swer set programs. In Proceedings of the BioNLP

2009 Workshop, pages 117–124.

Esser, M. and Struss, P. (2007). Obtaining models for

test generation from natural-language-like functional

speciﬁcations. In International workshop on princi-

ples of diagnosis, pages 75–82.

Fifarek, A. W., Wagner, L. G., Hoffman, J. A., Rodes, B. D.,

Aiello, M. A., and Davis, J. A. (2017). Spear v2. 0:

Formalized past ltl speciﬁcation and analysis of re-

quirements. In NASA Formal Methods Symposium,

pages 420–426. Springer.

Fu, R., Bao, X., and Zhao, T. (2017). Generic safety re-

quirements description templates for the embedded

software. In 2017 IEEE 9th International Conference

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

120

on Communication Software and Networks (ICCSN),

pages 1477–1481. IEEE.

Ghosh, S., Elenius, D., Li, W., Lincoln, P., Shankar, N.,

and Steiner, W. (2016). Arsenal: automatic require-

ments speciﬁcation extraction from natural language.

In NASA Formal Methods Symposium, pages 41–46.

Springer.

Haider, A. (2015). A survey of model checking tools using

ltl or ctl as temporal logic and generating counterex-

amples.

Holt, A. and Klein, E. (1999). A semantically-derived sub-

set of english for hardware veriﬁcation. In Proceed-

ings of the 37th annual meeting of the Association for

Computational Linguistics on Computational Linguis-

tics, pages 451–456. Association for Computational

Linguistics.

Houdek, F. (2013). System requirements speciﬁcation au-

tomotive system cluster(elc and acc). Technical Uni-

versity of Munich.

Jeannet, B. and Gaucher, F. (2016). Debugging embedded

systems requirements with stimulus: an automotive

case-study. In 8th European Congress on Embedded

Real Time Software and Systems (ERTS).

Justice, B. (2013). Natural language speciﬁcations for

safety-critical systems. Master’s thesis, Carl von Ossi-

etzky Universit

at.

Kittredge, R. I. (2003). Sublanguages and controlled lan-

guages. In The Oxford Handbook of Computational

Linguistics 2nd edition. Oxford University Press.

Konrad, S. and Cheng, B. H. (2005). Real-time speciﬁca-

tion patterns. In Proceedings of the 27th international

conference on Software engineering, pages 372–381.

ACM.

Konur, S. (2013). A survey on temporal logics for spec-

ifying and verifying real-time systems. Frontiers of

Computer Science, 7(3):370–403.

Kuhn, T. (2014). A survey and classiﬁcation of con-

trolled natural languages. Computational Linguistics,

40(1):121–170.

ucio, L., Rahman, S., bin Abid, S., and Mavin, A. (2017a).

Ears-ctrl: Generating controllers for dummies. In

MODELS (Satellite Events), pages 566–570.

ucio, L., Rahman, S., Cheng, C.-H., and Mavin, A.

(2017b). Just formal enough? automated analysis of

ears requirements. In NASA Formal Methods Sympo-

sium, pages 427–434. Springer.

Macias, B. and Pulman, S. G. (1995). A method for con-

trolling the production of speciﬁcations in natural lan-

guage. The Computer Journal, 38(4):310–318.

Marko, N., Leitner, A., Herbst, B., and Wallner, A. (2015).

Combining xtext and oslc for integrated model-based

requirements engineering. In 2015 41st Euromicro

Conference on Software Engineering and Advanced

Applications, pages 143–150. IEEE.

Mavin, A., Wilkinson, P., Harwood, A., and Novak,

M. (2009). Easy approach to requirements syntax

(ears). In Requirements Engineering Conference,

2009. RE’09. 17th IEEE International, pages 317–

322. IEEE.

Michael, J. B., Ong, V. L., and Rowe, N. C. (2001).

Natural-language processing support for developing

policy-governed software systems. In Technology

of Object-Oriented Languages and Systems, 2001.

TOOLS 39. 39th International Conference and Exhi-

bition on, pages 263–274. IEEE.

Nelken, R. and Francez, N. (1996). Automatic translation of

natural language system speciﬁcations into temporal

logic. In International Conference on Computer Aided

Veriﬁcation, pages 360–371. Springer.

Pease, A. and Li, J. (2010). Controlled english to logic

translation. In Theory and Applications of Ontology:

Computer Applications, pages 245–258. Springer.

Qiao, Y., Zhong, K., Wang, H., and Li, X. (2007). Devel-

oping event-condition-action rules in real-time active

database. In Proceedings of the 2007 ACM symposium

on Applied computing, pages 511–516.

R. S. Fuchs, N. E. (1996). Attempto controlled english

(ace). In CLAW 96, First International Workshop on

Controlled Language Applications.

Rolland, C. and Proix, C. (1992). A natural language ap-

proach for requirements engineering. In International

Conference on Advanced Information Systems Engi-

neering, pages 257–277. Springer.

Rupp, C. (2009). Requirements-Engineering und-

Management: professionelle, iterative Anforderungs-

analyse f

ur die Praxis. Hanser Verlag.

Schwitter, R. (2002). English as a formal speciﬁcation lan-

guage. In Proceedings. 13th International Workshop

on Database and Expert Systems Applications, pages

228–232. IEEE.

Scott, W., Cook, S. C., et al. (2004). A context-free re-

quirements grammar to facilitate automatic assess-

ment. PhD thesis, UniSA.

adekov

a, V. (2007). Methods used for requirements engi-

neering. Master’s thesis, Univerzity Komensk

eho.

Sturla, G. (2017). A two-phased approach for natural lan-

guage parsing into formal logic. PhD thesis, Mas-

sachusetts Institute of Technology.

Teige, T., Bienm

uller, T., and Holberg, H. J. (2016). Uni-

versal pattern: Formalization, testing, coverage, veri-

ﬁcation, and test case generation for safety-critical re-

quirements. pages 6–9. MBMV.

Thyssen, J. and Hummel, B. (2013). Behavioral speciﬁca-

tion of reactive systems using stream-based i/o tables.

Software & Systems Modeling, 12(2):265–283.

Van Kleek, M., Moore, B., Karger, D. R., Andr

e, P., and

Schraefel, M. (2010). Atomate it! end-user context-

sensitive automation using heterogeneous information

sources on the web. In Proceedings of the 19th inter-

national conference on World wide web, pages 951–

960.

Yan, R., Cheng, C.-H., and Chai, Y. (2015). Formal con-

sistency checking over speciﬁcations in natural lan-

guages. In 2015 Design, Automation & Test in Europe

Conference & Exhibition (DATE), pages 1677–1682.

IEEE.

RCM: Requirement Capturing Model for Automated Requirements Formalisation

121