Systematic formulation of non-functional characteristics of software

This paper presents NoFun, a notation aimed at dealing with non-functional aspects of software systems at the product level in the component programming framework. NoFun can be used to define hierarchies of non-functional attributes, which can be bound to individual software components, libraries of components or (sets of) software systems. Non-functional attributes can be defined in several ways, being possible to choose a particular definition in a concrete context. Also, NoFun allows to state the values of the attributes in component implementations, and to formulate non-functional requirements over component implementations. The notation is complemented with an algorithm able to select the best implementation of components (with respect to their non-functional characteristics) in their context of use.Peer ReviewedPostprint (published version

Using quality models in software package selection

The growing importance of commercial off-the-shelf software packages requires adapting some software engineering practices, such as requirements elicitation and testing, to this emergent framework. Also, some specific new activities arise, among which selection of software packages plays a prominent role. All the methodologies that have been proposed recently for choosing software packages compare user requirements with the packages' capabilities. There are different types of requirements, such as managerial, political, and, of course, quality requirements. Quality requirements are often difficult to check. This is partly due to their nature, but there is another reason that can be mitigated, namely the lack of structured and widespread descriptions of package domains (that is, categories of software packages such as ERP systems, graphical or data structure libraries, and so on). This absence hampers the accurate description of software packages and the precise statement of quality requirements, and consequently overall package selection and confidence in the result of the process. Our methodology for building structured quality models helps solve this drawback.Peer ReviewedPostprint (published version

Using i* to describe data structures

This paper explores the use of the i* language as a notation to describe data structures to be used in classical imperative programs written in e.g. Java or C#. Data structures are described at two levels of abstraction, their specification and their implementation (the data structure properly said). We analyze how iStar 2.0, enriched with both modularization and dependum specialization constructs, can be used in this context.Peer ReviewedPostprint (published version

Using Constraint Programming for the Automatic Detection of Conflicts in Quality Requirements

Requirements negotiation is quite an interesting, ongoing research area. Current requirements engineering models usually propose a negotiation process with similar methods and goals. Unfortunately, only a few have partial automatic support. in this paper, we revisit one of the most mature models, Boehm’s Win–Win model. Win–Win is a qualitative, process–oriented model so that it is specially suited to be used at the early stages of requirements engineering, when knowledge about requirements is still vague, but not for quantitative, product–oriented contexts where a more precise, exact knowledge about the requirements is needed. in this paper, we present a proposal to extend and refine Win–Win in order it can be used in product–oriented contexts. The main benefit of our approach is that the same conceptual model for requirements negotiation can be used during all software development process, instead of using different models in different phasesComisión Interministerial de Ciencia y Tecnología TIC 2000–1106–C02–0

Putting non-functional requirements into software architecture

This paper presents an approach for incorporating non-functional information of software system into software architectures. To do so, components present two distinguished slots: their non-functional specification, where non-functional requirements on components are placed, and their non-functional behaviour with respect to these requirements. Also, connector protocols may describe which non-functional aspects are relevant to component connections. We propose a notation to describe non-functionality in a systematic manner, and we use it to analyse two particular aspects of the meeting scheduler case study, user interaction and performance.Peer ReviewedPostprint (published version

An Empirical Study on Decision making for Quality Requirements

[Context] Quality requirements are important for product success yet often handled poorly. The problems with scope decision lead to delayed handling and an unbalanced scope. [Objective] This study characterizes the scope decision process to understand influencing factors and properties affecting the scope decision of quality requirements. [Method] We studied one company's scope decision process over a period of five years. We analyzed the decisions artifacts and interviewed experienced engineers involved in the scope decision process. [Results] Features addressing quality aspects explicitly are a minor part (4.41%) of all features handled. The phase of the product line seems to influence the prevalence and acceptance rate of quality features. Lastly, relying on external stakeholders and upfront analysis seems to lead to long lead-times and an insufficient quality requirements scope. [Conclusions] There is a need to make quality mode explicit in the scope decision process. We propose a scope decision process at a strategic level and a tactical level. The former to address long-term planning and the latter to cater for a speedy process. Furthermore, we believe it is key to balance the stakeholder input with feedback from usage and market in a more direct way than through a long plan-driven process

A quality-model-based approach for describing and evaluating software packages

Selection of software packages from user requirements is a central task in software engineering. Selection of inappropriate packages may compromise business processes and may interfere negatively in the functioning of the involved organization. Success of package selection is endangered because of many factors, one of the most important being the absence of structured descriptions of both package features and user quality requirements. In this paper, we propose a methodology for describing quality factors of software packages using the ISO/IEC quality standard as a framework. Following this standard, relevant attributes for a specific software domain are identified and structured as a hierarchy, and metrics for them are chosen. Software packages in this domain can then be described in a uniform and comprehensive way. Therefore, selection of packages can be ameliorated by transforming user quality requirements into requirements expressed in terms of quality model attributes. We illustrate the approach by presenting, in some depth, a quality model for the mail server domain.Peer ReviewedPostprint (published version

WHAT CONCERNS USERS OF MEDICAL APPS? EXPLORING NON-FUNCTIONAL REQUIREMENTS OF MEDICAL MOBILE APPLICATIONS

The increased use of internet through smartphones and tablets enables the development of new consumer-focused mobile applications (apps) in health care. Concerns including these apps´ safety, usability, privacy, and dependability have been raised. In this paper the authors present the results of a grounded theory-approach to finding what non-functional requirements of medical apps potential users view as most important. A document study and interviews with stakeholders yielded nine non-functional requirements for medical apps: accessibility, certifiability, portability, privacy, safety, security, stability, trustability, and usability. Six of these were evaluated with two groups (differing by age) of potential users through a vignette study. This revealed differences between the age groups regarding the importance each attributed to apps´ usability and certifiability. Furthermore, and contrary to consensus in literature, privacy was considered one of the least important attributes for medical apps by both groups. Trustability, security, and, for the younger group, certifiability, were considered the most important non-functional requirements for medical apps. The implications of these results for developing medical mobile applications are briefly visited

Modelling non-functional requirements

We present in this paper the language NoFun for stating component quality in the framework of the ISO/IEC quality standards. The language consists of three different parts. In the first one, software quality characteristics and attributes are defined, probably in a hierarchical manner. As part of this definition, abstract quality models can be formulated and further refined into more specialised ones. In the second part, values are assigned to component quality basic attributes. In the third one, quality requirements can be stated over components, both context-free (universal quality properties) and context-dependent (quality properties for a given framework-software domain, company, project, etc.). Last, we address to the translation of the language to UML, using its extension mechanisms for capturing the fundamental non-functional concepts.Peer ReviewedPostprint (author's final draft

WeSSQoS: Un sistema SOA para la selección de servicios web según su calidad

Los Servicios Web (WS) se han convertido en una tecnología altamente utilizada en el desarrollo de sistemas software. Una de sus problemáticas más importantes es la selección de los WS más apropiados para satisfacer los requisitos de dichos sistemas. Si consideramos los requisitos no funcionales (NFR), la calidad de servicio de los WS contiene la información necesaria para analizar dicha satisfacción. En este artículo se describe el sistema WeSSQoS para la ordenación de WS según su grado de satisfacción de los NFR, calculable a partir de la calidad de servicio de dichos WS, que puede declararse en el WSDL mismo o bien calcularse dinámicamente mediante monitorización. Esta información acerca de la calidad puede provenir de diversas fuentes (diferentes repositorios WSDL, diferentes monitores, etc.). La arquitectura de WeSSQoS permite la coexistencia de diversos algoritmos de ordenación de los WS, si bien en este artículo nos centramos en uno de ellos que usa la distancia euclidiana como criterio de ordenación.Peer ReviewedPostprint (author’s final draft