Context: Software is an important part in safety-critical system (SCS) development since it is becoming a major source of hazards. Requirements-related hazards have been associated with many accidents and safety incidents. Requirements issues tend to be mitigated in companies with high processes maturity levels since they do their business in a systematic, consistent and proactive approach. However, requirements engineers need systematic guidance to consider safety concerns early in the development process. Goal: the paper investigates which safety practices are suitable to be used in the Requirements Engineering (RE) process for SCS and how to design a safety maturity model for this area. Method: we followed the design science methodology to propose Uni-REPM SCS, a safety module for Unified Requirements Engineering Process Maturity Model (Uni-REPM). We also conducted a static validation with two practitioners and nine academic experts to evaluate its coverage, correctness, usefulness, and applicability. Results: The module has seven main processes, fourteen sub-processes and 148 practices that form the basis of safety processes maturity. Moreover, we describe its usage through a tool. Conclusions: The validation indicates a good coverage of practices and well receptivity by the experts. Finally, the module can help companies in evaluating their current practices.

Since its proposal in the nineties, the i* goal modeling proposal has spawned a number of complementary work, including: language extensions, automated reasoning, and transformation to/from i* models. In order to automate their proposals, researchers need to either create a new tool from scratch or to extend an existing tool. In fact, the i* Wiki lists 29 different i* modeling tools. A common approach for creating such tools has been to use the Eclipse tools as a foundation (12 listed tools), which presents complexity issues of its own. The main idea of this work is the creation of an i* modeling tool with low entry barriers for developers wishing to extend it. Our piStar tool can be extended with JavaScript, requiring no specific development tools. Alternatively, developers can adopt their language of choice (such as Java and Python), using piStar models as input either through manually downloading the model file or by sending it for processing through a REST request.

Context: Requirements issues tend to be mitigated in organizations with high process maturity levels since they do their business in a systematic, consistent and proactive approach. In a Safety-Critical System (SCS), requirements problems have been associated with accidents and safety incidents. Objective: This work investigates which safety practices/actions are suitable to be used in the Requirements Engineering (RE) process of SCS and how to design a safety maturity model for this area. Method: we adopted different empirical techniques to propose Uni-REPM SCS, which consists of a safety module to be included in the Unified Requirements Engineering Process Maturity Model (Uni-REPM). Results: The safety module has seven main processes, 14 sub-processes and 148 safety actions describing principles and practices that form the basis of safety processes maturity. Conclusions: Preliminary validation with two practitioners and nine academic experts indicates that the safety module can help organizations to evaluate their current safety practices with respect to their RE process. Moreover, it also offers a step-wise improvement strategy to raise their safety maturity level.

Creating and maintaining visual models is a time-consuming step in software engineering processes. In order to support the creation of some of these models, we have developed the Goal to Architecture tool (GATO). This web tool handles the creation and edition of goal models, as well as the derivation of statecharts. The particular variation of goal modelling supported by this tool contains four views: requirements view, design view, delegation view, and behavioural view.

i* is a goal-oriented and agent-oriented modeling framework that focuses on the analysis of intentional and strategic relationships among actors. In this mini-tutorial, we highlight a number of recent applications in practical industrial and business settings.

Requirements Engineering and Architectural Design are activities of the software development process that are strongly related and intertwined. Thus, providing effective methods of integration between requirements and architecture is an important Software Engineering challenge. In this context, the STREAM process presents a model-driven approach to generate early software architecture models from requirements models. Despite being a systematic derivation approach, STREAM does not support the documentation of architectural decisions and their corresponding rationale. Recent studies in the software architecture community have stressed the need to treat architectural design decisions and their rationale as first class citizens in software architecture specification. In this paper we define an extension of this process, named STREAM-ADD (Strategy for Transition between Requirements and Architectural Models with Architectural Decisions Documentation). This extended process aims to systematize the documentation of architectural decisions by the time they are made and to support the refinement of the architecture according to such decisions. In order to illustrate our approach, it was applied for creating the architecture specification of a route-planning system.

Whilst it is considered a good practice to focus Requirements Engineering on current stakeholder needs, the high costs implied by requirements changes and the emergence of the Autonomic Computing paradigm raised the need for dealing with issues that are not currently requirements but that may come to be in the future. This work shows how foresight techniques can be used for requirements elicitation, and discusses the impacts of studying the future to that requirements engineering activity. In particular, it addresses the use of the Futures Wheel method to enrich goal models.

i* is a framework for goal-oriented requirements modeling. This framework contains an organizational modeling language defined by actors and dependencies among them. Although i* has been widely used, it is still hard to work with it due to its diversity of variants. In this paper, we propose a unified metamodel that presents elements of two well-known variants of i*. We show how OCL restrictions can be applied this metamodel in order to generate a specific variant. In doing so, we intend to unify the efforts of i* community. This metamodel can be useful when developing generic tools for i*, as well as to reason about i* language. Moreover, it makes it easier to extend the i* language. Thus, our proposal is an attempt towards the unification on i* variants by considering similarities and differences among them.

Crosscutting concerns usually affect large portions of requirements models, compromising their modularity and, consequently, their evolution. Models built using the Problem Frames (PF) approach are no exception. PF models can be better modularized by integrating aspect-oriented concepts, as these provide mechanisms to systematically deal with crosscutting model elements. This poster outlines a hybrid approach for integrating aspects and PF, supporting aspects representation through pattern, and modelling composition of aspects. This improves the definition of PF aspectual concepts, as well as their composition process.

Abstract: Problem frames provide an approach to an initial requirements structure which can subsequently help the developer to analyse a problem and to understand its nature. Aspect‐oriented software development offers complementary techniques to handle crosscutting concerns in a systematic and effective way, providing improved support for software maintenance and evolution. This paper explores the integration of aspect concepts with problem frames with the eventual aim of providing a more modular, evolvable requirements structure.

This poster outlines a set of rules to systematically identify crosscutting concerns present in i* models, and modularizing them using aspects. The result is the reduction of the complexity of those models

Understanding and supporting the interaction between software requirements and architectures remains one of the challenging problems in software engineering research. Our aim is to be able to derive architectural models in concert with multi-agent system requirements specifications. In this paper we present an approach to derive multi-agent systems architecture from requirements using social analysis methods. It is based on two complementary models (organisational model and assignment model) that separate the requirements of the social organisation from those of the software system architecture. A process is defined to provide a systematic way to assist the transition from requirements models to an architectural configuration

Objects and agents are abstractions that exhibit Points of similarity, but the development of multi-agent systems (MASs) poses other challenges to Software Engineering since software agents are inherently more complex entities. In addition, a large MAS needs to satisfy multiple stringent requirements such as reliability, trustability, security, interoperability, scalability, reusability, and maintainability. This workshop brings together researchers and practitioners to discuss the current state of the art and the future research directions in software engineering for large-scale MASs. A particular interest is to understand those issues in the agent technology that make it difficult and/or improve the production of complex distributed systems.

In the novel domain of data warehouse systems, software engineers are required to define a solution that integrates with a number of heterogeneous sources to extract, transform and aggregate data, as well as to offer flexibility to run adhoc queries that retrieve analytic information. Moreover, these activities should be performed based on a concise dimensional schema. This intricate process with its particular multidimensionality claims for a requirements engineering approach to aid the precise definition of data warehouse applications. We adapt the traditional requirements engineering process and propose DWARF, a data warehouse requirements definition method. A case study demonstrates how the method has been successfully applied in the company wise development of a large-scale data warehouse system that stores hundreds of gigabytes of strategic data for the Brazilian Federal Revenue Service.

Objects and agents are abstractions that exhibit points of similarity, but the development of agent-based software poses other challenges to software engineering since software agents are inherently more complex entities. In addition, a large-scale multi-agent system needs to satisfy multiple stringent requirements such as reliability, security, interoperability, scalability, reusability, and maintainability. This workshop brought together researchers and practitioners to discuss the current state and future direction of research in software engineering for large-scale multi-agent systems. A particular interest was to understand those issues in the agent technology that difficult and/or improve the production of large-scale distributed systems.

Use cases diagrams in the Unified Modeling Language (UML) have been used for capturing system functional requirements. However, the system development occurs in a context where organizational processes are well established Therefore, we need to capture organizational requirements to define how the system fulfils the organization goals, why it is necessary, what are the possible alternatives, etc. Unfortunately, UML is ill equipped for modeling organizational requirements. We need other techniques, such as i*, to represent these aspects. Nevertheless, organizational requirements must be related to functional requirements represented as Use Cases. In this paper we present some guidelines to assist requirement engineers in the development of Use Cases from the i* organizational models.

In recent years we have observed a growing influence of the object-oriented paradigm. Unfortunately, the current dominant object oriented modeling technique, i.e. the Unified Modeling Language, UML, is ill equipped for modeling early requirements which are typically informal and often focus on stakeholder objectives. Instead, UML is suitable for later phases of requirement capture which usually focus on completeness, consistency, and automated verification of functional requirements for the new system. We present a set of guidelines for the integration of early and late requirements specifications. For early (organizational) modeling we rely on the i* framework, whereas for late (functional) requirements specification, we rely on a precise subset of UML. A small example is used to illustrate how the requirements process iterates between early and late requirements.