Scenarios are well recognised as an important strategy towards understanding the interface between the environment and the system as well as a means of eliciting and specifying software behaviour. We adopt a broader view of scenarios. For us, a scenario is an evolving description of situations in the environment. Our proposal is framed by Leite's work on a client-oriented requirements baseline, which aims to model the external requirements of a software system and its evolution. Scenarios start by describing the environment situations, according to the main actions performed outside the software system. Scenarios also help to clarify the interrelation between functional and non-functional requirements. We have validated our strategy and the related representations based on case studies.

No abstract

Abstract.Context/Background: process and practice adoption is a key element in modern software process improvement initiatives, and many of them fail. Goal: this paper presents a preliminary version of a usability model for software development process and practice. Method: this model integrates different perspectives, the ISO Standard on Systems and Software Quality Models (ISO 25010) and classic usability literature. For illustrating the feasibility of the model, two experts applied it to Scrum. Results: metrics values were mostly positive and consistent between evaluators. Conclusions: we find the model feasible to use and potentially beneficial.

Abstract. Background: Agile Software Development is widely used nowadays and to measure its real usage we need to analyze how its practices are used. These practices have been categorized by several authors and some practitioners have suggested that technical practices have a lower usage level than organizational practices. Objective: In this study we aim to understand the actual usage of technical and organizational agile practices in the Latin-American Agile community. Method: We conducted a three-stage survey in conferences of the Latin-American Agile Community. Results: Organizational practices are much more used than technical ones. The number of practices used is a direct function of organization experience using agile. The difference between technical and organizational practices reduces with the experience of the organization using agile. Team size and project duration seem to have no effect in the number of practices used.

Software development is a succession of descriptions in different languages in which every description is based on a previous one. Since the requirements specification is one of the first descriptions, it is important to begin software development with requirements that are as correct and as complete as possible. Although some literature holds the belief that correctness and completeness are two attributes that requirements specifications must satisfy, we know that these attributes are very difficult to meet. However, we have to find ways to diminish the level of incompleteness and deal with the possible conflicts that do arise in the requirements context. Defining the domain language before specifying the requirements is a way of coping with these problems. Nowadays, software systems involve many stakeholders and it is hard to engage all of them to produce a domain language specification. We rely on collaboration to foster the involvement and cooperation of the stakeholders, thus they are able to explore the differences constructively and provide a common understanding of the domain language beyond their own limited views. In this paper, we propose a strategy to capture the domain language in a collaborative way using the Language Extended Lexicon and we show a validation of the proposed strategy.