Requirements Engineering: An Overview

Klaus Pohl

           Traditionally, requirements engineering (RE) has been seen
           as the first phase of the software life cycle in which a
           specification is produced from informal ideas. During RE,
           the functional and non functional requirements to be met by
           the system, as well as the criteria for measuring the degree
           of their satisfaction, must be elicited and documented
           in a requirements specification. If the specification
           describes both hardware and software, it is called system
           requirements specification; if it describes only software, it
           is called software requirements specification (cf. [IEEE-830,
           1984]). The process of developing a requirements specification
           has been called requirements engineering (RE). Since the
           establishment of RE as a distinct field in the mid 1970s
           (see [TSE, 1977]) a great deal of progress has been made.
           Nowadays, RE is seen as a key issue for the development of
           software systems with the responsibility for maintaining the
           requirements of a system over time and across traditional
           and organizational boundaries (cf. [Jarke and Pohl, 1994;
           Loucopoulos and Karakostas, 1995]).  Correct understanding
           (elicitation), documentation (specification) and validation
           of user/customer needs are becoming more and more crucial
           as the ultimative measurement for systems quality is the
           degree of user satisfaction, i.e. the ability of the system
           to meet the user needs. Thus, RE is becoming the essential
           activity within the software life cycle in which a variety
           of stakeholders must be involved. The growing importance
           of the field is also reflected in new international RE
           conferences and symposia started in the 1990s (see [Fickas
           and Finkelstein, 1993; Davis and Siddiqi, 1994; Harrison and
           Zave, 1995]).  RE as a discipline is still immature. It is
           commonly accepted that only what a system should do has to be
           defined in a requirements and not how it should do it. Whereas
           almost everybody agrees that requirements must be elicited,
           specified, and validated/verified little uniformity is reached
           in the terminology 1 of the activities performed (cf. [Davis,
           1988]). For example, the understanding of what the problem
           being solved is without defining how it will be solved is
           called requirements analysis [Charette, 1986; Wasserman et
           al., 1986] but also problem analysis [Davis, 1990], problem
           definition [Roman et al., 1984] and requirements definition
           [Berzins and Gray, 1985]. Another indication for the immaturity
           is the existing vast amount of literature covering distinct
           facets and individual isolated contributions to philosophical
           and technical problems of the area.  To provide an overview of
           the field, we first reflect on some definitions of RE (Section
           2) and typical products of the RE process (Section 3). Despite
           of the fact that the knowledge about the RE process is poor,
           four tasks to be performed can be identified (Section 4).
           Towards a common understanding we define RE as a process of
           "establishing vision in context" (Section 5). For the case
           of information systems, which are increasingly becoming
           an integral part of our everyday life, we use a framework
           for structuring the context, namely the four worlds of
           information systems (development, usage, subject, and system
           world). The RE process itself can be characterized by three
           orthogonal dimensions, namely the agreement, representation,
           and specification dimension (Section 6). These dimensions
           reflect that RE is faced with social, technical, and cognitive
           problems. The consequences of these definitions on the RE
           process, its products, and requirements traceability are
           outlined in Section 7. In Section 8 we briefly summarize the
           contributions made and sketch the future perspective of RE.