15-16 novembre 2001

1

Enhancing Requirements Engineeringby Quality Modelling:

a structured Framework

Paolo Donzelli Dept of Informatics

Office of the Prime MinisterRome, Italy

[email protected]

(Cranfield University, RMCS – Shrivenham UK)

15-16 novembre 2001

2

Outline

• Problem description

• The Requirements Engineering Framework

• The Framework at work: a case study

• From RE to system implementation

3

Problem description

4

Introducing an IT system into an organisation

• a successful system implementation relies on

• a firm understanding of the application domain

• our ability of envisioning its impact

• but the application domain is far from being stable

• drives the IT system development

• but must evolve to exploit the system capabilities

• The system must become an "organic" component of the re-engineered company (the to-be company)

5

Envisioning the to-be company (a difficult task)

• The system and its application domain form a larger social-technical system whose overall needs are the ones to be fulfilled.

• Organisations are made of people: the goals, the expectations, and the needs of all the stakeholders, have to be explicitly addressed

• Customer satisfaction becomes an organisation-wide concept, beyond the simple individual customer or user point of view.

6

Advances in Requirements Engineering (1)

• Process modelling-based techniques have been suggested to support the Early RE Phases (requirements discovery, validation and verification), by providing a collaborative environment between analysts and stakeholders to:

• understand the application domain

• translate application domain needs into system requirements

• design the to-be company (by reasoning through feasible alternatives)

(i*)

7

Initial Why/What

OtherApplication

Process

HOW

Why/WhatWhy/What

Why/WhatWhy/What

Why/What

SE

Why/ WhatWhy/What

How

Application Domain (Equipment Procurement)

Application Process (T&E)

Application System (to perform T&E)

Synthetic Environment(to support T&E)

the WHYas

driving factor of the requirementsdiscovery/modelling

process

(KAOS – I*)

Advances in Requirements Engineering (2)

8

Genesis of the proposed RE Framework (1)

• adopt new RE techniques (i.e. process modelling-based and “why”-oriented approaches)

• encompass Quality Modelling approaches, to better deal with stakeholders’ quality issues

• move from “slow, reactive, adversarial, separated software engineering and systems engineering processes to unified, concurrent processes”, which will also include business process reengineering.

9

WHAT

HOW

WHY

assures feasibility

constraints

rationalises

Organisation Modelling

satisfies

specifiesGoal Modelling

Hard Goal Modelling (Functional Aspects)

Soft Goal Modelling (Quality Aspects)

Genesis of the proposed RE Framework (2)

Reasoning about the Why, the What and the How

10

Main Objectives

• Support discovery, and early verification and validation of both user-oriented and organisation-oriented requirements

• Facilitate envisioning and designing the to-be company

• Force reasoning about non-functional requirements since the outset of the project, while dealing with functional ones

• Soft goals play a central role, providing a systematic and organized way of handling non-functional requirements constraints in operational terms, or fit criteria for assessment purposes!

11

The Requirements EngineeringFramework

Main characteristics, Notation, Process

12

The RE Framework: main characteristics

constraints

hard goals

map

ping

to

orga

nisa

tion

soft goals

hard

goa

ls

Soft GoalModelling

OrganisationModelling

Hard GoalModelling

DevelopmentFlow

VerificationFlow

Elicitation &Validation

Flow

stakeholders &analysts

Process

Soft Goalmodelling

Hard Goalmodelling

Organisationmodelling

case study

13

Organisation Modelling (1)

Task

Hard GoalAgent

Resource

Soft Goal

dependency link

deals with the application domain structure

basic elements

14

Organisation Modelling (2)

Agent 1

Task

Hard Goal

Resource

Agent 4

Agent 2

Soft Goal

Data

Agent 3.2

Agent 3.1

CloudAgent 3

complexagent

simpleagent

15

Soft Goal Modelling

link

constraintSG112

A A

AA

OO

link

constraintSG121

link

constraint

soft goals

hard goalderived from

a soft goal

constraint upona hard goal or a task(indicated by the link

field)

A

O

AND decomposition

OR decomposition

SG 1

SG 11 SG 12

SG 122

derived Hard GoalHG 111

HG

dependency link

produces operational definitions of the soft goals, decomposing them into sub hard goals and constraints

16

Hard Goal Modelling

hard goal

task

A

O

AND decomposition

OR decomposition

resource

dependency link

HG 1

TASK 12

resource

A A

OO

Task 112

Task 111HG 122

HG 11

....

determines how to achieve hard goals, by decomposing them into sub hard goals and tasks

17

Combining soft and hard goal models

HG1 SG 1

Agent

HG1

TasK12

A

HG122

A

A

.....

.....

SG1

HG11

constraint121 constraint 122

SG12

A A

A A

HG1

TasK12

resource1111

A

OO

TasK112

Task111

HG122

HG11

Task 112

constraint121 HG122

constraint122

A

.....

A

.....

Agent’s behaviour

(simple or complex)

18

Applying the Framework: the process

• Development Flow

• from top organisational level, down to simple agents level, the models feed each others, in a continuous loop. The complete organisation model will result into a flat network of interrelated goals, tasks, and resources, with agents acting as a modularization mechanism

• Elicitation and Validation Flow

• where interaction with the stakeholders occurs

• Verification Flow

• to guarantee consistency between models

19

A Case Study

20

The case study

• Strongly interrelated with the application domain, highly complex and expensive, they require a RE process strongly focused on the early verification and validation

• Synthetic Environments are distributed interactive simulations of real-world systems, used to support operational, political and economic decisions

• RE process for a ground-based simulator suitable to investigate the feasibility of equipping an aircraft with a new avionics sub-system

21

A ground-based simulator

Ethernet

Software Testing Station

Software Development Stations

AirborneComputer

RadarRadar

Altimeter

NavigationSensors

ThermalPod

controls

Air DataSensors

Radio

Aircraft Model

Simulated Equipments

Head-downDisplays

Head-upDiplay

NavigationDisplays Stick

ThrottleSelectorsThermal

Pod

Real Equipments

Airborne Network System

22

The Organisation Model

ProjectLeader

developThermal Pod

prototypeintegration

evaluateintegrationfeasibility

AirborneSW

Expert

AvionicsSystemExpert

AvionicsSystem Rig

Flight TestCrew

developprototypeavionics

integration

evaluateavionics

integrationfeasibility

collocatethe pod

in its avionicsenvironment

judgment inoperativeconditions

try the pod inflight conditions

podavionics

environmentrealism

flight conditionsrealism

T&EApplication

Process

evaluatenew aircraft

capability

quick / low costprototype

integration

SE trained

SE

evaluatecrew

workload

........

crewjudgement

monitoravionicssystem

behavior

.....

evaluatesoftware

integrationfeasibility

developprototypesoftware

integration

......

providecrew interface

displays

provideairborne

computers

.....

from goals to req.s

clashingreq.s

23

Soft goal upon the Project Leader

A

evaluateintegrationfeasibility

evaluatefinal integration

time & cost

evaluatefinal integration

risks

A

A

estimate final integration

time & cost

evaluatetechnicalfeasibility

A

A

AA

A

evaluate crewworkload

evaluateavionics integration

feasibility.....20% tolerance

A

A

interface ThermalPod

with realequipments

evaluatesoftware integration

feasibility

24

Hard goals upon the Project Leader

developThermal Pod

prototypeintegration

A

AA

A

developprototype

integration

A

estimate final integration

time & cost

A

.....

20%tolerance

developprototypeavionics

integration

.....develop

prototype SWintegration

A

forecast final avionics

time & cost

A

forecastfinal

time & cost

A

interface ThermalPod with realequipments

allocateresource &

staff

A

.....A

.....

.....

25

From high level goals to system requirements

• there is not one single set of global goals that has to be achieved (from which the others are refined in a top-down way)• an organisation consists of numerous processes

occurring simultaneously, involving various agents, following different paths, and intersecting each other

• an agent may operate as goal generator, as well as a goal transformer

• goals propagate through the organisation in complex patterns and may even conflict

• It is from the set of goals and constraints placed upon the system that the final requirements can be obtained

26

Clashing Requirements: detecting and resolving them through soft goals

• Agents may have different opinions, and their goals collide. How can Soft Goals help?

• provide a way to reason about trade-offs, to freeze temporary solutions, and to formalise final decisions

• encourage interactions and a common terminology

• force us to clarify, very early in the project, concepts that are usually left blurred until it is too late (or too expensive) for any corrective intervention

27

“Realism” soft goal for the Flight Test Crew

AA

Flight Crewinterfacerealism

externalcontextrealism

commands &controlsrealism

A

stick, throttleand selectors

realism displaysrealism

AA

realstick, throttleand selectors

realdisplays

AA

A

..... wrap-aroundprojected

display

conflict with AvionicsSystem Expert Soft Goal

provide pilotcockpit view

A

A

ASRmovements

AA

.....

provide amotion

platform

A.....

flight conditions realism

A

sensors &aircraft model

realism

A

5% errortolerance for

altitude sensors

.....A

aircraft model toprovide complete

flight envelope

A

A

A

28

“Realism” soft goal for the Avionics System Expert

A



A


realism

displaysrealism

AA


O O

syntheticstick, throttleand selectors

realdisplays

O O

external contextrealism

A

podavionics

environmentrealism

sensors &aircraft model

realismavionics system

realism

AA

.....A

A

.....A

A

.....

conflict with Flight Test

Crew Soft Goal

Arealon-board

computers


sensorsA

.....A

aircraft model toprovide only

basic flight envelope

A

no externalview

A

conflict with Flight Test

Crew Soft Goal

realon-boarddata-links

A

syntheticdisplays

29

Resolved “Realism” soft goal

A



A


realismdisplaysrealism

A

A


A A

real displays(when pod related)

external contextrealism


.....A

A

.....

pilot viewon flat screen

A

ASRmovements

A

provideno movement

A

A

A

30

Deliverables of the RE Framework

Quality Modelsto

CertificationAuthority

SERequirements

toDevelopment

OrganisationModels

toManagement

31

Have the objectives been achieved?

• The RE Framework improves the early-stage verification and validation of the requirements of a IT system:• Verification is improved by reconciling the different

models• Validation is improved because of the visibility of the

decisions made by stakeholders.

• Application results suggest that the Framework offers benefits to accreditation and maintenance activities, mainly thanks to the two-way goal <-> requirement link• Accreditation should be made easier by tracing the IT

system properties to application domain needs• Maintainability is improved because changes in the

application domain may be easily linked to system changes.

32

From RE to System Implementation

33

Deriving the System Requirements Architecture

• the RE framework allows us to model the application domain at a social-technical level, by providing a systematic approach to deal with agents, soft goals, hard goals and their incremental refinement

• requirements are expressed as a collection of hard goals and constraints placed upon the system by other agents

34

An Extract from the Organisation Model


AvionicsSystem Rig

Flight TestCrew

collocate thepod in itsavionics

environment


podavionics environment

realism

flightconditions

realism

SE


behavior

35

The RE Framework outcomea set of Hard Goals and Constraints

realon-board

computers

real on-boarddata-links

aircraft model toprovide basic

flight envelope


real displays(pod related)


provideno movement


AvionicsSystem Rig

Flight TestCrew


environment



behavior


10% errortolerance for noaltitude sensors

aircraft model toprovide low-altitude flight

capability


altitude sensors

Soft Goals- derived

Constraints&

Hard Goals

....

....

....

36

RE Framework as forerunner for UML

• the front-end activity of any UML-based approach is the use-case modelling, i.e. capturing the ways in which the users intend to interact with it.

• use-case analysis can benefit from supporting methods (Business Process Modelling and Black Box approaches) that help to identify both the actors, and their goals

• the output from our RE Framework, in the form of a set of hard goals and constraints placed upon the system by well-defined agents, is entirely consistent with this.

37

Use-cases as a Goal-refinement Strategy

• a hard goal can lead to one or more use-cases

• constraints will become non-functional requirements

• use-cases offer a systematic and intuitive means of capturing functional requirements

• constraints enrich and complete the use-cases, by providing a systematic and intuitive means of dealing with non-functional requirements.

38

Avionics System Expert: Use-case Diagram

.....real

on-boarddata links

connect pod to avionicssystem

perform pod on-groundoperations

Avionics System Expert

(down)-loadinternal software

perform built-intest procedures

uses

uses


track object on ground

object on ground positionacquisition

acquisition supported byradar altimeter

acquisition supported byGPS

extends

extends


environment

realon-board

computers

perform pod in-flightoperations

uses

uses

uses

.....extends

collect data


behaviour

aircraft model toprovide low-altitude

flight capability

.....


aircraft model toprovide basic flight

envelope realstick, throttleand selectors

Constraintsderived from

Soft Goal Modelling


providepilot cockpit

view

Hard Goalderived from

Soft Goal Modelling

constraints

goals

39

The Use-case Diagram

.....real

on-boarddata links

connect pod to avionicssystem

perform pod on-groundoperations


(down)-loadinternal software

perform built-intest procedures

uses

uses


acquisition supported byradar altimeter

acquisition supported byGPS

extendsextends


environment

realon-board

computers

perform pod in-flightoperations

uses

uses

uses

.....

extends

collect data


behaviour


flight capability

.....



envelope realstick, throttleand selectors



view

track object on ground

object on ground positionacquisition


flight capability

.....


perform pre-, post-and in-flight checks

"fly" the aircraft

Flight Test Crew

low-altitude flight envelope uses

uses

use pod in isolation

use pod combined with other subsystems

try the podin flight

conditions


enveloperealstick, throttleand selectors


view

use pod in operative profiles(e.g search & rescue)

uses

uses

uses

uses

uses

uses

low and/or night visibilityconditions

uses


.....

uses

uses

uses

Airborne SW Expert

40

Building the conceptual model: the class diagram

Flight Test Crew


thermal podselectors

thermal pod

airbornecomputer

aircraft modelview fromcockpit

thermal poddisplay

move, centre, stabilise

activate podselect pod

move, centre,stabilise

external view

pod image

move, centre,stabilise

aircraft position

aircraft position

pod orientation

realon-board

computers





sensors

realpod

Crew selectors& controls

15-16 novembre 2001

Documents

Transcript of 15-16 novembre 2001