Some believe that Requirements Engineering (RE) for a computer-based system (CBS) should be done upfront, producing a complete requirements specification before any of the CBS’s software is written. A common complaint is that (1) new requirements never stop coming; so upfront RE goes on forever with an ever growing scope. However, data show that (2) the cost to modify written software to include a new requirement is at least 10 times the cost of writing the software with the requirement included from the start; so upfront RE saves development costs, particularly if the new requirement is one that was needed to prevent a failure of the implementation of a requirement already included in the scope. The scope of a CBS is the set of requirements that drive the CBS’s implementation. We believe that both (1) and (2) are correct, but each is about a different category of requirements, (1) scope determininG (G) or (2) scope determineD (D), respectively. Reexamination of the reported data of some past case studies through the lens of these categories indicates that when a project fails, a large majority of its defects were due to missing D requirements, and when a project succeeds, the project focused its RE on finding all of its D requirements. The hypothesis that waterfall methods (WMs), with their upfront RE, do a better job of avoiding missing D requirements in developing CBSs than do agile methods (AMs) was not supported by the data from 8 WM projects and 8 similar AM projects in one company. In fact, the null hypothesis, that there is no difference between WMs and AMs in avoiding missing D requirements in developing CBSs, cannot be rejected for any logically posssible assignment of the collective data from the 16 projects to 16 specific projects. It appears that intimate knowledge of the domain and development of a CBS is necessary to be able to classify the CBS’s defects arising from missing requirements as of category D or G with respect to (w.r.t.) the CBS’s scope. Finally, software and requirement engineers are able to learn from a half-hour lecture about D and G requirements to correctly categorize most requirements of a familiar CBS as D or G, w.r.t. the CBS’s scope.

Research and full paper. Digital games are increasingly a part of our daily lives and are already considered teaching and learning tools. However, its production and documentation is a very complicated task that requires programming skills and knowledge from different areas. This has hampered the development of games in the classroom environment. On the other hand, some teachers have proposed this activity to enable their students to learn school content in a more meaningful way and, consequently, improve learning rates. An alternative for the adoption of game-based learning is an unplugged approach for creating games based on natural language, in which students learn the fundamentals of computing in a playful way and without the use of computers. In this context, this article presents an approach that proposes the creation of games in an unplugged way by using texts produced by students, thus favoring the development of computational thinking and reading and writing skills in the classroom. Also, it may support the students' interest in the computing area by motivating them to enter a higher education course or pursue a career in that area. The results of the exploratory study show that the proposed approach can favor the development of computational thinking, as well as motivate the production of texts, developing students' reading and writing skills, therefore contributing to the improvement of learning assessments.

Digital games are becoming more and more a part of our daily lives. After realizing this, several educators have been motivated to use games as teaching and learning tools. In this sense, it is possible to involve teachers and students in the production of their own games, thus contributing both to the development of computational thinking and to acquiring knowledge related to the different disciplines involved in this process. Despite the benefits, the production of games is a complex task that requires knowledge of a specific domain and presents a significant learning curve for students and teachers. The choice of using effective strategies such as Model-Driven Engineering (MDE) practices supported by a Controlled Natural Language (CNL) to promote the production of games in the educational context is decisive and can favor the adoption of game-based learning. This work proposes a strategy for the specification of game design for digital games by students and teachers in the classroom, that can promote the development of computational thinking, as well as reading and writing skills.

Potigol is a new multi-paradigm programming language specially designed for beginners. Its main features are an agile syntax, which looks like dynamically-typed scripting languages, and a statically-typed semantics with limited side-effects. Both syntax and semantics encourage a functional programming style. It is an open-source project that can be freely used and modified.

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.

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.