Eliciting Goals for Business Process Models with Non-

Functional Requirement Catalogues

Renata S.S. Guizzardirguizzardi@inf.ufes.br

Workshop on Ontologies in Conceptual Modeling

Valencia, SpainJuly, 2010

Knowledge Management

KM can be defined as a systematic process for acquiring, organizing and communicating

knowledge to all members of an organization, enabling them to be more effective and

productive in their work.

Conveying to people the right piece of information

at the right place, in the right time.

“There is no time for filling in the system with new knowledge.”

“Oh, it’s too much effort to fill in the system, and then I can never find something useful in it when I need it.”

“What if someone does something wrong with the knowledge I give away?”

“Why should I share my knowledge if knowledge is power?”

Knowledge Management Pitfalls

Lack of trust

Effort vs. Knowledge availability

Detachment from daily working practices

Lack of motivation

Two views of Knowledge Management

Codification: systematically storing worker’s knowledge

Personalization: supporting worker’s in their natural knowledge sharing processes.

(Hansen et al. 1999)

Theoretical Framework

knowledge spiral

communities of practice

distributed knowledge management

situated learning

genetic epistemology

social-historical constructivism

constructionism

dialogue and context in learning

knowledge management theories

constructivism

physical meaningful

artifactsperturbation context

autonomynon-hierarchical

knowledge sharingsocial interaction

Applying Agents as a Modeling Paradigm

Concepts which are able to capture the human dimension which are closer to people (communication to the

user is made easier)

belief

goalintention

social ability desires

learning ability

Combining Different Agent-oriented Modeling Languages

Methodology Requirements Developing a good understanding of the

organizational setting before jumping into the solution space.

Designing the system with an enough amount of detail to enable coding

Key question

What are the right set of abstractions for each activity (or phase) in the system development

process?

Ontological Approach

Developing Effective KM Solutions

overall organizational goals

stakeholders goals

negotiating and reconciling

these goals

Methodology

Requirements Model + Architectural Design + Detailed Design

Tropos AORML

ARKnowD =

ARKnowD: Agent-oriented Recipe for KM Systems Development

ARKnowD: Agent-oriented Recipe for KM Systems Development

Agents as development paradigm Cognitive and social characteristics.

Combining Existing work Tropos for Analysis & AORML for Design

MDD-inspired Transformation from Tropos to AORML

Agent Ontology Clarifying definition of applied concepts. Assisting the transformation from Tropos to AORML. Evaluating and adjusting ARKnowD’s notation.

Tropos’ Language Actor Resource Goal Softgoal Plan Dependency Decomposition Contribution Means-end

Characteristics of Tropos Potential

gives particular attention to requirements engineering, this makes it a natural candidate for organizational modeling

is based in goal modeling: represent organization’s and stakeholders’ goals

provides an abstract view of the organization (actors, goals, dependencies…), allowing us to leave details for later development cycles

Limitations does not provide tools to model agent’s interaction and

behavior with an appropriate amount of detail due to large use, constructs are extremely overloaded

(there is no consensus regarding their use)

Agent-Object-Relationship Modeling Language (AORML) Agent Object Action (Communicative Action) Interaction Event Commitment/Claim Association Specialization Composition Do/Perceive (the action)

Characteristics of AORML Potential

offers the means to model agent’s information, interaction and internal behavior in detail

naturally captures reactive behavior by using rules models both agents and objects provides deontic modeling constructs such as

commitments and claims, which form the basis for the establishment of such norms and contracts.

Limitations lacks constructs specific for requirements analysis limited case tools support so far

UFO-C: Social and Mental Moments

UFO-C: Dependency vs. Delegation

Fixing Incompleteness in Tropos

Fixing Construct Overload in AORML

Transformation Rules

• MDD metamodel transformation: from CIM to PIM

ARKnowD

dependeedepender

goal dependency

delegateedelegator

goal delegation

dependeedepender

resource dependency

aquisiteeacquisitor

resource acquisition

Early Requirements

Late Requirements

human and institutional agents

plan

artificial agents

Architectural Design

Detailed Design

Transformation

agent

object

<<communication>>

relationships

Mike's AM: Artifact Model

Mike: Peer

createTaxonomy

title=”Health Insurance Taxonomy”

1

inclConceptTax

taxID= 12parent=nullconcept=”Health Insurance”

2

inclConceptTax

taxID= 12parent=”Health Insurance”concept="Client”

3

4

5

newTaxonomytaxID=12title="Health Insurance”

newConcepttaxID=12parent=nullconcept=”Health Insurance”

6

newConcepttaxID=12parent=”Health Insurance”concept="Client”

Interaction modeling

searchAnswer

Peer Assistant Artifact Manager

KeyQuestion,VectConcR1

<<belief>>Artifact Model

provideDocument Docs

provideExplanation

Question, Answer

noAvailableArtifact

behavior modeling

Tropos AORML

Ongoing Work Evolving UFO-C

ARKnowD’s Case Tool Completing previous work on implementing the

transformation from Tropos to AORML on an existing tool (TAOM4E).

Extending the methodology to coding (MDD: PIM to PSM).

Organizational Patterns (Semi)-automatically recognizing the Constructivist

KM Principles in the Tropos models.

But...

KM support does not always require a supporting system.

Business Process Modeling

Business Process Modeling focuses on a detailed understanding of the chain of

activities that deliver the organization’s products and services.

Main benefits Allowing traceability between goals and

business process models How goals are operationalized into BP. How BP impact the achievement of goals.

Providing Modularity both to Goal and BP models.

Diagnosing needs for reengineering.

Developing process-oriented information systems which are aligned with organization’s goals.

Combining Goals and BPM

Goal modeling + Business Process Modeling

Tropos ARIS-EPC

Organizational Model =

Example - BPMCarries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Carries out & Supports Other

Org

aniz

ati..

..

Patient Physician

Laboratorialexams

previouslyachieved

Verify thepreviously

achievement oflaboratorial exams

Laboratorialexams

not previouslyachieved

Ask forlaboratorial

exams

Performrequired

laboratorialexams

Laboratorialexams

performed

Process

A Fragment of a Business Process Model in ARIS: Diagnosing a Patient

BPM Approaches Neglect Goals

Minimize patient'sphysical sufferingand symptoms

Heal thepatient

Diagnosepatient's

health state

Prescribepatient`streatment

Show empathyto patient

Providemedical care

to patient

Overriding Goals

Subordinate Goals

Function ARIS goal model

Limitations of goal models of BPM approaches Do not allow an in depth goal analysis

Unclear semantics for decomposition. It does not model alternatives. It does not allow one to reason about how a

goal directly impacts other goals.

Weak connection to processes Relation about goals and processes is not

clear.

Lack of methodological guidance to elicit and model goals.

Atualmente: Tropos+ARIS

dependeedepender

goal dependency

delegateedelegator

goal delegation

dependeedepender

resource dependency

aquisiteeacquisitor

resource acquisition

Requisitos Iniciais

Requisitos Finais

human and institutional agents

plan

VAC EPC

Transformation

FAD

?

?

?

?

Tropos - objetivos ARIS - processos

artificial agents

Case Study A case study in a real organization was

conducted with the purpose of supporting the investigation regarding the relations between goals and processes.

Three phases: Elicitation phase: goal models and BPMs were

captured; Harmonization phase: a goal taxonomy was

created to help in the alignment of goals and BPs; Alignment phase: UFO is applied to clarify the

semantics of the elements of both models, enabling the alingment.

Elicitation Phase Preliminarly, standard methods were applied:

interviews and observation of work.

process oriented goals

Non Functional Requirements (NFR) Catalogues were applied, helping to elicit

allowed a more strategic point of view

NFR Catalogue (Chung et al., 2000)

Adjusting NFRs BP Requirements

NFRs have been originally proposed for system requirements elicitation. We should adjust them for eliciting BP requirements.

Approach: translating NFRs to the medical goal domain, relating the existing NFR types to selecting goals in our models.

One big distinction: originally, they lead to Tropos softgoals in our case, they may lead both to Tropos goals and

softgoals.

A Model without NFR

A Model with Catalogue

A few examples Accessibility - Access patient’s data records; Confidentiality - Maintain healthcare information private; Completeness - Obtain complete information about patient’s

treatment; Accuracy - Obtain accurate information about patient’s treatment; Traceability - Obtain traceability for information in patient’s

treatment (refined into Obtain traceability in investigation of patient’s condition, Obtain traceability in relation to treatment administered to patient and Obtain traceability in relation to physicians who prescribed patient’s treatment);

Integrability - Integrate service with other hospital departments, Integrate service with municipal and state health services and Integrate service with specialists in areas related to rheumatology;

Trust and confidence to the provider (assurance) - Trust physician

Empathy – provide patient with caring and personalized attention

Harmonization Phase

Taxonomy to guide how goals connect to processes (or portions of processes)

Total of 15 different goal types, classified according to 6 dimensions.

Examples: Dimension: Level of abstraction

Fundamental goal (provide medical care to patient) Process goal (diagnose patient health state) Activity goal (prescribe patient’s treatment)

Dimension: Temporal Aspect AS-IS (approve the treatment proposed by the resident) Change goal (standardize diagnosis cue sheets) TO-BE (coordinate patient care with other healthcare providers)

Acknowledgements

This research is funded by the Brazilian ResearchFunding Agencies FAPES (grant number 45444080/09) and

CNPq (grants number 481906/2009-6)