Business Processes and Requirements plus an overview of

Business Processes and Requirements plus an overview of some BU research in the area Professor Keith Phalp http: //dec. bournemouth. ac. uk/staff/kphalp/

The BPR unit rationale • Customers want systems to support their business processes. – (We can argue about the b word). • Developers build systems for clients • “Oh dear. The system doesn’t seem to meet the client’s needs”. (It must be someone’s fault – next slide). • This is a requirements problem, and very common. • One reason is that the developers didn’t understand the problem: or what they wanted or needed. – That’s where the business process modelling comes in, and some other assorted ideas. • Another problem is that they didn't really consider requirements (so we will review what requirements should be). • Finally we consider how best to get the process knowledge to inform the specification, that is how to map from process model to specification. • Will also justify why we need to spend the effort; why requirements matters. Software Systems Research Centre PORE

Who is at fault? Software Systems Research Centre PORE

How bad is it? • Chaos reports: 75% of projects failed or failed to deliver key functions. • Why? Poor / no requirements engineering. • 2004 Job. Serve report: only 16% of UK software projects are successful. • Why? Poor / no analysis (requirements) skills. • Robert Glass: Software Runaways: all attributed to requirements issues. • Famous UK versions? • And even if you get it right they want changes when the project is delivered! Software Systems Research Centre PORE

Size Really Does Matter • Importance of getting the foundations right? • All taken from: • Bray, I ‘An introduction to Requirements Engineering’ Software Systems Research Centre PORE

What do I know • • • My experiences. Software Process modelling (91. . . ) Business Process Modelling (94. . . ) Consultancy, UK & Europe (plus short courses) Methods used more widely Process Oriented Requirements Engineering (taught here since 97 in various forms. . ) - many gone on to use in practice. Use case guidelines (2000 onwards. . . ) Strategy and Process Oriented Requirements Methods, widely published from around 2005 onwards (BSCP 2006). Much of this part of the units covers methods that I have used directly (such as RADs), invented or co-authored (BSCP, mappings to use cases), and which has been used across many industries. Supervision of Ph. D which embedded requirement with MDA. Software Systems Research Centre PORE

Impact Process approaches (BSCP) Enterprise Analysts Pty Ltd Promise Point: boutique management, Japan NICTA Ltd Consultants NTT Data (largest SI in Japan), use of tool (based on method): estimated to save potentially Y 10 Ms of rework costs on one project alone NRI (2 nd largest SI in Japan) Commonwealth Bank Australia Centrelink (Australian Benefits Agency): IT refresh across whole country delivered real business benefits, saving potentially $Ms in rework NICTA (new management system) -> saved over $150 K (on initially budgeted $250 K project) Prickie. com (saved $100 Ks for company directors) Use case guidelines various papers 2000 -2012 Used in practice and taught to business analysts at major Bank Share traders to support IT Dept expansion when acquired by American Express Software Systems Research Centre PORE

Some past projects • • • Process models (Role Activity Diagrams) are used to model the problem domain (and thus to inform requirements). Enactable process models to prototype behaviour. Guidelines for writing use case descriptions (specifications). To improve comprehension, and therefore ensure that all understand what to build. Augmented use cases to make dependencies among events clear. Enactable use cases to improve validation of specification. In-house tool supports guidelines and allows enactable use cases too. Process models mapped to (augmented) use case specification (EDUCATOR), such that process information can be represented and retained (REBNITA). Method to ensure that process models mapped to requirements, ensure that process knowledge not lost. Collaboration with NICTA- Australia) to align business strategy, context and process (B-SCP) with IT. VIDE project on extending accessible models to MDA tools MDA support and requirements with MDA within automotive software engineering, automatic gearboxes. Software Systems Research Centre PORE

Role Activity Diagrams • • • Software Systems Research Centre For now, for brevity, we have omitted states from the diagram No choice constructs shown here. Have included a System Role. PORE

Role Activity Diagrams Original concepts in paper by Ould & Roberts (1986), book by Ould 1995 (a great read). Initially, promoted by Praxis & Coordination Systems (Roberts), and the DTI sponsored IOPTClub. Variants and extensions, e. g. , PROCESS project (Southampton Uni, 94 -97) produced families of models (mapping to CSP) and enactable models (Rol. Enact 98). Phalp, K. T. , G. K. Abeysinghe, P. Henderson, and R. J. Walters, (1998), Rol. Enact: Enactable Models of Business Processes, Information and Software Technology, vol. 40, num 3. Recent resurgence of interest, with popular books by Keith Harrison Broninski and Martin Ould (both BCS). Still supported by many, e. g. , see Venice Consulting (Martin Ould’s site), for much of interest at: www. veniceconsulting. co. uk Software Systems Research Centre PORE

Software View • • • This is against the purist approach, and a rather simplified (teaching) example. We (as software engineers) move towards specification. Need to ensure that we capture the system boundary (as with say a Yourdon Context Diagram). Need to ensure that, in moving to spec, we show cross boundary (problem to machine interactions). With a system RAD (usually will have different sub-system names) the interaction is between the roles (which will be actors) and the system role. This will correspond to use case communications or associations. Software Systems Research Centre PORE

A simplified use case • • • Hence, RAD acts as a way to consider the problem domain (inform requirements). RAD (with system roles) allows one to ‘discover’ or discuss the system boundary. Acts as a link between business view (intentions for system) and IT. Practical • • • Software Systems Research Centre Acts as a checklist for the specification. Gives a first cut list for the use case diagram communications. Of course the meat of the use case is in the description, which brings further considerations… PORE

Two sporting use cases 1. The match reached full-time 2. The referee blew his/her whistle 3. The ball crossed the goalline 4. The goal was not given 1. Alternatives 1. The goal was given Alternatives 1. The goal was not given 2. 3. 4. The match reached fulltime The referee blew his/her whistle The ball crossed the goalline The goal was given Someone who ‘knows the game’. Software Systems Research Centre PORE

Previous incarnation Software Systems Research Centre PORE

CP Style Rules • Style 3 (contd. ) • The patient stands next to the doctor. • He puts the prescription in his pocket. • Who is “he”? Whose pocket is “his”? Write proper nouns / names instead: • The doctor puts the prescription in the patient’s pocket. • The GP puts the prescription in the customer’s pocket. • This sentence is at fault because it uses synonyms (GP for doctor and customer for patient). Only use the agreed language of the domain since a synonym does not convey the same meaning. Software Systems Research Centre PORE

Parallel: Standard RAD view Suppose our event is now Make smoothie, which requires that when we have fruit. We actually have both apples and oranges. For a use case we would be required to choose that the gaining of apples and oranges occurs in some arbitrary sequence. That is: 1 Fruit Finder get apples 2 Fruit Finder get oranges However, in reality one might gather these fruits independently and in any, often unknown order. Also within the Use Case description the dependencies are unclear Software Systems Research Centre PORE

Considering dependencies 1. 2. 3. 4. 5. 6. Client requests connection via Scheduler acknowledges connection Client sends network layout Scheduler creates network handler Scheduler registers network handler Client starts executing its tasks Software Systems Research Centre PORE

Simple (single UC) Enaction Software Systems Research Centre PORE

An Enaction… Events re-ordered. New order is in effect: 1, 3, 4, 5, 2, 6 Of course, states not written order really control invocation of events. Software Systems Research Centre PORE

Three Notations Interaction Role 1. Interaction Me(before 1 after 1) Role 2(before 2 after 2) End Interaction Keith. gives_pen Me (has_pen -> no_pen) Karl (no_pen -> has_pen) End Actor Keith Event gives pen Software Systems Research Centre post Actor 2 pre post has pen no pen Karl no pen has pen PORE

Some Future Directions • Requirements within a Model Driven (MDA) framework. • BU ran MDABIZ (TOOLS) in Zurich • Recent Ph. D completion. • Model driven in automotive software engineering an d model merging issues. • Continuation of mapping themes (PM to Spec). • Further work on Spec to Design (and tool support) • Continuation of strategic level work (and collaboration). • Examination of comprehension in requirements (a thorough study to challenge the assumption that things should be easy to understand). • Supporting real industrial projects to ensure that business needs are met by software. Software Systems Research Centre PORE