The Focus of Requirements Engineering in Workflow Application Development

1. The Focus of Requirements EngineeringinWorkflow Application Development Niko Kleiner Dept. for Programming Methodology University of Ulm

2. Overview • Motivational Project History • Recent Results from Organizational Science • Project History Explained • Impact on RE Job?

3. 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 packagingprocess and supporting software system into existingpassenger car development world Coordinator Checks and forwards the request Packager Checks for collisions and reports about results Engineer Constructs parts (CAD), requests check for a part in its future environment

4. 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 BP Analysis „Transformation“ into Executable Definition Business Process Workflow Workflow (refined) (executable) Process Definition

5. 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 qualityof 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) PDM EDM (new)

6. Project History (4/4) Trial 3 • Use of EDM integrated WfMS • Different workflow designswere tried out to overcomethe „request problem“ • Result: Users interpreted important state indifferent ways; Requests still tended toaccumulate 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 easier interpretation finer control 3 state design 8 state design 5 state design EDM (new) PDM

7. 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 1988-2000] • The life cycle model for workflow applications presented is a direct conclusion

8. 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 Resulting org. Structure „Reality“ Feedback from operative Use (Defined org. Structure) „Modalities“ Workflow Application (and related IT Env.) Assumptions, Knowledge Business Process (and related BPs) enact construct define „Actors“ Users System Developers Managers, Consultants

9. 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)

10. 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?

11. 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?