1 VARIES Global Requirements and future outlook
This text collects input from WP2 deliverables [D2.2], [D2.3] and [D2.4] and has been adapted for publication in the framework of the CoIE.
1.1 The purpose and scope of requirements work in VARIES
Requirements engineering comprises a series of processes to gather the requirements that define a given artefact, a requirement being a singular documented physical and functional need that a particular design, product or process must be able to perform. It is most commonly used in a formal sense in systems engineering, software engineering, or enterprise engineering. It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.
From the inception of VARIES project, the definition of what we do globally has been elusive, thus we felt the need of devising a thorough process to try and elicit the requirements that was based on the following principles:
- Requirements would be derived from a multidimensional analysis including (a) demonstrator requirements as the most concrete and focused, (b) partners’ own perception of VARIES-wide requirements, gathered from a questionnaire or directly and (c) a questionnaire prepared by experts in the field to get the partners’ implicit feedback that may be different to what they report explicitly.
- Multi-staged development of the requirements, with an early collection of the first demonstrator requirements followed by three iterations of Global Requirements that collected a more comprehensive overview of the process.
- An understanding that producing requirements for such a moving target as variability management would be, at best, always imperfect, incomplete and subject to change. This is especially true when compared to requirements for concrete, marketable products.
This final outlook for the CoIE is expected to be not the last but a new stage in the collective understanding of this. Here we will summarize the followed procedure to gather the requirements, expand on the motivations for this strategy and present the final incarnation of the requirements for the use of the CoIE stakeholders.
1.2 The collection of the Global Requirements
Since the beginning of the work in VARIES, we detected that requirement management and understanding by the rest of the stakeholders in the consortium and beyond is far from a trivial task. It is often daunting to deal with the large list of requirements and it is clear that a structured approach is indeed helpful for dealing with the requirements. Thus, in the work in requirements we have searched not only for the requirements themselves (be them partner specific, demonstrator or ultimately global ones) but also for different strategies to deal with this complexity. This translated to some particular strategies to elicit, analyse and document them.
In Figure 1 below, we can see a bird’s eye view of the different stages that we have followed and how they apply to the requirements for each of the three iterations in VARIES:
As it can be seen from Figure 1 the process started with the gathering of the first set of demonstration requirements, which was documented in [D2.1]. This was just a preliminary data gathering step and no effort was undertaken to analyse the requirements. Note that, at the start of the first iteration the understanding of variability of the demonstrator partners still had to grow and therefore the requirements were often set on the selected use cases technical aspects instead of on the variability that did arise from the use cases. After this, in [D2.2] an analysis was performed to extract the implicit categories in this list of requirements. This was done using well known methods of data architecture analysis (card sorting followed by creating affinity diagrams) and the result of this was the VARIES requirement taxonomy. This was used to classify a first set of global requirements that were extracted from that same data set of demonstration requirements from experts in the consortium.
From this first vision of our global requirements, it was decided that traceability of our process was essential and thus measures were undertaken to uniquely identify the requirements and subsequently follow a process that kept the relationship between these identified artefacts clear. It was in this first stage as well that a pressing need for a common glossary of terms used in this work was detected and a task force to build it was produced in VARIES to tackle the task.
During the second iteration, an analysis of the updated demonstrator requirements was performed to get insight on the refined needs of demonstrators following the developments during the first iteration and the extended partner understanding of the VARIES project. It was detected that in addition to the classification of the requirements following the complex regular taxonomy, a simplified three core categories was useful to focus the demonstration requirements. Namely, the categories chosen were Tools, Methods and Processes with an auxiliary category Demonstrator Specific for those requirements that were very much domain-specific to the associated demonstrator. It is important to note that these categories were not mutually exclusive: some requirements could be under two or more of them. Thus, the 2nd iteration demonstration requirements were classified and delivered under this formalism.
For the requirement analysis work in iteration 3 described in [D2.4], it was decided to continue with a similar format. Now, in addition to the main categories described above, demonstrator owners were asked to further classify requirements on being safety-critical or not due to increased emphasis on this aspect asked for by the project management. The third iteration also tried to identify aspects that could not be finished in time for the closing of the activities and thus would be used as inputs for future research, such as this CoIE work.
In the following sections we present the final Global Requirements of VARIES and the summarized overview of unfulfilled topics that would require additional investigation post VARIES conclusion.
2 VARIES Global Requirements
In this subsection we summarise the global requirements that are related to tools in VARIES. These requirements are a refined version from the global requirements found in [D2.3]. In the current document we will further revise them using the updates given by the demonstrator owners, to produce the third iteration tool requirements. They have also been updated based on the revisions by WP5 as part of the work produced for deliverable [Error! Reference source not found.].
The subtitles of this section follow the 1st iteration taxonomy described in deliverable [D2.2].
2.1 Global Tool – Related Requirements
These requirements collected below define the ones that outline the needs from the tools in the project VARIES. This is to be understood as requirements for a purported ‘Global Tool’. A number of concrete tools are available and some were produced or refined during the project according to at least some of these requirements and thus represent a first step towards a more integrated tool set for variability.
|Name||ID#||Description||Category in the taxonomy|
|Global-1||VARIES.Req.1||The VARIES platform must support different roles for stakeholders.||Tool → Work Flow|
|Global-2||VARIES.Req.2.||The VARIES platform must support different functionality for each of the stakeholders.||Tool → Work Flow|
|Global-3||VARIES.Req.3.||The VARIES platform must support the definition of different stages of the work flow.||Tool → Work Flow|
|Global-6||VARIES.Req.6.||The VARIES platform must support the versioning of artefacts.||Tool → Work Flow → Versioning|
|Global-7||VARIES.Req.7.||The VARIES versioning for artefacts should support the used software versioning patterns in the industry.||Tool → Work Flow → Versioning|
|Global-8||VARIES.Req.8.||The architecture of the VARIES platform must be defined in modular fashion.||Tool → Architecture|
|Global-10||VARIES.Req.10.||The VARIES platform should support artefact re-use across different product domains.||Tool → Architecture → Extensibility|
|Global-11||VARIES.Req.11.||The architecture of the VARIES platform must support module extensibility.||Tool → Architecture → Extensibility|
|Global-12||VARIES.Req.12.||The VARIES platform must support data formats and methodologies to support interoperability with external systems using existing industry standards where possible.||Tools → Data Formats and Interoperability|
|Global-13||VARIES.Req.13.||The VARIES platform should support the export of artefacts using existing industry standard formats such as XML.||Tools → Data Formats and Interoperability|
|Global-14||VARIES.Req.14.||The VARIES platform should support multiple types of artefacts.||Tools → Data Formats and Interoperability|
|Global-15||VARIES.Req.15.||The VARIES platform should be able to exchange information and data with third party tools.||Tools → Data Formats and Interoperability|
|Global-16||VARIES.Req.16.||The VARIES software artefacts must be deployable in Microsoft Windows (XP and later), Ubuntu Linux (12.04 LTE and later) and Embedded Linux (uClinux)||Tools → Deployment|
|Global-18||VARIES.Req.18.||The VARIES platform should provide support for testing of artefacts at several levels of abstraction.||Tools → Testing|
|Global-20||VARIES.Req.20.||The VARIES platform should be able to test artefacts against different product releases.||Tools → Testing|
|Global-21||VARIES.Req.21.||The VARIES platform should provide support for data integrity.||Tools → Security|
|Global-23||VARIES.Req.23.||The VARIES platform must model the production of the description of variants using configuration of artefacts.||Tools → Configuration|
|Global-24||VARIES.Req.24.||The VARIES platform should integrate variability management tools across different stages of a products’ lifecycle.||Tools → Configuration|
|Global-27||VARIES.Req.27.||The VARIES platform should support impact analysis of product updates.||Tools → Configuration|
|Global-29||VARIES.Req.29.||The VARIES platform must support Variation Points, Variants, Artefact Dependencies and Variant Constraints.||Tools → Modelling|
|Global-31||VARIES.Req.31.||The VARIES platform must support links between Requirements, Variation Points, Blocks, Classes and other relevant modelling items to model product families and product instances.||Tools → Modelling|
|Global-32||VARIES.Req.32.||The VARIES platform must support variant selection based on Variation Points and Variant Constraints.||Tools → Modelling|
|Global-33||VARIES.Req.33.||The VARIES platform must support the modelling languages CVL and OVM.||Tools → Modelling|
|Global-34||VARIES.Req.34.||The VARIES platform must support traceability between artefacts.||Tools → Traceabiliy|
|Global-35||VARIES.Req.35.||The VARIES platform must support different binding times (e.g. design-time, deploy time and at run-time).||Tools → Binding time|
|Global-36||VARIES.Req.36.||The VARIES platform must supply metrics able to detect code duplication and code divergence.||Tools → Code Variability|
|Global-40||VARIES.Req.40.||The VARIES platform must support the specification of market and legal constraints.||Tools → Business|
|Global-41||VARIES.Req.41.||The VARIES platform must support metrics for cost estimation of producing variants and artefacts.||Tools → Business|
|Global-42||VARIES.Req.42.||The VARIES platform must model product lines and the operation upon them.||Tools → Business|
|Global-43||VARIES.Req.43.||The VARIES platform must support the specification of legal constraints.||Tools → Business|
In this subsection we will present the final collected global requirements that are related to process in VARIES. The process requirements presented in this section indicate requirements for product development process in order to support variability of the product. These requirements are based on [D2.3] requirements and have been updated based on updates to demonstrator requirements. These requirements are additional to standard product development process requirements / activities.
|Name||ID#||Description||Category in the taxonomy|
|Global-5||VARIES.Req.5.||The process must identify key decision points in which variability management can be introduced||Process → General|
|Global-9||VARIES.Req.9.||The process must be tool-independent.||Process → General|
|Global-39||VARIES.Req.39.||The process must provide support for certifying artefacts.||Process → General|
|Global-44||VARIES.Req.44.||The process must define the roles and responsibilities.||Process → General|
|Global-45||VARIES.Req.45.||The process must clearly define different stages and transition between the stages.||Process → General|
|Global-46||VARIES.Req.46.||The process must have clearly defined terms under a common vocabulary||Process → General|
|Global-47||VARIES.Req.47.||The process must support product lines and the operation upon them.||Process → General|
|Global-48||VARIES.Req.48.||The process should incorporate considering market constraints.||Process → General|
|Global-49||VARIES.Req.49.||The process should be cost effective.||Process → General|
|Global-50||VARIES.Req.50.||The process must allow for its extensibility to accommodate future improvements.||Process → General|
|Global-51||VARIES.Req.51.||The process should be reactive to changes, e.g., in technology, standards, markets etc.||Process → General|
|Global-52||VARIES.Req.52.||The process should cope with organisational structure (e.g., barriers between departments)||Process → General|
|Global-53||VARIES.Req.53.||The process should ensure availability of relevant skills relating to developing and maintaining variability||Process → General|
|Global-54||VARIES.Req.54.||The process should encourage use of standards||Process → General|
|Global-55||VARIES.Req.55.||The process should allow various product delivery models||Process → General|
|Global-56||VARIES.Req.56.||The process should support use of external components||Process → General|
|Global-57||VARIES.Req.57.||The process should support maximizing reuse, including maintaining reusable assets variants||Process → General|
|Global-58||VARIES.Req.58.||The process should support handling product variability in requirements engineering phase||Process → Engineering|
|Global-59||VARIES.Req.59.||The process must enforce defining architecture in modular fashion.||Process → Engineering|
|Global-60||VARIES.Req.60.||The process should allow module reusability to support different configurations.||Process → Engineering|
|Global-61||VARIES.Req.61.||The process should incorporate testing at several levels of abstraction (module, product, variant, project).||Process → Engineering|
|Global-62||VARIES.Req.62.||The process should support testing variability and variants, including combinatorial testing of configuration options.||Process → Engineering|
|Global-64||VARIES.Req.64.||The process should support validation and testing modules across/against different product releases.||Process → Engineering|
|Global-65||VARIES.Req.65.||The process should include test specifications variant management||Process → Engineering|
|Global-80||VARIES.Req.80.||The process should include modelling of variants in specification and testing phases.||Process → Engineering|
|Global-66||VARIES.Req.66.||The process must ensure and support versioning of all of artefacts using common software versioning patterns in the industry.||Process → Support|
|Global-67||VARIES.Req.67.||The VARIES configuration tools must be connected to the different stages in the products’ lifecycle.||Process → Support|
|Global-68||VARIES.Req.68.||The process should support tracing dependencies between the variability requirements, implementing artefacts, test cases and variants.||Process → Support|
|Global-69||VARIES.Req.69.||The process should support maintenance of variants in delivered products (incl. defect management)||Process → Support|
|Global-70||VARIES.Req.70.||The process should support long maintenance time||Process → Support|
|Global-71||VARIES.Req.71.||The process should incorporate transparency of variability decisions, including documentation.||Process → Support|
|Global-72||VARIES.Req.72.||The process should enable handling safety variability||Process → Support|
|Global-73||VARIES.Req.73.||The process should incorporate variability requirements maintenance.||Process → Support|
|Global-74||VARIES.Req.74.||The process should cover variability management throughout the development||Process → Support|
Finally, in this subsection we will examine the global requirements that are related to methods in VARIES.
|Name||ID#||Description||Category in the taxonomy|
|Global-75||VARIES.Req.75.||The modeling language used must be able to express topological variability – to model structure and architecture of systems.||Methods|
|Global-76||VARIES.Req.76.||The modeling of topologies must be able to handle hierarchical nesting.||Methods|
|Global-77||VARIES.Req.77.||The modeling language has to be able to handle constraints between the topological elements in the models to for example define dependencies between optional elements, or market segments and environment conditions.||Methods|
|Global-78||VARIES.Req.78.||It must be possible to integrate VARIES tools and methods into frameworks, tools and processes used by VARIES partners (so tools and methods must be open towards integration).||Methods|
|Global-79||VARIES.Req.79.||The VARIES framework must be able to trace dependencies between the variability requirements, and other software development artifacts (in specific all [SysML] artefacts (requirements, use cases, activities, interfaces, constraints …), including traceability between requirements themselves.||Methods|
3 Open questions and future research lines for the CoIE
This document has presented the ‘formal’ output of requirements engineering in VARIES. However, during the course of the work some of the findings have not yet been fully explored due to limitations in resources and scope for a research project such as VARIES. In this section, we provide a preliminary list of open research challenges found in our study on variability requirements that seem to be worth of more attention in future activities such as the ones organized for the CoIE.
This preliminary list of open issues is expected to be further worked over in the future activities of VARIES. As of the writing of this document at the formal end of VARIES, this includes the following items:
- The requirement work in VARIES has been driven largely by the demonstrator requirements. The demonstrators in the project include 9 demonstrators for 5 different domains which include some of the most relevant fields of activity in embedded systems (automotive, safety applications, health systems, industrial automation and telecommunications). The final global requirements derive from the needs of these so we are confident they are comprehensive in these domains. However, other relevant domains (e.g., aerospace applications) are not addressed in VARIES.
Research challenge #1: Prove that the global requirements are valid for domains outside the scope of VARIES and expand the requirement base if needed.
- Related to the challenge #1, the taxonomy of requirements that we have used is tightly tied to our inputs and therefore limited by the scope of the project. In addition, it can be argued that since the taxonomy was extracted from the requirements in the first place and then applied to further rounds of requirement elicitation and analysis, there is a recursiveness issue involved. Thus, it remains to be studied if other sources of information can be used to complete the taxonomy.
Research challenge #2: reassess the taxonomy of requirements formulated in [D2.2] and study further methods of expanding it not based on the domain-specific requirements and individual partner expertise.
- The requirements are formulated as natural language and using related expression methodologies such as the MoSCoW definitions (Must Have, Should, Could, Won’t). This makes for an easy elicitation of requirements by the different writers in the project. However, the expression of the requirements in this way offers few opportunities for analysis other than the human-based. By providing a more formal grounding for these, such as for example an SysML or RDF/OWL ontology (semantic description of the concepts and relationships) could be used to express the requirements as a body of rules or statements that could be then machine-analysed for example by logic reasoning. This could have applications for tools that derived new requirements automatically or detected constraint violations.
Research challenge #3: formulate the requirements using a formal model that can be leveraged automatically by machines such as reasoners or machine learning algorithms.
- The variability questionnaire, which was introduced in  and whose results were discussed in [D2.3], provided a good source of information that was more general (company-specific) that the demonstration requirements and produced some new global requirements and refinements to some of the existing ones. To get these results, the questionnaire was circulated among the VARIES participants. However, it can be expected that a wider distribution of this and similar requirements on a larger scale can provide a better understanding of the realities of variability management in companies beyond VARIES.
Research challenge #4: distribute the VARIES questionnaire (or refined versions) in a wider audience and collect more results to improve the requirements.
The core members of the requirements team who participate in the CoIE will now begin a process of collaboration with the rest of VARIES partners and other participants in the work in order to expand these initial requirements for the project and hopefully find new areas of research challenges to be studied in the closing activities of VARIES and beyond through the CoIE. These will be documented in future CoIE releases.
|D2.1||ARTEMIS Call 2011, ARTEMIS-2011-1, 295397 VARIES: VARiability In safety-critical Embedded Systems. Deliverable D2.1: Initial demonstrator requirements & evaluation criteria.|
|D2.2||ARTEMIS Call 2011, ARTEMIS-2011-1, 295397 VARIES: VARiability In safety-critical Embedded Systems. Deliverable D2.2: Global requirements.|
|D2.3||ARTEMIS Call 2011, ARTEMIS-2011-1, 295397 VARIES: VARiability In safety-critical Embedded Systems. Deliverable D2.3: Updated demonstrator requirements, global requirements & evaluation criteria.|
|D2.4||ARTEMIS Call 2011, ARTEMIS-2011-1, 295397 VARIES: VARiability In safety-critical Embedded Systems. Deliverable D2.4: Final demonstrator requirements, global requirements & evaluation criteria.|
|D5.1||ARTEMIS Call 2011, ARTEMIS-2011-1, 295397 VARIES: VARiability In safety-critical Embedded Systems. Deliverable D5.1: Identification of State of the Art & Requirements|
|VARIES-TA||ARTEMIS Call 2011, ARTEMIS-2011-1, 295397 VARIES: VARiability In safety-critical Embedded Systems. Technical Annex.|