requirement Req. 1: 11institutetext: ifak - Institut für Automation und
Kommunikation e.V., Magdeburg, Germany
11email<EMAIL_ADDRESS>11email<EMAIL_ADDRESS>11email:
<EMAIL_ADDRESS>
# Natural Language Processing for Requirements Formalization: How to Derive
New Approaches?

Viju Sudhi  Libin Kutty  Robin Gröpler

###### Abstract

It is a long-standing desire of industry and research to automate the software
development and testing process as much as possible. In this process,
requirements engineering (RE) plays a fundamental role for all other steps
that build on it. Model-based design and testing methods have been developed
to handle the growing complexity and variability of software systems. However,
major effort is still required to create specification models from a large set
of functional requirements provided in natural language. Numerous approaches
based on natural language processing (NLP) have been proposed in the
literature to generate requirements models using mainly syntactic properties.
Recent advances in NLP show that semantic quantities can also be identified
and used to provide better assistance in the requirements formalization
process. In this work, we present and discuss principal ideas and state-of-
the-art methodologies from the field of NLP in order to guide the readers on
how to create a set of rules and methods for the semi-automated formalization
of requirements according to their specific use case and needs. We discuss two
different approaches in detail and highlight the iterative development of rule
sets. The requirements models are represented in a human- and machine-readable
format in the form of pseudocode. The presented methods are demonstrated on
two industrial use cases from the automotive and railway domains. It shows
that using current pre-trained NLP models requires less effort to create a set
of rules and can be easily adapted to specific use cases and domains. In
addition, findings and shortcomings of this research area are highlighted and
an outlook on possible future developments is given. 00footnotetext: This is a
preprint of the following chapter: Viju Sudhi, Libin Kutty, and Robin Gröpler,
Natural Language Processing for Requirements Formalization: How to Derive New
Approaches?, published in Concurrency, Specification and Programming: Revised
Selected Papers from the 29th International Workshop on Concurrency,
Specification and Programming (CS&P’21), Berlin, Germany, edited by B.
Schlingloff et al., 2023, Springer reproduced with permission of Springer
Nature Switzerland AG. The final authenticated version is available online at:
https://doi.org/10.1007/978-3-031-26651-5˙1.
A detailed implementation and data can be found at: https://github.com/ifak-
prototypes/nlp˙reform.

###### Keywords:

Requirements Engineering (RE) Requirements Formalization Requirements Modeling
Requirements Analysis Natural Language Processing (NLP) Semantic Role
Labeling.

##  1 Introduction

Requirements engineering (RE) plays a fundamental role for the software
development and testing process. There are usually many people involved in
this process, such as the customer or sponsor, the users from different areas
of expertise, the development and testing team, and those responsible for the
system architecture. Therefore, requirements are intentionally written in a
textual form in order to be understandable for all stakeholders of the
software product to be developed. However, this also means that requirements
have an inherently informal character due to the ambiguity and diversity of
human language. This makes it difficult to automatically analyze the
requirements for further processing. There are many different processes that
build on them, such as requirements verification and test case generation (see
Fig. 1).

Figure 1: Requirements as the basis for the software development and testing
process.

In order to handle the growing complexity and variability of software systems,
model-based design and testing methods have been developed [3]. Especially for
safety-critical systems such as in the automotive, railway and aerospace
domains, extensive testing based on the requirements is necessary. However,
the manual creation of requirements models from natural language requirements
is time-consuming and error-prone, and also requires a lot of expert
knowledge. This is especially true in agile software development which
involves continuous improvements and many changes to requirements.

Numerous approaches based on natural language processing (NLP) have been
proposed in the literature to generate requirements models using mainly
syntactic properties [39, 20]. Recent advances in NLP show that semantic
quantities can also be identified and used to provide better assistance in the
formalization of unrestricted natural language requirements [28, 13]. However,
most studies propose concrete solutions that work well only for a very
specific environment.

The aim of this work is to focus on principal ideas and state-of-the-art
methodologies from the field of NLP to automatically generate requirements
models from natural language requirements. We iteratively derive a set of
rules based on NLP information in order to guide readers on how to create
their own set of rules and methods according to their specific use cases and
needs. In particular, we want to investigate the question: How to derive new
approaches for requirements formalization using natural language processing?
We highlight and discuss the necessary stages of an NLP-based pipeline towards
the generation of requirements models. We present and discuss two approaches
in detail: (i) a dependency and part-of-speech-based approach, and (ii) a
semantic-role-based approach. This significantly extends and enhances our
previous work [16]. The approaches are demonstrated on two industrial use
cases: a battery charging approval system from the automotive domain and a
propulsion control system in the railway domain. The requirements models are
represented in a human- and machine-readable format in a form of pseudocode
[17]. In summary, this work aims to provide more general and long-lasting
instructions on how to develop new approaches for NLP-based requirements
formalization.

In Section 2, we present our proposed NLP-based pipeline, introduce the use
cases, and present the two different approaches for NLP-based requirements
formalization. In Section 3, we review the state of the literature on the
various NLP methods for requirements formalization. In Section 4, we discuss
some general findings and shortcomings in this area of research and provide an
outlook on possible future developments. Finally, Section 5 concludes our
work.

##  2 Methodology

In this section, we propose an NLP-based pipeline for requirements
formalization. We first give a brief overview of the use cases and then
present and discuss the two different approaches in detail and demonstrate the
iterative development of rule sets.

The automatic generation of requirements models from functional requirements
written in unrestricted natural language is highly complex and needs to be
divided into several steps. Therefore, our pipeline consists of several
stages, as illustrated in Figure 2. The different stages of the pipeline are
described in more detail below.

#### Stage 1: Preprocessing

We start with preprocessing the requirements. According to our use cases, we
perform data preparation, where we clean up the raw text, and resolve
pronouns. This stage need not be limited to these steps and should be flexibly
adapted to the style and domain of the requirements at hand.

#### Stage 2: Decomposition

In order to extract individual actions, the preprocessed requirements are
decomposed into clauses. Industrial requirements tend to be complex in certain
cases with multiple sentences combined together to convey a particular system
behavior. We decompose each requirement sentence at certain conjunctions and
linking words (if, while, until, and, or, etc.), assuming that each clause
contains a single action. Multi-line and multi-paragraph requirements should
also be decomposed into clauses.

#### Stage 3: Entity detection

In this stage, we use the syntactic and semantic information of each clause to
identify the desired model entities, such as signals, components, and
parameters. We construct a rule-based mapping that is iteratively derived from
the considered requirements of our specific use cases. Further, we map
comparison words to operator symbols ($<$, $>$, $==$, etc.) using a
dictionary. These rules can be easily adapted to different use cases and
domains by following the same procedure as described below.

#### Stage 4: Model formation

In the final stage of the pipeline, we assemble the retrieved information to
form relations for each clause. These can either be assignments of the form
`signal(parameter*)` with optional parameter, or conditional statements of the
form `signal() operator parameter`. Then we combine them according to the
derived logical operators, and assign them to specific blocks (if, then, else,
etc.). This yields a requirements model for each requirement.

Figure 2: Proposed pipeline for requirements formalization.

The whole pipeline can be tailored according to the use case and the desired
output. For example, no components (actors) are explicitly mentioned in the
requirements we consider. Therefore, we have omitted this entity and assume
that this information is given. The decomposition and entity detection stages
are particularly based on information provided by NLP methods. We present two
approaches to handle these stages: (i) a dependency- and part-of-speech-based
approach (Section 2.2), which utilizes the grammatical constructs of the
requirement text, and (ii) a semantic-role-based approach (Section 2.3), which
makes use of the semantic roles given by a pre-trained model. Both approaches
work with unrestricted natural language and can be further refined and adapted
to different styles and domains according to the needs of the use case.

###  2.1 Use cases

We demonstrate the derivation of our approaches using functional requirements
from two different industrial use cases. The first use case is a battery
charging approval system provided by AKKA from the automotive domain. The use
case describes a system for charging approval of an electric vehicle in
interaction with a charging station. In total, AKKA has provided 14 separate
requirement statements. The requirements are used for a model-based software
development and implementation of the functionality in an electronic control
unit (ECU). More details about the industrial use case can be found in [15,
16].

The second industrial use case is a propulsion control system (PPC) provided
by Alstom from the railway domain. The PPC is part of a large, complex,
safety-critical system. It handles the control of the entire propulsion
system, including both control software as well as the electrical functions.
Alstom has provided 31 requirements which do not follow a prescribed format in
order not to focus on syntax when writing them. The system architecture and
software modules are modeled in Matlab Simulink using a model-based design
approach. More information about this use case is given in [35, 17].

Note that we show the requirements in a generalized form, as the data we use
is confidential. For demonstration purposes, we have also partially modified
the original requirements.

###  2.2 Dependency- and Part-of-Speech-Based Approach

One possible approach to arrive at formal requirements models is to
investigate the grammar of the natural language requirements. For instance,
one can make use of dependency tags, part-of-speech tags or combine both of
these syntactical information to arrive at the entities for the desired
requirements models.

Figure 3: Dependency and POS tags for an exemplary requirement phrase.

For example, consider the requirement phrase “if the temperature is larger
than t_batt_max”. When we parse the dependency and POS tags of this phrase
with the help of toolkits like
spaCy111https://spacy.io/222https://explosion.ai/demos/displacy, we arrive at
a directed graph as shown in Fig. 3. It illustrates that the root verb of the
phrase is “is” (from which the graph emerges) and shows how each word is
associated with this root verb. These associations or dependencies are
represented by different tags. For example, “temperature” is the nominal
subject (nsubj) of the root, “t_batt_max” is the prepositional object (pobj)
of the root, etc. Similarly, we can find the POS tag of each word in the
graph, e.g. “temperature” is a noun, “larger” is an adjective, etc. Some
dependency and POS tags are presented in Table 1. We suggest the reader to
gather an overview of the dependency and POS tags from the generic framework
presented as universal dependencies
333https://universaldependencies.org/u/dep/index.html444https://universaldependencies.org/u/pos/index.html.

Table 1: A few commonly used dependency and POS tags Dependency tag | Description
---|---
nsubj | Nominal subject - does the action
root | Root of the sentence - the action
dobj | Direct object - on which the action is done
mark | Marker - marks a clause as subordinate to another
conj | Conjunct - indicates a coordinating conjunction
Part-of-speech tag | Description
NOUN | Nouns denote a person, place, thing, animal or idea
ADJ | Adjectives modify nouns
ADV | Adverbs modify verbs
DET | Determiners indicate the reference of the nouns
SCONJ | Subordinating conjunction

With this background on dependencies and POS tags, we further discuss how we
tailor our pipeline with a rule base depending on the syntactic structure of
the requirement text. For better comprehensibility for readers, the
requirements are presented in the order of growing complexity.

The error state is ‘E_BROKEN’, if the temperature of the battery is larger
than t_batt_max.

As an entry point to the discussion, consider a simple requirement, Req. 2.2.
Here, the requirement has two primitive actions - one that talks about the
“error state” and another that talks about the condition when this “error
state” occurs. Similar to this requirement, individual industrial requirements
are often composed of multiple actions, making them inherently difficult to
process with information extraction toolkits. Hence, as shown in Fig. 2, we
propose a decomposition step to initially decompose a long complex requirement
into clauses which individually explain primitive actions.

#### Decomposition (conditions)

To decompose this requirement to individual clauses, we can use the
conditional keyword “if” as the boundary. This yields us the following
clauses:

  * The error state is ‘E_BROKEN’

  * if the temperature of the battery is larger than t_batt_max

#### Entity detection

For the first clause, we extract the subject of the clause as “error state”
and the object as “E_BROKEN”. The root verb in the clause is “is” which
decides how to form the relation. By mapping the subject (with an inflection
of the root verb) to the signal and the object as the parameter, we end up
with the relation `set_error_state(E_BROKEN)`. In the second clause, with
similar rules, we extract the subject of the clause as “temperature of the
battery” and the object as “t_batt_max”.

#### Operator detection

However, the root verb occurs in conjunction with a comparative term “larger”.
The appropriate operator for this word can be fetched with the help of a
hyperlinked thesaurus like Roget’s
Thesaurus555https://sites.astro.caltech.edu/~pls/roget/. This yields us the
symbol “$>$” indicating the quality “greatness”, see Table 2. The occurrence
of a comparative term differentiates how we form the relation for this clause
from the previous clause. The relation formed from this clause will be:
`temperature_of_battery() > t_batt_max`.

Table 2: Detection of comparison operators using Roget’s Thesaurus Quantity | Words | Operator
---|---|---
Superiority | exceed, pass, larger, greater, over, above, … | $>$
Greatness | excessive, high, extensive, big, enlarge, … | $>$
Inferiority | smaller, less, not pass, minor, be inferior, … | $<$
Smallness | below, decrease, limited, at most, no more than, … | $<$
Sameness | equal, match, reach, come to, amount to, … | $==$

The error state is ‘E_BROKEN’, if the temperature of the battery is larger
than t_batt_max and it is smaller than t_max.

Now consider a slightly different requirement with a different formulation in
the second clause as shown in Req. 2.2.

#### Decomposition (root conjunctions)

In this clause, the conjunction “and” occurs. Unless we decompose this
conjunction, the clause by itself does not address a single primitive action.
In this case, the conjunction “and” connects the two root verbs “is” (before
“larger”) and “is” (before “smaller”). Such root conjunctions can be
decomposed by considering the conjunction as the boundary. This yields us the
following clauses:

  * if the temperature of the battery is larger than t_batt_max

  * it is smaller than t_max

#### Pronoun resolution

The first clause is similar to the one presented in the previous requirement.
However, the second clause presents a new challenge. The pronoun “it” needs to
be resolved before proceeding to entity detection. We propose a simple pronoun
resolution step to find the third person pronouns (singular: it, plural: they)
by replacing each occurrence of a pronoun with the farthest subject. In this
clause, we replace “it” with “the temperature of the battery”. This yields the
clause “if the temperature of the battery is smaller than t_max”. This is
again similar to the discussed clauses and is handled with the same rules.

A further check on the grammatical number of the pronoun and its antecedent is
advised, if the requirement quality is in doubt. The pronouns without an
antecedent (called pleonastic pronouns) should not be resolved. We also assume
first person or second person pronouns hardly occur in industrial
requirements.

The error state is ‘E_BROKEN’, if the temperature of the battery is larger
than t_batt_max and t_max.

Now consider a requirement which has the following clause as given in Req.
2.2. Unlike the clause in the previous requirement, this clause has a
conjunction “and” between two noun phrases “t_batt_max” and “t_max”.

#### Decomposition (noun phrases)

This demands a slightly more complex noun phrase decomposition. Unlike the
other decomposition steps described above, this step further requires to
extract the subject phrase of the first noun phrase and prefix it to the
latter. This yields us the following clauses:

  * if the temperature of the battery is larger than t_batt_max

  * if the temperature of the battery is larger than t_max

These clauses are identical to the discussed clauses and hence, the entities
are extracted with the same rules.

The error state is ‘E_BROKEN’, if the temperature of the battery is between
t_batt_max and t_max.

Another clause is shown in Req. 2.2, with a connector “between” in the text.

#### Decomposition (connectors like “between”)

To decompose such clauses, we can replace between A and B with the construct
greater than A and less than B. This however, assumes the real values of A to
be less than B. Although the assumption is true in most cases, we advise to
further validate the decomposition, e.g. by integrating a user feedback loop.
With the above assumption, the decomposition of this clause results in the
following clauses:

  * if the temperature of the battery is greater than t_batt_max

  * if the temperature of the battery is less than t_max

The charging approval shall be given if the connection with the charging
station is active.

The charging approval shall not be given if the connection with the charging
station is inactive.

Requirements can also contain negations. Consider the pair of requirements
Req. 2.2 and Req. 2.2, which when decomposed yield the following clauses:

  * R5C1: The charging approval shall be given

  * R5C2: if the connection with the charging station is active

  * R6C1: The charging approval shall not be given

  * R6C2: if the connection with the charging station is inactive

#### Entity detection (negation handling)

The corresponding clauses of these requirements contradict each other, i.e.
R5C1 and R6C1 contradict each other as well as R5C2 and R6C2. In R5C1, there
is no explicit negation. Hence, we can handle this clause just as any other
clause explained before. However, the root verb in R6C1 “be” occurs in
conjunction with a “not”. This can be addressed by introducing a negation
operator (a logical `not`) in the relation. For example, R5C1 yields
`give_charging_approval()` and R6C1 yields `not give_charging_approval()`.

Handling the second clauses of the requirements poses a different challenge.
In R5C2, the word active occurs, while in R6C2, the antonym of this word
inactive occurs. We propose to assume the first occurrence of a word
qualifying such boolean expressions as boolean true and if its antonym is
cited in a different requirement, it can be assigned as boolean false. The
antonyms can be identified using a hierarchical thesaurus like
WordNet666http://wordnetweb.princeton.edu/perl/webwn. We assume this way of
approaching negations is more intuitive than looking at a single word and
inferring its sentiment. The sentiment of a word does not necessarily help us
define the boolean value of the word.

In the light of the above discussion, we present an overview of a few rules we
use to extract the entities in the following tables. The dependency and POS
tags are first mapped to the syntactic entities subject, object and predicate,
see Table 3. Then these syntactic entities are mapped to the model entities
signal and parameter according to specific rules, see Table 4. The operator is
identified from the ADJ denoted by op(ADJ) in the table. The rules can be
extended e.g. by considering the type of action (nominal, boolean, simple,
etc.) and verb types (transitive, dative, prepositional, etc.).

Table 3: Mapping of DEP/POS tags to syntactic entities DEP/POS tags (constituents) | Syntactic entities
---|---
nsubj, nsubjpass | subject
pobj, dobj | object
root, root + NOUN, | predicate
auxpass/root + ADP/ADV/ADJ
Table 4: Mapping of syntactic entities to model entities Syntactic entities | Signal | Operator | Parameter
---|---|---|---
subject, predicate | predicate_subject | - | -
subject, predicate, object | predicate_subject | - | object
ADJ, subject, predicate, object | predicate_ADJ | - | object
subject, ADJ, object | subject | op(ADJ) | object

#### Discussion

Although a custom rule base exploiting dependency and POS tags is well suited
for a particular use case, it demands a tremendous effort to generalize the
rules for requirements across domains varying in nature and style. With each
new style of requirement, the rule base may need to be updated, leading to
further effort and deliberation. We argue this by considering the number of
dependency and POS tags, which are 37 dependency tags and 17 POS tags
according to the revised universal dependencies [25].

###  2.3 Semantic-Role-Based Approach

We can also formalize requirements by extracting the semantic roles in the
requirement text. The semantic roles represent the relation between the words
or phrase in regards to the main verb present in the sentence. It describes
the conceptual meaning behind the word.

Figure 4: Semantic roles for an exemplary requirement phrase.

For example, consider a simple requirement phrase, “The system shall close the
valve”. As illustrated in Fig. 4, “the system” is semantically the agent of
the action “close”. Further, this action is performed on “the valve” which is
semantically its patient. In general, the agent is the one who initiates the
action and the patient is the one on whom the action is performed. These roles
are semantic properties in contrast to subject and object, we used in Section
2.2, which are syntactic properties. Some semantic roles are presented in
Table 5.

Table 5: List of basic semantic roles Role | Description
---|---
Agent | Who/what performed the action
Patient | Who/what was the action performed on
Location | Where the action was performed
Time | When the action was performed
Instrument | What was used to perform the action
Beneficiary | Who/what is benefited by the action

Semantic Role Labeling (SRL) is the task of assigning these roles to the
phrases or words that describe their semantic meaning. SRL is one of the
leading tasks in natural language processing [27]. It can be used for
applications such as question answering, data mining etc. We use SRL for
requirements formalization by identifying the roles to form the desired
requirements models. We use a state-of-the-art pre-trained deep learning BERT
model [34] by AllenNLP777https://demo.allennlp.org/semantic-role-labeling.
This model generates frames, each containing a set of arguments related to a
verb in the sentence. The arguments are defined based on English Propbank
defined by Bonial et al. [6]. Each argument describes the semantic relation of
a word to the verb with which it is associated. The arguments can be either
numbered or functional. Table 6 shows some of the arguments and the
corresponding roles.

Table 6: Basic arguments based on English Propbank | Argument | Role
---|---|---
Numbered | ARG0 | Agent
ARG1 | Patient
ARG2 | Instrument/beneficiary
ARG3 | Start point/beneficiary
ARG4 | End point
Functional | ARGM-LOC | Location
ARGM-TMP | Time
ARGM-NEG | Negation
ARGM-PRD | State

We will now demonstrate how we handle the decomposition and entity detection
stages with the SRL roles. This can help in considerably reducing the number
of rules compared to the first approach while handling even more complex
requirements. It is worth to note that there are only 24 SRL arguments (5
numbered and 19 functional) and we argue that even an exhaustive rule base
would only demand a combination of some of these different arguments.

The maximum power shall be limited to [G_Max] and the event “High device
temperature” shall be indicated when the device temperature exceeds [T_Hi] ºC.

Consider the requirement Req. 2.3. This requirement has three desired clauses
with two statements based on one condition.

#### Preprocessing

In the requirement, we have the name of an event “High device temperature”
within quotes which describes what happens when this event occurs in the
system. In certain other cases, the use case has longer event names which by
itself had semantic roles within. To help the SRL model to distinguish the
event names from the rest of the requirement text, we preprocess the
requirement by replacing the occurrences of event names in quotes with
abbreviated notations like “E1”. We also eliminate square brackets and units
around variables, for example “G_Max” and “T_Hi” in Req. 2.3.

Figure 5: SRL frames for Req. 2.3.

The pre-trained SRL model also retrieves frames for modal verbs like “be” or
“shall” which may not have any related arguments. To devise a rule set that
works with almost all frames, we discard frames with just one argument.

#### Decomposition

Unlike the decomposition described in Section. 2.2 which utilized dependency
and POS tags, here we discuss the decomposition of complex requirements based
on the detected SRL frames. As shown in Fig. 5, we obtain a total of three
frames from the pre-trained SRL model applied on Req. 2.3. The span (obtained
by adding up the requirement phrases belonging to each role in the frame) of
these detected frames yield us the following decomposed clauses:

  * the maximum power shall limited to G_Max

  * the event E1 shall indicated

  * when the device temperature exceeds T_Hi

In the second clause, we have the role ARGM-TMP which describes the condition
of the action. Here, we have ARGM-TMP with the desired conditional clause as
its span which tells us that this condition is related to this particular
action. But when we look at the requirement we know that the condition clause
applies to both the other clauses. So as to avoid wrong formation of the
output model, we will avoid those ARGM-TMP role with the full clause as span
and only consider those ARGM-TMP roles with a single word like “when” or with
the unit of time.

#### Entity detection

The first frame is associated with the verb “limited”. We have “The maximum
power” as ARG1 (describing on whom the action is performed on), “to G_Max” as
ARG2 (an instrument). We can map the verb together with ARG1 as the signal and
ARG2 as the parameter. Note that we use the lemma (basic form) of the verb to
form the signal. Also, the stop words in the arguments are eliminated. This
yields us the relation for this clause as: `limit_maximum_power(G_Max)`. From
this relation, we form the construct `V_ARG1(ARG2)` which can be further used
if we get similar frames.

The second frame, after avoiding the argument ARGM-TMP, follows a similar
construct as the first frame only without the optional parameter. We also
perform back mapping of the abbreviated event name “E1” with its actual event
name yielding the relation: `indicate_event_high_device_temperature()`.

The third frame is a conditional clause which is identified by the argument
ARGM-TMP with a span of “when”. Here, we have “the device temperature” as ARG0
(the agent) and “T_Hi” as ARG1 (the patient). We map ARG0 as the signal and
ARG1 as the parameter.

#### Operator detection

Additionally, a comparison word “exceeds” occurs in the role V of this clause.
We detect the corresponding operator by looking it up in Roget’s Thesaurus,
similar to the first approach. In this case, the word “exceeds” gives the
symbol “$>$”. Thus, this clause translates to the relation
`device_temperature() > T_Hi`. We build a general construct for similar frames
with operator as `ARG0 V ARG1`.

The device fuel pump shall not be activated until the fuel level falls below
[L_Fp].

Consider another requirement, Req. 2.3, with negation and the conditional
keyword “until”. SRL frames obtained from the pre-trained model are shown in
Fig. 6.

Figure 6: SRL frames for Req. 2.3.

#### Entity detection (negation handling)

The first frame follows the same construct as before leaving the argument ARG2
optional. However, we also have the argument ARGM-NEG indicating a negation in
the clause which should be considered while forming the relation. In this
case, we can modify the previous construct `V_ARG1()` to form a new construct
`not V_ARG1()`. This finally yields the relation `not
activate_device_fuel_pump()`.

Though the second frame indicates a conditional clause, it is difficult to
identify since no arguments have been assigned to the word “until”. So as to
recognize it as a condition, we apply rules to identify it as condition like
keyword identification. Considering the arguments, we have the role ARG4,
which indicates an ending point that can be mapped to a parameter and ARG1 to
a signal.

#### Operator detection

To find the operator symbol, the verb text will not be enough in this case as
“falls” alone cannot help in getting the operator symbol. So, as to get the
symbol, we apply one extra rule, i.e., to consider the next word in the
requirement in addition to the verb text to get the symbol. So the span text
would be “falls below” which gives the symbol “$<$”.

So this particular frame would lead to `fuel_level() < L_Fp` leading to the
formation of the construct `ARG1 V ARG4`.

The device fuel pump shall be deactivated within 3s and shall be closed when
the fuel level exceeds [L_Fp].

SRL can handle the time constraint and some complex decomposition as well. To
demonstrate this, we will modify the previous requirement as shown in Req.
2.3. Figure 7 shows the identified SRL frames.

Figure 7: SRL frames for Req. 2.3.

#### Decomposition

When we decompose this requirement with keywords like “and” and “when”, it
would lead to wrong formation of clause as the second clause would not show
what shall be closed. Looking at the SRL frames, it correctly identifies this
and forms the correct following clause by considering span text for each
frame.

  * The device fuel pump shall deactivated within 3s

  * The device fuel pump shall closed

  * when the fuel level exceeds L_Fp

The first and the second frame follows the same construct as before, i.e.,
`V_ARG1()`, and the third frame follows `ARG0 V ARG4`. In the first frame, we
have identified ARGM-TMP with a time constraint. This temporal behavior can be
detected by some rule, e.g. whether the span text contains a number and a unit
of time, or from the keyword “within”. However, we leave the discussion of
modeling non-functional properties such as temporal behavior to future work.

In Table 7 we have summarized some rules for mapping the arguments to model
entities. The first three lines in the table show some cases for assignments,
whereas the two last lines show cases for conditions. Conditions are
identified using the argument ARGM-TMP. The operator is identified from the V
role denoted by op(V) in the table.

Table 7: Mapping of SRL arguments to model entities SRL arguments | Signal | Operator | Parameter
---|---|---|---
ARG1 (patient), V | V_ARG1 | - | -
ARG1 (patient), V, ARG2 (instrument) | V_ARG1 | - | ARG2
ARG1 (patient), V, ARGM-PRD (state) | V_ARG1 | - | ARGM-PRD
ARG0 (agent), V, ARG1 (patient) | ARG0 | op(V) | ARG1
ARG1 (agent), V, ARG4 (end points) | ARG1 | op(V) | ARG4

#### Discussion

Using SRL information, we need much easier and less rules as compared to the
first approach. This makes it easy to adapt this approach according to a
specific use case and needs. However, in a few cases we found that SRL was not
working properly. For further improvements, one could of course combine both
approaches using the POS and dependency tags as well as SRL labels.

Similar as in the first approach, the underlying deep learning models are
evolving quickly. They are trained with new and better annotated datasets,
resulting in better generation of models with state-of-the-art performance and
higher accuracy. The above mentioned constructs and rules are based on the
specific model (current state of the art [34]) we used to extract SRL
arguments. This might not work completely with the future better models as
they would extract more information and these constructs/rules could be
outdated. So it might be necessary to change the rules when other models are
used.

###  2.4 Model Formation

Once the necessary entities are extracted from the requirement clauses, we
head to the last stage in the pipeline, model formation. As mentioned above,
we form a relation for each clause. In particular, assignments are of the form
`signal(parameter*)` with optional parameter, and conditional statements are
of the form `signal()` `operator` `parameter`. To generate requirement models
from these relations, we use a simple domain-specific language (DSL) with
abstract logical blocks. We extend the modalities of our previous work [17]
following the Temporal Action Language (TeAL) of Li et al. [21]. It maps the
relations according to some identified keywords to blocks. Conditional
statements starting with if/when/while are mapped to an if-block, those
starting with until to an until-block. Assignments without introductory
keyword are mapped to an then-block and those starting with else/otherwise to
an else-block. When there is no conditional statement given in the
requirement, we map all assignments to a statement-block without using any
keywords. Conjunctions (and/or) identified between relations are also
accommodated in these DSL blocks. Though this mapping appears rather trivial,
our aim is to make this translation simple and flexible, so that ways are open
for integration with other sophisticated languages. Obviously, our DSL is very
similar to the FRETISH language [14]. The resulting models can also be further
transformed into Matlab Simulink models or UML sequence diagrams, depending on
what the end user desires.

For example, the model for Req. 2.2 is of the form:

⬇

if( temperature_of_battery() > t_batt_max )

then( set_error_state( E_BROKEN) )

Similarly, the more complex requirement defined as Req. 2.3 will yield the
following model:

⬇

if( device_temperature() > T_Hi )

then( limit_maximum_power(G_Max)

and indicate_event_high_device_temperature() )

The maximum power shall be limited to [G_Max] when the device temperature
exceeds [T_Hi] ºC, otherwise indicate the error “Maximum power exceeded”,
until the device temperature falls below [T_Norm] ºC.

To demonstrate how we build the DSL with all the logical blocks, see Req. 2.4.
This requirement has an if-block, its corresponding then-block, an else-block
and an until-block. The formal model for this requirement is of the following
form:

⬇

if( device_temperature() > T_Hi )

then( limit_maximum_power(G_Max) )

else( indicate_error_maximum_power_exceeded() )

until( device_temperature() < T_Norm )

#### Discussion

There exist many different, more or less common textual and graphical
representations of behavioral models, for example temporal logic, cause-effect
graphs, UML diagrams (sequence diagrams, class diagrams, activity diagrams,
etc.), OCL constraints, Petri nets, or Matlab Simulink models. Initially, we
planned to use sequence diagrams as output format since it is very common and
can be represented textually and graphically888https://sequencediagram.org/.
However, we realized that some parts of the requirements, such as until-
conditions or temporal behavior, cannot be handled easily. For more complex
requirements, the overview gets lost due to many nested fragments. Pseudocode
has the advantage of being human- and machine-readable. It is a kind of more
abstract, intermediate format, one has to define a mapping for the keywords
for further processing. We see this as an advantage, since this mapping can be
adapted to different use cases and needs. It includes all information to be
mapped to other model formats.

##  3 Existing Methodologies

In this section, we want to give a brief overview of existing methodologies
for requirements formalization.

###  3.1 Controlled Natural Language (CNL)

The use of a Controlled Natural Language (CNL) is an old and common approach
to enable automatic analysis. The requirements need to be written in
restricted vocabulary and following some specific templates (also called
patterns or boilerplates). Commonly used templates include the SOPHIST
template [32], the EARS template [26] and the FRETISH template [14].

Early NLP methods used dictionaries and a large set of rules to extract
syntactic and semantic information such as syntax trees and semantic roles to
form models [31, 8]. More recently, Allala et al. [2] exploit templates to
represent requirements and utilize Stanford CoreNLP to create test cases and
meta-modeling for validation. The FRET tool can be used to map the structured
requirement with the help of templates and convert them into formal models
[11]. Giannakopoulou et al. [14] use FRETISH requirements and derive temporal
logic formulas from them. However, these approaches use rule sets rather than
any kind of NLP method.

###  3.2 Dependency and Part of Speech (POS)

As explained in Section 2.2, part-of-speech (POS) tags categorize words
according to their grammatical properties, and dependency tags identify
grammatical structure of the sentence. Different libraries like NLTK, spaCy
and Stanford CoreNLP can be used for POS tagging and dependency parsing.
Dependency annotation can also be done using Universal Dependencies Guidelines
on software requirements [18].

Pre-defined patterns are considered on dependency trees to identify subtrees
which would help in generation of cause-effect-graphs [12]. Unstructured
Information Management Architecture (UIMA) framework has been used to extract
POS tags and determine phrases to help identify actions and conditions to form
models on use case descriptions [36]. Fischbach et al. [12] also constructs
few patterns with combination of POS and dependency tags. Koscinski et al.
[20] use Stanford CoreNLP to assign dependency tags and use pre-defined
patterns to identify syntactical categories from which requirements models can
be generated with a small amount of rules. Fritz et al. [13] uses the
combination of both POS and dependency tags to identify semantic frames to map
requirements into an existing structure. The latter two papers are very
similar to our first approach, but use different categories and rules.

###  3.3 Named Entity Recognition (NER)

Phrases from sentences can be classified into some predefined categories known
as named entities. NER is the task of assigning these entities. Commonly used
categories are person, organization, location etc. But these categories are
not helpful for requirements analysis. To perform NER for requirement texts,
one needs to define new categories and manually annotate a dataset to train
ML-based approaches. Annotating a dataset is a laborious and a time consuming
task. Also, defining categories can vary depending on the requirement type.
Malik et al. [24] and Herwanto et al. [19] defined 10 and 5 entities,
respectively, for software requirement specifications and privacy related
tasks. In both approaches, the dataset is annotated manually. Multiple checks
with multiple human annotators are carried out to get better quality data.
Nayak et al. [28] have trained an NER model for creating expressions with 9
entity categories, which is then used to formalize requirements.

###  3.4 Semantic Role Labeling (SRL)

As described in Section 2.3, in Semantic Role Labeling (SRL), words or phrases
in a sentence are assigned labels that indicate their semantic role in the
sentence, such as the agent, the patient, etc. Semantic frames have been
widely used for requirements analysis in recent years. From simple dependency
parsing rules [33] to machine learning models [4, 34], much has been used to
extract semantic roles and frames. Sengupta et al. [33] use the Stanford
Dependency manual to create rules that help extract basic arguments for
requirement analysis, whereas Fritz et al. [13] use spaCy to extract POS and
dependency tags from which they create rules to extract semantic roles. Rules
can also be created to recognize semantic relations based on the lexeme (word
form) and its variants [5].

FrameNet was utilized to determine semantic relationships between requirements
with inheritance knowledge [1]. VerbNet and other open source resources were
used to perform semantic analysis for specification representation [23].

Recently, machine learning techniques have also been considered for semantic
role extraction. Wang et al. [38] use the SRL model of the CogComp NLP
pipeline to generate domain models with a rule set. Mate Tools [4] has been a
commonly used ML model for SRL which uses linear logistic regression.
Diamantopoulos et al. [10] extended Mate tools’ semantic role labeler by
training it with additional lexical attributes as features, and used it for
mapping of requirements to formal representations. The latter work is similar
to our second approach but we utilize a much more recent SRL model with very
flexible rules.

###  3.5 Translation and Back-Translation

Translation of requirement texts to some kind of model directly in one step is
not an easy task. As seen from all the above mentioned methods, it requires
multiple steps and multiple methods to form the output model. We can use the
concept of Neural Machine Translation (NMT)/Code Generation to translate
requirements to desired pseudocode. Code generation has been used to convert
complex text into programming language code using machine learning models
[22]. It can also be used to convert text into an Abstract Syntax Tree (AST)
which represents syntactic structure of the desired code [30]. This would
require manual creation of a large dataset with requirement texts and its
corresponding pseudocode or AST which is again a laborious and a time
consuming task.

Neural Machine Translation can also be used to back translate output models to
requirement text. Tools like OpenNMT has been used to convert temporal logic
into natural language requirements [9]. A set of rules can also be applied to
create functional natural language requirements from data models [7]. A
systematic survey on the generation of textual requirements specifications
from models can be found in [29].

##  4 Discussion

In view of the many recent developments in this area of research, the journey
towards the development of mature requirements formalization techniques has
only just begun. Since the aim of this work is to present principal ideas on
this research topic, we also want to discuss some findings and shortcomings
that we identified during our investigations. The tremendous survey of Zhao et
al. [39] has already identified some key findings for the NLP-supported
requirements engineering process, namely (i) a huge gap between the state of
the art and the state of the practice, i.e., an insufficient industrial
evaluation, (ii) little evidence of industrial adoption of the proposed tools,
(iii) the lack of shared RE-specific language resources, and (iv) the lack of
NLP expertise in RE research to advise on the choice of NLP technologies. We
agree that these findings also apply to the requirements formalization
process.

###  4.1 Lessons Learned

The international XIVT project999https://www.xivt.org/ addressed the challenge
of automatically analyzing and extracting requirements in order to minimize
the time for testing highly configurable, variant-rich systems. During the
three-year project period, we had many interesting talks and discussions with
research and industry partners on this research area. The approaches presented
in this work are the result of countless internal and external discussions,
which shows that it is not an easy task and very manifold, but also a very
interesting topic.

#### Generality

It is very tempting to try to develop a single algorithm that is general
enough to handle a wide range of natural language requirements. But, just as
natural language is diverse, so would the algorithm to be developed have to
be. Requirements are formulated by such a wide variety of people with
different motivations, experience and expert knowledge, from different
branches and with different social backgrounds, that it is currently
impossible to create one algorithm for the huge variety of styles of
unstructured natural language. The many existing approaches and our own
developments show that it is reasonable to automate this process to a high
degree for a specific use case, domain and writing style. In short: Don’t
worry about being specific!

#### Requirement quality

The human language is full of misunderstandings, ambiguities, inconsistent and
incomplete formulations. When developing a rule set we were strongly biased by
the given requirements. We kept trying to improve the rules to make them more
and more accurate. In discussion with our industry partners, we realized that
some parts of the requirements seemed to be somewhat poorly written. By a
short reformulation, our algorithm could handle them much easier. This shows
that the algorithmic treatment of the formalization process reveals many minor
issues that need to be fixed by the requirement engineers, and thus also
contributes to a higher quality of the requirements. In short: Don’t always
blame the model!

#### Degree of automation

For a long time of our development, we planned to build a standard
input/output tool that would generate the requirements models fully
automatically without asking the user for any input or confirmation. However,
we have found that we are unable to properly process the data if some
information within the pipeline is missing. Additionally, our industry
partners have also requested to always have a quick verification option by
prompting missing or uncertain information to the user. So if even humans need
to review many details to formalize a set of requirements, how should an
algorithm be able to generate correct and complete models fully automatically?
The fact that requirements analysis is a highly interactive process should
also be taken into account when implementing the tool. It is much more
desirable from the industry to have assistance in creating correct
requirements models than to have a fully automated algorithm that produces
some erroneous models. In the end, the required working time of an engineer
decides whether the review of automatically generated models is preferable to
the manual creation process. That is, the algorithms need to be highly
efficient to have the chance of being used by the industry, therefore we
believe that an interactive, performant user interface is essential. In
addition, the information obtained from user input can also be used to improve
the underlying ML algorithms. In short: Go for user interaction!

#### Availability of data

A crucial obstacle in this research area is that the data situation for freely
available requirements with corresponding models is very poor. One would need
a large corpus of these data from different use cases to compare different
algorithms. Unless a reliable and sufficiently large amount of ground truth
exists, a benchmark of different approaches and tools is not possible [37].
Even if one takes the time in a group of scientists to analyze, label, and
model requirements, detailed discussions with industry stakeholders are
essential and time-consuming. Consider the quote of Steve Jobs: ”A lot of
times, people don’t know what they want until you show it to
them”101010Business Week 12 May 1998,
https://www.oxfordreference.com/view/10.1093/acref/9780191826719.001.0001/q-oro-
ed4-00005922. Thus, the success of ML-trained algorithms relies on having a
large amount of labeled and unlabeled data sets available. In short: Share
your data!

#### Availability of tools

Similarly, the availability of ready-to-use algorithms and tools is very
limited. Only a few tools are publicly available [39], and most of them are in
a prototypical stage. This makes it very difficult for industry to identify
useful tools for the application to their use cases. In short: Go for GitHub!

#### Evolution

Most approaches in the literature deal with a fixed set of requirements.
Likewise, most freely available requirements specifications are provided in a
single fixed document (with a few exceptions111111AUTOSAR,
https://www.autosar.org/nc/document-search/). However, this is completely
contrary to the highly iterative and evolving process of requirements
elicitation. Just as dynamic as software development is the corresponding
requirements engineering. On the other hand, we observe that NLP models have
evolved very rapidly in recent years. Since the publication of the BERT
models, there has been an exploding amount of research about the application
and further training of these models. Researchers are hunting for better and
better models with higher accuracy, algorithms from one or two years ago are
already outdated and need to be revised when used for further development. In
short: Everything evolves!

###  4.2 Possible Future Developments

From our perspective, there are a number of emerging, sophisticated NLP
methods and models that can be applied to the requirements formalization
process. Although it is very difficult to look into the distant future of NLP
research and predict developments, we do see some direct follow up to current
approaches and can envision some future developments.

#### Named Entity Recognition (NER)

The advantage of NER is the direct identification of model entities when they
are used as labels. However, the labeled dataset must be very large to achieve
reasonable accuracy. To reduce the intensive labelling work, one could use
pre-trained models (e.g. provided by AllenNLP) and fine-tune them with newly
annotated datasets with new categories.

#### Semantic Role Labeling (SRL)

The current SRL models already have an acceptable accuracy. However, we also
found that the predictions can change suddenly if just one word or comma is
changed. The model may not work as well for domain-specific wording or the
writing style of requirements. Therefore, the improvement in accuracy could be
studied if the SRL models are pre-trained with some labeled requirements data
(a starting point could be [10].

#### Question-Answer Driven Semantic Role Labeling (QA-SRL)

As mentioned above, requirements analysis is highly interactive and needs
several input from the user. It would be a new level of automation, if an
algorithm itself is able to formulate questions and process the given answers
to clarify missing or uncertain information for generating the model.

#### Transfer learning (TL)

It is very successful in other fields of NLP research to train a model an some
related tasks with a larger amount of data and then to fine-tune it for the
actual task with much less labeled data. We could imagine using models that
have already been trained for requirements classification or ambiguity
detection.

#### Online learning

Current approaches use NLP models that are trained once and will not change
according to user feedback. It would be much more convenient for the user if
the algorithm learns from the input and suggests better results for subsequent
requirements. This could be done by some sort of post-training of the models
or more sophisticated continuous learning methods. This could also be useful
for a completely new use case and domain, where the algorithm learns the rules
from the beginning and one could avoid implementing of a rule set at all.

#### Translation/back-translation

Directly translating requirements into models with a large ML model might be
far in the future or somehow not reasonable. But there are interesting
developments in the research area of translating text to code that could be
helpful in formalizing requirements as well. The other direction of generating
boilerplates sounds much simpler, but also needs to be studied in detail. We
can imagine that in the future a coexistence of requirements and models will
be possible, where hand-written requirements are transformed into models and
transformed back into structured text that can be used for further processing
- a kind of ”speaking models”.

#### Semantic similarity

As shown in our previous work [17], semantic similarity between requirements
and product design descriptions (if available) is helpful for generating more
concrete requirements models, i.e., identifying signal and parameter names
from the design specification instead of generating abstract entity names.
However, identifying the correct Boolean value (antonym detection), for
example, is still a difficult task in NLP research. Moreover, requirements
formalization and quality analysis are strongly interlinked. Semantic
similarity can be useful for consistency checking, e.g. for identifying of
identical signals and parameters used with slightly different terms within the
set of requirements, see [38] for a first approach.

#### Auxiliary documents

Requirements do not fall from the sky. Usually, an extensive elicitation phase
takes place in advance. One could make use of preparatory documents such as
interviews, meeting notes, etc., or implementation artifacts such as issue
descriptions (bug reports, feature requests, etc.). They can provide context,
different formulations, and missing information. It would also be interesting
to explore how to support the entire requirements development process. One
would need to study the process in great detail, track and analyze the
documents, and identify some successful workflows that can be assisted by NLP
approaches (a starting point could be the FRET tool [14]).

##  5 Conclusion

In this work, we have presented and discussed principal ideas and state-of-
the-art methodologies from the field of NLP to automatically generate
requirements models from natural language requirements. We have presented an
NLP pipeline and demonstrated the iterative development of rules based on NLP
information in order to guide readers on how to create their own set of rules
and methods according to their specific use cases and needs. We have studied
two different approaches in detail. The first approach, using dependency and
POS tags, shows good results but is somewhat inflexible in adopting the
underlying rule set for different use cases and domains. The second approach,
using semantic roles, shows similar good results, but requires less effort to
create a set of rules and can be easily adapted to specific use cases and
domains. The use of a human- and machine-readable format for the requirements
models appears suitable for easy reading comprehension and at the same time
for automatic further processing. The results show that the current pre-
trained NLP models are suitable to automate the requirements formalization
process to a high degree.

Furthermore, we provided an overview of the literature and recent developments
in this area of research and discussed some findings and shortcomings (lessons
learned) that we identified throughout the development of our approaches.
Finally, we suggested some possible future developments in NLP research for an
improved requirements formalization process.

#### Acknowledgments

This research was funded by the German Federal Ministry of Education and
Research (BMBF) within the ITEA projects XIVT (grant no. 01IS18059E) and
SmartDelta (grant no. 01IS21083E). We thank AKKA Germany GmbH and Alstom for
providing industrial use cases for the demonstration of the presented methods.
We are grateful to Prof. Holger Schlingloff from Fraunhofer FOKUS/HU Berlin
for his valuable recommendations.

## References

  * [1] Alhoshan, W., Zhao, L., Batista-Navarro, R.: Using semantic frames to identify related textual requirements: An Initial Validation. In: ESEM ’18. pp. 1–2. ACM, New York (2018). https://doi.org/10.1145/3239235.3267441
  * [2] Allala, S.C., Sotomayor, J.P., Santiago, D., King, T.M., Clarke, P.J.: Towards Transforming User Requirements to Test Cases Using MDE and NLP. In: COMPSAC 2019\. pp. 350–355. IEEE (2019). https://doi.org/10.1109/COMPSAC.2019.10231
  * [3] Ammann, P., Offutt, J.: Introduction to Software Testing. Cambridge University Press, Cambridge and New York, NY and Melbourne, second edition edn. (2017)
  * [4] Björkelund, A., Hafdell, L., Nugues, P.: Multilingual Semantic Role Labeling. In: CoNLL 2009. pp. 43–48. ACL, Boulder (2009), https://aclanthology.org/W09-1206
  * [5] Bokaei Hosseini, M., Breaux, T.D., Niu, J.: Inferring Ontology Fragments from Semantic Role Typing of Lexical Variants. In: REFSQ 2018. LNCS, vol. 10753, pp. 39–56. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-77243-1_3
  * [6] Bonial, C., Bonn, J., Conger, K., Hwang, J.D., Palmer, M.: PropBank: Semantics of New Predicate Types. In: LREC 2014. pp. 3013–3019. ELRA (2014), https://aclanthology.org/L14-1011/
  * [7] de Brock, B., Suurmond, C.: NLG4RE: How NL Generation Can Support Validation in RE. In: NLP4RE 2022. CEUR-WS.org (2022), http://ceur-ws.org/vol-3122/nlp4re-paper-2.pdf
  * [8] Carvalho, G., Barros, F., Carvalho, A., Cavalcanti, A., Mota, A., Sampaio, A.: NAT2TEST Tool: From Natural Language Requirements to Test Cases Based on CSP. In: SEFM 2015. LNCS - LNPSE, vol. 9276, pp. 283–290. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-22969-0_20
  * [9] Cherukuri, H., Ferrari, A., Spoletini, P.: Towards Explainable Formal Methods: From LTL to Natural Language with Neural Machine Translation. In: REFSQ 2022\. LNCS, vol. 13216, pp. 79–86. Springer, Cham (2022). https://doi.org/10.1007/978-3-030-98464-9_7
  * [10] Diamantopoulos, T., Roth, M., Symeonidis, A., Klein, E.: Software requirements as an application domain for natural language processing. Language Resources and Evaluation 51(2), 495–524 (2017). https://doi.org/10.1007/s10579-017-9381-z
  * [11] Farrell, M., Luckcuck, M., Sheridan, O., Monahan, R.: FRETting About Requirements: Formalised Requirements for an Aircraft Engine Controller. In: REFSQ 2022. LNCS, vol. 13216, pp. 96–111. Springer, Cham (2022). https://doi.org/10.1007/978-3-030-98464-9_9
  * [12] Fischbach, J., Vogelsang, A., Spies, D., Wehrle, A., Junker, M., Freudenstein, D.: SPECMATE: Automated Creation of Test Cases from Acceptance Criteria. In: ICST 2020. pp. 321–331. IEEE (2020). https://doi.org/10.1109/ICST46399.2020.00040
  * [13] Fritz, S., Srikanthan, V., Arbai, R., Sun, C., Ovtcharova, J., Wicaksono, H.: Automatic Information Extraction from Text-Based Requirements. International Journal of Knowledge Engineering 7(1), 8–13 (2021). https://doi.org/10.18178/ijke.2021.7.1.134
  * [14] Giannakopoulou, D., Pressburger, T., Mavridou, A., Schumann, J.: Generation of Formal Requirements from Structured Natural Language. In: REFSQ 2020. LNCS, vol. 12045, pp. 19–35. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-44429-7_2
  * [15] Grujic, D., Henning, T., García, E.J.C., Bergmann, A.: Testing a battery management system via criticality-based rare event simulation. In: MSCPES ’21. pp. 1–7. ACM, New York (2021). https://doi.org/10.1145/3470481.3472701
  * [16] Gröpler, R., Sudhi, V., Calleja García, E.J., Bergmann, A.: NLP-Based Requirements Formalization for Automatic Test Case Generation. In: CS&P’21. pp. 18–30. CEUR-WS.org (2021), http://ceur-ws.org/Vol-2951/paper15.pdf
  * [17] Gröpler, R., Sudhi, V., Kutty, L., Smalley, D.: Automated Requirement Formalization using Product Design Specifications. In: NLP4RE 2022. CEUR-WS.org (2022), http://ceur-ws.org/Vol-3122/NLP4RE-paper-1.pdf
  * [18] Hassert, N., Ménard, P.A., Galy, E.: UD on Software Requirements: Application and Challenges. In: UDW 2021. pp. 62–74. ACL (2021), https://aclanthology.org/2021.udw-1.5/
  * [19] Herwanto, G.B., Quirchmayr, G., Tjoa, A.M.: A Named Entity Recognition Based Approach for Privacy Requirements Engineering. In: REW 2021. pp. 406–411. IEEE (2021). https://doi.org/10.1109/REW53955.2021.00072
  * [20] Koscinski, V., Gambardella, C., Gerstner, E., Zappavigna, M., Cassetti, J., Mirakhorli, M.: A Natural Language Processing Technique for Formalization of Systems Requirement Specifications. In: REW 2021. pp. 350–356. IEEE (2021). https://doi.org/10.1109/REW53955.2021.00062
  * [21] Li, W., Hayes, J.H., Truszczyński, M.: Towards More Efficient Requirements Formalization: A Study. In: REFSQ 2015. LNCS, vol. 9013, pp. 181–197. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-16101-3_12
  * [22] Ling, W., Grefenstette, E., Hermann, K.M., Kočiský, T., Senior, A., Wang, F., Blunsom, P.: Latent Predictor Networks for Code Generation (2016). https://doi.org/10.48550/ARXIV.1603.06744
  * [23] Mahmud, N., Seceleanu, C., Ljungkrantz, O.: Specification and Semantic Analysis of Embedded Systems Requirements: From Description Logic to Temporal Logic. In: SEFM 2017. LNCS, vol. 10469, pp. 332–348. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-66197-1_21
  * [24] Malik, G., Cevik, M., Khedr, Y., Parikh, D., Başar, A.: Named Entity Recognition on Software Requirements Specification Documents. In: Canadian AI 2021 (2021). https://doi.org/10.21428/594757db.507e7951
  * [25] de Marneffe, M.C., Manning, C.D., Nivre, J., Zeman, D.: Universal Dependencies. Computational Linguistics pp. 1–54 (2021). https://doi.org/10.1162/coli_a_00402
  * [26] Mavin, A., Wilkinson, P., Harwood, A., Novak, M.: Easy Approach to Requirements Syntax (EARS). In: RE ’09. pp. 317–322. IEEE, Piscataway (2009). https://doi.org/10.1109/RE.2009.9
  * [27] Màrquez, L., Carreras, X., Litkowski, K.C., Stevenson, S.: Semantic Role Labeling: An Introduction to the Special Issue. Computational Linguistics 34(2), 145–159 (2008). https://doi.org/10.1162/coli.2008.34.2.145
  * [28] Nayak, A., Timmapathini, H.P., Murali, V., Ponnalagu, K., Venkoparao, V.G., Post, A.: Req2Spec: Transforming Software Requirements into Formal Specifications Using Natural Language Processing. In: REFSQ 2022. LNCS, vol. 13216, pp. 87–95. Springer, Cham (2022). https://doi.org/10.1007/978-3-030-98464-9_8
  * [29] Nicolás, J., Toval, A.: On the generation of requirements specifications from software engineering models: A systematic literature review. Information and Software Technology 51(9), 1291–1307 (2009). https://doi.org/10.1016/j.infsof.2009.04.001
  * [30] Rabinovich, M., Stern, M., Klein, D.: Abstract Syntax Networks for Code Generation and Semantic Parsing (2017). https://doi.org/10.48550/ARXIV.1704.07535
  * [31] Riebisch, M., Hübner, M.: Traceability-Driven Model Refinement for Test Case Generation. In: ECBS’05. pp. 113–120. IEEE (2005). https://doi.org/10.1109/ECBS.2005.72
  * [32] Rupp, C., SOPHISTen, d.: Requirements-Engineering und -Management. Hanser, München (2014). https://doi.org/10.3139/9783446443136
  * [33] Sengupta, S., Ramnani, R.R., Das, S., Chandran, A.: Verb-based Semantic Modelling and Analysis of Textual Requirements. In: ISEC ’15. pp. 30–39. ACM, New York (2015). https://doi.org/10.1145/2723742.2723745
  * [34] Shi, P., Lin, J.: Simple BERT Models for Relation Extraction and Semantic Role Labeling, https://arxiv.org/pdf/1904.05255
  * [35] Simonson, E.: An MBD Adoption Story from Bombardier Transportation. In: MATLAB EXPO 2018 Sweden (2018), https://www.matlabexpo.com/se/2018/proceedings/proceedings.html
  * [36] Sinha, A., Paradkar, A., Kumanan, P., Boguraev, B.: A linguistic analysis engine for natural language use case description and its application to dependability analysis in industrial use cases. In: DSN 2009. pp. 327–336. IEEE, Piscataway (2009). https://doi.org/10.1109/DSN.2009.5270320
  * [37] Tichy, W.F., Landhäußer, M., Körner, S.J.: nlrpBENCH: A Benchmark for Natural Language Requirements Processing. In: SE SWM 2015. pp. 159–164. GI, Bonn (2015), https://dl.gi.de/handle/20.500.12116/2542
  * [38] Wang, C., Pastore, F., Goknil, A., Briand, L.C.: Automatic Generation of Acceptance Test Cases From Use Case Specifications: An NLP-Based Approach. IEEE Transactions on Software Engineering 48(2), 585–616 (2022). https://doi.org/10.1109/tse.2020.2998503
  * [39] Zhao, L., Alhoshan, W., Ferrari, A., Letsholo, K.J., Ajagbe, M.A., Chioasca, E.V., Batista-Navarro, R.T.: Natural Language Processing for Requirements Engineering: A Systematic Mapping Study. ACM Computing Surveys 54(3), 1–41 (2021). https://doi.org/10.1145/3444689