TDT 4242

Inah Omoronyia and Tor Stålhane

Guided Natural Language and

Requirement Boilerplates

TDT 4242

Institutt for datateknikk oginformasjonsvitenskap

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

Requirements elicitation

Req.012: The system shall enable cabin temperature regulation between 15°C and 30°C

……

Req.124: Cabin temperature shall not exceed 35°

Step 1:Capture Requirements in Natural Language

Step 2:Transfer Requirements and functions into a semi-formal requirements model

Function 1

Req 001Req 002Req 012

…Req 124

Function 2

Req 011Req 028Req 050

……

Function 1

Req 001Req 002Req 012

…Req 124

Function 1

Req 001Req 002Req 012

…Req 124

Function 2

Req 011Req 028Req 050

……

Function 2

Req 011Req 028Req 050

……

Function 1

Function 1a

Function 1b

Function 1c

Function 1

Function 1a

Function 1b

Function 1c

Req 001.01Req 001.02….

Step 3:Refine the requirements model and derive detailed requirements

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.

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 – 1

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

RMM- Refinement- Specialization

Example: The <system function> shall provide <system capability> to achieve <goal>

Template based textual Meta Model

Syntax

Semantics

Guided RSL Boilerplates

Requirements expressed using a vocabulary guideUses predefined concepts, relations and axioms to guide requirements elicitation

Requirements expressed on templatesUses predefined templates based on concepts, relations and axioms to guide requirements elicitation

Keywords:Reflects requirement, system and domain concepts

Analysis-Correctness-Completeness-Consistency-Safety analysis

Ontology: General and SP specific- Requirements classification- System attributes- Domain concepts

= + +

Example:The ACC system shall be able to determine the speed of the ego-vehicle.

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 constraintsRequires minimal expertise.

What is GNL - 1

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 un-ambiguity (reduced variability)

• Provide the basis for semantic processing and checking of requirements.

• Dictionary – Simple taxonomy or more formal ontology

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 – 1

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

TDT 4242

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.

Fixed Terms

Attributes

TDT 4242

Boilerplate examples - 1

BP32The <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 - 3BP43 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 exampleFunctional 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>

Non functional requirement example – 3

BP43While <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...>

TDT 4242

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