Requirements Engineering: Foundation for Software Quality

[Context and motivation] Finding a balance between commercial (customer specific, market pull and external quality requirements) and internal quality requirements is a recognized challenge in market driven software product development (MDSPD). In order to address this challenge it is important to understand the preferences and biases influencing decision makers selecting requirements for software releases. [Question/problem] Prospect theory has been successfully applied to many disciplines. Applying it to MDSPD suggests decision makers will avoid risk when selecting between commercial requirements, take risk with internal quality requirements, and prefer commercial requirements over internal quality requirements in order to maximize their perceived value. This paper seeks to investigate this claim. [Principal ideas/results] This paper presents an experiment investigating whether the biases proposed by prospect theory can be seen operating in MDSPD requirements engineering (RE). The results indicate risk avoidance when dealing commercial requirements, while greater risk is taken when dealing with internal quality requirements. [Contribution] As this is the first paper to use prospect theory to explain requirements selection decisions, it presents opportunity to educate people in the biases they bring to the RE process, and facilitate the creation of strategies for balancing the different requirements types.

[Context and motivation] Service Management has been steadily gaining in importance in many organizations and is becoming a major force of change in IT departments. ITIL, one of the main service management frameworks, defines the value of a service for its customers as the sum of the service utilities and service warranties but provides no specific rules for defining them. [Question/problem] Companies, IT departments and their consultants face difficulties defining utilities and warranties, as well as identifying their value for customers. [Principal ideas/results] We propose a general framework for understanding service requirements and for analyzing the quality of a service. The framework is based on General Systems Thinking. We define service utilities as norms created by the service for a given stakeholder. Service warranties then protect the stakeholder from variations of these norms as a result of threats. Value is created when the norms are maintained within the tolerance range of the stakeholder. Risk is defined as the possibility of detrimental consequences for a stakeholder if the norm is pushed outside its tolerance range. [Contribution] We believe that this work has the potential to advance theory and practice of service management in both academia and industry, and to reduce the risk of overlooking important service properties when defining service requirements.

[Context and motivation] In market-driven product development of software intensive products large numbers of requirements threaten to overload the development organization. It is critical for product management to select the requirements aligned with the overall business goals, product strategies and discard others as early as possible. Thus, there is a need for an effective and efficient method that deals with this challenge and supports product managers in the continuous effort of early requirements triage [1, 2] based on product strategies. This paper evaluates such a method – A Method for Early Requirements Triage Utilizing Product Strategies (MERTS), which is built based on the needs identified in literature and industry. [Question/problem] The research question answered in this paper is “If two groups of subjects have a product strategy, one group in NL format and one in MERTS format, will there be a difference between the two groups with regards to effectiveness and efficiency of requirements triage?” The effectiveness and efficiency of the MERTS were evaluated through controlled experiment in a lab environment with 50 software engineering graduate students as subjects. [Principal ideas/results] It was found through results that MERTS method is highly effective and efficient. [Contribution] The contribution of this paper is validation of effectiveness and efficiency of the product strategies created through MERTS method for requirements triage, prior to industry trials. A major limitation of the results is that the experiment was performed with the graduate students and not the product managers. However, the results showed that MERTS is ready for industry trials.

[Context and motivation] Most software products are developed and improved over time in iterative releases. Defining the contents of the next product release is an important, but challenging activity, as a large number of potential requirements is typically available. [Question/problem] Implementing these requirements in a single release is impossible, and prioritizing them is hard: which requirements deliver the most value, and what is their value exactly? A study among European software companies in the context of the Flexi project revealed that this release definition challenge is still significant, in spite of the available state-of-the-art. [Principle ideas/results] This paper reports on a number of myths surrounding release definition we observed during the study, and explains shortcomings of the available state-of-the-art in a context where many requirements should be considered and defining and quantifying value is hard. [Contribution] We then propose a novel approach for reducing the risk of making wrong choices, based on emerging social technologies.

[Context and motivation] Requirements engineering methods and examples presented in textbooks and scientific publications usually treat software which is developed - and therefore specified - from scratch. However, in the software development practice, this situation is very rare. In an industry case study, we encountered the situation that a software system in use had to be enhanced by a small delta. [Question/problem] Our objective was to specify these delta requirements without having to describe the complete system in detail. Therefore we explored how much of the existing system had to be specified in order to make the delta requirements understandable. [Principal ideas/results] We made an intensive literature search to proven practices. As we were not successful we applied the requirements engineering method TORE and extended it to capture the delta requirements. [Contribution] In this paper we describe a process for capturing delta requirements. To our knowledge, this is the first work about this practically relevant question. In our case study, hierarchical refinement of requirements top-down and iterative requirements prioritization successfully supported the specification of deltas, combined with a high-level specification of the existing system. We also present our experiences during the case study and propose ideas for further research.

[Context and motivation] All systems are susceptible to the need for change, with the desire to operate in changeable environments driving the need for software adaptation. A Dynamically Adaptive System (DAS) adjusts its behaviour autonomously at runtime in order to accommodate changes in its operating environment, which are anticipated in the system’s requirements specification. [Question/Problem] In this paper, we argue that Dynamic Adaptive Systems’ requirements specifications are more susceptible to change than those of traditional static systems. We propose an extension to i* strategic rationale models to aid in changing a DAS. [Principal Ideas/Results] By selecting some of the types of tracing proposed for the most complex systems and supporting them for DAS modelling, it becomes possible to handle change to a DAS’ requirements efficiently, whilst still allowing artefacts to be stored in a Requirements Management tool to mitigate additional complexity. [Contribution] The paper identifies different classes of change that a DAS’ requirements may be subjected to, and illustrates with a case study how additional tracing information can support the making of each class of change.

[Context and motivation] The principle of “divide and conquer” suggests that complex software problems should be decomposed into simpler problems, and those problems should be solved before considering how they can be composed. The eventual composition may fail if solutions to simpler problems interact in unexpected ways. [Question/problem] Given descriptions of individual problems, early identification of situations where composition might fail remains an outstanding issue. [Principal ideas/results] In this paper, we present a tool-supported approach for early identification of all possible interactions between problems, where the composition cannot be achieved fully. Our tool, called the OpenPF, (i) provides a simple diagramming editor for drawing problem diagrams and describing them using the Event Calculus, (ii) structures the Event Calculus formulae of individual problem diagrams for the abduction procedure, and (iii) communicates with an off-the-shelf abductive reasoner in the background and relates the results of the abduction procedure to the problem diagrams. The theory and the tool framework proposed are illustrated with an interaction problem from a smart home application. [Contribution] This tool highlights, at an early stage, the parts in problem diagrams that will interact when composed together.

[Context and motivation] Ever-growing systems’ complexity and novel requirements engineering approaches such as reuse or globalization imply that requirements are produced by different stakeholders and written in possibly different languages. [Question/ problem] In this context, checking consistency so that requirements specifications are amenable to formal analysis is a challenge. Current techniques either fail to consider the requirement set as a whole, missing certain inconsistency types or are unable to take heterogeneous (i.e. expressed in different languages) specifications into account. [Principal ideas/ results] We propose to use model composition to address this problem in a staged approach. First, heterogeneous requirements are translated in model fragments which are instances of a common metamodel. Then, these fragments are merged in one unique model. On such a model inconsistencies such as under-specifications can be incrementally detected and formal analysis is made possible. Our approach is fully supported by our model composition framework. [Contribution] We propose model composition as means to address flexibility needs in requirements integration. Threats to validity such as the impact of new requirements languages needs to be addressed in future work.

[Context and motivation] Experiences in working with customers in the software development community have shown that the language used to talk about requirements is inconsistent. Because of this inconsistency, projects are struggling to develop products that meet the organizations’ goals. [Question/problem] An inconsistent terminology leads to barriers to communication, which increases both the cost and length of time of development. In addition, the artifacts of requirements planning efforts are often ill-defined, and the team creates products that are not aligned with the organization’s goals. [Principal ideas/results] As an attempt at resolving this inconsistent terminology and its fallout, this paper outlines the need for a common language. We propose a solution in the form of a Requirements Object Model (ROM) and study the use of the ROM in the requirements efforts on three software development projects. [Contribution] Evidence from these three projects demonstrates that the adoption of a common terminology leads to improved communication among project teams, and as a result, alignment about the business objectives for software development projects was achieved.

[Context & motivation] When large organizations develop systems for large markets, the size and complexity of the work artefacts of requirements engineering impose critical challenges. [Problem] This paper presents an industrial case study with the goal to increase our understanding of large-scale requirements engineering practice. We focus on a senior requirements engineering role at our case company, called requirements architect, responsible for quality and coordination of large requirements repositories.[Results] Based on interviews with 7 requirements architects, we present their tasks and views on architecture quality. [Contribution] Our results imply further research opportunities in large-scale requirements engineering.

[Context & motivation] The need of organizational modelling during the requirements engineering process of an information system has been widely acknowledged, and business process modelling can be considered a must. Nonetheless, the specification of functional requirements can be inadequate if business processes are not properly analysed so as to elicit these requirements. [Question/problem] There is a gap between business processes and functional requirements that must be bridged in order to specify the functional requirements of an information system. In addition, means of precisely and homogeneously elicit these requirements from business processes are necessary. [Principal ideas/results] The goals of this paper are: 1) to present an approach that provides methodological guidance to properly specify functional requirements from business processes; and 2) to report on practical experience using the approach. The approach is based on the analysis and graphical enrichment of BPMN diagrams for the elicitation and specification of functional requirements in the form of task descriptions, and it has been applied in field trials with a software development company. [Contribution] The main contributions of the paper are: 1) the extension of BPMN for proper elicitation of task descriptions; 2) the provision of detailed guidance in order to adequately use BPMN diagrams for the specification of task descriptions; and 3) the presentation of the lessons learnt by using the approach.

[Context and motivation] The starting point for software development is usually the system requirements. The requirements, especially nonfunctional requirements specified in a document are often incomplete and inconsistent with the initial user needs and expectations. [Question/problem] Experience at Siemens showed us that programmers working on software development often have trouble interpreting under-specified non-functional requirements, resulting in code that does not meet the users’ quality expectations and contains “quality faults” that can only be detected later through expensive user acceptance testing activities. [Principal ideas/results] In this problem statement paper, we investigate the need for clarifying non-functional requirements in software specifications to improve user acceptance. In particular we focus on establishing the role of non-functional requirements on user acceptance. [Contribution] Our contribution is that we emphasize the need for a systematic empirical study in this area. We propose a possible set-up where a number of hypotheses have been developed that a systematic experiment will help to validate. Our work is based on industrial experiments at Siemens, in the particular context of the installation of a Product Lifecycle Management (PLM) system.

[Context and motivation] A number of ethnographic approaches are available to gather requirements where they emerge, i.e. in the workplace of future system users. [Question/problem] Most of these approaches do not provide guidance and software tool support for on-site analysts. [Principal ideas/results] In this paper we present a tool-supported contextual method that combines key benefits of contextual inquiry and scenario-based techniques. It aims to improve guidance and support for on-site analysts performing a contextual requirements discovery. [Contribution] We applied this method in the Austrian Alps to discover stakeholder’s requirements for a ski tour navigation system. This paper reports on this inquiry and analyses its results. Moreover, we discuss lessons learned and conclusions.

[Context and motivation] Creativity is indispensable for software systems to deliver progress and competitive advantage for stakeholders. Yet it is rarely supported in requirements processes. [Question/problem] This paper investigated integration of two software tools, one for generating requirements with scenarios, the other for supporting people to think creatively while finding and collecting information. The effectiveness of the integration was investigated. [Principal ideas/results] The technical integration is described, and an evaluation is reported. [Contribution] Results reveal some effect on the novelty of the requirements generated, and have implications for the design of tools to support creative requirements processes.

[Context and motivation] Two years ago, the authors conducted an extensive meta-analysis of the requirements engineering (RE) literature and reported a demographic analysis by date, type, outlet, author, and author affi liation for just over 4,000 RE publications. We have now added two more years and 1,200 more publications. [Question/ problem] The current paper continues this analysis to see if the same publication trends in RE continue or if unique new trends are emerging. It explores the past ten years in more depth, and separately analyzes the trends in journals. [Principal ideas/results] The study uncovers some continuing trends: (1) European Union countries continue to be the leaders in publishing RE papers, (2) the UK continues to surpass most countries in annual production, (3) the USA continues to lose market share, and (4) the same institutions lead the effort. But some new trends emerge as well: (1) total production of papers in RE has decreased since its high in 2005, (2) the average number of authors per paper has increased, (3) non-RE-specific conferences and non-RE-specific conferences have published fewer RE papers, and (4) some institutions strong in RE paper production in general are not as productive with respect to journal articles, and vice versa. [Contribution] This paper enables RE researchers to understand where RE research is being conducted and where results are being published. Although we report some interesting trends, the data cannot help us understand causes of these trends.

[Context and motivation] Case studies have the potential to be an essential bridge between the constructive (build new theories, algorithms, or methods to address practical problems) and the empirical (develop evidence through observation of or experience with existing methods or artifacts in practice) approaches to requirements engineering research. [Question/problem] To realize this potential, our aim is to provide representational guidance for designing a case study as a part of the invention process of a novel requirements engineering methodology (REM). [Principal ideas/results] In this paper, we present the innovative use of assurance cases to emphasize argumentation and rigorous evidence planning during case study research design. [Contribution] The steps involved in case study research design using the assurance case notation are outlined as a systematic way to plan a validation effort for a REM.

[Context and motivation] The use of conceptual models in automotive requirements engineering is impaired due to the lack of appropriate modelling guidelines. [Question/problem] The goal of this paper is to propose a requirements reference model that serves as the basis for defining such guidelines. [Principal ideas/results] The reference model distinguishes three abstraction layers and three content categories for requirements models. [Contribution] The reference model has been successfully applied in the REMsES project to support the development of a model-based requirements engineering approach for the automotive domain.

[Context and motivation] In market-driven software development it is crucial, but challenging, to find the right balance among competing quality requirements (QR). [Problem] In order to identify the unique challenges associated with the selection, trade-off, and management of quality requirements an interview study is performed. [Results] This paper describes how QR are handled in practice. Data is collected through interviews with five product managers and five project leaders from five software companies. [Contribution] The contribution of this study is threefold: Firstly, it includes an examination of the interdependencies among quality requirements perceived as most important by the practitioners. Secondly, it compares the perceptions and priorities of quality requirements by product management and project management respectively. Thirdly, it characterizes the selection and management of quality requirements in down-stream development activities.

[Context and motivation] The clustering of system requirements groups together related requirements. In a concept paper, we had previously proposed a requirements clustering approach for the purpose of modularizing software. [Question/problem] In this short paper, we describe a preliminary study to explore the answer to the posed question: whether or not requirements clustering leads to modular design as measured by design goodness criteria. [Principal ideas/results] The study assesses the modularity of software designs developed by independent groups given the same requirements. These are then compared against the expected design resultant from implementing the requirements cluster. [Contribution] The study results are encouraging and it warrants further investigation.

[Context and motivation] The use of websites for gathering and prioritizing requirements in large-scale distributed projects is becoming increasingly prevalent in the software industry. These websites include both forums and wiki-style collaborative tools, and are designed to allow large numbers of stakeholders to participate in the requirements gathering process. [Question/problem] This paper explores and evaluates the forum-based requirements gathering and prioritization processes adopted by vendor-based open source software projects. The findings of this work have implications far beyond the domain of open source projects as they highlight requirements processes that could be applicable to any distributed, web-based requirements process. [Principal ideas/result] The effectiveness of various requirements gathering and prioritization practices adopted by vendor-based projects are evaluated, through observing how feature requests are managed in the forums, and also through a survey of vendor-based forum users and project managers. [Contribution] Our results highlight practices that could lead to more effective requirements processes in web-based requirements gathering and prioritization tools.