1. Steffen Bjerkenås Method Engineering 10.04.2013

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

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

4. 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. 5 Main steps

6. 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 1994 1997 1998 1999

7. 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 2003 2010 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) 2011 2012

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

11. 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. 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. 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. 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. 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. 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. 33-42). Shanghai, China: Association for Computing Machinery. doi: 10.1145/1134285.1134292 Grimm, K. (2003). Software technology in an automotive company: major challenges. 25th International Conference on Software Engineering - ICSE (pp. 498-503). Washington, USA: IEEE Computer Society. doi: 10.1109/ICSE.2003.1201228 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), 202-218. doi: 10.1007/s007660050005 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. 58-65). Limerick, Ireland: IEEE Computer Society. doi: 10.1109/ISRE.1999.777985 Potts, C., Takahashi, K., & Antón, A. I. (1994). Inquiry-Based Requirement Analysis. Software - IEEE Software, 11(2), 21-32. doi: 10.1109/52.268952 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. 205-222). 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. 45-59). Essen, Germany: Springer. doi: 10.1007/978-3-642-14192-8_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. 6606. Requirements Engineering: Foundation for Software Quality (pp. 151-165). Berlin, Germany: Springer. doi: 10.1007/978-3-642-19858-8_16 Sikora, E., Tenbergen, B., & Pohl, K. (2012). Industry needs and research directions in requirements engineering for embedded systems. Requirements Engineering, 17(1), 57-78. doi: 10.1007/s00766-011-0144-x

17. 17