Institutt for datateknikk og
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Inah Omoronyia and Tor Stålhane Guided Natural Language and Requirement Boilerplates PowerPoint PPT Presentation


  • 51 Views
  • Uploaded on
  • Presentation posted in: General

Institutt for datateknikk og informasjonsvitenskap. Inah Omoronyia and Tor Stålhane Guided Natural Language and Requirement Boilerplates. TDT 4242. Requirements. There are three levels of requirements: Informal – e.g. Natural language (NL): free text, no rules apply Semiformal

Download Presentation

Inah Omoronyia and Tor Stålhane Guided Natural Language and Requirement Boilerplates

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

Institutt for datateknikk og

informasjonsvitenskap

Inah Omoronyia and Tor Stålhane

Guided Natural Language

and

Requirement Boilerplates

TDT 4242

TDT 4242


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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

Requirements elicitation


The challenge

The challenge

The main challenges in RE for large, embedded, safety critical systems are that:

There are many requirements – often several thousands.

Several requirements are interdependent

Requirements are related to two or more of:

Hardware – computers, sensors, actuators, machinery

Software – control, measurement, logging

Operators – procedures, behavior


Brake by wire system 1

Brake by Wire System - 1

WSS = Wheel Sped Sensor


Brake by wire system 2

Brake by Wire System - 2

moving

Requirement - Natural language:

On a blocked wheel the brake shall be released within 100ms, while the vehicle is moving.


Humans and machines 1

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

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

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

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

GNL and BPs

Template based textual

Semantics

=

+

+

Syntax

Meta Model

  • RMM

  • Refinement

  • Specialization

Keywords:

Reflects requirement, system and domain concepts

Guided RSL

Boilerplates

  • Analysis

  • Correctness

  • Completeness

  • Consistency

  • Safety analysis

Requirements expressed on templates

Uses predefined templates based on concepts, relations and axioms to guide requirements elicitation

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

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

What is GNL - 2

Aim:

Bridge the gap between unconstrained expression and qualitychecking 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


Approach for gnl 1

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

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

What is a boilerplate – 2

The RE process is as follows:

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.

If needed, identify and include mode boilerplates

Instantiate all attributes

A boilerplate consists of fixed terms and attributes. It may, or may not, contain one or more modes.

TDT 4242


Boilerplate rationale

Boilerplate Rationale


Boilerplates

Boilerplates

Preamble


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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

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


Inah omoronyia and tor st lhane guided natural language and requirement boilerplates

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


  • Login