The Focus of Requirements Engineering in Workflow Application Development Niko Kleiner Dept. for Programming Methodology University of Ulm

Niko Kleiner, University of Ulm Overview Motivational Project History Recent Results from Organizational Science Project History Explained Impact on RE Job?

Niko Kleiner, University of Ulm Project History (1/4) Goals Serves as motivation for research presented Example for discussion, not an empirical validation Project Context Seven year project history from automotive industry Our task was to design and introduce new packaging process and supporting software system into existing passenger car development world Engineer Constructs parts (CAD), requests check for a part in its future environment Coordinator Checks and forwards the request Packager Checks for collisions and reports about results

Niko Kleiner, University of Ulm Project History (2/4) Trial 1 Very systematical approach according to the ARIS method, only one iteration Result: System was rejected by users Focus Much effort spent for business process analysis and modeling We thought: We can foresee the optimal business process We thought: The resulting work practice will be like the implemented workflow We thought: WfM technology is primary cause for failure Business Process Workflow (refined) (executable) Process Definition BP Analysis „Transformation“ into Executable Definition

Niko Kleiner, University of Ulm Project History (3/4) Trial 2 Same workflow design, but intranet technology Application not integrated with existing EDM/PDM world Change in EDM system Result: Data inconsistencies, bad quality of system (due to high change ratio) Observation: Requests tended to accumulate (unprocessed) Focus Focus on implementation technique We thought: We only need to deal with the IT infrastructure in more detail We did not further analyze the observation EDM (old) EDM (new) PDM

Niko Kleiner, University of Ulm Project History (4/4) Trial 3 Use of EDM integrated WfMS Different workflow designs were tried out to overcome the „request problem“ Result: Users interpreted important state in different ways; Requests still tended to accumulate Focus First: Workflow design Then: Study about why users interpreted this state in so many ways and why requests tended to accumulate brought fundamental problem to light: there was a misconception in the synchronization between the packaging and another, related business process! The tried workflow designs had to fail. Today Misconception resolved, trial 4 still in progress – first results are positive EDM (new) PDM 3 state design8 state design5 state design finer control easier interpretation

Niko Kleiner, University of Ulm Related Research Activities Goals Find/Develop theory, that explains project history Use theory as basis for (software) development process of WfAs Subgoal: Use theory to reason about the role of requirements engineering in workflow application development Activities Literature research in organizational science, information systems research... Analysis of project history (further project analysis scheduled) Results Organizational science provides theory that explains the role of (information) technology in organizations [Orlikowski, Robey, Markus ] The life cycle model for workflow applications presented is a direct conclusion

Niko Kleiner, University of Ulm A Lifecycle Model for WfA Remarks Theory integrates three levels of construction into one framework – organizational, technical, social (enactment) Emergence of „Resulting org. Structure“, dependent on context and history Context = three modalities = knowledge+assumptions, norms, resources Assumptions, Knowledge (Defined org. Structure) Workflow Application (and related IT Env.) Resulting org. Structure UsersSystem DevelopersManagers, Consultants defineconstructenact Feedback from operative Use Business Process (and related BPs) „Reality“ „Modalities“ „Actors“

Niko Kleiner, University of Ulm Key Lessons from Org. Science Uncertainty in Design Decisions Managers/Consultants have partial knowledge of work practice => suboptimal, macro view oriented business process design System Developers choose a technical design and have partial view of both, work practice and macro view => suboptimal technical design (WfA) (RE already contributes a lot to this problem, but usually focuses on the artifact – the WfA - and „only“ wants it to fit the business process design) Emergent Work Practice Work practice always emerges, the WfA influences but does not determine a certain usage This emerging work practice is micro view oriented and often conflicts with the makro view (suboptimal)

Niko Kleiner, University of Ulm Impact on RE Job? General Conclusion Business Process (Def. org. Structure) and Work Practice (Res. org. Structure) need to learn from each other and converge Remarks As a consequence, putting more effort into early activities - like business process analysis and modeling – does not necessarily contribute to the project‘s sucess Additionally, the „optimal process“ we want to converge to, changes over time Question If the RE job is to help to drive the WfA towards its real world goals and one of them is to help to drive the business process it supports towards its business goals, isn‘t then the RE job to support this convergence?

Niko Kleiner, University of Ulm Impact on RE Job? If you say yes, then Traditional RE does not become obsolete But focus becomes How do users enact the WfA in daily use, and where and why do they deviate from the intended process Work practice is dependent on all three modalities – not just the implemented workflow - and emerges in operational use Question Is this the job of a Requirements Engineer? If not, who else should do it?