University of Trier
For supplying software tools a software engineer has to know what workers do on their jobs. The necessary data are derived from organisational specifications of jobs (e.g. job orders, specifications of results or work flow), checklists, scenarios, prototypes, interviews, and modelling ( Partsch, 1991). As tasks of people are not necessarily congruent to their instructions ( Rautenberger, Spinas, Strohm, Ulich, & Waeber, 1994; Hacker, 1998; Hacker, Großmann, & Teske-El Kodwa, 1991), the organisational specifications may not be sufficient for a proper task modelling.
There is a broad consensus among software engineers that it is a basic need to do user-centred engineering (e.g. Helander, 1988; Ziegler & Ilg, 1993; Jacobsen, Christerson, Jonsson & Övergaard, 1992). Only - as the understanding of the models used in progress requires a certain amount of specific knowledge - the user's inclusion is reduced to being asked. The usual procedure in task modelling is as follows: first the analyser interviews the task-owner about his job and he himself does the modelling afterwards. It would be preferable to make the task-owner model the job by himself, which mostly is prohibited by the lack of modelling know-how of the owner. As software engineers have obtained many skills on how to model tasks and most users have not, a tool for the user's inclusion in the process should guarantee the same quality of the model, with no respect to the modellers previous modelling capacities.
The process of software engineering can be seen as a series of translations from reality to the actual computer program ( Schneider, 1986; see figure 1). As many transformation steps seem to be necessary for programming a proper computer