1. TDT 4242 Inah Omoronyia and Tor Stålhane Guided Natural Language and Requirement Boilerplates TDT 4242 Institutt for datateknikk og informasjonsvitenskap

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

3. Requirements elicitation

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

5. 5 Trondheim, Norway Brake by Wire System - 1 WSS = Wheel Sped Sensor

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

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

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

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

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

11. GNL and BPs RMM - Refinement - Specialization Example: The shall provide to achieve Template based textual Meta Model Syntax Semantics Guided RSLBoilerplates Requirements expressed using a vocabulary guide Uses predefined concepts, relations and axioms to guide requirements elicitation Requirements expressed on templates Uses 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.

12.  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 - 1

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

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

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

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

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

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

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

20. 20 Trondheim, Norway Boilerplate Rationale

21. 21 Trondheim, Norway Boilerplates Preamble

25. TDT 4242 Boilerplate examples - 1 BP32 The shall be able to Attributes: = driver = start the ACC system Requirement The driver shall be able to start the ACC system

26. TDT 4242 Boilerplate examples - 2 BP2 The shall be able to Attributes: = ACC system = determine = the speed of the ego-vehicle Requirement The ACC system shall be able to determine the speed of the ego-vehicle

27. TDT 4242 Boilerplate examples - 3 BP43 While BP32 The shall be able to BP43 is a mode Attributes = activated = driver = 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

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

29. TDT 4242 Non functional requirement example – 1 Non-functional requirements and soft goals fits into the same BPs as functional requirements BP61 The shall be able to to Suitability: The shall be able to to

30. TDT 4242 Non functional requirement example – 2 Non-functional requirements and soft goals fits into the same BPs as functional requirements BP2-1 The shall be able to BP12 …for a sustained period of at least Maturity: The shall be able to for a sustained period of at least

31. Non functional requirement example – 3 BP43 While BP2 The shall be able to While the shall be able to

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