Requirements models in context

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.