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

2. Software Systems Research Centre PORE 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.

3. Software Systems Research Centre PORE Who is at fault?

4. 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 JobServe 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!

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

6. 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 PhD which embedded requirement with MDA.

7. 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 Y10Ms of rework costs on one project alone NRI (2nd 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 $150K (on initially budgeted $250K project) Prickie.com (saved $100Ks 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

8. 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 MDA within automotive software engineering, automatic gearboxes.

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

10. Software Systems Research Centre 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 (RolEnact 98). Phalp, K.T., G.K. Abeysinghe, P. Henderson, and R.J. Walters, (1998), RolEnact: 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

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

12. 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 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…

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

14. Software Systems Research Centre PORE Previous incarnation

15. 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.

16. 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

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

18. Software Systems Research Centre PORE Simple (single UC) Enaction

19. 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.

20. Software Systems Research Centre PORE Three Notations Interaction Role1.Interaction Me(before1  after1) Role2(before2  after2) End Interaction Keith.gives_pen Me (has_pen -> no_pen) Karl (no_pen -> has_pen) End ActorEvent prepostActor 2prepost Keithgives penhas penno penKarl no penhas pen

21. Software Systems Research Centre PORE Some Future Directions Requirements within a Model Driven (MDA) framework. BU ran MDABIZ (TOOLS) in Zurich Recent PhD 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.