Research Directions in Requirements Engineering

Abstract:

In this paper, we review current requirements engineering (RE) research and identify future research directions suggested by emerging software needs. First, we overview the state of the art in RE research. The research is considered with respect to technologies developed to address specific requirements tasks, such as elicitation, modeling, and analysis. Such a review enables us to identify mature areas of research, as well as areas that warrant further investigation. Next, we review several strategies for performing and extending RE research results, to help delineate the scope of future research directions. Finally, we highlight what we consider to be the “hot” current and future research topics, which aim to address RE needs for emerging systems of the future.

Introduction:

The success of a software system depends on how well it fits the needs of its users and its environment [127, 130]. Software requirements comprise these needs, and requirements engineering (RE) is the process by which the requirements are determined. Successful RE involves understanding the needs of users, customers, and other stakeholders; understanding the contexts in which the to-be-developed software will be used; modeling, analyzing, negotiating, and documenting the stakeholders’ requirements; validating that the documented requirements match the negotiated requirements; and managing requirements evolution1. In this paper, we offer our views on the research directions in requirements engineering.

The paper builds on Nuseibeh and Easterbrook’s paper [127], hereafter referred to as the “2000 RE Roadmap Paper”, from the Future of Software Engineering track at ICSE 2000 [64]. Whereas the 2000 RE Roadmap Paper focused on current research in requirements engineering, this paper concentrates on research directions and identifies RE challenges posed by emerging and future software needs. We start, in Section 2, with an overview of the inherent difficulties in requirements engineering. In Section 3, we provide a summary of the state of the art of RE knowledge and research, and in Section 4, we enumerate general research strategies for advancing the state of the art. The strategies range from revolutionary research to empirical evaluation to codifying proven solutions. In Section 5, we highlight what we consider to be RE research hotspots: the most pressing needs and grand challenges in RE research. Some hotspot topics are natural extensions to existing knowledge and technologies, whereas others arise as RE aspects of predicted software needs. We conclude with strategic recommendations for improving the research infrastructure for RE researchers, thus facilitating the research community’s ability to make better progress on addressing these problems.

Why Requirements Engineering is Difficult:

In general, the research challenges faced by the requirements-engineering community are distinct from those faced by the general software-engineering community, because requirements reside primarily in the problem space whereas other software artifacts reside primarily in the solution space. That is, requirements descriptions, ideally, are written entirely in terms of the environment, describing how the environment is to be affected by the proposed system. In contrast, other software artifacts focus on the behavior of the proposed system, and are written in terms of internal software entities and properties. Stated another way, requirements engineering is about defining precisely the problem that the software is to solve (i.e., defining what the software is to do), whereas other SE activities are about defining and refining a proposed software solution. Several consequences follow from this distinction that cause requirements engineering to be inherently difficult:

    • Requirements analysts start with ill-defined, and often conflicting, ideas of what the proposed system is to do, and must progress towards a single, detailed, technical specification of the system.
    • The requirements problem space is less constrained than the software solution space – in fact, it is the requirements definition that helps to delimit the solution space. As such, there are many more options to consider and decisions to make about requirements, such as selecting from collections of proposed requirements, prioritizing requirements, deciding on the system boundaries, negotiating resolutions to conflicts, setting objective acceptance criteria, and so on [172].
    • One means of simplifying the problem space is to constrain the environmental conditions under which the system is expected to operate. In such cases, reasoning about requirements involves reasoning about the combined behavior of the proposed system and assumptions made about the environment. Taking into consideration environmental conditions significantly increases the complexity of the problem at hand, since a system’s environment may be a combination of hardware devices, physical-world phenomena, human (operator or user) behavior, and other software components.
    • Reasoning about the environment includes identifying not only assumptions about the normal behavior of the environment, but also about possible threats or hazards that the environment could pose to the system.
    • The resulting requirements artifacts have to be understood and usable by domain experts and other stakeholders, who may not be knowledgeable about computing. Thus, requirements notations and processes must maintain a delicate balance between producing descriptions that are suitable for a non-computing audience and producing technical documents that are precise enough for downstream developers.

Due to all of the above, RE activities, in contrast to other software-engineering activities, may be more iterative, involve many more players who have more varied backgrounds and expertise, require more extensive analyses of options, and call for more complicated verifications of more diverse (e.g., software, hardware, human) components.

Matrix Summarizing the State of the Art of Requirements Engineering:

Enumeration of Research Strategies:

Recommendations and Conclusions:

In this paper, we have described a number of exciting and challenging research directions in requirements engineering. Some of these directions are natural extensions of work already being performed by RE researchers, whereas others are major discontinuities due to fundamental changes in computing needs. All of the problems described above will require substantial effort in order to make progress towards effective solutions. To help alleviate this effort, we offer some recommendations of short- and long-term actions that the RE community could take, to position itself to make more rapid progress on these research problems.

There are five recommendations that the RE community could take immediate action on, to start improving the maturity of current requirements technologies:

    • Researchers should work with practitioners. Such partnerships can help to ensure that researchers have a through understanding of the real problems that practitioners face.
    • RE researchers should work with other SE researchers and practitioners, to establish stronger links between their respective artifacts. If the transition between RE tasks and other development tasks were more seamless, management would view RE efforts more positively, because the resulting requirements knowledge and artifacts would make more concrete progress towards achieving downstream milestones.
    • RE researchers should not neglect evaluation and empirical research. For practitioners to consider adopting a given research technique, they must know how the technique compares with similar techniques. Also, practitioners and their managers need to see that the technique can be applied to problems relevant to their organization, from both domain and scale perspectives.
    • Industrial organizations should provide (sanitized) industrial-strength project data to researchers. It is especially critical that industry provide realistic data for ultra-large scale or cyber-physical systems to ensure that researchers tackle problems that are representative of those faced by practitioners. Researchers can use this data to guide the development and validation of their new techniques, thereby yielding more relevant and useful research results that explicitly address industrial needs.
    • RE researchers and practitioners, together, should establish repositories of RE artifacts. Such repositories can serve as a resource for practitioners and educators to share best practices and exemplar artifacts. Repositories can also store requirements patterns for potential reuse, case studies that evaluate individual or composite RE techniques, benchmark data for evaluating competing technologies, and tools that support specific RE techniques.

The above actions would help the RE research community to make immediate progress on improving existing knowledge and techniques. In addition, there are some longerterm actions that would help to improve the community’s research infrastructure and its ability to confront the challenges posed by emerging systems:

    • The RE community needs to be proactive in identifying the RE research problems that arise from new computing challenges. New challenges reflect changing stakeholders’ needs. As such, RE researchers should be involved in the initial investigations of any new computing challenge, to help tease out the essential goals and to assess their impact on RE tasks.
    • Researchers need to think beyond current RE and SE knowledge and capabilities, in order to make significant headway in addressing the challenges posed by emerging systems. They need to be willing to search for new solutions that may lead to paradigm shifts in RE practices, at the risk of possible failure. One strategy is for researchers to seek out collaborators from other disciplines to leverage successful techniques that could be used to address analogous challenges faced by cyber systems.
    • RE academics need to educate the next generation of developers on RE problems and technologies. Students need curricula that combine the study of computing with the study of specialized application domains. They also need computing courses that teach them how to make design decisions that achieve requirements (e.g., modularity vs. performance requirements) in the context of the software’s operating environment.

In conclusion, the RE research community has made significant progress along many fronts. At the same time, the demands placed on computing and the cyberinfrastructure have increased dramatically, raising many new critical RE research questions. For these reasons, it is an exciting time to be involved in RE research. Technologies that make significant advances in solving these problems are likely to lead to paradigm shifts that will impact many future generations of developers, computing systems, and the ultimate stakeholders – consumers.