1 Making Requirements Elicitation Traceable Orlena Gotel & Anthony Finkelstein Department of Computing Imperial College of Science, Technology & Medicine London SW7 2BZ email: oczg; acwf@doc.ic.ac.uk This workshop seeks to examine how progress can be made in determining customer requirements, particularly in the development of large software-based systems, to address the problem of systems which fail to meet customer's needs on their delivery. The cause of this situation is multifaceted, and can be due to a combination of: inadequate requirements elicitation; the inability to transcribe elicited requirements in a tangible or representative form; the different interpretations given to requirements throughout their development and use; the difficulty in reconciling diverse requirements; the problems involved when integrating additional or changing requirements; and so forth. Although improvements in requirements elicitation and requirements description can offer more assurance that customer's needs are obtained and recorded, they offer no guarantee that these needs will get met. In addition, they offer no guarantee that any subsequent changes to these needs can be handled and taken into account. Unless such improvements are coupled with techniques which enable these needs to be both considered and reconsidered, throughout the entire development process, systems will still be delivered which fail to meet them. Therefore, some form of connection needs to be established and maintained between the information elicited from customers, the requirements which have been derived from this elicited information, and the subsequent artifacts in which these requirements have been distributed. In other words, the ability to obtain and meet customer’s needs depends on requirements being traceable from their origin and throughout their project life, so right back to and from the requirements elicitation phases. The ability to describe and follow the life of a requirement has been referred to elsewhere as requirements traceability [Gotel & Finkelstein, 1994a]. In this paper, and in more depth in [Gotel & Finkelstein, 1993], we analysed the nature of requirements traceability problems that are commonly experienced in practice. This work led to the identification of two basic types of requirements traceability, revolving around a baselined requirements specification (RS), which have been referred to as: (i) post-RS traceability, which is concerned with requirements deployment; and (ii) pre-RS traceability, which is concerned with requirements production. The empirical data we gathered strongly suggested that the majority of the problems currently attributed to poor requirements traceability were in fact due to inadequate pre-RS traceability. Moreover, many of these problems were informational in character, such as the difficulty in locating the origin of dispersed needs, and the inability to reconstruct how these were integrated in the RS. An obvious first step towards addressing these problems involves obtaining and recording comprehensive details about requirements production, and further organising these details so that they are traceable in multiple ways. However, with the present emphasis on developing formalisms in which to describe elicited requirements, there is a natural tendency to “black box” what is elicited, thereby divorcing the end product of requirements elicitation from the process which generated it. The absence of production details renders these results closed to