Steffen Bjerkenås Method Engineering

Dr. Ernst Sikora  Background from industry an academia  Research fields: Software Engineering and Requirements Engineering Marian Daun  Background from academia  Research fields: Requirements Engineering, Embedded Systems and Automotive Engineering Dr. Klaus Pohl  Background from industry and academia  Research fields: Requirements Engineering, Software Services and Software Quality Assurance  Over 200 publications, authored 3 books 2

Supporting the Consistent Specification of Scenarios across Multiple Abstraction Levels (Sikora et al., 2010) Why is this interesting?  Scenario-based requirements engineering (RE): Using scenarios to test the quality of requirements related to a specific system and its components  Purpose of paper: Support the development of scenarios for different levels of abstraction, and detect inconsistencies between these scenarios  Detection of these inconsistencies late in the development process  delays, financial setback 3

Supporting the Consistent Specification of Scenarios across Multiple Abstraction Levels (Sikora et al., 2010) Why is this interesting? 4 Headlight (system) Requirements: (...) Headlight (system) Requirements: (...) Component 1 Requirements: (...) Component 1 Requirements: (...) Component 2 Requirements: (...) Component 2 Requirements: (...) Component 3 Requirements: (...) Component 3 Requirements: (...) System-level scenarios Component- level scenarios Incosistencies?

5 Main steps

6 Inquiry Cycle model (Potts, Takahashi, & Antón, 1994)  Supports the use of scenarios in RE  No formalized framework for development of the scenarios Inquiry Cycle model (Potts, Takahashi, & Antón, 1994)  Supports the use of scenarios in RE  No formalized framework for development of the scenarios ScenIC (Potts, 1999)  Successor of the Inquiry Cycle  No support for detecting inconsistencies between scenarios developed for different levels of abstraction ScenIC (Potts, 1999)  Successor of the Inquiry Cycle  No support for detecting inconsistencies between scenarios developed for different levels of abstraction Heymans and Dubois (1998)  Formalized framework for developing scenarios  No inconsistency-checking Heymans and Dubois (1998)  Formalized framework for developing scenarios  No inconsistency-checking FRED (Regnell & Davidson, 1997)  Supports development of scenarios on different levels of abstraction  No inconsistency-checking FRED (Regnell & Davidson, 1997)  Supports development of scenarios on different levels of abstraction  No inconsistency-checking

7 Play in/Play out (Harell & Marelly, 2003)  Supports development of scenarios on different levels of abstraction  No inconsistency-checking Play in/Play out (Harell & Marelly, 2003)  Supports development of scenarios on different levels of abstraction  No inconsistency-checking Sikora et al., 2010  Supports development of scenarios on different levels of abstraction  Inconsistency checking Sikora et al., 2010  Supports development of scenarios on different levels of abstraction  Inconsistency checking Research Study (Sikora, Tenbergen, & Paul, 2011)  Identifies industry need for methods such as Sikora et al. (2010) Research Study (Sikora, Tenbergen, & Paul, 2011)  Identifies industry need for methods such as Sikora et al. (2010) Research Study (Sikora, Tenbergen, & Paul, 2012)  Identifies industry need for methods such as Sikora et al. (2010) Research Study (Sikora, Tenbergen, & Paul, 2012)  Identifies industry need for methods such as Sikora et al. (2010)

8  Research within the automotive industry (Sikora, Tenbergen, & Paul, 2011; Sikora, Tenbergen, & Paul, 2012; Grimm, 2003; Broy 2006) identifies the need for consistency-checking of scenarios  More elaborate empirical studies must be conducted before the method can be developed further (E. Sikora, personal communication, February 15, 2013)  Model-based methods for specification, simulation and verification of requirements are not commonly used (E. Sikora, personal communication, February 15, 2013)

9 Describe requirements System/component level Create system-level requirements Use case diagrams Message Sequence Charts Create component-level requirements Use case diagrams Message Sequence Charts Perform scenario comparison Interface automata

10

11  (Simple) Short-Range Air Defense System (Hutchings & Streets, 2001) Step 1: Create system-level scenario in a Use Case-diagram System-level scenario represented by a Use Case-diagram

12 Step 2: Based on system-level scenario; create system-level MSC and component- level MSC System-level scenario represented by a Message Sequence Chart

13 Step 2: Based on system-level scenario; create system-level MSC and component- level MSC Component-level scenario represented by a Message Sequence Chart

14 Step 3: Convert system-level and component-level MSC’s into interface automata System-level scenario represented by interface automaton Component-level scenario represented by interface automaton

15 Step 4: Detect incosistencies between system-level and component-level automata Detected inconsistencies Project-specific inconsistency rules dictates to what degree the detected inconsistencies impacts the development process

16 Broy, M. (2006). Challenges in automotive software engineering. In L. J. Osterweil, H. Rombach, & M. Soffa (Eds.), 28th International Conference on Software Engineering (pp ). Shanghai, China: Association for Computing Machinery. doi: / Grimm, K. (2003). Software technology in an automotive company: major challenges. 25th International Conference on Software Engineering - ICSE (pp ). Washington, USA: IEEE Computer Society. doi: /ICSE Harel, D., & Marelly, R. (2003). Come, Let’s Play - Scenario-Based Programming Using LSCs and the Play-Engine. Springer. Heymans, P., & Dubois, E. (1998). Scenario-Based Techniques for Supporting the Elaboration and the Validation of Formal Requirements. Requirements Engineering, 3(3-4), doi: /s Hutchings, P., & Streets, N. (2001). Future Short Range Ground-based Air Defence: System Drivers, Characteristics and Architectures. Defence Evaluation and Research Agency, Airspace Management Systems Department, Malvern, United Kingdom. Potts, C. (1999). ScenIC: A Strategy for Inquiry-driven Requirements Retermination. IEEE International Symposium on Requirements Engineering (pp ). Limerick, Ireland: IEEE Computer Society. doi: /ISRE Potts, C., Takahashi, K., & Antón, A. I. (1994). Inquiry-Based Requirement Analysis. Software - IEEE Software, 11(2), doi: / Regnell, B., & Davidson, A. (1997). Requirements Engineering with Use Cases - Experiences from Industrial Pilot Projects. 3rd Intl. Workshop on Requirements Engineering - Foundation for Software Quality (pp ). Barcelona, Spain. Sikora, E., Daun, M., & Pohl, K. (2010). Supporting the Consistent Specification of Scenarios Across Multiple Abstraction Levels. In R. Wieringa & A. Persson (Eds.), 16th Edition Requirements Engineering: Foundation for Software Quality (pp ). Essen, Germany: Springer. doi: / _6 Sikora, E., Tenbergen, B., & Pohl, K. (2011). Requirements Engineering for Embedded Systems: An Investigation of Industry Needs. In D. Berry & X. Franch (Eds.), Lecture Notes in Computer Science: Vol Requirements Engineering: Foundation for Software Quality (pp ). Berlin, Germany: Springer. doi: / _16 Sikora, E., Tenbergen, B., & Pohl, K. (2012). Industry needs and research directions in requirements engineering for embedded systems. Requirements Engineering, 17(1), doi: /s x

17