Requirements Engineering: Foundation for Software Quality

[Context and motivation] In 2009 Denmark got a compulsory IT system for Land Registration of ownership. It soon created a national disaster because selling houses and getting mortgages might take months, rather than a couple of days. In this period, house owners had to pay a much higher interest rate. [Question/problem] The press claimed it was yet another IT failure, but actually the IT system worked as intended. What was the real cause? [Principal ideas/results] The visible problem was overloaded staff in the Registry Office, but behind this were optimistic estimates of human performance, lack of usability, insufficient user interface requirements, unrealistic SOA requirements, immature risk analysis, and other factors. [Contribution] This paper shows details of the requirements, what went wrong, and what could have been done, e.g. early design of the user interface and giving the supplier more influence on the architecture.

[Context and motivation] The tender process is a special requirements engineering process. The customer provides a request for proposal (RFP) with requirements of varying detail. Several software companies answer with a solution proposal. The customer chooses the supplier according to the price and the quality of the proposed solution. So far very little has been published on how the requirements engineering process of the suppliers in producing the solution proposal should be performed. [Question/problem] The main challenges of the tender process for the supplier are that the RFP is very big and the solution proposal has to be produced in a very tight time frame. Furthermore, there is typically very little direct communication between customer and supplier, which is needed to clarify the requirements in the RFP. So, the supplier needs to guess the meaning of the requirements. [Principal ideas/results] The main idea to overcome these challenges is to produce a structured documentation of available solutions and typical risks experienced in former tender processes. This documentation can be used to identify the most important risks of the current tender process and to efficiently produce a viable solution proposal. [Contribution] In this paper we report on the experiences of a supplier company with tender processes. We summarize the challenges of the requirements engineering for tender processes from the viewpoint of the supplier and we describe the solutions envisaged by this company for these challenges.

[Context & motivation] Large contractual projects often have to comply against government regulations and standards. [Question/problem] In such a context, the contractual document can be voluminous, and there can be a large number of standards and regulations to follow. These documents typically form a complex interrelationship network. This means that in the requirements engineering (RE) process, this network needs to be analysed for deriving project requirements to be implemented. A key activity of this RE process is to demonstrate compliance by showing, through appropriate traces, that all relevant requirements have been elicited from the regulatory documents. [Principal ideas/results] [Contribution] In this problem-statement paper, we describe some key impediments to achieving requirements-compliance that we have identified in a large systems engineering project.

This paper presents the analysis and key findings of a survey about dealing with non-functional requirements (NFRs) among architects. We find that, as long as the architect is aware of the importance of NFRs, they do not adversely affect project success, with one exception: highly business critical modifiability tends to be detrimental to project success, even when the architect is aware of it. IT projects where modifiability is perceived to have low business criticality lead to consistently high customer satisfaction. Our conclusion is that modifiability deserves more attention than it is getting now, especially because in general it is quantified and verified considerably less than other NFRs. Furthermore, IT projects that applied NFR verification techniques relatively early in development were more successful on average than IT projects that did not apply verification techniques (or applied it relatively late in development).

[Context and motivation] Quality requirements are a main driver for architectural decisions of software systems. Although the need for iterative handling of requirements and architecture has been identified, current architecture design processes do not provide systematic, quantitative feedback for the prioritization and cost/benefit considerations for quality requirements. [Question/problem] Thus, in practice stakeholders still often state and prioritize quality requirements before knowing the software architecture, i.e. without knowledge about the quality dependencies, conflicts, incurred costs, and technical feasibility. However, as quality properties usually are cross-cutting architecture concerns, estimating the effects of design decisions is difficult. Thus, stakeholders cannot reliably know the appropriate required level of quality. [Principal ideas/results] In this research proposal, we suggest an approach to generate feedback from quantitative architecture evaluation to requirements engineering, in particular to requirements prioritization. We propose to use automated design space exploration techniques to generate information about available trade-offs. Final quality requirement prioritization is deferred until first feedback from architecture evaluation is available. [Contribution] In this paper, we present the process model of our approach enabling feedback to requirement prioritization and describe application scenarios and an example.

Requirement volatility is a common and inevitable project risk which has severe consequences on software projects. When requirement change occurs, a project manager wants to analyze its impact so as to better cope with it. As the modification to one requirement can cause changes in its dependent requirements and its dependency relationship, the impact analysis can be very complex. This paper proposes a simulation approach DepRVSim (Requirement Volatility Simulation considering Dependency relationship) to assessing this sort of impact. We abstract the general patterns of the influence mechanism, which may trigger modification in its dependency relationship and bring changes in other requirements through dependency. DepRVSim can generate such information as the probability distribution of effort deviation and schedule deviation. As a proof-of-concept, the applicability of DepRVSim is demonstrated with an illustrative case study of a real software project. Results indicate that DepRVSim is able to provide experimental evidence for decision making when requirement changes.

[Context and motivation] There is considerable flexibility in requirements specifications (both functional and non-functional), as well as in the features of available OSS components. This allows a collaborative matching and negotiation process between stakeholders such as: customers, software contractors and OSS communities, regarding desired requirements versus available and thus reusable OSS components. [Problem] However, inconclusive research exists on such cooperative processes. Not much empirical data exists supporting the conduction of such research based on observation of industrial OSS adoption projects. This paper investigates how functional and non-functional requirement mismatches are handled in practice. [Results] We found two common approaches to handle functional mismatches. The main resolution approach is to get the components changed by the development team, OSS community or commercial vendor. The other resolution approach is to influence requirements, often by postponing requirements. Overall, non-functional requirements are satisfactorily achieved by using OSS components. Last but not least, we found that the customer involvement could enhance functional mismatch resolution while OSS community involvement could improve non-functional mismatch resolution. [Contribution] Our data suggests that the selecting components should be done iteratively with close collaboration with stakeholders. Improvement in requirement mismatch resolution to requirements could be achieved by careful consideration of mismatches size, requirements flexibility and components quality.

Effective requirements management plays an important role when it comes to the support of product development teams in the automotive industry. A precise positioning of new cars in the market is based on features and characteristics described as requirements as well as on costs and profits. [Question/problem] However, introducing or changing requirements does not only impact the product and its parts, but may lead to overhead costs in the OEM due to increased complexity. The raised overhead costs may well exceed expected gains or costs from the changed requirements. [Principal ideas/results] By connecting requirements with direct and overhead costs, decision making based on requirements could become more valuable. [Contribution] This problem statement results from a detailed examination of the effects of requirements management practices on process complexity and vice versa as well as on how today’s requirements management tools assist in this respect. We present findings from a joined research project of RWTH Aachen University and Volkswagen.

[Context and Motivation] The word “creativity” is used widely in business and academia, but its meaning may differ greatly depending on context. This may cause confusion in the minds of requirements engineers who have to determine which kinds of creativity are relevant to their project and which creativity tools to use. [Question/Problem] The main goal of this work is to understand why and how the meaning of the word “creativity” varies, and study the impacts of these variations on requirements engineering. [Principal ideas / results]. A comparative review of creativity-related literature from Social Sciences and Requirements Engineering was performed. [Contributions] This study results in a new framework for understanding the precise local meaning of creativity used in a specific context, before deciding on the adequate support for it. Since creativity in RE is still a relatively new topic, research directions are also proposed.

[Context and motivation] In air traffic management (ATM) safety assessments are performed with traditional techniques such as failure mode and effect analysis (FMEA). [Question/problem] As system modelling is becoming an increasingly important part of developing ATM systems, techniques that integrate safety aspects and modelling are needed. [Principal ideas/results] This paper proposes an approach for thorough failure analysis of ATM systems that consist of several interacting components and similar systems. The new technique is called failure sequence diagrams (FSD) and supports FMEA in modelling failures and their effects through interactions between system components. FSD has been used in a case study by safety and system engineers in three different ways. [Contribution] The study suggests that FSD was easy to use and supported FMEA well, but did not cover its weakness in analysing multiple failures.

[Context and motivation] Security engineering is one of the important concerns during system development. It should be addressed throughout the whole system development process. There are several languages for security modelling that help dealing with security risk management at the requirements stage. [Question/problem] In this paper, we are focusing on Mal-activity diagrams that are used from requirement engineering to system design stage. More specifically we investigate how this language supports information systems security risks management (ISSRM). [Principal ideas/results] The outcome of this work is an alignment table between the Mal-activity diagrams language constructs to the ISSRM domain model concepts. [Contribution] This result may help developers understand how to model security risks at the system requirement and design stages. Also, it paves the way for interoperability between the modelling languages that are analysed using the same conceptual framework, thus facilitating transformation between these modelling approaches.

[Context and motivation] i* is one of the most popular modelling languages in Requirements Engineering. i* models are meant to support communication between technical and non-technical stakeholders about the goals of the future system. Recent research has established that the effectiveness of model-mediated communication heavily depends on the visual syntax of the modelling language. A number of flaws in the visual syntax of i* have been uncovered and possible improvements have been suggested. [Question/problem] Producing effective visual notations is a complex task that requires taking into account various interacting quality criteria. In this paper, we focus on one of those criteria: Semantic Transparency, that is, the ability of notation symbols to suggest their meaning. [Principal ideas/results] Complementarily to previous research, we take an empirical approach. We give a preview of a series of experiments designed to identify a new symbol set for i* and to evaluate its semantic transparency. [Contribution] The reported work is an important milestone on the path towards cognitively effective requirements modelling notations. Although it does not solve all the problems in the i* notation, it illustrates the usefulness of an empirical approach to visual syntax definition. This approach can later be transposed to other quality criteria and other notations.

[Context & Motivation] Developing new software systems based on a software product line (SPL) in so-called application engineering (AE) projects is still a time-consuming and expensive task. Especially when a large number of customer-specific requirements exists, there is still no systematic support for efficiently aligning these non-anticipated requirements with SPL characteristics early on. [Question/problem] In order to improve this process significantly, sound knowledge about an SPL must be available when guiding the requirements elicitation during AE. Thus, an appropriate reflection of SPL characteristics in process-supporting artifacts is indispensable for actually supporting a requirements engineer in this task. [Principal ideas/results] In this paper, a validated template for elicitation instructions that aims at providing a requirements engineer with knowledge about an underlying SPL in an appropriate manner is presented. This template consists of predefined text blocks and algorithms that explain how SPL-relevant product and process knowledge can be systematically reflected into capability-aware elicitation instructions. [Contribution] By using such elicitation instructions, requirements engineers are enabled to elicit requirements in an AE project more effectively.

Context & motivation: Despite significant advances in requirements engineering (RE) research and practice, software developing organisations still struggle to create requirements documentation in sufficient quality and in a repeatable way. Question/problem: The notion of good-enough quality is domain and project specific. Software developing organisations need concepts that i) allow adopting a suitable set of RE methods for their domain and projects and ii) allow improving these methods continuously. Principal ideas/results: Automatic analysis of requirements documentation can support a process of organisational learning. Such approaches help improve requirements documents, but can also start a discussion about its desired quality. Contribution: We present a learning model based on heuristic critiques. The paper shows how this concept can support learning on both the organisational and individual levels.

[Context and motivation] Implicit requirements (ImRs) are defined as requirements of a system which are not explicitly expressed during requirements elicitation, often because they are considered so basic that developers should already know them. Many products have been rejected or users made unhappy because implicit requirements were not sufficiently addressed. [Question/Problem] Requirement management tools have not addressed the issue of managing ImRs, also despite the challenges of managing ImRs that exist in practice the issue has not received sufficient attention in the literature. [Principal Idea/results] This planned research will investigate how automated support can be provided for managing ImRs within an organizational context, which is currently lacking in practice. This work proposed an approach that is based on semantic case-based reasoning for managing ImRs. [Contribution] We present the concept of a tool which enables managing of ImRs through the analogy-based requirements reuse of previously known ImRs. This ensures the discovery, structured documentation, proper prioritization, and evolution of ImRs, which improves the overall success of software development processes.

[Context and motivation] Safety critical software systems pervade almost every facet of our lives. We rely on them for safe air and automative travel, healthcare diagnosis and treatment, power generation and distribution, factory robotics, and advanced assistance systems for special-needs consumers. [Question/Problem] Delivering demonstrably safe systems is difficult, so certification and regulatory agencies routinely require full life-cycle traceability to assist in evaluating them. In practice, however, the traceability links provided by software producers are often incomplete, inaccurate, and ineffective for demonstrating software safety. Also, there has been insufficient integration of formal method artifacts into such traceability. [Principal ideas/results] To address these weaknesses we propose a family of reusable traceability queries that serve as a blueprint for traceability in safety critical systems. In particular we present queries that consider formal artifacts, designed to help demonstrate that: 1) identified hazards are addressed in the safety-related requirements, and 2) the safety-related requirements are realized in the implemented system. We model these traceability queries using the Visual Trace Modeling Language, which has been shown to be more intuitive than the defacto SQL standard. [Contribution] Practitioners building safety critical systems can use these trace queries to make their traceability efforts more complete, accurate and effective. This, in turn, can assist in building safer software systems and in demonstrating their adequate handling of hazards.

Traceability supports users in describing and tracking the relationships between software artifacts. Techniques such as traceability matrices and graphs visualize these relationships and help users to access and understand them. Researchers agree that different visualization techniques add valuable information in different contexts. However, there is an ambiguity which visualization is suitable for which context. To clarify this we conducted a comparative study of common visualization techniques, including an experiment and interviews with 24 participants.

We found that traceability matrices and graphs are most preferred in management tasks, while hyperlinks are preferred in implementation and testing tasks. Traceability lists seem to be the least attractive technique for most participants. Graphs are preferred to navigate linked artifacts, while matrices are appropriate for overview. Hyperlinks are regarded to fit for fine-grained information. Participants stressed the importance of visualizing semantics of artifacts and links. Our finding also indicates that users are not always able to choose the most suitable visualization.

[Context and Motivation] This paper notes the advanced state of the natural language (NL) processing art and considers four broad categories of tools for processing NL requirements documents. These tools are used in a variety of scenarios. The strength of a tool for a NL processing task is measured by its recall and precision. [Question/Problem] In some scenarios, for some tasks, any tool with less than 100% recall is not helpful and the user may be better off doing the task entirely manually. [Principal Ideas/Results] The paper suggests that perhaps a dumb tool doing an identifiable part of such a task may be better than an intelligent tool trying but failing in unidentifiable ways to do the entire task. [Contribution] Perhaps a new direction is needed in research for RE tools.

[Context and motivation] Traditionally, requirements are documented using natural language text. However, there exist several approaches that promote the use of rich media requirements descriptions. Apart from text-based descriptions these multimodal requirements can be enriched by images, audio, or even video. [Question/Problem] The transcription and automated analysis of multimodal information is an important open question, which has not been sufficiently addressed by the Requirement Engineering (RE) community so far. Therefore, in this research preview paper we sketch how we plan to tackle research challenges related to the field of multimodal requirements analysis. We are in particular focusing on the automation of the analysis process. [Principal idea/results] In our recent research we have started to gather and manually analyze multimodal requirements. Furthermore, we have worked on concepts which initially allow the analysis of multimodal information. The purpose of the planned research is to combine and extend our recent work and to come up with an approach supporting the automatic analysis of multimodal requirements. [Contribution] In this paper we give a preview on the planned work. We present our research goal, discuss research challenges and depict an early conceptual solution.

[Context and motivation] Quality is one of the most critical success factors of software products. [Question / problem] Nevertheless, during software development processes software quality is still not given the proper attention and relevance it deserves. [Principal ideas / results] This paper outlines ten common myths about software quality prevailing in practice. [Contribution] The discussion of these myths unveils challenges which need further attention in requirements engineering (RE) research and practice.

[Context & motivation] The process of requirements engineering affects software quality. However, stronger empirical evaluation of this impact is required. [Question/problem] This paper aims to answer the following questions: (1) which factors related to requirements engineering affect software quality, (2) what is the nature of these relationships, and (3) how are soft quality features related to each other? [Principal ideas/results] To answer these questions we performed a quantitative and visual analysis using the extended ISBSG dataset. Obtained results cover a discussion on identified and unconfirmed relationships. [Contribution] The main contribution is an investigation of the relationships between factors of requirements engineering and software quality. Provided results can be used in further research and to guide industrial decision makers. The main limitation in generalizing the results is related to the high number of missing values in the dataset.

[Context and Motivation] As a result of recent trends in enhancing Service Oriented Requirement Engineering activities, a number of service description methods have been proposed for describing services. The availability of different service description methods can give developers a range of options to choose from so that they can have an appropriate description method that fits best their services. [Question/problem] But there is neither holistic information on service description methods nor a clear understanding of the strengths and weaknesses of each service description method. The aim of this paper is to identify problems of service descriptions that have been researched so far, and the techniques or methods available to tackle these problems. [Principle ideas/results] Thus, to gather this relevant information available in the literature, a systematic review was conducted. A total of 191 articles were examined, of which 24 articles focus on service description related concepts. The results show that, despite the recent efforts in describing the nonfunctional requirements of services through approaches like semantic annotations and policy attachments, there is still a lot to do in enhancing the description of quality aspects of services. Furthermore, this study reveals that a negligible effort is given to the description of consumer oriented services. [Contribution] This paper identifies and analyzes the current service description methods that exist in the literature and explains the pros and cons inherent to these methods.

Nowadays many legislators decided to enact different laws, which all enforce legal and natural persons to deal more carefully with IT systems. Hence, there is a need for techniques to identify and analyze laws which are relevant for an IT system. But identifying relevant compliance regulations for an IT system and aligning it to be compliant is a challenging task. This paper presents a novel method for identifying and analyzing laws. The method makes use of different kinds of law analysis patterns that allow legal experts and software and system developers to understand and elicit relevant laws for the given development problem. Our approach also helps to detect dependent laws. We illustrate our method using an online-banking cloud scenario.

[Context and motivation] Self-adaptive systems (SAS) monitor and adapt to changing end-user requirements, operating context conditions, and resource availability. Specifying requirements for such dynamic systems is not trivial. Most of the research on self-adaptive systems (SAS) focuses on finding solutions to the requirements that SAS is built for. However, elicitation and representation of requirements for SAS has received less attention at early stages of requirements engineering (RE). [Question/problem] How to represent requirements for SAS in a way which can be read by non-engineering stakeholders? [Principal ideas/results] A requirements modeling language with a diagrammatic syntax to be used to elicit and represent requirements for SAS and perform analysis based on our recently proposed core ontology to perform RE for SAS. [Contribution] A modeling language, called Adaptive RML, for the representation of early requirements for Self-adaptive systems (SAS). The language has graphical primitives in line with classical goal modeling languages and is formalized via a mapping to Techne. Early validation is performed by modeling the same case study in an established goal modeling language and in Adaptive RML. The results suggest that context and resource concepts, as well as relegation and influence relations should be part of graphical modeling languages used to make early requirements models for SAS and to perform analysis over them.

[Context and motivation] Adaptive Service Based Applications (SBAs) need to cope with continuously changing environments. Monitoring becomes a key requirement for engineering Adaptive SBAs. [Question/problem] Ongoing research on Requirements Engineering (RE) for Adaptive SBAs strives to answer challenging questions such as how to monitor changes affecting user’s requirements? and how the monitored information helps in adapting to the candidate solutions? [Principal ideas/results] Existing approaches and techniques to specify requirements monitoring for Adaptive SBAs are either formal or specialized to a particular domain. A convenient and easy approach to specify requirements monitoring for Adaptive SBAs is still missing. In this paper, we focus on this issue. [Contribution] We describe a systematic approach for deriving requirements monitoring specifications for the running Adaptive SBA. We use a running example from a travel domain case study to elaborate our approach.

[Context and motivation] Requirements catalogues for software release planning are often not complete and homogeneous. Current release planning approaches, however, assume such commitment to detail – at least implicitly. [Question/problem] We evaluate how to relax these expectations, while at the same time reducing release planning effort and increasing decision-making flexibility. [Principal ideas/results] Feature trees capture AND, OR, and REQUIRES relationships between requirements. Such requirements structuring can be used to hide incompleteness and to support abstraction. [Contribution] The paper describes how to utilize feature trees for planning the releases of an evolving software solution and evaluates the effects of the approach on effort, decision-making, and trust with an industrial case.

An enterprise-architecture (EA) is a high-level representation of the enterprise, used for managing the relation between business and IT. [Problem] Ideally, all elements of an enterprise architecture can be traced to business goals ad vice versa, but in practice, this is not the case. In this experience paper we explore the use of goal-oriented requirements engineering (GORE) techniques to improve this bidirectional traceability. [Principal ideas/results] We collected GORE techniques from KAOS, i*, Tropos, BMM and TOGAF and integrated them in a language called ARMOR. This was used by enterprise architects in case study. It turned out that the language was too complex for the architects to understand as intended. Based on this we redefined ARMOR to contain only a minimum number of goal-oriented concepts, and this was tested in a second case study. This second case study suggests that the minimal version is still useful for traceability management in practice. [Contribution] We have identified a core set of concepts of goal-oriented requirements engineering, that can be used in the practice of enterprise architecture. Our analysis provides hypotheses into GORE that will be tested in future case studies.