Institutt for datateknikk og
informasjonsvitenskap
Inah Omoronyia and Tor Stålhane
Guided Natural Language
and
Requirement Boilerplates
TDT 4242
TDT 4242
Requirements
There are three levels of requirements:
• Informal – e.g. Natural language (NL): free text,
no rules apply
• Semiformal
• Guided Natural Language (GNL): free text but
allowable terms are defined by a vocabulare
• Boilerplates (BP): structured text and an
ontology – vocabulary plus relationships
between terms
• Formal: e.g. state diagrams or predicate logic
TDT 4242
Requirements elicitation
Step 1:
Capture
Requirements in
Natural Language
Req.012: The system
shall enable cabin
temperature regulation
between 15°C and 30°C
…
…
Req.124: Cabin
temperature shall not
exceed 35°
Step 2:
Transfer Requirements and
functions into a semi-formal
requirements model
Function 1
Function 2
Req 001
Req 002
Req 012
…
Req 124
Req 011
Req 028
Req 050
…
…
Step 3:
Refine the requirements model
and derive detailed requirements
Function 1
Function 1a
Function 1b
Req 001.01
Req 001.02
….
Function 1c
Parallel Steps:
Apply dictionary with common vocabulary; validate and check Requirements consistency and completeness
Step 4:
Create a
preliminary
design model
based on the
requirement
model (to be
used and
refined in
SP3)
Humans and machines – 1
Given the amount and complexity of RE, we
need to automate as much as possible.
Humans and machines have different strong
and weak points.
We want to elicit and analyze requirements in a
way that allows both parties to build on their
strong sides.
Humans and machines - 2

Machines are
 good at observing quantitative data and being
deductive, fast and precise. In addition, they are
good at doing consistent repetition of several
actions.
 bad at handling variations in written material and
pattern recognition.

Humans are good at handling variations in written
material, being inductive. In addition, they are good
at doing error correction.
Why BPs and GNL – 1

GNL and BPs will reduce variation and thus giving
the machines the opportunity to do what they are
best at: to be fast, precise and consistent.

By combining humans and machines and let both do
what they are best at, we get a better result than we
would get if we left the job of handling requirements
to just one of them.
Why BPs and GNL - 2

The final goal is to allow the machine to assist the
developers in analysing requirements for:
 Consistency
 Completeness
 Safety implications
GNL and BPs
Template based textual
Guided RSL
=
Boilerplates
Syntax
+
Semantics
Keywords:
Reflects requirement,
system and domain
concepts
Requirements expressed on templates
Uses predefined templates based on concepts,
relations and axioms to guide requirements elicitation
+
Analysis
-Correctness
-Completeness
-Consistency
-Safety analysis
Meta Model
RMM
- Refinement
- Specialization
Example:
The <system function> shall provide <system capability> to achieve <goal>
Requirements expressed using a vocabulary guide
Uses predefined concepts, relations and axioms to
guide requirements elicitation
Example:
The ACC system shall be able to determine the speed of the ego-vehicle.
Ontology: General and SP specific
- Requirements classification
- System attributes
- Domain concepts
What is GNL - 1



Free text requirement elicitation with the
assistance of prescribed words from a
dictionary. This will give us requirements
which use all terms in a uniform way, this
reducing misunderstandings
No formal constraints
Requires minimal expertise.
What is GNL - 2
Aim:
• Bridge the gap between unconstrained
expression and quality checking when
representing requirements as free text. Quality
measures:
Correctness, consistency, completeness and unambiguity (reduced variability)
• Provide the basis for semantic processing and
checking of requirements.
• Dictionary – Simple taxonomy or more formal
ontology
Approach for GNL – 1
Ontology = Thesaurus + Inference Rules
• Thesaurus – Domain concepts: entities,
terms and events
• Inference Rules – Relations, attributes and
axioms
• Causality, similarity, reflexivity,
transitiveness, symmetric, disjoint
(contradiction) …
Approach for GNL – 2
Required Activity
 Knowledge capture: Information embedded in
domain events from domain experts and ontologist
 Implementation: Formal representation of captured
knowledge. Language: OWL, Support environment:
Protégé.
 Verification: Checking that represented ontology is
correct using
• Classifiers/reasoners
• Domain experts (semantic accuracy)
• Mapping of requirement segments to ontology concepts
Motivation for use of templates - 1
Text has the advantage of unconstrained
expression. There is, however, a need for
common
• Understanding of concepts used to express
the requirements and relations between them.
• Format of presentation
Lack of common understanding makes
requirement specifications expressed as free text
prone to ambiguous representations and
inconsistencies.
TDT 4242
Motivation for use of templates - 1
Template based textual requirements
specification (boilerplates) will introduce some
limitations when representing requirements
but will also reduce the opportunity to
introduce ambiguities and inconsistencies.
Boilerplates
• Provides an initial basis for requirements
checking
• Are easy to understand for stakeholders
compared to more formal representations
TDT 4242
What is a boilerplate – 1
Boilerplates is a set of structures that can be used to
write requirements. They use high-level concept
classification and attributes
TDT 4242
What is a boilerplate – 2
The RE process is as follows:
1. Select a boilerplate or a sequence of
boilerplates. The selection is based on the
attributes that need to be included and how
they are organized – fixed terms.
2. If needed, identify and include mode
boilerplates
3. Instantiate all attributes
A boilerplate consists of fixed terms and attributes.
It may, or may not, contain one or more modes.
TDT 4242
Fixed Terms
Attributes
Boilerplate examples - 1
BP32
The <user> shall be able to <capability>
Attributes:
• <user> = driver
• <capability> = start the ACC system
Requirement
The driver shall be able to start the ACC system
TDT 4242
Boilerplate examples - 2
BP2
The <system> shall be able to <action> <entity>
Attributes:
• <system> = ACC system
• <action> = determine
• <entity> = the speed of the ego-vehicle
Requirement
The ACC system shall be able to determine the
speed of the ego-vehicle
TDT 4242
Boilerplate examples - 3
BP43 While <operational condition>
BP32 The <user> shall be able to <capability>
BP43 is a mode
Attributes
• <operational condition> = activated
• <user> = driver
• <capability> = override engine power control of
the ACC system
Requirement
While activated the driver shall be able to override
engine power control of the ACC-system
TDT 4242
Functional requirements example
Functional requirements from the SafeLoc system
 The robot control system shall stop the robot within 10
milliseconds if a gate is opened to the zone where the robot is
operating
 The robot shall only be allowed to start when all gates are
closed and the reset button is pushed
 The robot shall stop if it tries to move into a zone already
occupied by an operator
TDT 4242
Non functional requirement example – 1
Non-functional requirements and soft goals fits into
the same BPs as functional requirements
BP61
The <system> shall be able to <action> to <entity>
Suitability:
The <system > shall be able to <provide an
appropriate set of functions> to <the user>
TDT 4242
Non functional requirement example – 2
Non-functional requirements and soft goals fits into
the same BPs as functional requirements
BP2-1 The <system> shall be able to <capability>
BP12 …for a sustained period of at least
<number> < unit>
Maturity:
The <system > shall be able to <operate without
failure> for a sustained period of at least <quantity>
<time unit>
TDT 4242
Non functional requirement example – 3
BP43
While <operational condition>
BP2
The <system> shall be able to <action> <entity>
While <normal operational condition> the
<system> shall be able to <tolerate>
<90% of software faults of category...>
Summing up
The use of boiler plates and ontologies will
• Enforce a uniform use of terms
• Reduce the variability of presentations –
requirements that are similar will look similar
Reduced variation in form and contents simplifies
the use of automatic and semi-automatic tools
for
• Checking requirement quality – e.g
completeness and consistency
• Creating test cases
TDT 4242