Steffen BjerkenåsMethod Engineering

10.04.2013

Supporting the Consistent Specification of Scenarios across Multiple

Abstraction Levels (Sikora, Daun, & Pohl, 2010)

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

Topic

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

Topic

Supporting the Consistent Specification of Scenarios across Multiple Abstraction Levels (Sikora et al., 2010)

Why is this interesting?

4

Headlight (system)

Requirements:(...)

Component 1

Requirements:(...)

Component 2

Requirements:(...)

Component 3

Requirements:(...)

System-level scenarios

Component-level scenarios

Incosistencies?

Topic

5

Main steps

Related Literature

6

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

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

1994 1997 1998 1999

Related Literature

7

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

2003 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)

2011 2012

Related literature

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)

Process-deliverable Diagram

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

Process-deliverable Diagram

10

Example

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

Example

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

Example

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

Example

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

Example

15

Step 4: Detect incosistencies between system-level and component-level automata

Detected inconsistencies

Project-specific inconsistency rules dictates to what degree the detected inconsistenciesimpacts the development process

References

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