Modelling Software Systems and Engineering their Requirements: Why should we care?

Modelling Software Systems

and Engineering their Requirements:

Why should we care?

Axel van Lamsweerde

University of Louvain B-1348 Louvain-la-Neuve

Inaugural Lecture

Belgian 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:

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)

A serious problem ...

(3)

u EU survey: 3800 organizations, 17 countries

Main perceived software problems are in... – requirements specification

> 50% responses

– requirements management 50% responses

A serious problem ...

(4)

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

Getting the right system Getting the software right

What is RE about ?

goals

WHY ?

WHAT ?

operationalization requirements, assumptions

domain

knowledge

What is RE about ?

goals

WHY ?

WHAT ?

WHO ?

operationalization responsibility assignment requirements, assumptions

domain

knowledge

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 assertions

formulated in terms of environment phenomena

TrainMoving ⇒ DoorsClosed

u Software requirements: prescriptive assertions

formulated in terms of shared phenomena

measuredSpeed ≠0 ⇒ doorsState = 'closed' u Domain properties: descriptive assertions about

environment, needed for mapping SysReq to SoftReq

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

The RE process

start domain analysis & elicitation evaluation & negotiation

alternative proposals

agreed

requirements

The RE process

start domain analysis & elicitation evaluation & negotiation

alternative proposals

agreed

requirements

specification & documentation

The RE process

start domain analysis & elicitation evaluation & negotiation

alternative proposals

agreed

requirements

documented requirements

consolidated

requirements

specification & documentation validation & verification

RE: an iterative process

start domain analysis & elicitation evaluation & negotiation

alternative proposals

agreed

requirements

consolidated

requirements

specification & documentation 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, policies devices, physical laws

Multiple concerns

functional, quality, development concerns Multiple abstraction levels

strategic 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, policies devices, physical laws

u Multiple concerns

– functional, quality, development concerns

Why RE is hard

(2)

u Multiple stakeholders

– with different background

– with different interests and conflicting viewpoints project managers domain experts users, clients subcontractors decision makers analysts, developers ...

Why RE is hard

(3)

u Multiple intertwined activities during iterative

elicitation-evaluation-specification-consolidation – conflict management

functionality vs. quality vs. cost

diverging viewpoints among stakeholders – risk management

anticipation of hazards and threats evaluation of alternatives, prioritization quality assurance

Why RE is hard

(3)

u Multiple intertwined activities during iterative

elicitation-evaluation-specification-consolidation – conflict management

functionality vs. quality vs. cost

diverging viewpoints among stakeholders – risk management

anticipation 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

Requirements impact on many software artefacts

requirements & assumptions

project estimations & planning (size, cost, schedules)

software prototype, mockup

software architecture

call for tenders, proposal evaluation quality assurance checklists project contract software evolution directives software documentation user manual acceptance test data implementation directives 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 software assumptions 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 expensive

costs ... 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

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 software

u Patriot anti-missile system (1st Gulf war)

– hidden assumption on maximum usage time London Ambulance System: fatal intervention delays

wrong assumptions on crew behavior, ambulance localization system, radio communication, ... Boeing 757 crash, Cali

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 software

u 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 assumption on flap extension point

u ...

Example: a fatal error in A320 braking logic

MotorReversed ⇔MovingOnRunway MotorReversed ⇔ WheelsTurning MovingOnRunway

Finding the error by obstacle analysis

NOT MovingOnRunway ⇔WheelsTurning NOT MotorReversed ⇔WheelsTurning MotorReversed ⇔MovingOnRunway MotorReversed ⇔ WheelsTurning MovingOnRunway ⇔WheelsTurning obstruction

Detecting the error by obstacle analysis

NOT MovingOnRunway ⇔WheelsTurning NOT MotorReversed ⇔WheelsTurning MotorReversed And Not WheelsTurning ... MotorReversed ⇔MovingOnRunway MotorReversed ⇔ WheelsTurning MovingOnRunway ⇔WheelsTurning obstruction WheelsTurning And Not MotorReversed MovingOnRunway And Not WheelsTurning WheelsTurning And Not MovingOnRunway ...

of an “intelligent” car

BrakeReleased ⇔DriverWantsToStart BrakeReleased ⇔MotorRaised MotorRaised ⇔ AccelerPedalPressed AccelerPedalPressed ⇔ DriverWantsToStart

A similar fatal error in the handbraking logic

of an “intelligent” car

BrakeReleased ⇔DriverWantsToStart BrakeReleased ⇔MotorRaised MotorRaised ⇔ AccelerPedalPressed AccelerPedalPressed ⇔ DriverWantsToStart

MotorRaised And Not

AccelerPedalPressed

... ... ...

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 key

aspects

u Support for early detection and fix of errors

u Interface among RE activities: produce or consume

model items

Support for understanding and explanation to stakeholders

Basis for making decisions: multiple options made explicit

Basis for generating requirements document

Why models for RE ?

u Abstraction from multiple details: focus on key

aspects

u Support for early detection and fix of errors

u Interface among RE activities: produce or consume

model items

u Support for understanding and explanation to

stakeholders

u Basis for making decisions: multiple options made

Requirements on models for RE

u Adequate: close reflection of system while

abstracting from unnecessary details

u Complete & pertinent: capture of all relevant system

facets 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 while

abstracting from unnecessary details

u Complete & pertinent: capture of all relevant system

facets 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 of

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 further elicitation, 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 further

elicitation, evaluation, validation, modification

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

who? why?

how?

What models ?

Interaction scenarios Behaviors

Hazards Threats

I

Multiple languages are integrated for

specification 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

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: Station

Objects

Hazards,

responses

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 with countermeasures - 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 with

Animation

Check demo

ItemOrderedByBuyer⇒ ◊_≤7d ItemReceivedByBuyer ItemOrdered ⇒ ◊≤2dItemPaid ItemPaid⇒ ◊≤2d ItemSent ItemPaid ⇒ ◊≤1dBELIEFS(ItemPaid) ItemSent ⇒ ◊≤3dItemReceived BELIEF_S(ItemPaid) ⇒ ◊≤1dItemSent Seller ItemPaid ⇒ ◊≤8hPaymentReceived PaymentReceived⇒ ◊≤8hNotificationSent NotificationSent⇒ ◊≤8hNotificationReceived NotificationReceived⇒ BELIEF_S(ItemPaid) Seller ShippingCo

Threat analysis for more complete model

ItemOrderedByBuyer⇒ ◊_≤7dItemReceivedByBuyer ItemOrdered ⇒ ◊_≤2dItemPaid ItemPaid⇒ ◊≤2d ItemSent ItemPaid ⇒ ◊≤1dBELIEFS(ItemPaid) ItemSent ⇒ ◊≤3dItemReceived BELIEF_S(ItemPaid) ⇒ ◊≤1dItemSent Seller ItemPaid ⇒ ◊≤8hPaymentReceived NotificationReceived⇒ BELIEF_S(ItemPaid) Seller ShippingCo ◊≤2d ItemSent ∧¬ ItemPaid ◊≤1d BELIEFS(ItemPaid) ¬ItemPaid ◊≤1d NotificationReceived

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

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 difficult

and 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 from beginning about software and environment

Conclusion

u Engineering high-quality requirements is difficult

and 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 pessimistic

from beginning about software and environment – hazards, threats, conflicts

Conclusion

(2)

u Rich models facilitate the RE process and increase

the quality of the resulting product ...

– software + environment (humans, devices, other software, mother Nature, attacker, attackee) – multiple dimensions: intentional, structural,

responsibility, operational, behavioral

– analyzability for early error detection & fix – seamless transition from high-level concerns to

Conclusion

(3)

u Goal-based reasoning is central to REfor...

– 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 as

researchers, 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 significant

More information ...

u ... on the method & associated techniques

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

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

u ... on the tools:

http://objectiver.com http://faust.cetic.be