1

Advanced Information System Engineering

Lecture 4 SD3043

2

Outline• Requirements Engineering

• Different Requirements Elicitation Methods

• Goal Oriented Requirements Engineering

• Tropos concepts

• Tropos methodology Stages

• OME Tool

• Case Study step-by-step

3

Requirements Engineering• Each software system is built for a purpose• “Software systems requirements engineering (RE) is the process of

discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation” (Nuseibeh, 2001)

• Requirements should specify ‘what’ but not ‘how’• ‘What’ refers to a system’s purpose

– it is external to the system– it is a property of the application domain

• “How’ refers to a system’s structure and behaviour– it is internal to the system– it is a property of the machine domain

4

Functional vs Non Functional• “Functional Requirements”

– fundamental functions of the system• E.g. mapping of inputs to outputs, control sequencing,

formats of input and output data.

• “Non-Functional Requirements (NFRs)”– constraints

• E.g. security, safety, availability, usability, performance, portability,…

Source: Adapted from van Vliet 1999, p241-2

5

RE Elicitation Techniques• Traditional Approaches

– Introspection– Interview/survey– Group elicitation

• Observational approaches– Protocol analysis– Participant Observation

• Model-based approaches– Scenarios: characterizations of the ways in which the system is

used– Use Cases: specific instances of interaction with the system– Goal-based: hierarchies of stakeholders’ goals

• Exploratory approaches– Prototyping (“plan to throw one away”)– http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf– Source: Adapted from Nuseibeh & Easterbrook, 2000 and van Vliet 1999, section 9.1.1

6

RE Elicitation Techniques II• Most existing requirements techniques are intended more for the

later phase of requirements engineering;• Requirements engineering research has taken as starting point the

initial requirements statements, which express customer’s wishes about what the system should do;

• Initial requirements are often ambiguous, incomplete, inconsistent, and usually expressed informally;

• However, understanding the organizational context and rationales that lead up to systems requirements can be just as important for the ongoing success of the system;

• “Early Phase” activities include those that consider – how the intended system would meet organizational goals– why the system is needed– what alternatives might exist– what the implications of the alternatives are for various stakeholders– how the stakeholders’ interests and concerns might be addressed.

7

Goal Oriented RE• Goal-oriented analysis focuses on early requirements,

when problems are identified, and alternative solutions are explored and evaluated.

• During goal-oriented analysis, we start with initial stakeholder goals such “Schedule meeting” and keep refining them until we have reduced them to alternative collections of functional requirements each of which can satisfy the initial goals.

• Initial goals may be contradictory, so the analysis must facilitate the discovery of tradeoffs and the search of the full space of alternatives, rather than a subset.

8

The electronic Single Assessment Process Case Study

• Single Assessment Process (SAP), national policy about an integrated assessment of health and social care needs of older people

• The purpose of the SAP is – to ensure that older people receive appropriate,

effective and timely responses to their health and social care needs, and that professional resources are used effectively.

• eSAP - electronic Single Assessment Process: an electronic system to deliver an integrated assessment of health and social care needs of older people. – http://ftp1.de.freebsd.org/Publications/CEUR-WS/Vol-5

7/id-16.pdf

9

The eSAP context9

• In the SAP, different health care professionals, such as general practitioners, nurses and social workers, must cooperate together in order to provide patients with appropriate care

• professionals work in teams :– Each team consists of many different professionals– Professionals cooperate between them– Professionals share information between them– Each professional has some expertise– Teams will promote person-centred care

10

The eSAP context II• SAP provides the older person and their carer with a

personal copy of their care plancare plan to support person-person-centred carecentred care

• The SAP works in three main stages:

1.1.contactcontact assessment will provide basic information

2.2.overall assessmentoverall assessment using a validated assessment instrument, such as Easy-Care, will take place

3.3.more caremore care in particular problems and with more more detailed assessmentdetailed assessment if appropriate.

11

A Use Case Diagram(what important information is missing?)

Arrange Appointment

Access Medical RecordsOlder Person

Provide Personal Information

12

The Tropos Methodology• The framework was developed for modelling and

reasoning about organizational environments and their information systems.

• It adds a process to the i* framework modelling language

• It consists of two main modelling components: – The Actor Diagram: used to describe the dependency

relationships among various actors in an organizational context.

– The Goal Diagram: is used to describe stakeholder interests and concerns, and how they might be addressed by various configurations of systems and environments.

13

The i* language• The central concept in i* is that of the intentional actor• Organizational actors are viewed as having intentional

properties such as goals, plans, beliefs, abilities, and commitments.

• Actors depend on each other for goals to be achieved, plans to be performed, and resources to be furnished.

• By depending on others, an actor may be able to achieve goals that are difficult or impossible to achieve on its own.

• On the other hand, an actor becomes vulnerable if the depended-on actors do not deliver.

• Actors are strategic in the sense that they are concerned about opportunities and vulnerabilities, and seek rearrangements of their environments that would better serve their interests.

14

Graphical Representation of Tropos concepts

Plan

15

Actor• An actor represents an entity that has intentionality and strategic

goals; • An actor can be a (social) agent, a position, or a role. • Agents can be physical agents, such as a person, or software

agents. – Software agent is a software entity that has properties such as

autonomy, social ability, reactivity, and proactivity. • A role represents an abstract characterisation of the behaviour

of a social actor within some specialised context or domain of endeavour.

• A position represents a set of roles, typically played by one agent.

16

Goal• In Tropos, the concept of a hard-goal (simply goal

hereafter) is differentiated from the concept of soft-goal.• A (hard) goal represents a condition in the world that

an actor would like to achieve. • In other words, goals represent actor’s strategic

interests. • A soft-goal is used to capture non-functional

requirements of the system, and unlike a (hard) goal, it does not have clear criteria for deciding whether it is satisfied or not and therefore it is subject to interpretation.

• For instance, an example of a soft-goal is “the system should be scalable”.

17

Plan• A plan/task represents, at an abstract level, a

way of doing something. • The fulfilment of a task can be a means for

satisfying a goal, or for contributing towards the satisficing of a soft-goal.

• In Tropos different (alternative) tasks, that actors might employ to achieve their goals, are modelled.

• Therefore developers can reason about the different ways that actors can achieve their goals and decide for the best possible way.

18

Resource• A resource presents a physical or

informational entity that one of the actors requires.

• The main concern when dealing with resources is whether the resource is available and who is responsible for its delivery.

19

Dependency• A dependency between two actors represents that one actor depends on the

other to attain some goal, execute a task, or deliver a resource. • The depending actor is called the depender and the actor who is depended

upon is called the dependee. • The type of the dependency describes the nature of an agreement (called

dependum) between dependee and depender. • Goal dependencies represent delegation of responsibility for fulfilling a goal. • Soft-goal dependencies are similar to goal dependencies, but their fulfilment

cannot be defined precisely • Task dependencies are used in situations where the dependee is required to

perform a given activity. • Resource dependencies require the dependee to provide a resource to the

depender. • By depending on the dependee for the dependum, the depender is able to

achieve goals that it is otherwise unable to achieve on their own, or not as easily or not as well.

• On the other hand, the depender becomes vulnerable, since if the dependee fails to deliver the dependum, the depender is affected in their aim to achieve their goals.

20

Modelling Activities• Actor modelling consists of identifying and analysing

the system’s domain actors as well as the actors of the system together with their goals.

• Dependency modelling, which involves the identification of the dependencies between the different actors.

• Goal modelling involves further analysis of particular actors’ goals, from the viewpoint of the actor. In other words, the internal goals of each actor identified through actor modelling are furthered analysed in order to provide a more precise definition of the actor.

• Soft-goal and task modelling are considered complimentary to the goal modelling activity and they employ similar reasoning techniques.

21

Reasoning Techniques• Goal, soft-goal and plan modelling are mainly based on

three reasoning techniques • Means-end analysis is employed to identify goals, soft-

goals, plans, and/or resources that can provide means for reaching a goal.

• Contribution analysis can be thought of as a special case of means-end analysis in which means are goals or soft-goals. Such analysis identifies goals that can contribute either positively or negatively to the achievement of other goals (or soft-goals).

• Decomposition refers to the systematic breakdown of a component into simpler more specific components. – AND decomposition means all the sub-goals/sub-plans must be

achieved for the root goal/task to be achieved, – OR decomposition means that the achievement of one of the sub-

goals/sub-plans leads to the achievement of the root goal/task.

22

Tropos Links

23

The eSAP Case Study: Actor Diagram

24

24

25

25

26

26

27

Tropos Methodology Stages

Early Requirements

Early Requirements

Late Requirements

Late Requirements

Architectural Design

Architectural Design

Detailed DesignDetailed Design

Start

End

28

Early Requirements Stage• Developers are concerned with the understanding of a problem by

studying an existing organisational setting. – Identification of the domain stakeholders and their modelling as

social actors; – Model the stakeholders as actors, their intentions as goals, and

their relationships as dependencies (Actor diagram); – Through a goal-oriented analysis, the actors’ goals are

decomposed into more precise goals and sometimes into tasks that if performed by the actor, allow for goal achievement (Goal diagram);

– The output of this phase is an organisational model (Actor and respective goal diagrams), which include relevant actors and their respective dependencies.

29

Late Requirements Stage• The system-to-be is specified within its operational

environment, together with relevant functions and qualities.

• This description models the system as an actor, who has a number of dependencies with the actors identified during the previous stage.

• These dependencies indicate the obligations of the system towards its environment, and therefore define the system’s functional and non-functional requirements.

• Same models as Early Requirements but with the System!

30

Stages / Diagrams• Early Requirements (only stakeholders)

– Actor Diagram

– Goal Diagrams for each actor

• Late Requirements (stakeholders and System)– Actor Diagram

– Goal Diagrams for each actor

31

Organisational Modelling Environment (OME) Tool

http://www.cs.toronto.edu/km/ome/

32

Graphical Representation of Tropos concepts

Plan

33

eSAP Brief Description• Single Assessment Process (SAP), an integrated

assessment of health and social care needs of older people.

• The Single Assessment Process aims to create closer working for providing primary health and social care for older people and other groups.

• In the SAP setting, different health care professionals, such as general practitioners, nurses and social workers, must cooperate together in order to provide patients with appropriate care.

34

Case Study: eSAP Stakeholders

• Main Stakeholders:– Older Person (OP) is the patient that wishes to

receive appropriate health and social care.

– Department of Health (DoH) is the government department that must provide older people with health and social care.

– R&D Agencies are agencies that wish to obtain information about older people to help them in their research.

35

eSAP: Stakeholders’ Goals• The Older Person actor has as a main goal to

receive appropriate health and social care and as a soft goal to Maintain Good health.

• The Older Person depends on the DoH to accomplish their goal and soft goal.

• The DoH has as a main goal to Provide Better Health and Social Care to Elderly.

• The R&D Agency has a goal to Obtain Patient Information For Research.

36

Early Requirements: Actor Diagram

37

eSAP: OP Actor Analysis• Older Person actor has as a goal to receive appropriate

care and a soft goal to maintain good health. • The receive appropriate care goal is fulfilled by the tasks

Undertake Assessment, Follow Care Plan, Get Info about Care Plan, Obtain Medical Info, and Have Appointment with Professionals.

• To perform the last three tasks the Older Person must use the eSAP system, so the last three tasks are decomposed into the goal Use eSAP System.

38

eSAP: OP extra dependencies• In addition, the Maintain Good Health soft

goal depends on the Follow Care Plan and Undertake Assessment tasks to be fulfilled.

• Furthermore, the Older Person depends on the DoH to make the Technology Infrastructure Available, and also to make the eSAP System Available and Easy-to-Use.

39

Early Requirements: OP Goal Diagram

40

eSAP: DoH analysis• The main goal of the Department of Health is to

Provide Better health and Social Care to Elderly. • To accomplish this goal, DoH defines a sub goal

to Make Care Person-Centred. The later is essential for the DoH to fulfil its main goal since the Older Person is the most important participant of the whole procedure, since they know better than anyone their difficulties and when they need health and social care.

41

DoH Analysis (2)• The Make Care Person-Centred goal is further

decomposed into the two sub-goals Promote SAP and Involve Elderly in their Care.

• The later sub-goal depends on the task Provide Guidelines for the Older People to be fulfilled.

• The Promote SAP sub-goal is decomposed into the Computerise SAP goal and the Provide Guidelines for the SAP task. The later task is decomposed into two sub-tasks: Provide Guidelines for the Different Health and Social Care Professionals and Provide Guidelines for the Care-Teams.

42

DoH Analysis (3)• The first sub-task is further decomposed

into four sub-tasks: Provide Guidelines for GPs, Provide Guidelines for Nurses, Provide Guidelines for Other Professionals and Provide Guidelines for Social Workers.

• In addition, to fulfil the Provide Guidelines for the Care-Teams goal each locality must comply with the proposed guidelines.

43

DoH Analysis (4)• Provide Efficient Care is another important goal of the

DoH. To accomplish this goal the sub goal Computerise SAP has been identified. Computerising the SAP will help health and social care professionals to automate some procedures required while caring of the older person and thus help to Provide Efficient Care. To accomplish the Computerise eSAP sub goal, Technology Infrastructure must be provided and the eSAP System must be available. The goal Build eSAP is motivated by these two goals since it has no sub-goals.

44

DoH Goal Diagram

45

Late Requirements: eSAP Goal Diagram

46

Conclusions46

• Requirements Engineering• Goal Oriented RE• i* (http://www.cs.toronto.edu/km/istar)• Tropos (www.troposproject.org)• Next week:

– Tool support (OME);– Create Actor and Goal Models for a Case Study

• Tropos methodology Stages• OME Tool• Case Study step-by-step

47

References

• Requirements Engineering: A Roadmap http://mcs.open.ac.uk/ban25/papers/sotar.re.pdf

• Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering http://www.cs.toronto.edu/pub/eric/RE97.pdf

• UML for Early Requirements Elicitation: A Regulation based Approach http://infoscience.epfl.ch/record/416/files/TR02_013.pdf

• Using Tropos Methodology to Model an Integrated Health Assessment System http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-57/id-16.pdf

• Tropos: An Agent-Oriented Software DevelopmentMethodology http://www.troposproject.org/