Requirements Engineering: Foundation for Software Quality

Frontmatter

Experimental Validation of a Risk Assessment Method

Abstract

[Context and motivation] It is desirable that requirement engineering methods are reliable, that is, that methods can be repeated with the same results. Risk assessments methods, however, often have low reliability when they identify risk mitigations for a system based on expert judgement. [Question/problem] Our goal is to assess the reliability of an availability risk assessment method for telecominfrastructures, and to identify possibilities for improvement of its reliability. [Principal ideas/results] We propose an experimental validation of reliability, and report on its application. We give a detailed analysis of sources of variation, explain how we controlled them and validated their mitigations, and motivate the statistical procedure used to analyse the outcome. [Contribution] Our results can be used to improve the reliability of risk assessment methods. Our approach to validating reliability can be useful for the assessment of the reliability of other methods.

Eelco Vriezekolk, Sandro Etalle, Roel Wieringa

Supporting the Validation of Adequacy in Requirements-Based Hazard Mitigations

Abstract

[Context and motivation] In practice, validating functional safety requirements is mainly done by means of reviews, which require large amounts of contextual information about hazards, such as safety goals or the operational conditions under which the hazard occurs. [Question/problem] This information is often scattered across a plethora of artifacts produced particularly during requirements engineering and safety assessment. In consequence, there is a risk that not all relevant information is considered during reviews, leading to subjective and misjudged results. [Principal ideas/results] In order to improve the consideration of all relevant information necessary to validate functional safety requirements, we propose a diagrammatic representation integrating all relevant contextual information. [Contribution] We hypothesize that reviewers are more likely to base their judgment on the relevant contextual information about the hazard, which increases objectivity and confidence in review results. To support this hypothesis, we report preliminary results of an empirical study.

Bastian Tenbergen, Thorsten Weyer, Klaus Pohl

Metrics for the Evaluation of Feature Models in an Industrial Context: A Case Study at Opel

Abstract

[Context & motivation] Feature models are used in product line engineering to document possible product configurations on the feature level. [Problem] In order to quantify the success of adopting feature modeling in practice, we need to understand the industry relevant metrics for feature model evaluation. [Solution] In order to identify the metrics a Goal-Question-Metric approach was used in the context of a case study conducted at Adam Opel AG. [Contribution:] We identified seven goals (quality criteria) we should strive for and evaluate when using feature models. Furthermore, we identified 18 sub-goals, 27 questions and corresponding metrics. The metrics were used to reflect on the feature modeling conducted at the company.

Olesia Oliinyk, Kai Petersen, Manfred Schoelzke, Martin Becker, Soeren Schneickert

Modeling and Reasoning About Information Quality Requirements

Abstract

[Context and motivation] Information Quality (IQ) is a key success factor for the efficient performance of any system, and it becomes a vital issue for critical systems, where low-quality information may lead to disasters. [Question/problem] Despite this, most of the Requirements Engineering frameworks focus on “what” and “where” information is required, but not on the intention behind its use, which is essential to define the required level of quality that information should meets. [Principal ideas/results] In this paper, we propose a novel conceptual framework for modeling and reasoning about IQ at requirements level. [Contribution] The proposed framework is based on the secure Tropos methodology and extends it with the required concepts for modeling and analyzing IQ requirements since the early phases of software development. A running example concerning a U.S stock market crash (the May 6, 2010 Flash Crash) is used throughout the paper.

Mohamad Gharib, Paolo Giorgini

Detecting and Correcting Outdated Requirements in Function-Centered Engineering of Embedded Systems

Abstract

[Context and Motivation] In function-centered engineering of embedded systems, changes of stakeholder intentions are often directly incorporated in the functional design without updating the behavioral requirements accordingly. [Question/Problem] As a consequence, it is likely that the behavioral requirements of the system become outdated over the course of the engineering process. [Principal Ideas/Results] We propose a validation technique that aids the requirements engineer in detecting and correcting outdated behavioral requirements. The approach relies on a dedicated review model that represents a consolidated view of behavioral requirements and functional design. [Contributions] This paper reports on a semi-automated approach and presents first experimental results showing that our technique can significantly aid the requirements engineer in the detection and correction of outdated behavioral requirements.

Marian Daun, Thorsten Weyer, Klaus Pohl

Estimating the Implementation Risk of Requirements in Agile Software Development Projects with Traceability Metrics

Abstract

[Context and Motivation] Agile developments follow an iterative procedure with alternating requirements planning and implementation phases boxed into sprints. For every sprint, requirements from the product backlog are selected and appropriate test measures are chosen. [Question/problem] Both activities should carefully consider the implementation risk of each requirement. In favor of a successful project, risky requirements should either be deferred or extra test effort should be dedicated on them. Currently, estimating the implementation risk of requirements is mainly based on gut decisions. [Principal ideas/results] The complexity of the graph spanned by dependency and decomposition relations across requirements can be an indicator of implementation risk. In this paper, we propose three metrics to assess and quantify requirement relations. We conducted a study with five industry-scale agile projects and found that the proposed metrics are in fact suitable for estimating implementation risk of requirements. [Contribution] Our study of heterogeneous, industrial development projects delivers for the first time evidence that the complexity of a requirements traceability graph is correlated with the error-proneness of the implementing source code. The proposed traceability metrics provide an indicator for requirements’ implementation risks. This indicator supports product owners and developers in requirement prioritization and test measure selection.

Patrick Rempel, Patrick Mäder

The Role of Catalogues of Threats and Security Controls in Security Risk Assessment: An Empirical Study with ATM Professionals

Abstract

[Context and motivation] To remedy the lack of security expertise, industrial security risk assessment methods come with catalogues of threats and security controls. [Question/problem] We investigate in both qualitative and quantitative terms whether the use of catalogues of threats and security controls has an effect on the actual and perceived effectiveness of a security risk assessment method. In particular, we assessed the effect of using domain-specific versus domain-general catalogues on the actual and perceived efficacy of a security risk assessment method conducted by non-experts and compare it with the effect of running the same method by security experts but without catalogues.

[Principal ideas/results] The quantitative analysis shows that non-security experts who applied the method with catalogues identified threats and controls of the same quality of security experts without catalogues. The perceived ease of use was higher when participants used method without catalogues albeit only at 10 % significance level. The qualitative analysis indicates that security experts have different expectations from a catalogue than non-experts. Non-experts are mostly worried about the difficulty of navigating through the catalogue (the larger and less specific the worse it was) while expert users found it mostly useful to get a common terminology and a checklist that nothing was forgotten.

[Contribution] This paper sheds light on the important features of the catalogues and discuss how they contribute into risk assessment process.

Martina de Gramatica, Katsiaryna Labunets, Fabio Massacci, Federica Paci, Alessandra Tedeschi

Analyzing and Enforcing Security Mechanisms on Requirements Specifications

Abstract

 [Context and motivation] Security mechanisms, such as firewalls and encryption, operationalize security requirements, such as confidentiality and integrity. [Question/problem] Although previous work has pointed out that the application of a security mechanism affects system specifications, there is no systematic approach to describe and analyze this impact. [Principal ideas/results] In this paper, we investigate more than 40 security mechanisms that are well documented in security pattern repositories in order to better understand what they are and how they function. [Contribution] Based on this study, we propose a conceptual model for security mechanisms, and evaluate this model against 20 security mechanisms. Using the conceptual model, we provide a systematic process for analyzing and enforcing security mechanisms on system requirements. We also develop a prototype tool to facilitate the application and evaluation of our approach.

Tong Li, Jennifer Horkoff, John Mylopoulos

How Artifacts Support and Impede Requirements Communication

Abstract

[Context & motivation] Requirements artifacts, like specifications, diagrams, or user stories, are often used to support various activities related to requirements. How well an artifact can support a specific activity depends on the artifact’s nature. For example, a plain text document can be adequate to provide contextual information, but is not well suited in terms of documenting changes. [Questions / problem] We wanted to understand how practitioners in various roles use requirements artifacts, how they manage to work with multiple artifacts at a time, and whether they use current practices for linking related artifacts. [Principal ideas / results] We have conducted an interview study with 21 practitioners from 6 companies. The interviews indicate that often a variety of artifact types is needed to successfully conduct a project. At the same time, using multiple artifacts causes problems like manual translation effort and inconsistencies. Mapping mechanisms that explicitly relate different artifacts are needed. However, existing methods are often not used. We investigate why these methods challenge developers in practice. [Contribution] We show challenges and chances of requirements artifacts. Our findings are grounded on true experiences from the industry. These experiences can support software developers in planning and improving their processes with regard to better requirements communication and researchers in making mapping methods more applicable in industry.

Olga Liskin

Consonance Between Economic and IT Services: Finding the Balance Between Conflicting Requirements

Abstract

[Context and motivation] Service Orientation has been heralded as the solution for seamless alignment of the business and IT. [Question/problem] Alignment, however, remains far from being resolved. [Principal ideas/results] While alignment research typically concentrates on mapping the counterpart elements, this paper provides a case for what we coin consonance—the mutual adjustment of conflicting requirements between business and IT perspectives. In previous work, we have identified inherent discrepancies between the requirements of the business- and IT perspectives. [Contribution] In this paper, to better understand such discrepancies and the kind of support needed for their consonance, we have carried out a real-world example in the music industry. Moreover, we study consonance in a networked setting; both in terms of a business network of enterprises, and in terms of a cross-organizational IT network. The use of the consonance approach in this example reveals important lessons learned.

Maryam Razavian, Jaap Gordijn

From Stakeholder Requirements to Formal Specifications Through Refinement

Abstract

[Context and motivation] Stakeholder requirements are notoriously informal, vague, ambiguous and often unattainable. The requirements engineering problem is to formalize these requirements and then transform them through a systematic process into a formal specification that can be handed over to designers for downstream development. [Question/problem] This paper proposes a framework for transforming informal requirements to formal ones, and then to a specification. [Principal ideas/results] The framework consists of an ontology of requirements, a formal requirements modeling language for representing both functional and non-functional requirements, as well as a rich set of refinement operators whereby requirements are incrementally transformed into a formal, practically satisfiable and measurable specification. [Contributions] Our proposal includes a systematic, tool-supported methodology for conducting this transformation. For evaluation, we have applied our framework to a public requirements dataset. The results of our evaluation suggest that our ontology and modeling language are adequate for capturing requirements, and our methodology is effective in handling requirements in practice.

Feng-Lin Li, Jennifer Horkoff, Alexander Borgida, Giancarlo Guizzardi, Lin Liu, John Mylopoulos

Towards More Efficient Requirements Formalization: A Study

Abstract

[Context and motivation] Validating natural language requirements is an important but difficult task. Although there are techniques available for validating formalized requirements, the gap between natural language requirements and formalism is huge. [Question/ problem] As part of a larger piece of work on temporal requirements consistency checking, we developed a front end to semi-automatically translate natural language requirements into an formal language called Temporal Action Language or \( TeAL \). This work is based on an underlying assumption that human analysts can assist us in filling in the missing pieces as we translate natural language temporal requirements to \( TeAL \).[Principal ideas/results] We performed a study to validate this assumption. We found that using the statements generated by our front-end tool appears to be more effective and efficient than a manual process. [Contribution] We present the design of our front-end and a study that measures the performance of human analysts in formalizing requirements with the help of an automated tool.

Wenbin Li, Jane Huffman Hayes, Mirosław Truszczyński

The Emerging Requirement for Digital Addiction Labels

Abstract

[Context & motivation] Digital Addiction, e.g. to social networks sites and games, is becoming a public interest issue which has a variety of socio-economic effects. Recent studies have shown correlation between Digital Addiction and certain negative consequences such as depression, reduced creativity and productivity, lack of sleep and disconnection from reality. Other research showed that Digital Addiction has withdrawal symptoms similar to those found in drug, tobacco, and alcohol addiction. [Question/problem] While industries like tobacco and alcohol are required by certain laws to have a label to raise awareness of the potential consequences of the use, we still do not have the same for addictive software. [Principal ideas/results] In this study, we advocate the need for Digital Addiction labels as an emerging ethical and professional requirement. We investigate the design of such labels from a user’s perspective through an empirical study, following a mixed-methods approach, and report on the results. [Contribution] Our ultimate goal is to introduce the need for labelling to both researchers and developers and provide a checklist of questions to consider when handling this non-functional requirement.

Raian Ali, Nan Jiang, Keith Phalp, Sarah Muir, John McAlaney

Challenges of the Customer Organization’s Requirements Engineering Process in the Outsourced Environment – A Case Study

Abstract

[Context and motivation] The increasingly complex business and development environment brings challenges to IT system development and requirements engineering (RE) activities. [Question/problem] The goal of the case study was to investigate what the challenges of a customer organization’s RE process are in the outsourced development environment and what demands these challenges bring to RE process development. The case study was conducted in a Finnish insurance company. [Principal ideas/results] The results are based on 17 interviews and the analysis of 15 large projects. The case study indicates that one of the biggest challenges is to develop business and IT as a whole. When combining business process and IT system development, requirements are an important tool. Another critical challenge in the outsourced environment is that the RE process is distributed between the customer organization and the supplier. Furthermore, highly integrated IT systems and enterprise architecture bring demands to RE process. [Contribution] The paper describes a complex environment in which the customer organization develops IT systems, and systematically defines challenges related to the RE process.

Heli Hiisilä, Marjo Kauppinen, Sari Kujala

A Case Study Evaluation of the Guideline-Supported QUPER Model for Elicitation of Quality Requirements

Abstract

[Context & motivation] For market-driven software product developing organizations operating on a competitive open market, it is important to plan the product’s releases so that they can reach the market as early as possible with a competitive level of quality compared to its competitors’ products. Hence, quality requirements can be seen as a key competitive advantage. The QUPER model was developed with the aim to support high-level decision-making in release planning of quality requirements. [Question/problem] As a follow up on previous studies on QUPER, this study investigates: What are practitioners’ views on the utilities of QUPER extended with guidelines including domain-specific examples? [Principal ideas/results] In the presented case study, a set of detailed guidelines of how to apply QUPER in practice, including how to handle cost dependencies between quality requirements, was evaluated at a case company in the mobile handset domain with 24 professionals using real quality requirements. [Contribution] The results point to the importance of having concrete guidelines combined with instructive examples from real practice, while it is not always obvious for a practitioner to transfer cost-dependency examples into the domains that are different from the example domain. The transferability of guidelines and examples to support methodology adoption is an interesting issue for further research.

Richard Berntsson Svensson, Björn Regnell

Towards Crowd-Based Requirements Engineering A Research Preview

Abstract

[Context and motivation] Stakeholders who are highly distributed form a large, heterogeneous online group, the so-called “crowd”. The rise of mobile, social and cloud apps has led to a stark increase in crowd-based settings. [Question/problem] Traditional requirements engineering (RE) techniques face scalability issues and require the co-presence of stakeholders and engineers, which cannot be realized in a crowd setting. While different approaches have recently been introduced to partially automate RE in this context, a multi-method approach to (semi-)automate all RE activities is still needed. [Principal ideas/results] We propose “Crowd-based Requirements Engineering” as an approach that integrates existing elicitation and analysis techniques and fills existing gaps by introducing new concepts. It collects feedback through direct interactions and social collaboration, and by deploying mining techniques. [Contribution] This paper describes the initial state of the art of our approach, and previews our plans for further research.

Eduard C. Groen, Joerg Doerr, Sebastian Adam

Functional Requirements Modelling for Interactive TV Applications

Abstract

[Context and motivation] There is a scarcity of proposals for functional requirements modelling for the interactive TV applications (iTV); this is a complex problem due to several fields/factors/dimensions/trends involved; therefore, it is necessary to give support to model iTV requirements. [Question/problem] We have found in the literature some iTV task classifications; some of their limitations are: classifications of actions were not proposed, the action classes found are not enough, it was not explained for each functionality kind how to systematically describe its members in terms of action classes of a taxonomy of actions, and the task classes are not enough for practical iTVs. [Principal ideas/results] For iTV applications we defined two UML profiles: one extending use case diagrams (UCD), and another extending activity diagrams (AD) for describing use cases (UC); 4 real iTVs were (partially) considered to illustrate the use of both profiles. [Contribution] Both profiles describe useful classifications with tasks/actions classes not found in the literature; for the identification of UCs we consider using few criteria instead of considering a lot of task classes; for every UC kind we indicate which action kinds must be used (for describing UCs of this kind); our approach allows to answer the question: to what kind of stakeholder a UC implementation should be assigned.

Sergio Canchi, Juan Eduardo Durán

FlexiView: A Magnet-Based Approach for Visualizing Requirements Artifacts

Abstract

[Context and motivation] Requirements engineers create large numbers of artifacts when eliciting and documenting requirements. They need to navigate through these artifacts and display information details at points of interest for reviewing or editing information. [Question/problem] Traditional visualization mechanisms such as scrolling and opening multiple windows lose context when navigating and can be cumbersome to use, hence. On the other hand, focus+context approaches can display details in context, but they distort the data shown (e.g., fisheye views) or result in a large display canvas which again requires scrolling (e.g., zooming in Adora). [Principal ideas/results] We are developing a novel method for displaying just the information needed to perform an intended task. Our method partitions the available screen space into regions. The boundaries of regions are simulated with a model consisting of virtual magnetic balls and springs that behaves like a physical system. This model supports the requirements engineer in selecting how the relevant information should be displayed. [Contribution] In this paper, we present preliminary results on how our conceptual solution works and what benefits are expected.

Parisa Ghazi, Norbert Seyff, Martin Glinz

Requirements Engineering in the Bidding Stage of Software Projects – A Research Preview

Abstract

[Context and motivation] Before a software project officially starts, there is a stage that has not received much consideration in literature: the precontract or bidding stage. [Question/problem] In this phase, basic Requirements Engineering (RE) activities are conducted without having a budget, yet. In this paper, the SmartOffer project is described, which aims on improving RE during this precontract phase. [Principal idea/results] Therefore, bidding processes of several organizations were analyzed and commonalities/differences were identified. The consolidated process is described in this paper. It consists out of four abstract phases: assessment of demand, conception, proposal, and actual project conduction. Mandatory and optional process steps within these phases allow for being tailored to different companies and products. [Contribution] The consolidated bidding process provides the potential for automation and tool support. In consequence the precontract phase will be more efficient and effective. Building a tool supporting this process as well as evaluating this tool will be addressed in future work to complement this research preview.

Kai Breiner, Michael Gillmann, Axel Kalenborn, Christian Müller

Research Preview: Supporting Requirements Feedback Flows in Iterative System Development

Abstract

Context & motivation: Today, embedded systems are increasingly interconnected and operate in a rich context of systems and internet-based services. Iterative development is one strategy of developing such cyber-physical systems. It enables exploration of early prototypes of a feature in the context of its intended use and collecting telemetric data from test-runs. This is a rich data source that can be leveraged for learning behavioural requirements for a feature. Question/problem: However, we found practitioners struggling with deriving requirements for the next iteration from such test-runs in a systematic and repeatable way. Principal ideas/results: We allow test drivers to add markers when the system behaves unexpectedly by introducing a dedicated feedback tool. Preliminary evaluation shows that these markers lead to better feedback to the development team and indicates a positive impact on the development cycle. Contribution: We give an example, report experiences, and discuss industrial implications of feedback systems and in situ requirements gathering in iterative system development.

Eric Knauss, Andreas Andersson, Michael Rybacki, Erik Israelsson

User-Constrained Clustering in Online Requirements Forums

Abstract

[Context & motivation:] Software development projects involving geographically dispersed stakeholders often use web-based discussion forums to gather feature requests. Our previous study showed that users have a tendency to create redundant threads as well as large unfocused mega-threads. [Question/problem:] In this paper we propose novel solution for integrating user feedback into the process of dynamically and iteratively clustering features into discussion threads. [Principal ideas/results:] We integrate feed back in the form of stick-together and move-apart advice, plus user-defined tags into our consensus based clustering process. [Contribution:] Experimental results demonstrate that our approach is able to deliver high quality and stable clusters to facilitate forum-based requirements elicitation.

Chuan Duan, Horatiu Dumitru, Jane Cleland-Huang, Bamshad Mobasher

A Systematic Literature Review of Requirements Prioritization Criteria

Abstract

[Context & motivation] Requirements prioritization is typically applied in order to determine which requirements or features should be included in a certain release or implemented first. While most requirements prioritization approaches prescribe a fixed set of prioritization criteria that have to be assessed during the prioritization process, there is often a need for criteria that are customized to the specific project situation. [Question/problem] However, determining customized prioritization criteria is a time-consuming and laborious task. Instead of an in-depth analysis, criteria are often identified by gut feeling, which is error-prone and bears the risk of choosing misleading criteria. [Principal ideas/results] This paper aims at identifying and categorizing prioritization criteria discussed in the vast body of prioritization literature for software development. We describe a systematic literature review and, as a result, present a consolidated prioritization criteria model. [Contribution] Besides a comprehensive overview of prioritization criteria discussed in the literature, this paper introduces a classification schema that allows researchers and practitioners to identify prioritization criteria and related literature in a time-saving manner.

Norman Riegel, Joerg Doerr

Embedding Stakeholder Values in the Requirements Engineering Process

Abstract

Software has become an integral part of our daily lives and should therefore account for human values such as trust, autonomy and privacy. Human values have received increased attention in the field of Requirements Engineering over the last few years, but existing work offers no systematic way to use elicited values in requirements engineering and evaluation processes. In earlier work we proposed the Value Story workshop, a domain-independent method that connects value elicitation techniques from the field of Human-Computer Interaction to the identification of user stories, a common requirements specification format in Requirements Engineering. This paper studies whether user stories obtained in a Value Story workshop 1) adequately account for values, and 2) are usable by developers. The results of an empirical evaluation show that values are significantly better incorporated in user stories obtained in a Value Story workshop than through user stories obtained in regular requirements elicitation workshops. The results also show that value-based user stories are deemed valuable to the end-user, but rated less well on their size, estimableness and testability. This paper concludes that the Value Story workshop is a promising method for embedding values in the Requirements Engineering process, but that value-based user stories need to be translated to use cases to make them suitable for planning and organizing implementation activities.

Maaike Harbers, Christian Detweiler, Mark A. Neerincx

Backmatter