Requirements and Scenarios Elicitation
Origin: Eike Möhlmann / OFFIS, Sebastian van der Maelen / OFFIS
Written: May 2019
Purpose: Combined elicitation of requirements and the scenario in which they have to be satisfied.
Context/Pre-Conditions: A (abstract) function architecture of the system under test has to be provided in order to derive function requirements. These functional requirements will be refined into safety and security requirements and combined with a scenario catalog suitable for testing the requirements.
To consider: The process has to be iterated until a consistent and complete set of requirements and a representative scenario catalog has been derived.
Participants and Important Artefacts
Functional Requirements DB: A set of functional requirements for the SUT.
Real World Data DB: A set or catalog of recorded/measured data which have been reconstructed from real world data by observing the deployment context of the SUT.
Abstract Scenarios DB: A set or catalog of abstract scenarios in which the requirements have to be satisfied.
Representativeness measure / Confidence in the coverage: Estimated probability that a (random) real world data point can be represented with an abstract scenario and vice versa. This estimate is valid up to a known confidence. As the recorded data is used as a proxy for the real world, the estimated probability measures the likelihood relative to this recording process.
Abstract Scenarios Mining: (see sub-pattern). Mining of abstract scenarios covering the deployment context of the SUT.
(Requirement) Consistency and Completeness Analysis: Check whether the set of requirements is (a) complete wrt the functional requirements in all scenarios and (b) consistent, i.e., not contradictory.
Representativeness Checking: (see sub-pattern). Check whether the abstract operational scenarios are representative for the real world scenarios for the derived set of requirements.
Benefits: Once a scenario catalog and criticality indicators have been shown to be sufficiently representative for a set of requirements, the set of scenarios can be re-used for a continuous design/development process together with a (semi-)virtual verification and validation.
– As the representativeness checking favors hypothesis-testing the result is influenced by parameters characterizing the statistical power of the tests (sensitivity, significance).
– The quality of the scenario catalog and the completeness of the requirements are relative to the quality of the recorded data.
ENABLE-S3 Use Case 2 “Intersection Crossing”, ENABLE-S3 Use Case 6 “Valet Parking”: this pattern is used for derivation of a set of requirements, a deployment context, and a scenario catalog suitable for testing a SUT to satisfy the requirements in the deployment context.
Relations to other Patterns
|Scenario-based V&V Process||This pattern is sub-pattern of the Scenario-based V&V Process Pattern|
|Abstract Scenarios Mining||Abstract Scenarios Mining finds scenarios from deployment context|
|Scenario-based Safety and Security Analysis||That sub-pattern elaborates the requirements which are, together with scenarios, elicitated here|
|Scenario Representativeness Checking||That sub-pattern evaluates scenarios and requirements coverage|
* “this pattern” denotes the pattern described here, “that pattern” denotes the related pattern