Background: Since sustainability became a challenge in software engineering, researchers mainly from requirements engineering and software architecture communities have contributed to defining the basis of the notion of sustainability-aware software. Problem: Despite these valuable effort s, the assessment and design based on the notion of sustainability as a software quality is still poorly understood. There is no consensus on which sustainability requirements should be considered. Aim and Method: To fill this gap, a survey was designed with a double objective: i) determine to which extent quality requirements contribute to the sustainability of software-intensive systems; and ii) identify direct dependencies among the sustainability dimensions. The survey involved different target audiences (e.g. software architects, ICT practitioners with expertise in Sustainability). We evaluated the perceived importance/relevance of each sustainability dimension, and the perceived usefulness of exploiting a sustainability model in different software engineering activities. Results: Most respondents considered modifiability as relevant for addressing both technical and environmental sustainability. Functional correctness, availability, modifiability, interoperability and recoverability favor positively the endurability of software systems. This study has also identified security, satisfaction, and freedom from risk as very good contributors to social sustainability. Satisfaction was also considered by the respondents as a good contributor to economic sustainability.

This paper describes an empirical mapping study, which was designed to identify what aspects of Software Requirement Specifications (SRS) are empirically evaluated, in which context, and by using which research method. On the basis of 46 identified and categorized primary studies, we found that understandability is the most commonly evaluated aspect of SRS, experiments are the most commonly used research method, and the academic environment is where most empirical evaluation takes place.

No abstract

No abstract

Abstract-In Model-Driven Development (MDD), defects are managed at the level of conceptual models because the other artefacts are generated from them, such as more refined models, test cases and code. Although some studies have reported on defect types at model level, there still does not exist a clear and complete overview of the defect types that occur at the abstraction level. This paper presents a systematic mapping study to identify the model defect types reported in the literature and determine how they have been detected. Among the 282 articles published in software engineering area, 28 articles were selected for analysis. A total of 226 defects were identified, classified and their results analysed. For this, an appropriate defect classification scheme was built based on appropriate dimensions for models in an MDD context.

No abstract

Usability is currently a key feature for developing quality systems. A system that satisfies all the functional requirements can be strongly rejected by end-users if it presents usability problems. End-users demand intuitive interfaces and an easy interaction in order to simplify their work. The first step in developing usable systems is to determine whether a system is or is not usable. To do this, there are several proposals for measuring the system usability. Most of these proposals are focused on the final system and require a large amount of resources to perform the evaluation (end-users, video cameras, questionnaires, etc.). Usability problems that are detected once the system has been developed involve a lot of reworking by the analyst since these changes can affect the analysis, design, and implementation phases. This paper proposes a method to minimize the resources needed for the evaluation and reworking of usability problems. We propose an early usability evaluation that is based on conceptual models. The analyst can measure the usability of attributes that depend on conceptual primitives. This evaluation can be automated taking as input the conceptual models that represent the system abstractly.

No abstract