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

The i* framework for goal-oriented modeling

The final publication is available at Springer via http://dx.doi.org/10.1007/978-3-319-39417-6i* is a widespread framework in the software engineering field that supports goal-oriented modeling of socio-technical systems and organizations. At its heart lies a language offering concepts such as actor, dependency, goal and decomposition. i* models resemble a network of interconnected, autonomous, collaborative and dependable strategic actors. Around this language, several analysis techniques have emerged, e.g. goal satisfaction analysis and metrics computation. In this work, we present a consolidated version of the i* language based on the most adopted versions of the language. We define the main constructs of the language and we articulate them in the form of a metamodel. Then, we implement this version and a concrete technique, goal satisfaction analys is based on goal propagation, using ADOxx. Throughout the chapter, we used an example based on open source software adoption to illustrate the concepts and test the implementation.Peer ReviewedPostprint (author's final draft

An Analysis of Service Ontologies

Services are increasingly shaping the world’s economic activity. Service provision and consumption have been profiting from advances in ICT, but the decentralization and heterogeneity of the involved service entities still pose engineering challenges. One of these challenges is to achieve semantic interoperability among these autonomous entities. Semantic web technology aims at addressing this challenge on a large scale, and has matured over the last years. This is evident from the various efforts reported in the literature in which service knowledge is represented in terms of ontologies developed either in individual research projects or in standardization bodies. This paper aims at analyzing the most relevant service ontologies available today for their suitability to cope with the service semantic interoperability challenge. We take the vision of the Internet of Services (IoS) as our motivation to identify the requirements for service ontologies. We adopt a formal approach to ontology design and evaluation in our analysis. We start by defining informal competency questions derived from a motivating scenario, and we identify relevant concepts and properties in service ontologies that match the formal ontological representation of these questions. We analyze the service ontologies with our concepts and questions, so that each ontology is positioned and evaluated according to its utility. The gaps we identify as the result of our analysis provide an indication of open challenges and future work

Theory of Regulatory Compliance for Requirements Engineering

Regulatory compliance is increasingly being addressed in the practice of requirements engineering as a main stream concern. This paper points out a gap in the theoretical foundations of regulatory compliance, and presents a theory that states (i) what it means for requirements to be compliant, (ii) the compliance problem, i.e., the problem that the engineer should resolve in order to verify whether requirements are compliant, and (iii) testable hypotheses (predictions) about how compliance of requirements is verified. The theory is instantiated by presenting a requirements engineering framework that implements its principles, and is exemplified on a real-world case study.Comment: 16 page

Exploiting a Goal-Decomposition Technique to Prioritize Non-functional Requirements

Business stakeholders need to have clear and realistic goals if they want to meet commitments in application development. As a consequence, at early stages they prioritize requirements. However, requirements do change. The effect of change forces the stakeholders to balance alternatives and reprioritize requirements accordingly. In this paper we discuss the problem of priorities to non-functional requirements subjected to change. We, then, propose an approach to help smooth the impact of such changes. Our approach favors the translation of nonoperational specifications into operational definitions that can be evaluated once the system is developed. It uses the goal-question-metric method as the major support to decompose non-operational specifications into operational ones. We claim that the effort invested in operationalizing NFRs helps dealing with changing requirements during system development. Based on\ud this transformation and in our experience, we provide guidelines to prioritize volatile non-functional requirements

Modeling the object-oriented software process: OPEN and the unified process

A short introduction to software process modeling is presented, particularly object-oriented modeling. Two major industrial process models are discussed: the OPEN model and the Unified Process model. In more detail, the quality assurance in the Unified Process tool (formally called Objectory) is reviewed