Modelling Software Systems and Engineering their Requirementsssel.vub.ac.be/francqui/lib/exe/fetche365.pdf?cache=... · 2007-05-03 · Modelling Software Systems and Engineering their

Axel van LamsweerdeModeling Software Systems and Engineeringtheir Requirements: why should we care?

Belgian Francqui Chair 2006-2007Vrije Universiteit Brussel

© A. van Lamsweerde 1

Modelling Software Systemsand Engineering their Requirements:

Why should we care?

Axel van LamsweerdeUniversity of Louvain

B-1348 Louvain-la-Neuve

Inaugural LectureBelgian Francqui Chair 2006-2007

Vrije Universiteit Brussel

A serious problem ...

u US survey: 8000 software projects, 350 companies

– success: 16 %

– failure: 33 %– so so: 51 % (partial functionalities, excessive costs, big delays)

major source of failure: requirements-related causes ≅ 50% responses




A serious problem ... (2)

Major source of failure: requirements-related causes ≅ 50% responses:

– lack of user involvement 13%

– incomplete requirements 13%– changing requirements 9%

– unrealistic expectations 10%– unclear goals 5%

(www.standishgroup.com/chaos.html, 1995)


u EU survey: 3800 organizations, 17 countries

Main perceived software problems are in...

– requirements specification

> 50% responses

– requirements management

50% responses

(European Software Institute, 1996)





u ... perceived to persist in spite of progress in software technology

(J. Maresco, IBM developersWork, 2007)

Failure %

1994 2000 2003

100

50

other causes

requirements-related

0

Outline

u Requirements engineering (RE)– What it is– Why it is difficult– Why it is important

u Models for RE– Why models, what models?

u Goal-oriented RE– Goal-based model building

– Model analysis




What RE is, roughly ...

u Analyze problems with an existing system (system-as-is),

u Identify objectives & opportunities for new system(system-to-be),

u Define functionalities of, constraints on,responsibilities in system-to-be,

u Specify all of these in a requirements document

System = software + environment (humans, devices, other software)

Requirements in the software lifecycle

Requirements engineering

Software design

Software implementation

Software evolution

Gettingthe

rightsystem

Gettingthe

softwareright




What is RE about ?

goalsWHY ?

WHAT ?

operationalization

requirements,assumptions

domainknowledge

What is RE about ?

goalsWHY ?

WHAT ?

WHO ?

operationalization

responsibilityassignment

requirements,assumptions

domainknowledge




What is RE about ? (2)

u System requirements vs. software requirements– some phenomena are shared by the software

and its environment– other phenomena are owned by the environment– other phenomena are owned by the software

Environment Sofware

E ∩ S

TrainMoving

TrainAtStation

DoorsClosed

measuredSpeed ≠ 0

doorsState = ’closed'

errorCode = 013

What is RE about ? (3)

u System requirements: prescriptive assertionsformulated in terms of environment phenomena

TrainMoving ⇒ DoorsClosed

u Software requirements: prescriptive assertionsformulated in terms of shared phenomena

measuredSpeed ≠ 0 ⇒ doorsState = 'closed'

u Domain properties: descriptive assertions aboutenvironment, needed for mapping SysReq to SoftReq

TrainMoving ⇔ measuredSpeed ≠ 0




Requirements vs. assumptions and domain properties

u RE involves satisfaction arguments

SoftReq, Ass, Dom |— SysReq

“ in view of properties Dom & assumptions Ass, the software requirements SoftReq meet the system requirements SysReq”

SoftReq: doors get open at station

Dom: passenger can get out when doors are open

Ass: passenger gets out if doors open at destination

SysReq: passenger gets out at destination station

The RE process

start

domain analysis& elicitation

alternative proposals




The RE process

start


evaluation& negotiation


agreedrequirements

The RE process

start




agreedrequirements

documented requirements

specification& documentation




The RE process

start




agreedrequirements


consolidatedrequirements


validation& verification

RE: an iterative process

start




agreedrequirements


consolidatedrequirements


validation& verification




Why RE is hard

u Broad scope– two systems: system-as-is, system-to-be– system-to-be = software + environment– hybrid environment:

human organizations, policiesdevices, physical laws

Multiple concernsfunctional, quality, development concerns

Multiple abstraction levelsstrategic objectives, operational details

Why RE is hard

u Broad scope– two systems: system-as-is, system-to-be– system-to-be = software + environment– hybrid environment:

human organizations, policiesdevices, physical laws

u Multiple concerns– functional, quality, development concerns

u Multiple abstraction levels– strategic objectives, operational details




Why RE is hard (2)

u Multiple stakeholders

– with different background

– with different interests and conflicting viewpointsproject managersdomain expertsusers, clientssubcontractorsdecision makersanalysts, developers...

Why RE is hard (3)

u Multiple intertwined activities during iterative elicitation-evaluation-specification-consolidation

– conflict managementfunctionality vs. quality vs. costdiverging viewpoints among stakeholders

– risk managementanticipation of hazards and threats

evaluation of alternatives, prioritizationquality assurancechange anticipation




Why RE is hard (3)

u Multiple intertwined activities during iterative elicitation-evaluation-specification-consolidation

– conflict managementfunctionality vs. quality vs. costdiverging viewpoints among stakeholders

– risk managementanticipation of hazards and threats

– evaluation of alternatives, prioritization– quality assurance– change anticipation

Why RE is important

u Legal impact– contractual commitment client-provider

u Social impact– from user satisfaction

to degradation of working conditions to system rejection

u Technical impact– on many software-related artefacts




Requirements impact on many software artefacts

requirements& assumptions

project estimations & planning(size, cost, schedules)

software prototype,mockup

softwarearchitecture

call for tenders,proposal evaluation

qualityassurance checklists

projectcontract

software evolutiondirectives

software documentationuser manual

acceptancetest data

implementationdirectives

impact

Why RE is important (2)

u Impact on certification– mastered RE process required by many quality

standards & certification authorities

u Impact on economy, security, and safety– cost and consequences of errors in ...

requirements on softwareassumptions about environment




Wide variety of errors & flaws in requirements, assumptions, and domain properties

– Incompleteness critical !– Inconsistency critical !– Inadequacy critical ! – Ambiguity critical ! – Unintelligibility– Unmeasurability– Poor structure– Overspecification– Noise

Errors in requirements/assumptions are ...

u the most numerous– ± 40% of software errors

u the most persistent– often found very late, after software delivery

the most expensivecosts ... 5x more if fixed during design 10x more if fixed during implementation

20x more if fixed during integration testing 200x more if fixed after delivery66% of software error costs(Boehm, Jones, Lutz, Hooks & Farry, ...)




Errors in requirements/assumptions are ...

u the most numerous– ± 40% of software errors

u the most persistent– often found very late, after software delivery

u the most expensive– cost ... 5x more if fixed during design 10x more if fixed during implementation

20x more if fixed during integration testing 200x more if fixed after delivery– account for 66% of software error costs(Boehm, Jones, Lutz, Hooks & Farry, ...)

Requirements errors are the most dangerous

u US Aegis/Vincennes (1988): shooting of IranAir airbus– missing timing between 2 threat events in

requirements on alarm softwareu Patriot anti-missile system (1st Gulf war)

– hidden assumption on maximum usage time

London Ambulance System: fatal intervention delayswrong assumptions on crew behavior, ambulance

localization system, radio communication, ...Boeing 757 crash, Cali

wrong timing/localization assumption on flapextension point

etc




Requirements errors are the most dangerous

u US Aegis/Vincennes (1988): shooting of IranAir airbus– missing timing between 2 threat events in

requirements on alarm softwareu Patriot anti-missile system (1st Gulf war)

– hidden assumption on maximum usage time

u London Ambulance System (1993): fatal delays– wrong assumptions on crew behavior, ambulance

localization system, radio communication, ...u Boeing 757 crash, Cali (1995)

– autopilot ’s wrong timing/localization assumptionon flap extension point

u ...

Example: a fatal error in A320 braking logic

MotorReversed ⇔ MovingOnRunway

MotorReversed⇔ WheelsTurning

MovingOnRunway⇔ WheelsTurning




Finding the error by obstacle analysis

NOTMovingOnRunway ⇔ WheelsTurning

NOTMotorReversed ⇔ WheelsTurning




obstruction

Detecting the error by obstacle analysis

NOTMovingOnRunway ⇔ WheelsTurning

NOTMotorReversed ⇔ WheelsTurning

MotorReversed And NotWheelsTurning

Aquaplaning ...




obstruction

WheelsTurning And NotMotorReversed

MovingOnRunway And Not WheelsTurning

WheelsTurning And NotMovingOnRunway

WheelsNotOut WheelsBroken ...

...

...

Lufthansa crashin Warsaw




A similar fatal error in the handbraking logicof an “intelligent” car

BrakeReleased ⇔ DriverWantsToStart

BrakeReleased⇔ MotorRaised

MotorRaised ⇔AccelerPedalPressed

AccelerPedalPressed⇔ DriverWantsToStart

A similar fatal error in the handbraking logicof an “intelligent” car

BrakeReleased ⇔ DriverWantsToStart

BrakeReleased⇔ MotorRaised

MotorRaised ⇔AccelerPedalPressed

AccelerPedalPressed⇔ DriverWantsToStart

MotorRaised And NotAccelerPedalPressed

AirConditioningRaised

...

... ...

...

Driver killed by hisluxurious car on a hot summerday




Outline

u Requirements engineering (RE)– What it is– Why it is difficult– Why it is important

u Models for RE– Why models, what models?

u Goal-oriented RE– model building

– model analysis

Model-based RE

u Model =– abstract representation of complex system

(as-is or to-be)– highlights, specifies, inter-relates key

system features– facilitates analysis

u Provides focus & structure for RE activities– target for what must be elicited, evaluated,

specified, consolidated, modified




Why models for RE ?

u Abstraction from multiple details: focus on keyaspects

u Support for early detection and fix of errors

u Interface among RE activities: produce or consumemodel items

Support for understanding and explanation tostakeholders

Basis for making decisions: multiple options madeexplicit

Basis for generating requirements document

Why models for RE ?

u Abstraction from multiple details: focus on keyaspects

u Support for early detection and fix of errors

u Interface among RE activities: produce or consumemodel items

u Support for understanding and explanation tostakeholders

u Basis for making decisions: multiple options madeexplicit

u Basis for generating requirements document




Requirements on models for RE

u Adequate: close reflection of system whileabstracting from unnecessary details

u Complete & pertinent: capture of all relevant systemfacets along WHY-, WHAT-, WHO-dimensions

⇒ multi-view model

Precise & analyzable: for error detection/fix⇒ formal specification when & where needed

Multi-level: capture of different levels of abstraction& precision for incremental analysis

⇒ refinement mechanism

Requirements on models for RE

u Adequate: close reflection of system whileabstracting from unnecessary details

u Complete & pertinent: capture of all relevant systemfacets along WHY-, WHAT-, WHO-dimensions

⇒ multi-view model

u Precise & analyzable: for error detection/fix⇒ formal specification when & where needed

u Multi-level: capture of different levels ofabstraction & precision for incremental analysis

⇒ mechanism for model refinement




Requirements on models for RE (2)

u Open & evolvable⇒ highlighting of alternative options

u Traceable: easy retrieval of source, rationale,impact of modeling decisions

⇒ rich traceability links

Comprehensible by stakeholders for furtherelicitation, evaluation, validation, modification

⇒ diagrammatic representation

Requirements on models for RE (2)

u Open & evolvable⇒ highlighting of alternative options

u Traceable: easy retrieval of source, rationale,impact of modeling decisions

⇒ rich traceability links

u Comprehensible by stakeholders for furtherelicitation, evaluation, validation, modification

⇒ diagrammatic representation




KAOS: goal-oriented, model-driven RE

modeling

generation of RE deliverables

interviews documents

.html

.rtf.pdf.mif

existing systems

analysis

What models ?

Goals Agents, responsibilities

Objects Operations

on what?

who ?why ?how ?

what ?




What models ? (2)

Interaction scenarios Behaviors

Hazards Threats

I

Multiple languages are integrated forspecification of model components

u Diagrammatic, for comprehension

– AND/OR graphs

– simple subset of UML

u Formal, for analysis (optional) based on mathematical logic and automata

– Real-time linear temporal logic

– Labeled Transition Systems (LTS)




Goals

Specifying goals in RT-LTL for formal analysis

Goal Maintain [DoorsClosedUntilNextStation]

FormalSpec ∀ tr: Train, s: Station

At (tr, st) ∧ o ¬ At (tr, st) ⇒ tr.Doors = "closed" W At (tr, next(st))

Goal Achieve [FastJourneyBetweenStations]

FormalSpec ∀ tr: Train, s: StationAt (tr, st) ⇒ ◊≤T At (tr, next(st))




Objects

Responsibilities




Hazards,responses

Operationalizations




What kind of model-based reasoning ?

u Checking / deriving goal refinements &operationalizations

u Goal-oriented model animation

u Conflict analysis

Hazard analysis: generating & resolving obstacles to goals

Threat analysis for more complete model withcountermeasures - generating attack graphs

Synthesis of behavior models from scenarios & goals

What kind of model-based reasoning ?

u Checking / deriving goal refinements &operationalizations

u Goal-oriented model animation

u Conflict analysis

u Hazard analysis: generating & resolving obstacles to goals

u Threat analysis for more complete model withcountermeasures - generating attack graphs

u Synthesis of behavior models from scenarios & goals




Animation

Check demo

Refinement checking




Threat analysis for more complete model

ItemOrderedByBuyer ⇒ ◊≤7d ItemReceivedByBuyer

ItemOrdered ⇒◊≤2d ItemPaid

ItemPaid ⇒◊≤2d ItemSent

ItemPaid⇒ ◊≤1d BELIEFS(ItemPaid)

ItemSent ⇒ ◊≤3d ItemReceived

BELIEFS(ItemPaid) ⇒ ◊≤1d ItemSent

Seller

ItemPaid ⇒◊≤8h PaymentReceived

PaymentReceived ⇒◊≤8h NotificationSent

NotificationSent ⇒◊≤8h NotificationReceived

NotificationReceived ⇒BELIEFS(ItemPaid)

Seller

ShippingCo

Threat analysis for more complete model

ItemOrderedByBuyer ⇒ ◊≤7dItemReceivedByBuyer

ItemOrdered ⇒◊≤2d ItemPaid

ItemPaid ⇒◊≤2d ItemSent

ItemPaid⇒ ◊≤1d BELIEFS(ItemPaid)

ItemSent ⇒ ◊≤3d ItemReceived

BELIEFS(ItemPaid) ⇒ ◊≤1d ItemSent

Seller

ItemPaid ⇒◊≤8h PaymentReceived

PaymentReceived ⇒◊≤8h NotificationSent

NotificationSent ⇒◊≤8h NotificationReceived

NotificationReceived ⇒BELIEFS(ItemPaid)

Seller

ShippingCo

◊≤2d ItemSent∧ ¬ ItemPaid

◊≤1d BELIEFS(ItemPaid)¬ ItemPaid

◊≤1d NotificationReceived

Attacker◊≤16h FakeNotificSent

anti-model




• Modeling terrorist threats (anti-goal model)• RE for on-board detection & reaction system

Application:Security of Aircraft in the Future European Environment

(External threats)

Threats against crew & passengers

Threats from baggage area

Synthesis of state machines from scenarios & goals




The next lectures...

u L2-L3: Model-based RE– goals, objects, agents, operations– a systematic model building method

u L4-L6: Reasoning about system models– Checking goal refinements– Deriving goal operationalizations– Obstacle analysis– Threat analysis– Conflict analysis– Goal-oriented model animation– Synthesizing behavior models from scenarios/goals

Conclusion

u Engineering high-quality requirements is difficultand critical ...– do requirements meet the system ’s goals ? under realistic assumptions ?– are such goals, requirements, assumptions

complete, adequate, consistent, non-ambiguous ?

The earliest requirements errors are found, the best

For requirements completeness: be pessimistic frombeginning about software and environmenthazards, threats, conflicts




Conclusion

u Engineering high-quality requirements is difficultand critical ...– do requirements meet the system ’s goals ? under realistic assumptions ?– are such goals, requirements, assumptions

complete, adequate, consistent, non-ambiguous ?

u The earliest requirements errors are found, the best

u For requirements completeness: be pessimisticfrom beginning about software and environment– hazards, threats, conflicts

Conclusion (2)

u Rich models facilitate the RE process and increasethe quality of the resulting product ...

– software + environment (humans, devices, othersoftware, mother Nature, attacker, attackee)

– multiple dimensions: intentional, structural,responsibility, operational, behavioral

– analyzability for early error detection & fix

– seamless transition from high-level concerns tooperational requirements




Conclusion (3)

u Goal-based reasoning is central to RE for ...

– model building & elaboration of requirements

– exploration & evaluation of alternative options(refinements, assignments)

– conflict management

– anticipation of abnormal behaviors

– optimization of model synthesis

Thanks ...

u to the KAOS crew at UCL, CEDITI and CETIC asresearchers, consultants, or tool developers

E. Letier, R. Darimont,

C. Damas, A. Dardenne, R. De Landtsheer,E. Delor, D. Janssens, B. Lambeau,P. Massonet, C. Ponsard, A. Rifaut, H. Tran Van

u to Steve Fickas and his group at Univ. Oregon

u to the EU & Region of Wallonia for significantfunding of research




More information ...

u ... on the method & associated techniques

A. van Lamsweerde, Requirements Engineering -From System Goals to UML Models to SoftwareSpecifications. Wiley, 2007.

www.info.ucl.ac.be/~avl

u ... on the tools:http://objectiver.comhttp://faust.cetic.be

Documents

Modelling Software Systems and Engineering their Requirementsssel.vub.ac.be/francqui/lib/exe/fetche365.pdf?cache=... · 2007-05-03 · Modelling Software Systems and Engineering their