How do software architects consider non-functional requirements: an exploratory study

© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes,creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Peer ReviewedPostprint (author’s final draft

Rationale Management Challenges in Requirements Engineering

Rationale and rationale management have been playing an increasingly prominent role in software system development mainly due to the knowledge demand during system evaluation, maintenance, and evolution, especially for large and complex systems. The rationale management for requirements engineering, as a commencing and critical phase in software development life cycle, is still under-exploited. In this paper, we first survey briefly the state-of-the-art on rationale employment and applications in requirements engineering. Secondly, we identify the challenges in integrating rationale management in requirements engineering activities in order to promote further investigations and define a research agenda on rationale management in requirements engineering.

Hypermedia support for argumentation-based rationale: 15 years on from gIBIS and QOC

Having developed, used and evaluated some of the early IBIS-based approaches to design rationale (DR) such as gIBIS and QOC in the late 1980s/mid-1990s, we describe the subsequent evolution of the argumentation-based paradigm through software support, and perspectives drawn from modeling and meeting facilitation. Particular attention is given to the challenge of negotiating the overheads of capturing this form of rationale. Our approach has maintained a strong emphasis on keeping the representational scheme as simple as possible to enable real time meeting mediation and capture, attending explicitly to the skills required to use the approach well, particularly for the sort of participatory, multi-stakeholder requirements analysis demanded by many design problems. However, we can then specialize the notation and the way in which the tool is used in the service of specific methodologies, supported by a customizable hypermedia environment, and interoperable with other software tools. After presenting this approach, called Compendium, we present examples to illustrate the capabilities for support security argumentation in requirements engineering, template driven modeling for document generation, and IBIS-based indexing of and navigation around video records of meetings

Taking Afrobarometer Data Everywhere

According to statistics gathered by research group Afrobarometer, many countries in Africa lack infrastructure and basic necessities. In fact, Afrobarometer knows the specific rates of need and availability sampled across thirty-six countries but more prosperous African countries do not know these numbers. These more developed countries are in a position to help their less fortunate neighbors if only made aware of the social and economic climate in the respective areas. Our partnership with Afrobarometer will allow us to advertise these statistics through the use of a mobile application. The data will be displayed in a way that is easy for the average reader to digest and understand. By exposing a larger African audience to the results from these public opinion surveys, Afrobarometer hopes to inspire these people to take action and make donations to the appropriate social benefit groups. The countries represented by the surveys can then receive help in the areas expressing need

Using mobile RE tools to give end-users their own voice

Researchers highlight end-user involvement in system design as an important concept for developing useful and usable solutions. However, end-user involvement in software engineering is still an open-ended topic. Novel paradigms such as service-oriented computing strengthen the need for more active end-user involvement in order to provide systems that are tailored to individual end-user needs. Our work is based on the fact that the majority of end-users are familiar with mobile devices and use an increasing number of mobile applications. A mobile tool enabling end-user led requirements elicitation could be just one of many applications installed on end-users' mobile devices. In this paper, we present a framework of end-user involvement in requirements elicitation which motivates our research. The main contribution of our research is a tool-supported requirements elicitation approach allowing end-users to document needs in situ. Furthermore, we present first evaluation results to highlight the feasibility of on-site end-user led requirements elicitation

A Survey of Architecture Design Rationale

Many claims have been made about the problems caused by not documenting design rationale. The general perception is that designers and architects usually do not fully understand the critical role of systematic use and capture of design rationale. However, there is to date little empirical evidence available on what design rationale mean to practitioners, how valuable they consider them, and how they use and document design rationale during the design process. This paper reports an empirical study that surveyed practitioners to probe their perception of the value of design rationale and how they use and document background knowledge related to their design decisions. Based on eighty-one valid responses, this study has discovered that practitioners recognize the importance of documenting design rationale and frequently use them to reason about their design choices. However, they have indicated barriers to the use and documentation of design rationale. Based on the findings, we conclude that much research is needed to develop methodology and tool support for design rationale capture and usage. Furthermore, we put forward some research questions that would benefit from further investigation into design rationale in order to support practice in industry

Reasoning and Reuse in Software Architecture Design: Practices in the Argentine Industry

Over the last years, software architecture design has gained significant importance in both, industrial and research areas due to its relevance in the software system development process. In this context, special attention has been given to the documentation of architects’ reasoning during an architectural design, highlighting the advantages and disadvantages of this activity. This work intends to present a view of architects’ practices in the Argentine industry regarding reasoning documentation and its subsequent use and access.Fil: Carignano, Maria Celeste. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); ArgentinaFil: Gonnet, Silvio Miguel. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); ArgentinaFil: Leone, Horacio Pascual. Consejo Nacional de Investigaciones Científicas y Técnicas. Centro Científico Tecnológico Santa Fe. Instituto de Desarrollo y Diseño (i); Argentin

Linking Quality Attributes and Constraints with Architectural Decisions

Quality attributes and constraints are among the main drivers of architectural decision making. The quality attributes are improved or damaged by the architectural decisions, while restrictions directly include or exclude parts of the architecture (for example, the logical components or technologies). We can determine the impact of a decision of architecture in software quality, or which parts of the architecture are affected by a constraint, but the difficult problem is whether we are respecting the quality requirements (requirements on quality attributes) and constraints with all the architectural decisions made. Currently, the common practice is that architects use their own experience to design architectures that meet the quality requirements and restrictions, but at the end, especially for the crucial decisions, the architect has to deal with complex trade-offs between quality attributes and juggle possible incompatibilities raised by the constraints. In this paper we present Quark, a computer-aided method to support architects in software architecture decision making