Requirements engineering: a roadmap
Proceedings of the Conference on The Future of Software Engineering
An Approach for Cross-Discipline Requirements Engineering Process Patterns
ICRE '98 Proceedings of the 3rd International Conference on Requirements Engineering: Putting Requirements Engineering to Practice
Child's Play: Using Techniques Developed to Elicit Requirements from Children with Adults
ICRE '98 Proceedings of the 3rd International Conference on Requirements Engineering: Putting Requirements Engineering to Practice
A controlled empirical evaluation of a requirements abstraction model
Information and Software Technology
Fostering user-developer collaboration with infrastructure probes
Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering
Semantic parameterization: A process for modeling domain descriptions
ACM Transactions on Software Engineering and Methodology (TOSEM)
Requirements modeling for embedded realtime systems
MBEERTS'07 Proceedings of the 2007 International Dagstuhl conference on Model-based engineering of embedded real-time systems
Hi-index | 0.00 |
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.