Requirements define what properties and functionality a software should have. It is impossible to assess the quality of a software without requirements. Moreover, writing requirements is only possible if the domain knowledge of the system-to-be and its environment is known and considered thoroughly, otherwise severe problems can occur during software development, e.g., technical solutions to requirements might be impractical or costly. It is an open research question how to elicit domain knowledge correctly for effective requirements elicitation. We address these problems by describing common structures and stakeholders for several different domains in so-called context-patterns for structured domain knowledge elicitation. Depending on the kind of domain knowledge that we have to elicit for a software engineering process, we always have certain elements that require consideration. We base our approach on Micheal Anthony Jackson’s work [1] that considers requirements engineering from the point of view of a machine in its environment.

Context-patterns are structural descriptions of kinds of systems including their environment, e.g., clouds. These descriptions can be instantiated in order to describe a specific system of a certain kind. Our context-patterns are described based on existing context descriptions of these systems, as well as our experience and the experience of practitioners. We illustrate several context-pattern in our Pattern Catalog.

[1] JACKSON, M. 2001. Problem Frames. Analyzing and structuring software development problems. Addison-Wesley.