Skip to main content

Über dieses Buch

This book constitutes the refereed proceedings of the 19th International Working Conference on Requirements Engineering: Foundation for Software Quality, REFSQ 2013, held in Essen, Germany, in April 2013. The papers are organized in 8 topical sections on requirements engineering and architecture; natural language requirements; requirements engineering and quality; traceability; requirements engineering and business/goals; requirements engineering and software development; requirements engineering in practice; product lines and product management.



RE and Architecture

Software Architects’ Experiences of Quality Requirements: What We Know and What We Do Not Know?

[Context/motivation] Quality requirements (QRs) are a concern of both requirement engineering (RE) specialists and software architects (SAs). However, the majority of empirical studies on QRs take the RE analysts’/clients’ perspectives, and only recently very few included the SAs’ perspective. As a result, (i) relatively little is known about SAs’ involvement in QRs engineering and their coping strategies, and (ii) whatever is known mostly comes from small and midsized projects. [Question/problem] The question in this exploratory study is how SAs cope with QRs in the context of large and contract-based software system delivery projects. [Principal ideas/results] We executed an exploratory case study with 20 SAs in the context of interest. The key results indicate the role SAs play in QRs engineering, the type of requirements communication processes SAs are involved in, the ways QRs are discovered, documented, quantified, validated and negotiated. Our most important findings are that in contract-based contexts: (1) the QRs are approached with the same due diligence as the functional requirements and the architecture design demand, (2) the SAs act proactively and embrace responsibilities over the QRs, (3) willingness to pay and affordability seem as important QRs prioritization criteria as cost and benefits do, and (4) QRs engineering is perceived as a social activity and not as much as a tool and method centric activity. [Contribution] The main contributions of the paper are (i) the explication of the QRs process from SAs’ perspective, and (ii) the comparison of our findings with previously published results.
Maya Daneva, Luigi Buglione, Andrea Herrmann

A Persona-Based Approach for Exploring Architecturally Significant Requirements in Agile Projects

[Context and motivation] Architecturally significant requirements (ASRs) drive and constrain many aspects of the architecture. It is therefore beneficial to elicit and analyze these requirements in early phases of a project so that they can be taken into consideration during the architectural design of the system. Unfortunately failure to invest upfront effort in exploring stakeholders quality concerns, can lead to the need for significant refactoring efforts to accommodate emerging requirements. This problem is particularly evident in agile projects which are inherently incremental. [Question/Problem] Existing techniques for early discovery of ASRs, such as Win-Win and i*, are typically rejected by agile development teams as being somewhat heavy-weight. A light-weight approach is therefore needed to help developers identify and explore critical architectural concerns early in the project. [Principal ideas/results] In this paper we present the use of Architecturally-Savvy Personas (ASP-Lite). The personas are used to emerge and analyze stakeholders’ quality concerns and to drive and validate the architectural design. ASP-Lite emerged from our experiences working with the requirements and architectural design of the TraceLab project. The approach proved effective for discovering, analyzing, and managing architecturally significant requirements, and then for designing a high-level architectural solution which was designed to satisfy requirements despite significant interdependencies and tradeoffs. [Contributions] This paper presents the ASP-Lite approach and describes its support for architectural design in the US$2 Million TraceLab project.
Jane Cleland-Huang, Adam Czauderna, Ed Keenan

Natural Language Requirements

Using Clustering to Improve the Structure of Natural Language Requirements Documents

[Context and motivation] System requirements are normally provided in the form of natural language documents. Such documents need to be properly structured, in order to ease the overall uptake of the requirements by the readers of the document. A structure that allows a proper understanding of a requirements document shall satisfy two main quality attributes: (i) requirements relatedness: each requirement is conceptually connected with the requirements in the same section; (ii) sections independence: each section is conceptually separated from the others. [Question/Problem] Automatically identifying the parts of the document that lack requirements relatedness and sections independence may help improve the document structure. [Principal idea/results] To this end, we define a novel clustering algorithm named Sliding Head-Tail Component (S-HTC). The algorithm groups together similar requirements that are contiguous in the requirements document. We claim that such algorithm allows discovering the structure of the document in the way it is perceived by the reader. If the structure originally provided by the document does not match the structure discovered by the algorithm, hints are given to identify the parts of the document that lack requirements relatedness and sections independence. [Contribution] We evaluate the effectiveness of the algorithm with a pilot test on a requirements standard of the railway domain (583 requirements).
Alessio Ferrari, Stefania Gnesi, Gabriele Tolomei

Automatic Requirement Categorization of Large Natural Language Specifications at Mercedes-Benz for Review Improvements

Context and motivation: Today’s industry specifications, in particular those of the automotive industry, are complex and voluminous. At Mercedes-Benz, a specification and its referenced documents often sums up to 3,000 pages. Question/problem: A common way to ensure the quality in such natural language specifications is technical review. Given such large specifications, reviewers have major problems in finding defects, especially consistency or completeness defects, between requirements with related information, spread over the various documents. Principal ideas/results: In this paper, we investigate two specifications from Mercedes-Benz, whether requirements with related information spread over many sections of many documents can be automatically classified and extracted using text classification algorithms to support reviewers with their work. We further research enhancements to improve these classifiers. The results of this work demonstrate that an automatic classification of requirements for multiple aspects is feasible with high accuracy. Contribution: In this paper, we show how an automatic classification of requirements can be used to improve the review process. We discuss the limitations and potentials of using this approach.
Daniel Ott

Requirement Ambiguity Not as Important as Expected — Results of an Empirical Evaluation

[Context and motivation] Requirement ambiguity is seen as an important factor for project success. However, empirical data about this relation are limited. [Question/problem] We analyze how ambiguous requirements relate to the success of software projects. [Principal ideas/results] Three methods are used to study the relation between requirement ambiguity and project success. First, data about requirements and project outcome were collected for 40 industrial projects. We find that, based on a correlation analysis, that the level of ambiguity in the requirements for a project does not correlate with the project’s success. Second, using a root-cause analysis, we observe that ambiguity does not cause more defects during the test phase. Third, expert interviews were conducted to validate these results. This resulted in a framework that outlines factors influencing requirement-ambiguity risk. [Contribution] Empirical data are presented about the relationship between requirement ambiguity and project success. A framework is created to describe nine factors that increase or mitigate requirement-ambiguity risk.
Erik Jan Philippo, Werner Heijstek, Bas Kruiswijk, Michel R. V. Chaudron, Daniel M. Berry

The Design of SREE — A Prototype Potential Ambiguity Finder for Requirements Specifications and Lessons Learned

[Context and Motivation] Many a tool for finding ambiguities in natural language (NL) requirements specifications (RSs) is based on a parser and a parts-of-speech identifier, which are inherently imperfect on real NL text. Therefore, any such tool inherently has less than 100% recall. Consequently, running such a tool on a NL RS for a highly critical system does not eliminate the need for a complete manual search for ambiguity in the RS. [Question/Problem] Can an ambiguity-finding tool (AFT) be built that has 100% recall on the types of ambiguities that are in the AFT’s scope such that a manual search in an RS for ambiguities outside the AFT’s scope is significantly easier than a manual search of the RS for all ambiguities? [Principal Ideas/Results] This paper presents the design of a prototype AFT, SREE (Systemized Requirements Engineering Environment), whose goal is achieving a 100% recall rate for the ambiguities in its scope, even at the cost of a precision rate of less than 100%. The ambiguities that SREE searches for by lexical analysis are the ones whose keyword indicators are found in SREE’s ambiguity-indicator corpus that was constructed based on studies of several industrial strength RSs. SREE was run on two of these industrial strength RSs, and the time to do a completely manual search of these RSs is compared to the time to reject the false positives in SREE’s output plus the time to do a manual search of these RSs for only ambiguities not in SREE’s scope. [Contribution] SREE does not achieve its goals. However, the time comparison shows that the approach to divide ambiguity finding between an AFT with 100% recall for some types of ambiguity and a manual search for only the other types of ambiguity is promising enough to justify more work to improve the implementation of the approach. Some specific improvement suggestions are offered.
Sri Fatimah Tjong, Daniel M. Berry

RE and Quality

Factors Influencing User Feedback on Predicted Satisfaction with Software Systems

[Context and motivation] Requirements engineers need feedback from users on planned system features. The simplest way is to present feature descriptions to the users and ask for their opinion. [Problem/question] The feedback users can give in such a situation is not always accurate. The mechanisms which cause a mismatch between actual and predicted user satisfaction are currently not well understood. [Method/results] We used the results from a previous study we conducted, together with insights on consumer satisfaction from marketing, to create a working model of predicted user satisfaction. We validated the model with a new, more extensive empirical study. [Contribution] We present a model of predicted user satisfaction. Unlike the existing models of user satisfaction for software systems, it can be used for gathering feedback before a user has had experience with a software system. Our study shows that measuring predicted satisfaction can deliver a good approximation of actual satisfaction, although there is some prediction discrepancy which could be reduced by choosing the right combination of influence factors.
Rumyana Proynova, Barbara Paech – Towards a Semi-Formal, Open and Scalable Requirements Modeling Tool

[Context and motivation] This research preview presents ongoing work on a free software requirements modeling tool called reqT that is developed in an educational context. [Question/problem] The work aims to engage computer science students in Requirements Engineering (RE) through a tool that captures essential RE concepts in executable code. [Principal ideas] Requirements are modeled using an internal DSL in the Scala programming language that blends natural language strings with a graph-oriented formalism. [Contribution] The metamodel of reqT and its main features are presented and modeling examples are provided together with a discussion on initial experiences from student projects, limitations and directions of further research.
Björn Regnell

Maps of Lessons Learnt in Requirements Engineering: A Research Preview

[Context and Motivation] "Those who cannot remember the past are condemned to repeat it" – George Santayana. From the survey we conducted of requirements engineering (RE) practitioners, over 70% seldom use RE lessons in the RE process, though 85% of these would use such lessons if readily available. Our observation, however, is that, RE lessons are scattered, mainly implicitly, in the literature and practice, which, obviously, does not help the situation. [Problem/Question] Approximately 90% of the survey participants stated that not utilising RE lessons has significant negative impact on product quality, productivity, project delays and cost overruns. [Principal Ideas] We propose “maps” (or profiles) of RE lessons which, once populated, would highlight weak (dark) and strong (bright) areas of RE (and hence RE theories). Such maps would thus be: (a) a driver for research to “light up” the darker areas of RE and (b) a guide for practice to benefit from the brighter areas. [Contribution] The key contribution of this work is the concept of “maps” of RE lessons.
Ibtehal Noorwali, Nazim H. Madhavji


Requirements Traceability across Organizational Boundaries - A Survey and Taxonomy

[Context and motivation] Outsourcing of software development is an attractive business model. Companies expect cost reduction, enhanced efficiency, and exploited external resources. However, this paradigmatic shift also introduces challenges as stakeholders are spread across distinct organizations. [Question/problem] Requirements traceability supports stakeholders in satisfying information needs about developments and could be a viable way of addressing the challenges of interorganizational development. While requirements traceability has been the subject of significant research efforts, its application across organizational boundaries is a largely unexplored area. [Principal ideas/results] We followed a qualitative research approach. First, we developed a taxonomy identifying the needs of inter-organizational traceability. Second, we conducted semi-structured interviews with informants from 17 companies. Eventually, we applied qualitative content analysis to extract findings that supported and evolved our taxonomy. [Contribution] Practitioners planning and managing inter-organizational relationships can use our findings as a conceptual baseline to effectively leverage traceability in those settings. Effective traceability supports projects in accomplishing their primary goal of maximizing business value.
Patrick Rempel, Patrick Mäder, Tobias Kuschke, Ilka Philippow

Regulatory Requirements Traceability and Analysis Using Semi-formal Specifications

Information systems are increasingly distributed and pervasive, enabling organizations to deliver remote services and share personal information, worldwide. However, developers face significant challenges in managing the many laws that govern their systems in this multi-jurisdictional environment. In this paper, we report on a computational requirements document expressible using a legal requirements specification language (LRSL). The purpose is to make legal requirements open and available to policy makers, business analysts and software developers, alike. We show how requirements engineers can codify policy and law using the LRSL and design, debug, analyze, trace, and visualize relationships among regulatory requirements. The LRSL provides new constructs for expressing distributed constraints, making regulatory specification patterns visually salient, and enabling metrics to quantitatively measure different styles for writing legal and policy documents. We discovered and validated the LRSL using thirteen U.S. state data breach notification laws.
Travis D. Breaux, David G. Gordon

A Survey on Usage Scenarios for Requirements Traceability in Practice

[Context and motivation] Requirements traceability is known as an important part of development projects. Studies showed that traceability is applied in practice, but insufficient tool- and method-support hinders its practical use. [Question/problem] We conducted a survey to understand which traceability usage scenarios are most relevant for practitioners. Gaining this information is a required step for providing better traceability support to practitioners. [Principal ideas/results] We identified a list of 29 regularly cited usage scenarios and asked practitioners to assess the frequency of use for each in a typical development project. Our analysis is restricted to those 56 participants that were actively using traceability in order to ensure comparable results. Subjects held various roles in the development and reported about diverse projects. [Contribution] This study provides not only an initial catalog of usage scenarios and their relevance, but also provides insights on practitioner’s traceability practices. In result, we found all scenarios to be used by practitioners. Participants use traceability especially for: finding origin and rationale of requirements, documenting a requirement’s history, and tracking requirement or task implementation state. Furthermore, we highlight topics for ongoing evaluation and better method and tool support in the area of requirements traceability.
Elke Bouillon, Patrick Mäder, Ilka Philippow

RE and Business/Goals

The Emergence of Mutual and Shared Understanding in the System Development Process

[Context and motivation] In interdisciplinary requirements engineering, stakeholders need to understand how other disciplines think and work (mutual understanding) and agree on the system they develop (shared understanding) in order to collaborate effectively. [Question/problem] In this paper we analyse extent and forms of (lacking) mutual understanding according to the periods in the process of conceptual change. [Principal ideas/results] We analyse the communication of a multidisciplinary team while developing a mobile application. Although the team tried to resolve differences in meaning early on by applying approaches for clarification, questions for consolidation, exploration and elaboration occurred at different points in time throughout the process. Even when artefacts were already agreed upon, the development team explored lack of mutual understanding to underlying concepts or relationships. A revised shared understanding led to adjustments of the artefacts and thus hampered the process. [Contribution] We therefore call for research that explores ways of systematically building mutual and shared understanding in the development process.
Axel Hoffmann, Eva Alice Christiane Bittner, Jan Marco Leimeister

Highlighting Stakeholder Communities to Support Requirements Decision-Making

[Context & motivation] Stakeholders participation is recognized as a key issue in the development of useful and usable systems. The Web has given rise to a growing number of collaborative working tools that facilitated the participation of stakeholders (and especially end-users). These tools create new opportunities of practice regarding requirement elicitation. [Question/problem] Nevertheless, they result in an information overload lacking structure and semantics. Consequently, requirements analysis and selection becomes more challenging. [Principal ideas/results] In this paper, we propose an approach based on semantic web languages as well as concept lattices to identify relevant groups of stakeholders depending on their past participation. [Contribution] These groups can be used to enable facilitated decision-making and handling of requirements. We detail the different steps and the possible configurations, using an example inspired by a collaborative software development environment.
Zeina Azmeh, Isabelle Mirbel, Pierre Crescenzo

Choosing Compliance Solutions through Stakeholder Preferences

[Context and motivation] Compliance to relevant laws is increasingly recognized as a critical, but also expensive, quality for software requirements. [Question/Problem] Laws contain elements such as conditions and derogations that generate a space of possible compliance alternatives. During requirements engineering, an analyst has to select one of these compliance alternatives and ensure that the requirements specification she is putting together complies with that alternative. However, the space of such alternatives is often large. [Principal ideas and results] This paper extends Nòmos 2, a modeling framework for laws, to support modeling of and reasoning with stakeholder preferences and priorities. The problem of preferred regulatory compliance is then defined as a problem of finding a compliance alternative that matches best stakeholder preferences. [Contribution] The paper defines the concept of preference between situations and integrates it with the Nòmos 2 modeling language. It also presents a reasoning tool for preferences and illustrates its use with an extract from a use case concerning the Italian law on Electronic Health Record.
Silvia Ingolfo, Alberto Siena, Ivan Jureta, Angelo Susi, Anna Perini, John Mylopoulos

Supporting Decision-Making for Self-Adaptive Systems: From Goal Models to Dynamic Decision Networks

[Context/Motivation] Different modeling techniques have been used to model requirements and decision-making of self-adaptive systems (SASs). Specifically, goal models have been prolific in supporting decision-making depending on partial and total fulfilment of functional (goals) and non-functional requirements (softgoals). Different goalrealization strategies can have different effects on softgoals which are specified with weighted contribution-links. The final decision about what strategy to use is based, among other reasons, on a utility function that takes into account the weighted sum of the different effects on softgoals. [Questions/Problems] One of the main challenges about decisionmaking in self-adaptive systems is to deal with uncertainty during runtime. New techniques are needed to systematically revise the current model when empirical evidence becomes available from the deployment. [Principal ideas/results] In this paper we enrich the decision-making supported by goal models by using Dynamic Decision Networks (DDNs). Goal realization strategies and their impact on softgoals have a correspondence with decision alternatives and conditional probabilities and expected utilities in the DDNs respectively. Our novel approach allows the specification of preferences over the softgoals and supports reasoning about partial satisfaction of softgoals using probabilities. We report results of the application of the approach on two different cases. Our early results suggest the decision-making process of SASs can be improved by using DDNs.
Nelly Bencomo, Amel Belaggoun

Mapping i* within UML for Business Modeling

[Context and Motivation] Business modeling is nowadays a common approach in huge enterprise software developments. It notably allows to align business processes and supporting IT solutions at best, to produce a documentation of the company’s “savoir-faire” and to look for possible optimizations. The business modeling discipline of the Rational Unified Process (RUP) has enriched the semantic of the Unified Modeling Language’s (UML) use case diagrams for the special purpose of representing the organization’s processes with accurate elements. [Question/Problem] RUP/UML business use case scemantics are nevetheless only intended to further stereotype use case models and not to be used for reasoning. In parallel and in line with artificial intelligence concepts, researchers have developed the i* framework enabling the evaluation and decomposition of multiple design opportunities. RUP/UML business use case scemantics could be used more efficiently to integrate the latter benefits. [Principal ideas/results] Through a systematic mapping of elements from i* on the one side and of the RUP/UML business use case model on the other, we have set up a RUP/UML graphical notation for i* elements. Applicability has been shown on an illustrative example. [Contribution] The main contribution of the framework is allowing to model in an i* fashion using CASE-tools meant for RUP/UML and proposing an interface for forward engineering the produced model in a classical UML requirements model. Future work is required to fully validate the proposal, notably to measure the method’s efficacy.
Yves Wautelet, Manuel Kolp

Risk Identification at the Interface between Business Case and Requirements

[Motivation:] The requirements engineering (RE) research community is aware of the importance of performing feasibility studies before starting requirements elicitation. Unfortunately, projects still frequently fail to achieve commercial success, responsibility is often unknown, and requirements engineers may be deemed responsible for mistakes made by others. [Problem:] There is neither empirical evidence available from a post-mortem risk analysis for projects that performed adequate RE but commercially failed nor guidance for requirements engineers on validating a business case analysis to mitigate this risk. [Principal idea:] By performing a post-mortem analysis of software development projects that failed to achieve commercial success, we investigate the root causes for the failures and, in most cases, trace the causes back to business case issues. We identify risk areas and provide practical due diligence guidance to the practitioner. [Contribution:] This exploratory case study performs an in-depth review of a detailed post-mortem analysis of three software development projects performed over a 2.5 year period. Each of the analyzed projects failed to make the expected transition to commercialization despite using appropriate RE techniques and achieving satisfactory deliverables. The analysis identifies risk factors that the RE practitioner should consider and we provide a checklist for RE practitioners to use when checking for these risks in an antecedent business case as part of their due diligence. A low-cost commercial viability assessment technique, employing Fermi approximation, is provided to equip the RE practitioner with a risk mitigation tool in the absence of business analyst resources.
David Callele, Birgit Penzenstadler, Krzysztof Wnuk

RE and Software Development

Analyzing an Industrial Strategic Release Planning Process – A Case Study at Roche Diagnostics

[Context and motivation] Strategic release planning (SRP) for a globally used information system is a challenging task. Changes to requirements on different abstraction levels are arriving continuously and have an impact on long-term selected features. [Question/problem] The major question is how to successfully do SRP to create competitive advantage. [Principal ideas/results] An exploratory case study in an industrial context was conducted (1) to get a deeper understanding of the as-is SRP process in practice, (2) to evaluate the suitability of a to-be SRP process, introducing the EVOLVE II method and corresponding ReleasePlanner tool and (3) to gather additional requirements for the to-be SRP process, with respect to feature generation and feature selection. [Contribution] In this paper we describe the case study and present lessons learned to improve and customize a SRP process in practice. In particular, we propose the Requirements Abstraction and Solution Model (RASM) to support feature generation.
Gabriele Zorn-Pauli, Barbara Paech, Tobias Beck, Hannes Karey, Guenther Ruhe

Redefinition of the Requirements Engineer Role in Mjølner’s Software Development Process

[Context and motivation] Our company’s software development process describes seven roles, one of which is the requirements engineer. We want the work of the requirements engineer to give more benefit in our development projects than is currently the case.
[Question/problem] The requirements engineer works in an interdisciplinary setting closely together with the other roles, in particular with the user experience specialist, the software architect, and the project manager. We have found that these three roles are performing most of the actual RE work in our projects. As a consequence, the requirements engineer often only plays a minor role, which is also explained by the fact that the requirements engineer role is not given high organisational attention. With a few exceptions, the requirements engineer is appointed ad hoc, at project level. This poses a potential risk of neglecting important RE activities. The problem that we address is how to best distribute responsibilities between the requirements engineer role and the other roles in our organization.
[Principal ideas/results] We have surveyed a number of recent projects and have analysed to which extent RE has been carried out, by which roles, and with which techniques and tools.
[Contribution] Our contribution is to discuss our survey results and on this basis propose a redefinition of the requirements engineer role that respects that user experience, software architecture, and project management have a higher organisational priority.
Anders Bennett-Therkildsen, Jens Bæk Jørgensen, Kim Nørskov, Niels Mark Rubin

Distances between Requirements Engineering and Later Software Development Activities: A Systematic Map

[Context and Motivation] The main role of requirements engineering (RE) is to guide development projects towards implementing products that will appeal to customers. To effectively achieve this RE needs to be coordinated with and clearly communicated to the later software development activities. [Question/Problem] Communication gaps between RE and other development activities reduce coordination and alignment, and can lead to project delays and failure to meet customer needs. [Principle ideas/results] The main hypothesis is that coordination is enhanced by proximity to RE roles and artefacts, and that distances to later activities increase the effort needed to align requirements with other development work. Thirteen RE-related distances have been identified through a systematic map of existing research. [Contribution] Reported distances are mapped according to research type, RE activity and later software development activities. The results provide an overview of RE distances and can be used a basis for defining a theoretical framework.
Elizabeth Bjarnason

Analyzing the Tracing of Requirements and Source Code during Software Development

A Research Preview
[Context and motivation] Traceability links between requirements and code are often created after development, which can, for example, lead to higher development effort. To address this weakness, we developed in previous work an approach that captures traceability links between requirements and code as the development progresses by using artifacts from project management called work items. [Question/problem] It is important to investigate empirically what is the best way to capture such links and how these links are used during development. [Principal ideas/results] In order to link requirements, work items and code during development, we extended our approach from previous work by defining three traceability link creation processes. We are applying these processes in practice in a software development project conducted with undergraduate students. The results indicate that our approach creates correct traceability links between requirements and code with high precision/recall during development, while developers mainly used the third process to link work items after implementation. Furthermore, the students used a subset of the created traceability links for navigating between requirements and code during the early phase of the development project. [Contribution] In this paper, we report on preliminary empirical results from applying our approach in practice.
Alexander Delater, Barbara Paech

RE in Practice

Requirements Engineering Meets Physiotherapy: An Experience with Motion-Based Games

[Context and motivation] In the last years motion-based games have achieved an increasing success. These games have great potential to support physiotherapeutic programs, as they can guide the patients in performing the right movements for their rehabilitation. [Question/problem] However, on the one hand, existing games performed on commercial systems (e.g., Wii, Kinect) are not suitable for people affected by motor pathologies. On the other hand, the design of games for physiotherapy is hard, as they should meet the “physiotherapy requirements” of the medical staff, provide an enjoyable experience to the patients, and overcome the technical limitations of the systems that support their execution. [Principal ideas/results] These limitations can be addressed by defining a standard process, independent from the considered pathology and that starts from the requirements collection and representation, to support the development of motion-based games for physiotherapy [Contribution] For this reason, this paper proposes RE-FIT, a methodology to elicit and model the RE-FIT extends existing requirements elicitation (brainstorming, surveys, and direct observation) and modeling techniques (FLAGS goal model). RE-FIT was developed in collaboration with the Spinal Unit of Niguarda Hospital and the Respiratory Medicine Section of Policlinico in Milan. Our experience demonstrated that RE-FIT is not only suitable to develop new physiotherapeutic games, but also to evaluate the adequacy of existing games for people affected by a specific pathology.
Liliana Pasquale, Paola Spoletini, Dario Pometto, Francesco Blasi, Tiziana Redaelli

Use Case and Requirements Analysis in a Remote Rural Context in Mali

[Context & motivation] Few studies have reported on a systematic use case and requirements analysis of low-tech, low-resource contexts such as rural Africa. This, despite the widespread agreement on the importance of Information and Communication Technologies (ICT) for social and rural development, and despite the large number of ICT projects targeting underprivileged communities. [Question/problem] Unfamiliarity with the local context and differences in cultural and educational backgrounds between end-users and software engineers are the challenges for requirements engineering (RE) we encountered. [Principal ideas/results] We describe a systematic approach to RE in developing areas, based on the Living Lab methodology. Our approach is supported by extensive field research and based on co-creation within a multi-disciplinary and multi-cultural team of developers and users. This approach creates a shared understanding of the problem and its local context, and optimizes communication. [Contribution] We illustrate the approach using a case study of web- and voice-based communication services, that we developed for a rural context in Mali.
Anna Bon, Victor de Boer, Nana Baah Gyan, Chris van Aart, Pieter De Leenheer, Wendelien Tuyp, Stephane Boyera, Max Froumentin, Aman Grewal, Mary Allen, Amadou Tangara, Hans Akkermans

Requirements Engineering in Practice: There Is No Requirements Engineer Position

[Context and motivation] For the requirements engineering (RE) community it is clear that requirements engineering is a specific activity and role within software development. [Question/problem] However: What about practice? Is RE seen there as a separate role? What qualifications do practitioners see as critical for this task? [Principal ideas/results] 141 job advertisements from 2009 and 67 from 2012 were analysed statistically in order to find out how practice perceives and staffs RE: Which official job title do those persons have who do RE? Which further responsibilities do these persons have? Which qualifications are demanded? [Contribution] The study´s main results are: The position “requirements engineer” hardly exists. RE instead is done by consultants, software engineers, architects, developers and project managers, who additionally have an average of 3 further tasks. RE is no task for job beginners: 73% of the job advertisements wish or demand previous job experience. Further important qualifications are: 94% soft skills (the Top 3 soft skills are: capacity for teamwork, English language and communication skills), 76% demand knowledge with respect to the technology used, while only 34% mention RE knowledge. RE is most often combined with solution design (77% respectively 61%).
Andrea Herrmann

Product Lines and Product Management

Effective Requirements Elicitation in Product Line Application Engineering – An Experiment

[Context & Motivation] Developing new software systems based on a software product line (SPL) is still a time-consuming task and the benefits of using such an approach are often smaller than expected. One important reason for this are difficulties in systematically mapping customer requirements to characteristics of the SPL. [Question/problem] Even though it has been recognized that the success of reuse strongly depends on how requirements are treated, it remains unclear how to perform this in an optimal way. [Principal ideas/results] In this paper, we present a controlled experiment performed with 26 students that compared two requirements elicitation approaches when instantiating a given SPL. [Contribution] Our findings indicate that a novel, problem-oriented requirements approach that explicitly integrates the reuse of SPL requirements into the elicitation of customer-specific requirements is more effective than a traditional SPL requirements approach, which distinguishes requirements reuse and additional elicitation customer-specific requirements.
Sebastian Adam, Klaus Schmid

Monitoring System-of-Systems Requirements in Multi Product Lines

[Context and motivation] Large-scale software-intensive systems are often considered as systems of systems comprising several interrelated product lines from which system variants are derived to meet the overall requirements. [Question/problem] If multiple teams and experts configure these individual systems, their individual configuration choices might conflict with the system-of-systems requirements. [Principal ideas/results] This research preview paper presents our ongoing work on a tool-supported approach for monitoring system-of-systems requirements formalized as constraints during distributed product derivation in multi product lines. [Contribution] The approach allows detecting violations of multi system requirements during the configuration of individual systems and provides immediate feedback to the involved configurers. Our approach is integrated in the product configuration tool DOPLER developed in cooperation with an industrial partner.
Thomas Klambauer, Gerald Holl, Paul Grünbacher

Adjusting to Increasing Product Management Problems: Challenges and Improvement Proposals in One Software Company

[Context and motivation] This paper seeks to understand the essential product management challenges that one software product company has recently started to face. [Question/problem] The paper illustrates how the case company, Maestro, has been forced to adjust its management style due to the increasingly complex and turbulent business environment. The paper further illustrates how the evolving management style has affected the way product requirements are managed. [Principal ideas/results] The comparison of our results with existing product management literature suggests that traditional product management approaches are becoming increasingly inadequate to deal with growing amounts of interpretations, requirements interdependencies and market turbulence. [Contribution] The findings of this paper indicate a need for examining literature from management and organizational sciences in order to expand the traditional view of requirements models as static and purely design-time entities towards new kinds of approaches that are more effective in dealing with complexity and turbulence. The paper eventually results with an identification of research gaps and important topics for future research.
Sami Jantunen, Kati Hietaranta, Donald C. Gause


Weitere Informationen

Premium Partner