Gustavo Gallindo gmg cin'ufpe'br

1
Business Process Modeling for Requirements
Analysis

• Gustavo Gallindo (gmg _at_ cin.ufpe.br)
• Laís Xavier (lx _at_ cin.ufpe.br)

2
Content

• Introduction
• Related Work
• BPMN
• Approaches
• CAiSE'07
• CAiSE'08
• BIS'08
• Practical Experience

3
Introduction

• RE is acknowledged as critical to IS development
• Common mistakes
• lack of understanding of the business by
  Requirements Engineers
• miscomunication between business people and
  systems analysts
• Because of that, organization needs aren't
  fulfilled
• Requirements documentation
• Usually solution oriented, although it must be
  defined in terms of phenomena that occur in the
  business environment

4
Introduction

• Solution business process modeling
• Allow analysts to understand the business
• Minimize communication problems between business
  and computing people (different domains) by using
  models that both can understand
• BPMN standard notation

5
Related Work

• i framework
• Most popular technique for organizational
  modeling
• focused on the modelling of dependencies among
  the organizational actors in order to achieve
  organizational goals
• Models are considered strategic
• Deficiencies
• Models can be too complex
• Do not suport granularity and refinement

6
Related Work

• KAOS
• Requirements models built from organizational
  goals
• Goals systematically refined
• Also uses object model, agent responsibility
  model, and operation model
• Deficiencies
• Not too simple (compared with Map CAiSE08)
• Doesn't provide any mechanism to model and
  analyze business processes

7
Related Work

• EKD
• Analyze an enterprise by using enterprise
  modeling
• Composed of goal model, business rules model,
  concepts model, business process model, actor
  model technical components model, and
  requirements model
• Deficiencies
• None of its models are standard
• Lack of tool support

8
Related Work

• ARIS
• Framework to describe an information system for
  supporting business process
• Four levels process engineering, process
  planning and control, workflow control, and
  application systems
• Five views organizational view, data view,
  control view, function view, and product/service
  view
• Deficiencies
• Requirements specifications should be more
  detailed, and they should be more focused on goal
  analysis (same occurs with EKD)
• Concrete description for use of each model is
  missing

9
Related Work

• UML based
• UML for organizational and business process
  modelling (some approaches)
• Elements that are close to those used in the
  software development area
• Deficiencies
• Complexity to non-development people
• Not focused on goal analysis

10
Related Work

• B-SCP
• Integrates business strategy, context and process
  using RE notation
• Enables verification and validation of
  requirements related to business strategy and
  business process
• Deficiencies
• Models (RAD) less expressive than BPMN
• Problems with goal decomposition
• Requirements specification isn't precise

11
BPMN

• Offers notation that is understandable by all
  business process users (process analysts, IS
  developers, process managers...)
• Fills gap between business models and their
  implementation
• Notation Business Process Diagram (BPD)
• graphical elements
• flow objects (activities, gateways and events)
• connecting objects (sequence flows, message
  flows, and associations)
• swimlanes (pools and lanes)
• artifacts (data objects, annotations, and groups)

12
BPMN

• Flow Objects
• Activities
• Events
• Gateways

13
BPMN

• Connecting Objects
• Sequence flows
• Message flows
• Associations

14
BPMN

• Swimlanes
• Pools
• Lanes

15
BPMN

• Artifacts
• Data objects
• Annotations
• Groups

16
BPMN

• It is more adequate for business process modeling
  than other notations (such as workflow patterns,
  quality principles, or the BWW representation
  model)
• Considered standard for business process modeling
• OMG

17
Approaches

• Common step-by-step
• organizational modeling
• purpose analysis
• functional requirements specification

18
Approaches
19
Approaches

• paper CAiSE'07
• Business strategy and infrastructure modeling
• 1) Describe business strategy by means of an
  organizational mission statement and the
  strategic goals that support it
• 2) Modeling of business infrastructure
• process map, a role model, a resource model, and
  business process models
• 3) Business processes are modeled

20
Approaches

• paper CAiSE'07
• Business strategy and infrastructure modeling
• 1) Describe business strategy by means of an
  organizational mission statement and the
  strategic goals that support it

21
Approaches

• paper CAiSE'07
• Business strategy and infrastructure modeling
• 2) Modeling of business infrastructure
• process map, a role model, a resource model, and
  business process models

22
Approaches

• paper CAiSE'07
• Business strategy and infrastructure modeling
• 3) Business processes are modeled

23
Approaches

• paper CAiSE'07
• IT infrastructure link
• 1) Derivation and analysis of Business process
  goals
• 2) System requirements derivation

24
Approaches

• paper CAiSE'07
• IT infrastructure link
• 1) Derivation and analysis of Business process
  goals

25
Approaches

• paper CAiSE'07
• IT infrastructure link
• 1) Derivation and analysis of Business process
  goals

26
Approaches

• paper CAiSE'07
• IT infrastructure link
• 2) System requirements derivation

27
Approaches

• paper CAiSE'08
• Organizational modeling (As-Is)

28
Approaches

• paper CAiSE'08
• Purpose analysis (To-Be)
• 1) Map Construction

29
Approaches

• paper CAiSE'08
• Purpose analysis (To-Be)
• 2) Map Operationalization

30
Approaches

• paper CAiSE'08
• Purpose analysis (To-Be)
• 3) BPDs Creation and Labeling

31
Approaches

• paper CAiSE'08
• Functional requirements specification (To-Be)

32
Approaches

• paper BIS'08
• Organizational Modeling

33
Approaches

• paper BIS'08
• Business Process Analysis

34
Approaches

• paper BIS'08
• Functional Requirements Specification

35
Practical Experience

• Research description
• UVA and CARE Technologies
• OO-Method
• Problems with traditional analysis
• Business understanding, purpose analysis, and
  communication with end-users
• Just some textual description of requirements and
  validate them on the class diagram or on the
  generated application
• Class diagrams alone might not be appropriate for
  communicating and verifying requirements
• Can be complex to people that haven't been
  trained
• Objects might not be a good way of thinking about
  a problem domain

36
Practical Experience

• Clients opinion
• Analysts opinion
• Difference between senior and junior analysts
• Analysis including enterprise apart from system
  strategies