Towards Human-Centered Design of Diagrammatic Representation Schemes Stefan Oppl University of Linz – Department of Business Information Systems – Communications Engineering Freistädterstraße 315 – A-4040 Linz
[email protected]
Christian Stary University of Linz – Department of Business Information Systems – Communications Engineering Freistädterstraße 315 – A-4040 Linz
[email protected] project (www.crosswork.info - IST 507590) targeting towards cross-organizational process development in the automotive industry. Our case studies have been performed in cooperation with a major OEM (Original Equipment Manufacturer) and a big supplier in this sector whose goal is to optimize their production processes involving their (sub-)suppliers and their internal processes.
ABSTRACT
Bridging the gap between individual mental models of stakeholders and organizational or software developers requires a diagrammatic acquisition and representation scheme that captures information provided by stakeholders in an accurate way for all involved parties. In this paper we reflect an action research approach for deriving such a scheme, and revisit existing approaches in the light of our developments. Since human-centered diagrammatic representation schemes need to ensure the intelligibility of process knowledge, they have to provide dedicated modeling elements, such as contextual information types.
In a first approach, we have modeled our partners’ processes with ARIS [1]. In the evaluation stage we figured out that the stakeholders were not able to find their mental model in the diagrammatic presentation due to the lacking semantics for this purpose. This led to misinterpreted, partly incomplete and wrong focused models. Thus, our claim was to develop a representation scheme that facilitates context sensitive recognition.
Author Keywords
Task modeling, process ontology, participatory design. ACM Classification Keywords
D.2.1 H.1.2
In the paper we introduce the diagrammatic language constructs we found to support the modeling process. We also reflect our experiences in light of other modeling languages, such as SeeMe ([10], [11]) or ProcessLens ([5], [6]), that aim to bridge the gap between mental models and diagrammatic process specifications, and examine their suitability for modeling the aspects identified to be necessary for intuitive intelligibility in our showcases. Based on the reflection we address the crucial design issues for this kind of diagrammatic schemes and, in this way, are able to set up a sound basis for human-centered design of diagrammatic representation schemes for (cross-) organizational development and user interface design.
Requirements/Specification, Languages User/Machine Systems, Human factors
INTRODUCTION
Organizational development based on business processes is often driven by languages and/or tools, such as ARIS [1] or UML [7], rather than by understanding, communicating, and reflecting specifications of tasks, workflows, process items or constraints. Such approaches might hinder complex integration or tuning processes, in particular when different organizational units or organizations are involved, lacking a common understanding of the problem domain. They also hinder task-based user interface design when interactive software supporting those processes is developed.
ON-THE-SPOT DEVELOPMENT – A SHOWCASE
The first case study has been performed in cooperation with a major OEM that has to tune several complex production processes involving various suppliers. The latter deliver parts in different granularities ranging from complete sub systems like the dashboard to simple components like bulbs for the driver’s compartment lightning. The goal of organizational development in this case is a process-based workflow formation and visualization based on the processes of the involved suppliers.
In this contribution we will reflect our experiences with task and process modeling in the EU-IST-CrossWork
In a 1.5h-interview, we have developed a common understanding of the process, which leads to the formation
1
and optimization of the production processes across organizational borders.
run through another process, which is called “evaluation of product/process optimization proposal”.
Changes in processes, which involve suppliers, are in general negotiated in special meetings called “supplier’s day” at the OEM’s site and subsequent workshops at the supplier’s site. The goal of the supplier’s day is to obtain mutual understanding of goals and procedures. These transparent data uncovers the internal processes of both the OEM and the supplier. It is then used to identify and agree upon possible changes in the respective workflows, or to find improvements. Another goal of this process is to identify possible weaknesses and potentials of the supplier and to devise a plan for developing capabilities of the supplier with respect to future integrations with the OEM’s production processes. Overall, the OEM intends a reduction of replenishment lead times and costs as well as an enhancement of quality requiring the supplier’s flexibility. The relevance of each of these four global goals is set from case to case when specifying the goals of a process.
The goal of this process is to achieve a “go/no go”-decision from the executive board. The targets of this process are the improvement of quality, the reduction of costs, and – depending on the expected order situation – the reduction of production time. The “go/no go”-decision is again based on the comments of the set of departments listed before. Their comments are issued based on existing product- and processspecifications, where not only improvement potential is taken into consideration but also capital and know-how invested into and bound to the current process. Additionally, knowledge available from former supplier’s days and also from assembly is part of the recommendations to the executive board. Since the “evaluation of proposal”-process can also be triggered by outcomes of a supplier’s day, the set of process under examination forms a cycle. Each sub-process can serve as an entry point to another.
A supplier’s day involves up to four suppliers. They are selected in a process called “evaluation of suppliers”. The selection is either driven by the presumed potential for improvements in logistics (in particular concerning the reduction of replenishment lead time, and the minimization of the OEM’s risks), or guided by a proposal for the definition of a novel process or for the optimization of an existing production process. The first case is accomplished by an OEM’s supplier manager, whereas the latter case is triggered by another process, which is described later on.
The first figure gives an overview of the whole process including the goals and knowledge flow, while the following figures show the two of the sub-processes with their involved roles and data in detail. During the modeling process all of these figures were integrated in one single diagram, but have been split up here for reasons of space.
As a prerequisite for the selection of possible suppliers, the goal of this process is the identification of the parameters – or rather capabilities suppliers must be able to provide – that are required for the intended or possible optimization of the product / process in question. Focus here is laid onto replenishment lead times and – connected to that – the flexibility of the supplier. Sufficient quality of the delivered products is considered a necessary prerequisite, whereas the costs are merely considered as a consequence of the fulfillment of a process goal. The OEM keeps internal classification and assessment data of its suppliers and uses them in addition to its experiences from former supplier’s days to select the participants of the upcoming supplier’s day. Although the entire process is coordinated by a single person, it involves a defined set of the OEM’s departments. They have to be consulted as a whole due to the OEM’s enterprise culture.
Figure 1. Showcase - Overview
As described before, the evaluation of suppliers can be triggered by proposals for new or alternative products or processes. These proposals can be submitted by any intraor extra-organizational person or unit that is involved in the concerned production process (including assembly, management and suppliers). However, before these proposals trigger the evaluation of suppliers, they have to
Figure 2. Showcase - Evaluation of product/process optimization proposal
2
the progression of a process are attached to the process owner. Data elements represent data involved in a process. They are created, used or modified by roles through a process. Input that is required and intended output of a process is modeled as a data-element. Data can be manifested within documents, files or oral information. Data can also be put into mutual relation to show dependencies explicitly (like “determines” or “is based on”).
Figure 3. Showcase - Supplier's day THE SCHEME
In the course of knowledge acquisition we have developed a diagrammatic scheme intelligible for all involved parties. It consists of fundamental modeling elements, relationships between them, and of contextual information types. The latter are required to represent context information and facilitate the communication.
In a more generalized approach data could be understood as a passive phenomenon (an “entity”) and then would also include tools, hard- and software and physical and virtual containers (such as rooms or operating systems). During the case study, the explicit modeling of goals of a process was identified as being crucial for human-centered process representation schemes. Information types, such as performance and quality constraints for task accomplishment, allow the stakeholders involved in the elicitation process to experience the explicated knowledge in its context. Each goal is linked to a process.
Fundamental Modeling Elements
The fundamental modeling elements are processes, goals, roles and data as well as different types of relationships between them. A process element represents a single process step (which may also be part of a more complex process). A process in general changes the state of the environment. Therefore it contains a set of activities that have not been further specified in our case and may, e.g., contain work tasks of stakeholders or manipulation facilities of data. Processes are the central parts of any model. In general, they have a defined starting- and end-point and can be set into temporal relation to other processes.
Scopes provide the possibility to divide diagrams into a part that contains the modeled processes of the task at hand, and a part, which provides the context for those processes. In this way external influences and interfaces to processes can be captured. They are visualized through a circumscribing dashed line. Relationships
Relationships mutually link process, role and data elements. Their visualization can be modified to express different types of relations. The most generic type is “general link”. It associates two elements and is visualized through a direct line between them. The meaning of a general link is determined through the types of elements it connects: “responsible” links roles to processes, “involves/consults” links roles mutually. If a link is intended to represent other meaning than the standard type, modelers have to provide an annotation that conveys the meaning of a general link.
The possibility to model ancillary processes is provided through the same notation. An ancillary process is used for the specification of sub-tasks and can only be connected to exactly one father process (also in cycles, cf. case study), contributes to its goals and shares its roles and data.
Figure 4. Fundamental Modeling Elements
As non-directed links are not sufficient to represent causal dependencies between elements, the second basic link type, “relation” was introduced and is visualized through an arrow. Again, if no annotation is defined, the particular meaning is determined by the respective source and destination elements: “before” links processes, “creates” links processes to data, “needs” links data to processes.
A role element represents a functional role within an organization. This role contains a set of rights and responsibilities and is assigned to a person, department or another kind of organizational unit. Roles can be assigned to a concrete position statically in advance, as well as dynamically, whenever the demand arises. As staff positions are not modeled explicitly, the role’s designator denotes the staff position. In the latter case, the role’s designator, which then is not assigned with an existing staff position, is put under quotation marks for a clearly visible distinction.
In certain cases additional link types may be required to augment the intelligibility for the involved parties. For this reason, modelers might add relationships and a corresponding visualization scheme. For instance, in our showcase we have introduced the link type “knowledge flow”. It is visualized by a dashed arrow and used to model the flow of knowledge between processes. This information is likely not to be represented by data elements per se, since the modeler is not able to identify the concrete data by the
A role element has to be associated with each process. If a role is involved in more than one process, a respective role element is inserted for each process. Processes always have exactly one process owner directly attached to them. Downstream roles that have to be consulted or involved in
3
time of elicitation. Another link type we introduced during the interview was “optional link” as a sub type of general link. This link is visualized as a dashed line.
flexibility. That depiction captures vague relations, e.g., that flexibility is “somehow” dependent on time. As the four global goals are of different relevance for particular processes, they were assigned roman numbers to represent priorities.
Contextual Information Types
Contextual information types are intended to express knowledge about an organization’s philosophy and basic concepts that lie behind any of its business processes, and thus differ from modeling case to modeling case.
The rhombus of goals shadows each specification of goals for a single process with the relevant global goals marked. The marking represents how these “local” goals are perceived or interpreted in a global context. This concept was extended while modeling the showcase to the definition of predetermined or subsequent global goals of processes. Hereby, it becomes apparent that the specification of the global goals using the traditional goal notation would lack important aspects of enterprise-wide global goals, in the first instance, the competitive nature of those goals. Furthermore, the process goals can be put into a global context and intuitively represent the relevant aspects for the respective process.
These concepts are in most cases tied to one of the fundamental modeling elements, but not sufficiently expressible through traditional elements. For this reason, we allow the definition of elements representing contextual information. It can be used to augment to traditional process notation with additional knowledge. In this way the communication among developers and stakeholders becomes context-sensitive. The two contextual information types used in our case study are the shamrock of involved departments, and the rhombus of goals. The shamrock of involved departments denotes an enterprise-wide philosophy of the OEM, namely to involve those departments in every decision-making process (see also Figure 2). The five departments are (1) procurement, (2) logistics, (3) quality assurance, (4) engineering and (5) production. Each of them or rather a representative of them is consulted in all cases when changes of products or business processes are likely to occur.
JUSTIFICATION – ANOTHER SHOWCASE
The scheme developed in our first showcase was justified by applying it in a second showcase, where the project management processes of a big supplier of interiors in the automotive sector were modeled. In this case we started by analyzing the enterprise project management handbook and refined our model during a personal interview with the author of this handbook. Again, the notation proved to be intuitively intelligible, as the interview partner was able to identify misinterpretations of the handbook within minutes after the concept was explained to him. The handbook describes the stages of a project on a rather general but very detailed level, defining the necessary activities, pre- and post-conditions, the participating roles and the affected documents. The main stages are ‘identification of project opportunity’, ‘evaluation and quotation’, ‘project planning’, ‘supervision and control of project’ and ‘closure of project’. Additionally there are supporting management processes (like ‘quality assurance’ or ‘change request management’) that span across the stages.
Figure 5. Contextual information types
At first glance, it seems evident those five departments could also be modeled as downstream roles of a role responsible for a process. But this form of representation lacks the additional context information that those five roles always have to be consulted as a whole and form an essential part of the organization’s decision-making culture. The proposed notation of a responsible role with the shamrock of involved departments ‘shadowing’ it clearly demonstrates the culture and provides an intuitive understanding of that culture.
Modeling was performed on the level of stages, including important contained process steps only when it showed to be reasonable during the interview. The relevant supporting processes were modeled independent from the main process. To connect the processes, the concept of shadowing – like it was used for contextual information types – was applied here too. The respective stages of the main process were shadowed with an iconographic representation of the support processes, showing which part of the main process is accompanied by the respective supporting processes.
The rhombus of goals (see above) is the second contextual information type that has been identified in the case study. It is used to arrange process goals according to global enterprise goals. Those goals are arranged in a rhombus to show their competitive nature. They denote the (1) (minimization of) time, (2) (improvement of) quality, (3) (minimization of) costs and (4) (improvement of)
An important finding was that the identified fundamental modeling elements (process, role, data, goal) are stable and
4
sufficient to model the processes. Again it proved reasonable to explicitly model goals of processes to preserve overall intelligibility also for users, who do not know the detailed sub-processes.
RELATED WORK
In the following we examine two approaches for processand work task modeling which also focus the modeling process on the stakeholders with respect to their suitability for human-centered representation of high-level business processes, i.e. the capability to capture the elicited and diagrammatically presented information (types) of our first showcase.
As expected, the contextual information types shadowing the fundamental elements were different in this case due to the different enterprise philosophy and knowledge domain. We introduced four contextual information types, of which two where used to shadow processes, one to shadow goals and one which was used to shadow different fundamental modeling elements.
SeeMe
SeeMe ([10], [11]) is a modeling method for the visualization of social and semi-structured aspects of communication and co-operation activities. SeeMe is intended to support discussion and justification of conceptual requirements for software. In this field, the expression of “soft” aspects is essential – SeeMe provides means to model justified, vague, incomplete, unsure or semi-structured information.
Processes were shadowed with the ‘X of risk evaluation’ and the ‘lattice of project accomplishment’. The ‘X of risk evaluation’ represents the fact, that risk evaluation is an integral part of certain processes. The X was chosen because of the evaluation method, which is based on multiplication of the three involved parameters.
SeeMe provides three basic elements: roles, activities and entities. These elements can be connected through generic relations. Their meaning is dependent on the context of use (namely the elements they connect). Basic elements can also be aggregated or embedded into another. Using this feature, the modeler can express entities and roles that are only relevant for a certain task and the like.
The ‘lattice of project accomplishment’ shadows the process ‘project supervision and control’. It denotes the fact that the actual accomplishment of the project is an important part of project work and should be kept in mind, but is out of scope of the actual model. The form was chosen due to the different stages of project accomplishment (the horizontal lines), in which different departments are involved (the vertical lines).
To support evolutionary design a meta-basis element is provided. It is a super class of the three basic elements and is used in early stages of modeling for collecting items and relations between them, without having to care for their type. The concept of meta-relations is used to denote the influence of one element on the internal structure of another element (e.g., a role that determines the way a certain activity is carried out).
Figure 6. Contextual information types of showcase 2
The concept of explicitly modeling vagueness is unique to SeeMe. Vagueness in a model may occur, if certain information is missing at modeling time or if the modeler has further information and intentionally does not want to include it in the model. Both cases can be modeled by annotating the respective element.
The ‘triangle of goals’ is used to shadow goals and can be interpreted in a similar way as the ‘rhombus of goals’ in the first showcase. The fourth contextual information type is the ‘H’. It is special in the way that it is used to shadow different modeling elements. It denotes that something is based on the guidelines of the project handbook.
The concept of modifiers is provided to model elements that only exist in certain cases or with a certain probability. Respective elements are also annotated indicating the conditions and/or the probability. As can be seen in Figure 8, not all aspects of the showcase can be modeled using SeeMe. The modeling language is especially lacking the capability to model goals of processes explicitly. However, we consider this capability helpful to create a common understanding of the concerned processes.
Figure 7. Example for the use of contextual information types
This contextual information symbol not only implicitly contains the project handbook itself (which would be a simple data element) but also the knowledge that the handbook contains directives applicable to the shadowed element and that those have to be adhered.
The few, intuitively intelligible basic elements and the generic relationships, as well as the possibility of evolutionary model development facilitates modeling. In that process inexperienced people can easily participate and explicate their view on the process.
5
Figure 8. SeeMe model of showcase
In addition, modeling vagueness and especially modifiers have shown to provide substantial value to the models, allowing to model “soft” aspects and providing a more comprehensive picture of the process.
relevant for task modeling are the user, task and data model: (i) The user model represents a role model by defining specific views on tasks and data (according to the functional roles of users). Typical elements of BILA used in this context are organizational unit, position, and person.
Contextual information types – as we have defined them above – are not provided by SeeMe. Although the shamrock of involved departments as a super-role containing roles for each department has been incorporated into the scheme, SeeMe does not capture the intentional meaning of the shamrock. It was not possible to model both, the shamrock and the rhombus of goals, including their original meaning. They are familiar for the involved units as they are, using exactly the chosen nomen-clature and visualization. Replacing this visualization with another notation, that is assumed to have a similar meaning and can be modeled with the chosen language, is a tool-driven approach. It introduces the need for further explanation and stifles the process of developing a common understanding of the process.
(ii) The task model comprises the decomposition of user tasks according to the economic and the social organization of work as well as the different activities that users have to perform to accomplish their tasks. Typical elements used for modeling are task, activity, and tool. (iii) The (problem domain) data model describes the data required for work-task accomplishment. In contrast to traditional data modeling, in ProcessLens both aspects of data are captured: structure and behavior. A particular element of BILA is used extensively in the data model, namely material. In ProcessLens UML class diagrams [7] are used to specify the structure of all models and their mutual relationships. A set of predefined elements and relations (some of them are mentioned above) supports the modeling activities of work processes.
ProcessLens
ProcessLens supports the task- und role-sensitive development of interactive software through providing an ontology that captures the essentials of work processes (cf. [5], [6]). It incorporates task and user models into a modelbased representation scheme. The unifying specification language BILA (Business Intelligence Language) is based on UML (cf. [7], [8]) and allows capturing model-specific elements and relationships, as well as the structural and dynamic linking of executable models.
Designers or users have to specify and assign activity diagrams [8] to dedicated model elements to describe the actual accomplishment of tasks (including the manipulation of data) and role-specific behavior. If elements from different models are related (structure level), their corresponding activity diagrams have to be synchronized using a special kind of ProcessLens transition (synchronization transition at the behavior level). This dynamic linking makes the model operational.
The ProcessLens approach also contains a certain design procedure that is based on a representation scheme containing different models. The ProcessLens models 6
Figure 9. ProcessLens model of showcase
As shown in Figure 9, only the structural view of ProcessLens has been used to model the showcase, because the actual accomplishment modeled in activity diagrams was not scope of this survey. Like SeeMe, ProcessLens also lacks the capability to explicitly model goals. Process goals have been inserted as ‘notes’, which does not correspond to an element (as goals in this case can only be distinguished from other ‘notes’ by considering their context).
should be enriched with dedicated contextual information types. A CRITICAL REFLEXION
Modeling the first showcase with SeeMe and ProcessLens shows that the processes in principle can be modeled and that even some of the contextual information types can be represented (using rather complex constructs). But in our interviews, it became obvious that for acquisition, the approach must be more human-centered, not forcing users to model complex relationships to represent their mental model, which then are hardly visible in the visualization anyway.
ProcessLens contains several elements that may appear similar to the inexperienced user (e.g. role, person, position) but are needed for a proper UI prototyping and simulation. In the worst case, choosing a wrong element-type may lead to the impossibility to connect elements considered related by the modeler.
It is therefore necessary to decouple the ‘content’ to be modeled from the limitations of visualization. The presentation of a process must not reduce the intelligibility for stakeholders, as this is the case for ARIS [1], for the presented approaches and for UML [7] [8].
In the modeled showcase, it was impossible to properly model the relations between the used elements because of the strictly predefined types of relations (lacking a generic connector type) and the restricted set allowed elementrelation-element-combinations.
Taking into account the findings mentioned above, several design issues have to be addressed for the development of human-centered representation schemes.
Although the concise set of elements and relations is required for UI prototyping and simulation, this structure makes ProcessLens unsuitable for evolutionary, casedriven, human-centered modeling also involving people with little or no modeling experience. For example the possibility to model the knowledge flow between the involved processes should be provided. It has been identified to be an intuitive means for modeling knowledge derived from former instances of other processes. Another example concerns the context. In ProcessLens, the shamrock had to be modeled by five different roles, mutually connected via the “informs”-relation. The scheme
Representation of user-, task- and data-aspects
Covering all essential dimensions of work-processes (cf. [5], [6]) is crucial for enabling a holistic understanding of them. Providing coequal information about the “What?” (task), the “Who?” (user) and the “Using what?” (data) as well as the relations between those aspects in one single diagram enables users to capture the essentials of a process at one glance. They don’t have to search for needed information implicitly contained in other elements or modeled in separate diagrams.
7
to be done to model contextual information types that seem to be crucial for diagrammatic representation schemes that are intended to involve end users in the modeling process. Such an involvement should enable them to actively participate when explicating their mental model of work processes using concepts they are familiar with.
Explicit modeling of goals
The possibility to model goals of processes explicitly (the “Why?” aspect) enables a better understanding of processes defined on an abstract level. It enables participants to remain mentally at a certain level of abstraction, without having to detail their information to sub processes immediately.
REFERENCES
Using explicit goal elements thus enables evolutionary modeling and provides a means for keeping a process’s goals in mind while refining or altering it. A formal approach to represent goals in task models is contained in higher-order task modeling [2]. The corresponding specification language TaOSpec (cf. [3], [4]) facilitates the modeling of goal networks, representing also the connections between sub-goals, thus giving a more comprehensive understanding of what tasks represent for humans. Contextual information types
The concept of contextual information types with userdefinable notation provides a surplus to traditional diagrammatic modeling languages by being able to “personalize” them with respect to the organizational context of the modeled process. By shadowing an element of the traditional process notation with an instance of a contextual information type, it provides intuitive understanding of the context of this element. It might also imply structural information or constrains, such as the shamrock in our showcase (when put behind a role responsible for a process it represents the five departments that have to be consulted by the responsible in order to come to a decision).
1.
A.-W. Scheer. ARIS – Business Process Modeling (3rd edition). Springer, 2003.
2.
A. Dittmar, P. Forbrig. Higher-Order Task Models. In [9].
3.
A. Dittmar. Ein formales Metamodell für den aufgabenbasierten Entwurf interaktiver Systeme. PhD thesis. University of Rostock, 2002.
4.
M. Stoy. TaOSpec - Implementation einer aktionsorientierten Spezifikationssprache. Studienarbeit, FB Informatik, Univ. Rostock, 2003.
5.
C. Stary. TADEUS: Seamless Development of TaskBased and User-Oriented Interfaces. IEEE Transactions on Systems, Man, and Cybernetics, Vol. 30, pp. 509-525, 2000.
6.
C. Stary, S. Stoiber. Model-based Performance Support. In [9].
7.
M. Fowler, S. Kendall. UML Distilled - Applying the Standard Object Modeling Language. Addison Wesley, Reading, Massachusetts, 1997.
8.
G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language User Guide. Addison Wesley, 1999.
9.
Electronic
J. Jorge, N. J. Nunes, J. F. e Cunha, editors, DSV-IS 2003: Issues in Designing New-generation Interactive Systems Proceedings of the Tenth Workshop on the Design, Specification and Verification of Interactive Systems. Nr. LNCS volume 2844, Springer, 2003. 10. T. Herrmann, M. Hoffmann, K. Loser. Sozioorientierte und semi-strukturierte Modellierung mit SeeMe. Rundbrief des GI-Fachausschusses 5.2. 5. Jg., Heft 2. S. 15-22. 11. T. Herrmann, G. Kunau, K. Loser, N. Menold. Sociotechnical Walkthrough: Designing Technology along Work Processes. Proceedings of the eighth Participatory Design Conference 2004. ACM, New York. S. 132-141. 12. A. Dittmar, P. Forbrig, S. Heftberger, C. Stary. Tool Support for Task Modelling - A Constructive Exploration. Proceedings of EHCI-DSVIS'2004, Hamburg, Germany, 2004
Generic relations
In contrast to predefined relation types an open approach using generic relations with default denotation depending on the connected elements and deliberately definable meaning by annotating them facilitates intuitive modeling and does not hinder the spontaneous and context-sensitive articulation of inputs in the course of elicitation. CONCLUSION
In this paper we tried to bridge the gap between individual mental models of stakeholders and organizational or software developers. We have shown a participatory design process of a diagrammatic acquisition and representation scheme that is able to capture information provided by stakeholders in an accurate way for all involved parties. Existing approaches allow some of the aspects to be captured explicitly, others require enhancements or notational overhead. Few approaches seem to capture social aspects and explicit goals of processes. Further research has
8
