No abstract

Artefacts play a vital role in software and systems development processes. Other terms like documents, deliverables, or work products are widely used in software development communities instead of the term artefact. In the following, we use the term 'artefact' including all these other terms. Despite its relevance, the exact denotation of the term 'artefact' is still not clear due to a variety of different understandings of the term and to a careless negligent usage. This often leads to approaches being grounded in a fuzzy, unclear understanding of the essential concepts involved. In fact, there does not exist a common terminology. Therefore, it is our goal that the term artefact be standardised so that researchers and practitioners have a common understanding for discussions and contributions. In this position paper, we provide a positioning and critical re-

Background] Requirements Engineering is crucial for project success, and to this end, many measures for quality assurance of the software requirements specification (SRS) have been proposed.[Goal] However, we still need an empirical understanding on the extent to which SRS are created and used in practice, as well as the degree to which the quality of an SRS matters to subsequent development activities.[Method] We studied the relevance of SRS by relying on survey research and explored the impact of quality defects in SRS by relying on a controlled experiment.[Results] Our results suggest that the relevance of SRS quality depends both on particular project characteristics and what is considered as a quality defect; for instance, the domain of safety critical systems seems to motivate for an intense usage of SRS as a means for communication whereas defects hampering the pragmatic quality do not seem to be as relevant as initially thought.[Conclusion] Efficient and effective quality assurance measures must be specific for carefully characterized contexts and carefully select defect classes.

No abstract

To facilitate engineering and evolution of automation systems, ensuring the correctness of the design models is an important topic. Industrial automation systems are composed of various heterogeneous elements designed by different disciplines such as mechanical, electrical/electronic and software engineering. In this contribution, an approach for modeling industrial automation systems is presented which is based on interface behavior modeling of design artifacts and which supports automatic verification of their functional conformance while considering information from various disciplines.

No abstract

No abstract

Modeling complex mechatronic systems containing parts such as mechanics, electronics and software is a major challenge for the engineering of automation production systems. As a result, many modeling languages as well as tools (e.g. petri nets or MATLAB/Simulink) and verification approaches (e.g. testing, simulation or formal verification) that focus on special challenges to model the mechatronic system correctly have already been developed. However, a holistic approach combining the strengths of the individual approaches adapted for the engineering of automation production systems has not yet been developed. In this paper we consider the combination of simulation with MATLAB/Simulink and a discrete event simulation model allowing model checking of specific constraints. Hence, the strengths of both approaches' formal verification, i.e. to identify not only faults but also correctness of a system, and simulation, i.e. showing the exact time behavior of the system, can be combined. A key challenge of our approach is to identify an appropriate level of abstraction of both models. The evaluation of the presented approach is introduced by modeling the throughput of a simple automation production system.