Iterative and Scenario-based Requirements Specification in a System of Systems Context

Wiecher, Carsten; Greenyer, Joel; Wolff, Carsten; Anacker, Harald; Dumitrescu, Roman

doi:10.48550/arxiv.2102.05400

Cited by 2 publications

(8 citation statements)

References 25 publications

(45 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Following the specification method we proposed in [11], we can intuitively model the SoS behavior on different levels of abstraction. Therefor, in a first step, we define the required CSs and the messages that these systems exchange (see Listing 1).…”

Section: Scenario-based Requirements Modelingmentioning

confidence: 99%

“…Therefor, in a first step, we define the required CSs and the messages that these systems exchange (see Listing 1). In a second step, we refine the internal CS behavior by separate scenario specifications [11].…”

Section: Scenario-based Requirements Modelingmentioning

confidence: 99%

“…Subsequently we create separate scenario specifications to model the internal behavior of selected CSs (see. [11]).…”

Section: Definition Of Systems and Their Interactionmentioning

confidence: 99%

“…Now we can assume that the smartphone app and the energy information service are existing systems that should be integrated with an electric vehicle under development. In this case, it is also necessary to identify the components of the electric vehicle that are involved in the desired SoS functionality, which can be done in a separate scenario specification that details the internal behavior of a CS [11].…”

Section: Definition Of Systems and Their Interactionmentioning

confidence: 99%

“…As introduced in previous work [8]- [10], we show how to specify stakeholder expectations in a comprehensive and structured form using feature files and usage scenarios. Based on this feature specification, we use a test-driven specification approach [8] to iteratively model the intended SoS behavior in form of a scenario specification [11]. By creating, executing and testing the scenario specification, we are able to refine the initial feature specification.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Selecting Features for the Next Release in a System of Systems Context

Wiecher¹,

Wolff²,

Anacker³

et al. 2021

Preprint

Self Cite

View full text Add to dashboard Cite

Smart Cities are developing in parallel with the global trend towards urbanization. The ultimate goal of Smart City projects is to deliver a positive impact for the citizens and the socio-economic and ecological environment. This involves the challenge to derive concrete requirements for (technical) projects from overarching concepts like Quality of Life (QoL) and Subjective Well-Being (SWB). Linking long-term, impact oriented goals with project outputs and outcomes is a complex problem. Decision making on requirements and resulting features of single Smart City projects (or systems) is even more complex since cities are not like monolithic, hierarchical and wellstructured systems. Nevertheless, systems engineering provides concepts which support decision making in such situations. Complex socio-technical systems such as smart cities can be characterized as systems of systems (SoS). A SoS is composed of independently developed systems that nevertheless provide a higher-level integrated functionality. To add new functionality to a SoS, either existing systems must be extended or new systems must be developed and integrated. In both cases, the extension of functionality is usually done in small increments and structured via software releases. However, the decision which features to include in the next release is complex and difficult to manage when done manually. To address this, we make use of the multiobjective next release problem (MONRP) to search for an optimal set of features for a software release in a SoS context. In order to refine the search in an early planning phase, we propose a technique to model and validate the features using the scenario modeling language for Kotlin (SMLK). This is demonstrated with a proof-of-concept implementation.

show abstract

Section: Scenario-based Requirements Modelingmentioning

confidence: 99%

Section: Scenario-based Requirements Modelingmentioning

confidence: 99%

“…Subsequently we create separate scenario specifications to model the internal behavior of selected CSs (see. [11]).…”

Section: Definition Of Systems and Their Interactionmentioning

confidence: 99%

Section: Definition Of Systems and Their Interactionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Selecting Features for the Next Release in a System of Systems Context

Wiecher¹,

Wolff²,

Anacker³

et al. 2021

Preprint

Self Cite

View full text Add to dashboard Cite

show abstract

Integrated and Iterative Requirements Analysis and Test Specification: A Case Study at Kostal

Wiecher¹,

Fischbach²,

Greenyer³

et al. 2021

Preprint

Self Cite

View full text Add to dashboard Cite

Currently, practitioners follow a top-down approach in automotive development projects. However, recent studies have shown that this top-down approach is not suitable for the implementation and testing of modern automotive systems. Specifically, practitioners increasingly fail to specify requirements and tests for systems with complex component interactions (e.g., e-mobility systems). In this paper, we address this research gap and propose an integrated and iterative scenario-based technique for the specification of requirements and test scenarios. Our idea is to combine both a top-down and a bottom-up integration strategy. For the top-down approach, we use a behavior-driven development (BDD) technique to drive the modeling of high-level system interactions from the user's perspective. For the bottomup approach, we discovered that natural language processing (NLP) techniques are suited to make textual specifications of existing components accessible to our technique. To integrate both directions, we support the joint execution and automated analysis of system-level interactions and component-level behavior. We demonstrate the feasibility of our approach by conducting a case study at Kostal (Tier1 supplier). The case study corroborates, among other things, that our approach supports practitioners in improving requirements and test specifications for integrated system behavior.

show abstract

Iterative and Scenario-based Requirements Specification in a System of Systems Context

Cited by 2 publications

References 25 publications

Selecting Features for the Next Release in a System of Systems Context

Selecting Features for the Next Release in a System of Systems Context

Integrated and Iterative Requirements Analysis and Test Specification: A Case Study at Kostal

Contact Info

Product

Resources

About