This paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future. The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. Software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. There are a number of inherent difficulties in this process. Stakeholders may be numerous and distributed. Their goals may vary and conflict, depending on their perspectives of the environment in which they work and the tasks they wish to accomplish. Their goals may not be explicit or may be difficult to articulate, and, inevitably, satisfaction of these goals may be constrained by a variety of factors outside their control. This paper presents an overview of current research in RE, presented in terms of the main activities that constitute the field. While these activities are described independently and in a particular order, in practice, they are actually interleaved, iterative, and may span the entire software systems development life cycle. Section 2 outlines the disciplines that provide the foundations for effective RE, while Section 3 briefly describes the context and background needed in order to begin the RE process. Sections 4 through 8 describe the core RE activities: eliciting requirements, modelling and analysing requirements, communicating requirements, agreeing requirements, and evolving requirements. Section 9 discusses how these different activities may be integrated into a single development process. We conclude with a summary of the state of the art in RE, and offer our view of the key challenges for future RE research. Before discussing RE activities in more detail, it is worth examining the role of RE in software and systems engineering, and the many disciplines upon which it draws. Zave provides one of the clearest definitions of RE: "Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families." This definition is attractive for a number of reasons. First, it highlights the importance of "real-world goals" that motivate the development of a software system. These represent the 'why' as well as the 'what' of a system. Second, it refers to "precise specifications". These provide the basis for analysing requirements, validating that they are indeed what stakeholders want, defining what designers have to build, and verifying that they have done so correctly upon delivery. Finally, the definition refers to specifications' "evolution over time and across software families", emphasising the reality of a changing world and the need to reuse partial specifications, as engineers often do in other branches of engineering. It has been argued that requirements engineering is a misnomer. Typical textbook definitionsThis paper presents an overview of the field of software systems requirements engineering (RE). It describes the main areas of RE practice, and highlights some key open research issues for the future. The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. Software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation. There are a number of inherent difficulties in this process. Stakeholders may be numerous and distributed. Their goals may vary and conflict, depending on their perspectives of the environment in which they work and the tasks they wish to accomplish. Their goals may not be explicit or may be difficult to articulate, and, inevitably, satisfaction of these goals may be constrained by a variety of factors outside their control. This paper presents an overview of current research in RE, presented in terms of the main activities that constitute the field. While these activities are described independently and in a particular order, in practice, they are actually interleaved, iterative, and may span the entire software systems development life cycle. Section 2 outlines the disciplines that provide the foundations for effective RE, while Section 3 briefly describes the context and background needed in order to begin the RE process. Sections 4 through 8 describe the core RE activities: eliciting requirements, modelling and analysing requirements, communicating requirements, agreeing requirements, and evolving requirements. Section 9 discusses how these different activities may be integrated into a single development process. We conclude with a summary of the state of the art in RE, and offer our view of the key challenges for future RE research. Before discussing RE activities in more detail, it is worth examining the role of RE in software and systems engineering, and the many disciplines upon which it draws. Zave provides one of the clearest definitions of RE: "Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families." This definition is attractive for a number of reasons. First, it highlights the importance of "real-world goals" that motivate the development of a software system. These represent the 'why' as well as the 'what' of a system. Second, it refers to "precise specifications". These provide the basis for analysing requirements, validating that they are indeed what stakeholders want, defining what designers have to build, and verifying that they have done so correctly upon delivery. Finally, the definition refers to specifications' "evolution over time and across software families", emphasising the reality of a changing world and the need to reuse partial specifications, as engineers often do in other branches of engineering. It has been argued that requirements engineering is a misnomer. Typical textbook definitions