Requirements Engineering: Foundation for Software Quality

[Context] Requirements quality can have a substantial impact on the effectiveness and efficiency of using requirements artifacts in a development process. Quantifiers such as “at least”, “all”, or “exactly” are common language constructs used to express requirements. Quantifiers can be formulated by affirmative phrases (“At least”) or negative phrases (“Not less than”). [Problem] It is long assumed that negation in quantification negatively affects the readability of requirements, however, empirical research on these topics remains sparse. [Principal Idea] In a web-based experiment with 51 participants, we compare the impact of negations and quantifiers on readability in terms of reading effort, reading error rate and perceived reading difficulty of requirements. [Results] For 5 out of 9 quantifiers, our participants performed better on the affirmative phrase compared to the negative phrase. Only for one quantifier, the negative phrase was more effective. [Contribution] This research focuses on creating an empirical understanding of the effect of language in Requirements Engineering. It furthermore provides concrete advice on how to phrase requirements.

[Motivation] The use of structured natural languages to capture requirements provides a reasonable trade-off between ambiguous natural language and unintuitive formal notations. [Problem] There are two major challenges in making structured natural language amenable to formal analysis: (1) associating requirements with formulas that can be processed by analysis tools and (2) ensuring that the formulas conform to the language semantics. [Results] FRETISH is a structured natural language that incorporates features from existing research and from NASA applications. Even though FRETISH is quite expressive, its underlying semantics is determined by the types of four fields: scope, condition, timing, and response. Each combination of field types defines a template with Real-Time Graphical Interval Logic (RTGIL) semantics. We present an approach that constructs future and past-time metric temporal logic formulas for each template compositionally, from its fields. To establish correctness of our approach we have developed a framework which, for each template: (1) extensively tests the generated formulas against the template semantics and (2) proves equivalence between its past-time and future-time formulas. Our approach has been used to capture and analyze requirements for a Lockheed Martin Cyber-Physical System challenge. [Contribution] To the best of our knowledge, this is the first approach to generate pure past-time and pure future-time formalizations to accommodate a variety of analysis tools. The compositional nature of our algorithms facilitates maintenance and extensibility, and our extensive verification framework establishes trust in the produced formalizations. Our approach is available through the open-source tool fret.

[Context and motivation] Software requirements specifications are the main point of reference in traditional software projects. Especially in large projects, these documents get read by multiple people, multiple times. [Question/problem] Several guidelines and templates already exist to support writing a good specification. However, not much research has been done in investigating how to support the use of specifications and help readers to find relevant information and navigate in the document more efficiently. [Principal ideas/results] We used eye tracking data obtained from observing readers when using specifications to create three different attention transfer features to support them in this process. In a student experiment, we evaluated if these attention visualizations positively affect the roles software architect, UI-designer and tester when reading a specification for the first time. The results show that the attention visualizations did not decrease navigation effort, but helped to draw the readers’ attention towards highlighted parts and decreased the average time spent on pages. [Contribution] We explored and evaluated the approach of visualizing other readers’ attention focus to help support new readers. Our results include interesting findings on what works well, what does not and what could be enhanced. We present improvement suggestions and ideas on where to focus follow-up research on.

[Context and Motivation] It is common for teams to take shortcuts during software development that, in the future, will lead to maintainability issues and affect productivity and development cost. Different types of technical debt may affect software projects, including those associated with software documentation. Although there are many studies on technical debt, few focus on documentation debt in an industrial environment. [Question/Problem] We aimed to identify how software practitioners perceive the occurrence of documentation debt in their projects. We present a combined analysis of the results from two complementary studies: a survey (InsighTD) and an interview-based case study. [Principal Ideas/Results] We provide a list of causes and effects of documentation debt, along with practices that can be used to deal with it during software development projects. [Contribution] We find that documentation debt is strongly related to requirements issues. Moreover, we propose a theoretical framework, which provides a comprehensive depiction of the documentation debt phenomenon.

[Context & motivation] Requirements engineering (RE) can be seen as creative problem solving (CPS), overlapping with user experience (UX) and design activities. Creative processes, such as innovation workshops (IWs), are often facilitated group activities. They provide an understanding of challenges and user needs, leading to increased software quality. A large number of results from IWs needs to be documented in a suitable manner for later use, as not all results can be followed up upon immediately. [Question/problem] With current means of IW documentation, it is hard to extract the required information (e.g., photo minutes), or they are inefficient to produce or digest (e.g., audio and video recordings, textual documentation). Documentation of only the results leads to the loss of any discussions, decisions, reasons, and discarded alternatives, as these are usually not written down during an IW. The interpretation of the documentation depends on the viewer’s memory and understanding of the IW and the results, which is prone to misinterpretation and errors unless enriched with context information from the IW planning. [Principal ideas/results] We explored the limitations of IW documentation during a workshop with 29 experts from the usability and UX domain. Problems with using the results in later software engineering (SE), RE, and UX activities arise from misalignment between IW result documentation and activity requirements. The experts created a set of initial solution ideas, but no concrete solutions. [Contributions] We address the need for reasonable methods for documenting the results of IWs so that they can be used efficiently in later activities. The design and preliminary results of the expert workshop are presented. Furthermore, we discuss a research roadmap towards making targeted improvements to IW documentation by understanding subsequent activities.

[Context and motivation] Requirements reuse has been proposed as a key asset for requirements engineers to efficiently elicit, validate and document software requirements and, as a consequence, obtain requirements specifications of better quality through more effective engineering processes. [Question/problem] Regardless the impact requirements reuse could have in software projects’ success and efficiency, the requirements engineering community has published very few studies reporting the way in which this activity is conducted in industry. [Principal ideas/results] In this paper, we present the results of an interview-based study involving 24 IT professionals on whether they reuse requirements or not and how. Some kind of requirements reuse is carried out by the majority of respondents, being organizational and project-related factors the main drivers. Quality requirements are the type most reused. The most common strategy is find-copy-paste-adapt. Respondents agreed that requirements reuse is beneficial, especially for project-related reasons. The most stated challenge to overcome in requirements reuse is related to the domain of the project and the development of a completely new system. [Contribution] With this study, we contribute to the state of the practice in the reuse of requirements by showing how real organizations carry out this process and the factors that influence it.

[Context and motivation] Several state laws and app markets, such as Google Play, require the disclosure of app data practices to users. These data practices constitute critical privacy requirements statements, since they underpin the app’s functionality while describing how various personal information types are collected, used, and with whom they are shared. [Question/Problem] When such statements contain abstract terminology referring to information types (e.g., “we collect your device information”), the statements can become ambiguous and thus reduce shared understanding among app developers, policy writers and users. [Principle Ideas/Results] To overcome this obstacle, we propose a syntax-driven method to infer semantic relations from a given information type. We use the inferred relations from a set of information types (i.e. lexicon) to populate a partial ontology. The ontology is a knowledge graph that can be used to guide requirements authors in the selection of the most appropriate information type terms. [Contributions] Our method employs a shallow typology to categorize individual words in an information type, which are then used to discharge production rules in a context-free grammar (CFG). The CFG is augmented with semantic attachments that are used to generate the semantic relations. This method is evaluated on 1,853 unique information types from 30 privacy policies to yield 0.99 precision and 0.91 recall when compared to human interpretation of the same information types.

[Context and motivation] Ensuring privacy of users’ data has become a top concern in software development, either to satisfy users’ needs or to comply with privacy laws. The problem may increase by the time a new law is in the vacancy period, and companies are working to understand how to comply with it. In addition, research has shown that many developers do not have sufficient knowledge about how to develop privacy-sensitive software. [Question/problem] Motivated by this scenario, this research investigates the personal factors affecting the developers’ understanding of privacy requirements during the vacancy period of a data protection law. [Principal ideas/results] We conducted thirteen interviews in six different private companies. As a result, we found nine personal factors affecting how software developers perceive and interpret privacy requirements. [Contribution] The identification of the personal factors contributes to the elaboration of effective methods for promoting proper privacy-sensitive software development.

[Context and motivation] Legal provisions create a distinct set of requirements for businesses to be compliant with. Capturing legal requirements and managing regulatory compliance is a challenging task in system development. [Question/problem] Part of this task involves modeling legal requirements, which is not trivial for requirements engineers as non-experts in law. The resultant legal requirements models also tend to be very complex and hard to understand. [Principal ideas/results] To facilitate the modeling process, we propose a formal framework for modeling legal requirements. This framework includes a methodology that helps to resolve complexities of legal requirements models. [Contribution] In this paper, we outline this methodology and present a procedure that reduces modal and conditional complexities of legal models and facilitates automation of the modeling process.

[Context and motivation] Modern software engineering processes have shifted from traditional upfront requirements engineering (RE) to a more continuous way of conducting RE, particularly including data-driven approaches. [Question/problem] However, current research on data-driven RE focuses more on leveraging certain techniques such as natural language processing or machine learning than on making the concept fit for facilitating its use in the entire software development process. [Principal ideas/results] In this paper, we propose a research agenda composed of six distinct research directions. These include a data-driven RE infrastructure, embracing data heterogeneity, context-aware adaptation, data analysis and decision support, privacy and confidentiality, and finally process integration. Each of these directions addresses challenges that impede the broader use of data-driven RE. [Contribution] For researchers, our research agenda provides topics relevant to investigate. For practitioners, overcoming the underlying challenges with the help of the proposed research will allow to adopt a data-driven RE approach and facilitate its seamless integration into modern software engineering. For users, the proposed research will enable the transparency, control, and security needed to trust software systems and software providers.

[Context and motivation] App stores and social media channels such as Twitter enable users to share feedback regarding software. Due to its high volume, it is hard to effectively and systematically process such feedback to obtain a good understanding of users’ opinions about a software product. [Question/problem] Tools based on natural language processing and machine learning have been proposed as an inexpensive mechanism for classifying user feedback. Unfortunately, the accuracy of these tools is imperfect, which jeopardizes the reliability of the analysis results. We investigate whether assigning micro-tasks to crowd workers could be an alternative technique for identifying and classifying requirements in user feedback. [Principal ideas/results] We present a crowdsourcing method for filtering out irrelevant app store reviews and for identifying features and qualities. A validation study has shown positive results in terms of feasibility, accuracy, and cost. [Contribution] We provide evidence that crowd workers can be an inexpensive yet accurate resource for classifying user reviews. Our findings contribute to the debate on the roles of and synergies between humans and AI techniques.

[Context and motivation] Role-playing offer experiential learning through the simulation of real-world scenarios; for this reason, it is widely used in software engineering education. In Requirements Engineering, role-playing is a popular way to provide students hands-on experience with requirements elicitation interviews. [Problem] However, managing a role-playing activity to simulate requirements elicitation interviews in a class is time consuming, as it often requires pairing students with student assistants or fellow classmates who act as either customers or requirement analysts as well as creating and maintaining the interview schedules between the actors. To make the adoption of role-playing activities in a class feasible, there is a need to develop a solution to reduce instructors’ workload. [Principal ideas] To solve this problem we propose the use of VIrtual CustOmer (VICO), an intent-based, multimodal, conversational agent. VICO offers an interview experience comparable to talking to a human and provides a transcript of the interview annotated with the mistakes students made in it. The adoption of VICO will eliminate the need to schedule interviews as the students can interact with it in their free time. Moreover, the transcript of the interview allows students to evaluate their performance to refine and improve their interviewing skills. [Contribution] In this research preview, we show the architecture of VICO and how it can be developed using existing technologies, we provide an online rule-based initial prototype and show the practicality and applicability of this tool through an exploratory study.

[Context & Motivation] Requirements and architectural components are designed concurrently, with the former guiding the latter, and the latter restricting the former. [Question/problem] Effective communication between requirements engineers and software architects is often experienced as problematic. [Principal ideas/results] We present the Requirements Engineering for Software Architecture (RE4SA) model with the intention to support the communication within the development team. In RE4SA, requirements are expressed as epic stories and user stories, which are linked to modules and features, respectively, as their architectural counterparts. Additionally, we provide metrics to measure the alignment between these concepts, and we also discuss how to use the model and the usefulness of the metrics by applying both to case studies. [Contribution] The RE4SA model employs widely adopted notations and allows for explicitly relating a system’s requirements and architectural components, while the metrics make it possible to measure the alignment between requirements and architecture.

[Context & Motivation] Agile Requirements Engineering (ARE) is a collaborative, team-based process based on frequent elicitation, elaboration, estimation and prioritization of the user requirements, typically represented as user stories. While it is claimed that this Agile approach and the associated RE activities are effective, there is sparse empirical evidence and limited theoretical foundation to explain this efficacy. [Question/problem] We aim to understand and explain aspects of the ARE process by focusing on a cognitive perspective. We appropriate ideas and techniques from Distributed Cognition (DC) theory to analyze the cognitive roles of people, artefacts and the physical work environment in a successful collaborative ARE activity, namely requirement prioritization. [Principal idea/results] This paper presents a field study of two early requirements related meetings in an Agile product development project. Observation data, field notes and transcripts were collected and qualitatively analyzed. We have used DiCoT, a framework for systematically applying DC as a methodological contribution, to analyze the ARE process and explain its efficacy from a cognitive perspective. The analysis identified three main areas of cognitive effort in the ARE process as well as the significant information flows and artefacts. Analysis of these have identified that the use of physical user story cards, specific facilitator skills, and development of shared understanding of the user stories, were all key to the effectiveness of the ARE activity observed. [Contribution] The deeper understanding of cognition involved in ARE provides an empirically evidenced explanation, based on DC theory, of why this way of collaboratively prioritizing requirements was effective. Our result provides a basis for designing other ARE activities.

[Context and Motivation] Requirements glossary defines specialized and technical terms used in a requirements document. A requirements glossary helps in improving the quality and understandability of requirements documents. [Question/Problem] Manual extraction of glossary terms from a large body of requirements is an expensive and time-consuming task. This paper proposes a fundamentally new approach for automated extraction of glossary terms from large-sized requirements documents. [Principal Ideas/Result] Firstly, our technique extracts the candidate glossary terms by applying text chunking. Next, we apply a novel word embeddings based semantic filter for reducing the number of candidate glossary terms. Since word embeddings are very effective in identifying terms that are semantically very similar, this filter ensures that only domain-specific terms are present in the final set of glossary terms. We create a domain-specific reference corpus for home automation by Wikipedia crawling and use it for computing the semantic similarity scores of candidate glossary terms. We apply our technique to a large-sized requirements document, i.e., a CrowdRE dataset with around 3000 crowd-generated requirements for smart home applications. Semantic filtering reduces the number of glossary terms by 92.7%. To evaluate the quality of our extracted glossary terms we manually create the ground truth data from CrowdRE dataset and use it for computing precision and recall. Additionally, we also compute the requirements coverage of these extracted glossary terms. [Contributions] Our detailed experiments show that word embeddings based semantic filtering can be very useful for extracting glossary terms from a large body of requirements.

[Context and motivation] Notations for expressing requirements are often proposed without explicit consideration of their suitability for specific tasks. Consequently, practitioners may choose a sub-optimal notation, thereby affecting task performance. [Question/problem] We investigate the adequacy of two well-known notations: use cases and user stories, as a starting point for the manual derivation of a static conceptual model. In particular, we examine the completeness and correctness of the derived conceptual model. [Principal ideas/results] We conducted a two-factor, two-treatment controlled experiment with 118 subjects. The results indicate that for deriving conceptual models, user stories fit better than use cases. It seems that the repetitions in user stories and their conciseness contribute to these results. [Contribution] The paper calls for evaluating requirements notations in the context of various requirements engineering tasks and for providing evidence regarding the aspects that need to be taken into account when selecting a requirement notation.

[Context and Motivation] A critical success factor in Requirements Engineering (RE) involves recognizing conflicts in Quality Requirements (QRs). Nowadays, Quality Attributes Relationship Matrix (QARM) is utilized to identify the conflicts in QRs. The static QARM represents how one Quality Attribute (QA) undermines or supports to achieve other QAs. [Question/Problem] However, emerging technology discovers new QAs. Requirements analysts need to invest significant time and non-trivial human effort to acquire knowledge for the newly discovered QAs and influence among them. This process involves searching and analyzing a large set of quality documents from literature and industries. In addition, the use of static QARMs, without knowing the purpose of the QRs in the system may lead to false conflict identification. Rather than taking all QAs, domain-specific QAs are of great concern for the system being developed. [Principal ideas/results] In this paper, we propose an approach which is aimed to build an adaptive QARM semi-automatically. We empirically evaluate the approach and report an analysis of the generated QARM. We achieve 85.67% recall, 59.07% precision and 69.14% F-measure to acquire knowledge for QAs. [Contributions] We provide an algorithm to acquire knowledge for domain-specific QAs and construct an adaptive QARM from available unconstrained natural language documents and web search engines.

[Context and Motivation] One must test a system to ensure that the requirements are met, thus, tests are often derived manually from requirements. However, requirements representations are diverse; from traditional IEEE-style text, to models, to agile user stories, the RE community of research and practice has explored various ways to capture requirements. [Question/problem] But, do these different representations influence the quality or coverage of test suites? The state-of-the-art does not provide insights on whether or not the representation of requirements has an impact on the coverage, quality, or size of the resulting test suite. [Results] In this paper, we report on a family of three experiment replications conducted with 148 students which examines the effect of different requirements representations on test creation. We find that, in general, the different requirements representations have no statistically significant impact on the number of derived tests, but specific affordances of the representation effect test quality, e.g., traditional textual requirements make it easier to derive less abstract tests, whereas goal models yield less inconsistent test purpose descriptions. [Contribution] Our findings give insights on the effects of requirements representation on test derivation for novice testers. Our work is limited in the use of students.

[Context and motivation] Creating a shared understanding of requirements between all parties involved about a future software system is difficult. Imprecise communication can lead to misunderstanding of requirements. Vision videos demonstrate and visualize the functionality, use and impact of a software system before the actual development process starts. They stimulate discussions about the software system and its associated requirements. [Question/problem] Vision videos should be produced with as little effort as possible, in terms of resources and time consumption, yet with sufficient quality. This raises the questions: Does the presentation of a vision video influence its perception by the audience? Do animated vision videos offer an alternative to real videos to communicate a vision? [Principal ideas/results] We conducted an experiment with 20 participants comparing animated and real videos showing the same content. The videos illustrate the population decrease in rural areas and envision a possible solution to counteract the consequences of grocery store closings. The participants suggested own solutions for the problem of grocery store closings, rated the videos and chose their preferred type of video representation. The results of the experiment show no difference in neither the amount of solutions proposed nor the rating of the videos. Likewise, the results show no difference in the preferred type of video representation. [Contribution] Our study indicates that animated vision videos offer an adequate alternative to real videos. Thus, vision video producers have another viable option to choose for achieving a shared understanding of a future software system.

[Context and motivation] Digitalization is increasingly influencing cities as they evolve into Smart Cities. However, involving citizens in order to develop digital solutions that address real needs of users is a challenging task. In the Smart City project “EnStadt:Pfaff”, concepts are to be developed to encourage residents of a city district to participate in the development of a Smart City district by communicating their needs, wishes, and ideas. [Question/problem] In the context of Smart City districts, classic requirements engineering (RE) methods such as interviews can be used, but there is high potential for novel methods, as the residents are concentrated within a very limited physical space and can communicate their needs and wishes through a digital platform as well as through analog communication channels. Our research goal is to investigate such novel methods and their potential for improving Smart City districts with digital solutions. [Principal ideas/results] In this research preview, we describe an initial approach for encouraging a group of citizens (potentially without any software engineering background) to participate in requirements elicitation in the context of Smart Cities. [Contribution] The presented approach consists of nine steps providing guidance for the selection of motivational measures, the reduction of obstacles to participation, and communication of requirements elicitation activities. Furthermore, we present topics for future research.

[Context and motivation] Software product lines evolve frequently to address customer requirements in different domains. This leads to a distributed engineering process with frequent updates and extensions. [Question/problem] However, such changes are typically managed and tracked at the level of source code while feature-level awareness about software evolution is commonly lacking. In this research preview paper we thus present an approach visualizing the evolution in software product lines at the level of features. [Principal ideas/results] Specifically, we extend feature models with feature evolution plots to visualize changes at a higher level. Our approach uses static code analyses and a variation control system to compute the evolution data for visualisation. As a preliminary evaluation we report selected examples of applying our approach to a cyberphysical ecosystem from the field of industrial automation. [Contribution] Integrating visualisations into state-of-the-art feature models can contribute to better integrate requirements-level and code-level perspectives during product line evolution.