Requirements elicitation has since long been recognized as critical to the success of requirements engineering, hence also to the success of systems engineering. Achieving sufficient scope and quality in the requirements elicitation process poses a great challenge, given the limited slices of budget and time available for this relatively sizeable activity. Among all predominant requirements elicitation techniques and approaches, operational scenarios development has a special standing and character. The set of operational scenarios is acknowledged as a constituent deliverable in the requirements engineering process, serving many purposes. Hence, ensuring success in the development of operational scenarios constitutes a consequential area of research. In this paper we present the results from an industrial survey on experienced and presumptive success factors in the development of operational scenarios. The survey was done using a strength-based approach, involving engineers and managers in two organizations developing cyber-physical systems in the transportation and construction equipment businesses. Our results suggest that operational scenarios reusability and a collaborative operational scenarios development environment are two prime areas for success. Our study provides two contributions. First, we provide an account of success factors in the view of practitioners. This is fundamental knowledge, since a successful deployment of any state-of-the-art approach and technology in a systems engineering organization needs to take the views of the practitioners into consideration. Second, the study adds input to the body of knowledge on requirements elicitation, and can thereby help generate suggestions on direction for future work by researchers and developers.

This article describes the architecture life cycle effect analysis (ALCEA) method, a structured method for evaluating proposed new architectures for software-intensive systems. The method evaluates a proposed architecture by quantifying its effect on the performance of system life-cycle phases. The method is instantiated by identifying the relevant life-cycle phases of the system under investigation and a set of evaluation functions that capture, in terms of basic factors, the effect of different architectural decisions on key life-cycle PAs, such as revenue, operating resources, and investments. The method results in a transparent cost and revenue structure, documented in a tabular form, based on quantifiable factors from the developing organization. The results of the method can be used directly as part of a business case, and their robustness can be estimated by sensitivity analysis. The ALCEA method is designed for system-level architectural analysis, covering both software and hardware aspects. In this article, we introduce the ALCEA method and provide a detailed example of how to apply it in the evolution of embedded systems. Moreover, we share early experiences of using the method in large-scale industrial settings.

The author of this article explores the question, what is human trafficking. In order to answer this question, definitions of human trafficking are examined, as well as the causes, types of trafficking, recruitment strategies, and the significant problems in conquering human trafficking internationally. Trafficking in human beings affects all regions and most countries of the world. According to official data, Bosnia and Herzegovina is a transit country, but certain reports indicate that it is becoming a country of origin and destination. In order to exemplify the issue of human trafficking on the concrete case study, there is further exploration of how the law of Bosnia and Herzegovina defines it, and how approachs to this problem. Taking into account the increase of human trafficking in the world, especially among countries in transition, it is extremely important to find effective solutions for the prevention of such cross-border criminal activity.

Model-based product line engineering applies the reuse practices from product line engineering with graphical modeling for the specification of software intensive systems. Variability is usually described in separate variability models, while the implementation of the variable systems is specified in system models that use modeling languages such as SysML. Most of the SysML modeling tools with variability support, implement the annotation-based modeling approach. Annotated product line models tend to be error-prone since the modeler implicitly describes every possible variant in a single system model. To identifying variability-related inconsistencies, in this paper, we firstly define restrictions on the use of SysML for annotative modeling in order to avoid situations where resulting instances of the annotated model may contain ambiguous model constructs. Secondly, inter-feature constraints are extracted from the annotated model, based on relations between elements that are annotated with features. By analyzing the constraints, we can identify if the combined variability- and system model can result in incorrect or ambiguous instances. The evaluation of our prototype implementation shows the potential of our approach by identifying inconsistencies in the product line model of our industrial partner which went undetected through several iterations of the model.

Model-based product line engineering applies the reuse practices from product line engineering with graphical modeling for the specification of software intensive systems. Variability is usually described in separate variability models, while the implementation of the variable systems is specified in system models that use modeling languages such as SysML. Most of the SysML modeling tools with variability support, implement the annotation-based modeling approach. Annotated product line models tend to be error-prone since the modeler implicitly describes every possible variant in a single system model. To identifying variability-related inconsistencies, in this paper, we firstly define restrictions on the use of SysML for annotative modeling in order to avoid situations where resulting instances of the annotated model may contain ambiguous model constructs. Secondly, inter-feature constraints are extracted from the annotated model, based on relations between elements that are annotated with features. By analyzing the constraints, we can identify if the combined variability- and system model can result in incorrect or ambiguous instances. The evaluation of our prototype implementation shows the potential of our approach by identifying inconsistencies in the product line model of our industrial partner which went undetected through several iterations of the model.

Software-intensive systems in the automotive domain are often built in different variants, notably in order to support different market segments and legislation regions. Model-based concepts are frequently applied to manage complexity in such variable systems. However, the considered approaches are often focused on single-product development. In order to support variable products in a model-based systems engineering environment, we describe a tool-supported approach that allows us to annotate SysML models with variability data. Such variability information is exchanged between the system modeling tool and variability management tools through the Variability Exchange Language. The contribution of the paper includes the introduction of the model-based product line engineering tool chain and its application on a practical case study at Volvo Construction Equipment. Initial results suggest an improved efficiency in developing such a variable system.