Date post: | 15-Dec-2015 |
Category: |
Documents |
Upload: | bryson-sollinger |
View: | 245 times |
Download: | 0 times |
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?
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
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