Since its proposal in the nineties, i* goal modeling has spawned a number of complementary work, including: language extensions, automated reasoning, and transformation to/from models. In order to automate their proposals, researchers need either create new tool from scratch or extend an existing tool. fact, Wiki lists 29 different tools. A common approach for creating such tools been use Eclipse as foundation (12 listed tools), which presents complexity issues own. The main idea this work...

The growing interest in adaptive software systems has resulted a number of different proposals for the design systems. Some approaches adopt architectural models, whereas others model adaptation options, at level requirements. This dichotomy motivated us to perform comparative study between two systems: Rainbow Framework (architecture-based) and our own proposal, Zanshin (requirements-based). evaluation paper reports on methodology results. It also provides comparison use requirements models...

Creating and reasoning with goal models is useful for capturing, understanding, communicating about requirements in the early stages of information system (re)development. However, utility greatly enhanced when an awareness intentions can feed into other analysis process (e.g. elaboration, validation, planning), be used as part entire life cycle (e.g., architecture, design, coding, testing, monitoring, adaptation, evolution). In order to understand progress that has been made integrating...

Service-based systems need to provide flexibility adapt both evolving requirements from multiple, often conflicting, ephemeral and unknown stakeholders, as well changes in the runtime behavior of their component services. Goal-oriented models allow representing system whilst keeping information about alternatives. We present MAESoS approach which uses i* diagrams identify quality service over The alternatives are extracted kept a variability model. A monitoring infrastructure identifies that...

Business processes can be performed in different ways according to the characteristics of organizational environment where they are placed. Representing and configuring business variability for a specific organization allows appropriate execution processes. However, selecting configuration process is challenging activity. Even though current approaches allow representation models, selection variants given context difficult issue. In this paper we advocate use Non-Functional Requirements...

The growing interest in adaptive software systems has resulted a number of different proposals for the design systems. Some approaches adopt architectural models, whereas others model adaptation options, at level requirements. This dichotomy motivated us to perform comparative study between two systems: Rainbow Framework (architecture-based) and our own proposal, Zanshin (requirements-based). evaluation paper reports on methodology results. It also provides comparison use requirements models...

The derivation of statecharts from requirements has been addressed many perspectives. All them assume that the process is a linear series refinements resulting in single statechart, thereby missing opportunity to explore alternatives design space. We propose multi-dimensional approach exploits inherent variability space, where alternative are considered for same intermediate problem, multiple solutions (statecharts) initial problem (requirements). In order accomplish this, we an extended...

Requirements Engineering and Architectural Design are activities of the software development process that strongly related intertwined. Thus, providing effective methods integration between requirements architecture is an important Software challenge. In this context, STREAM presents a model-driven approach to generate early models from models. Despite being systematic derivation approach, does not support documentation architectural decisions their corresponding rationale. Recent studies in...

In the context of agile development methodologies, due to volatile nature requirements and constant changes, prioritizing is often a problem. Requirements prioritization complex, collaborative, continuous, cyclical, laborious process, resulting in low engagement. Gamification viable strategy for improving engagement such processes, as it enhances activities by promoting experiences akin those found when playing games. This paper proposes gamified approach, called PRIUS, software development....

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

Context-sensitive systems use contextual information in order to adapt the user’s current needs or requirements failure. Therefore, they need dynamically their behavior. It is of paramount importance specify and analyze intended behavior these before are fully implemented. The behavioral specification can be used for validation check if will able achieve goals. Moreover, reasoning about properties systems, such as deadlocks, reachability, completeness correctness system, supported. it have...

The use of package managers is commonplace for software developers working with programming languages such as Ruby, Python, and JavaScript. This not the case C++ developers, which present a low adoption rate managers.

Despite its potential benefits, requirements inspection is an often overlooked activity. When it performed, usually in unstructured, ad hoc fashion. This particularly the case for documented as i* goal models, considering that there no process designed specifically to address this kind of models. In paper, we propose a gamified goes beyond straightforward application game mechanics. The Ring-i (Requirements Inspection Gamified Models) allows stakeholders verify models together, playful...

Requirements models can be used to describe what is expected from a software system. On the other hand, architectural structure of system in terms its components and connectors. However, these do not capture rationale decisions made during design. This knowledge important throughout maintenance evolution system, as it allows better understanding well impact changes on it. In this paper, we consider existing proposals for documentation define template recording design decisions. based...