In Requirements Engineering, requirements elicitation aims the acquisition of information from the stakeholders of a system-to-be. An important task during elicitation is to identify and render explicit the stakeholders' implicit assumptions about the system-to-be and its environment. Purpose of doing so is to identify omissions in, and conflicts between requirements. This paper o?ers a conceptual framework for the identi?cation and documentation of default requirements that stakeholders may be using. The framework is relevant for practice, as it forms a check-list for types of questions to use during elicitation. An empirical validation is described, and guidelines for elicitation are drawn.
There has been limited attention regarding the question of . Yet, context as a source of information is not new. Many papers propose high level discussions about context in RE: Potts and Hsi @cite_7 emphasize the existence of -- opposed to abstractionism -- as a possible alternative design philosophy for information systems. Viller and Sommerville @cite_21 propose discussions about how is value-added to RE, thereby broadening the scope of RE context to culture questions. Beyer and Holtzblatt propose the Contextual Design model @cite_31 , which increases the scope of relevant information to any data about . Previous works illustrate the trend to include even more data in the scope of RE relevant information. Cohene and Easterbrook @cite_9 discuss a topic closer to what we address in this paper. They suggest that elicitation techniques that are used in an interview should be adapted to fit the kind of information engineers are trying to find, i.e. adapt the elicitation technique to the situation -- or context.
@cite_9 @cite_31 @cite_21 @cite_7
2147295172 1941671609 2115203384
Interviews with stakeholders can be a useful method for identifying user needs and establishing requirements. However, interviews are also problematic. They are time consuming and may result in insufficient, irrelevant or invalid data. Our goal is to re-examine the methodology of interview design, to determine how various contextual factors affect the success of interviews in requirements engineering. We present a case study of a Web conferencing system used by a support group for spousal caregivers of people with dementia. Two sets of interviews were conducted to identify requirements for a new version of the system. Both sets of interviews had the same information elicitation goals, but each used different interview tactics. A comparison of the participants' responses to each format offers insights into the relationship between the interview context and the relative success of each interview technique for eliciting the desired information. As a result of what we learned, we propose a framework to help analysts design interviews and chose tactics based on the context of the elicitation process. We call this the contextual risk analysis framework. Over a number of years, we have been involved in investigations into using workplace observation to inform requirements for complex systems. This paper discusses how our work has evolved from ethnography with prototyping through presentation of ethnographic fieldwork, to developing a method for social analysis that has been derived from our experience of applying ethnographic techniques. We discuss the strengths and weaknesses of each of these approaches with a particular focus on our most recent work in developing the Coherence method. This method is based on a fusion of viewpoint-oriented and ethnographic approaches to requirements engineering and uses an industry-standard notation (UML) to represent knowledge of work. We use a common example of an air traffic control system to illustrate each approach. The field of requirements engineering emerges out of tradition of research and engineering practice that stresses the importance of generalizations and abstractions. Although abstraction is essential to design it also has its dark side. By abstracting away from the context of an investigation, the designer too easily lapses into modeling only those things that are easy to model. The subtleties, special cases, interpretations and concrete features of the context of use are smoothed over in the rush to capture the essence of the requirements. Often, however, what is left out is essential to understanding stakeholders' needs. In contrast, approaches that stress context at the expense of abstraction may lead to floundering or to short-term customer satisfaction at the expense of long-term fragility of the system. What is needed is a synthesis of these two approaches: a synthesis that recognizes the complementary values of abstraction and context in requirements engineering and that does not relegate either one to a background role. Such a synthesis requires us not only to adopt new methods in practice but also to rethink our underlying assumptions about what requirements models are models of and what it means to validate them.