professor keith phalp n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Business Processes and Requirements plus an overview of some BU research in the area PowerPoint Presentation
Download Presentation
Business Processes and Requirements plus an overview of some BU research in the area

Loading in 2 Seconds...

play fullscreen
1 / 21

Business Processes and Requirements plus an overview of some BU research in the area - PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on

Professor Keith Phalp. Business Processes and Requirements plus an overview of some BU research in the area. The BPR unit rationale. Customers want systems to support their business processes. (We can argue about the b word). Developers build systems for clients

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Business Processes and Requirements plus an overview of some BU research in the area' - iolani


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
the bpr unit rationale
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.

how bad is it
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!
size really does matter
Size Really Does Matter
  • Importance of getting the foundations right?
  • All taken from:
  • Bray, I ‘An introduction to Requirements Engineering’
what do i know
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.

impact
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

some past projects
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.

role activity diagrams
Role Activity Diagrams
  • For now, for brevity, we have omitted states from the diagram
  • No choice constructs shown here.
  • Have included a System Role.
role activity diagrams1
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

software view
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.
a simplified use case
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…
two sporting use cases
Two sporting use cases

The match reached full-time

The referee blew his/her whistle

The ball crossed the goal-line

The goal was not given

Alternatives

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

cp style rules
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.

parallel standard rad view
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

considering dependencies
Considering dependencies
  • Client requests connection via Schedule
  • Scheduler acknowledges connection
  • Client sends network layout
  • Scheduler creates network handler
  • Scheduler registers network handler
  • Client starts executing its tasks
an enaction
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.

three notations
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 pen has penno penKarl no penhas pen

some future directions
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.