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

Transcription

1 Modelling Software Systems and Engineering their Requirements: Why should we care? Axel van Lamsweerde University of Louvain B-1348 Louvain-la-Neuve Inaugural Lecture A serious problem... 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 50% responses A. van Lamsweerde 1

2 A serious problem... (2) Major source of failure: requirements-related 50% responses: lack of user involvement 13% incomplete requirements 13% changing requirements 9% unrealistic expectations 10% unclear goals 5% ( 1995) A serious problem... (3) EU survey: 3800 organizations, 17 countries Main perceived software problems are in... requirements specification > 50% responses requirements management 50% responses (European Software Institute, 1996) A. van Lamsweerde 2

3 A serious problem... (4)... perceived to persist in spite of progress in software technology Failure % 100 other causes 50 requirements-related (J. Maresco, IBM developerswork, 2007) Outline Requirements engineering (RE) What it is Why it is difficult Why it is important Models for RE Why models, what models? Goal-oriented RE Goal-based model building Model analysis A. van Lamsweerde 3

4 What RE is, roughly... Analyze problems with an existing system (system-as-is), Identify objectives & opportunities for new system (system-to-be), Define functionalities of, constraints on, responsibilities in system-to-be, Specify all of these in a requirements document System = software + environment (humans, devices, other software) Requirements in the software lifecycle Getting the right system Requirements engineering Getting the software right Software design Software implementation Software evolution A. van Lamsweerde 4

5 What is RE about? WHY? WHAT? domain knowledge goals requirements, assumptions operationalization What is RE about? WHY? WHAT? WHO? domain knowledge goals requirements, assumptions operationalization responsibility assignment A. van Lamsweerde 5

6 What is RE about? (2) 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 TrainMoving measuredspeed 0 DoorsClosed errorcode = 013 E S TrainAtStation Environment Sofware doorsstate = closed' What is RE about? (3) System requirements: prescriptive assertions formulated in terms of environment phenomena TrainMoving DoorsClosed Software requirements: prescriptive assertions formulated in terms of shared phenomena measuredspeed 0 doorsstate = 'closed' Domain properties: descriptive assertions about environment, needed for mapping SysReq to SoftReq TrainMoving measuredspeed 0 A. van Lamsweerde 6

7 Requirements vs. assumptions and domain properties 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 domain analysis & elicitation The RE process alternative proposals start A. van Lamsweerde 7

8 The RE process alternative proposals domain analysis & elicitation evaluation & negotiation start agreed requirements The RE process alternative proposals domain analysis & elicitation evaluation & negotiation start agreed requirements documented requirements specification & documentation A. van Lamsweerde 8

9 The RE process alternative proposals domain analysis & elicitation evaluation & negotiation consolidated requirements validation & verification start agreed requirements specification & documentation documented requirements RE: an iterative process alternative proposals domain analysis & elicitation evaluation & negotiation consolidated requirements validation & verification start agreed requirements specification & documentation documented requirements A. van Lamsweerde 9

10 Why RE is hard 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 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 A. van Lamsweerde 10

11 Why RE is hard (2) 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) 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 A. van Lamsweerde 11

12 Why RE is hard (3) 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 Legal impact contractual commitment client-provider Social impact from user satisfaction to degradation of working conditions to system rejection Technical impact on many software-related artefacts A. van Lamsweerde 12

13 Requirements impact on many software artefacts call for tenders, proposal evaluation project contract project estimations & planning (size, cost, schedules) software prototype, mockup requirements & assumptions software architecture acceptance test data quality assurance checklists implementation directives software documentation user manual software evolution directives impact Why RE is important (2) Impact on certification mastered RE process required by many quality standards & certification authorities Impact on economy, security, and safety cost and consequences of errors in... requirements on software assumptions about environment A. van Lamsweerde 13

14 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... the most numerous ± 40% of software errors 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 66% of software error costs (Boehm, Jones, Lutz, Hooks & Farry,...) A. van Lamsweerde 14

15 Errors in requirements/assumptions are... the most numerous ± 40% of software errors the most persistent often found very late, after software delivery 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 US Aegis/Vincennes (1988): shooting of IranAir airbus missing timing between 2 threat events in requirements on alarm software 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 wrong timing/localization assumption on flap extension point etc A. van Lamsweerde 15

16 Requirements errors are the most dangerous US Aegis/Vincennes (1988): shooting of IranAir airbus missing timing between 2 threat events in requirements on alarm software Patriot anti-missile system (1st Gulf war) hidden assumption on maximum usage time London Ambulance System (1993): fatal delays wrong assumptions on crew behavior, ambulance localization system, radio communication,... Boeing 757 crash, Cali (1995) autopilot s wrong timing/localization assumption on flap extension point... Example: a fatal error in A320 braking logic MotorReversed MovingOnRunway MovingOnRunway WheelsTurning MotorReversed WheelsTurning A. van Lamsweerde 16

17 Finding the error by obstacle analysis MotorReversed MovingOnRunway MovingOnRunway WheelsTurning NOT MovingOnRunway WheelsTurning obstruction MotorReversed WheelsTurning NOT MotorReversed WheelsTurning Detecting the error by obstacle analysis MotorReversed MovingOnRunway MovingOnRunway WheelsTurning NOT MovingOnRunway WheelsTurning obstruction MotorReversed WheelsTurning NOT MotorReversed WheelsTurning MovingOnRunway And Not WheelsTurning WheelsTurning And Not MovingOnRunway MotorReversed And Not WheelsTurning WheelsTurning And Not MotorReversed... WheelsNotOut WheelsBroken Aquaplaning Lufthansa crash in Warsaw... A. van Lamsweerde 17

18 A similar fatal error in the handbraking logic 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... Driver killed by his luxurious car on a hot summerday AirConditioningRaised A. van Lamsweerde 18

19 Outline Requirements engineering (RE) What it is Why it is difficult Why it is important Models for RE Why models, what models? Goal-oriented RE model building model analysis Model-based RE Model = abstract representation of complex system (as-is or to-be) highlights, specifies, inter-relates key system features facilitates analysis Provides focus & structure for RE activities target for what must be elicited, evaluated, specified, consolidated, modified A. van Lamsweerde 19

20 Why models for RE? Abstraction from multiple details: focus on key aspects Support for early detection and fix of errors 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? Abstraction from multiple details: focus on key aspects Support for early detection and fix of errors 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 A. van Lamsweerde 20

21 Requirements on models for RE Adequate: close reflection of system while abstracting from unnecessary details 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 Adequate: close reflection of system while abstracting from unnecessary details 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 mechanism for model refinement A. van Lamsweerde 21

22 Requirements on models for RE (2) Open & evolvable highlighting of alternative options 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) Open & evolvable highlighting of alternative options Traceable: easy retrieval of source, rationale, impact of modeling decisions rich traceability links Comprehensible by stakeholders for further elicitation, evaluation, validation, modification diagrammatic representation A. van Lamsweerde 22

23 KAOS: goal-oriented, model-driven RE interviews existing systems documents analysis modeling generation of RE deliverables.html.rtf.pdf.mif What models? Goals Agents, responsibilities why? how? Objects who? Operations on what? what? A. van Lamsweerde 23

24 What models? (2) Hazards Threats I Interaction scenarios Behaviors Multiple languages are integrated for specification of model components Diagrammatic, for comprehension AND/OR graphs simple subset of UML Formal, for analysis (optional) based on mathematical logic and automata Real-time linear temporal logic Labeled Transition Systems (LTS) A. van Lamsweerde 24

25 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 At (tr, st) At (tr, next(st)) T A. van Lamsweerde 25

26 Objects Responsibilities A. van Lamsweerde 26

27 Hazards, responses Operationalizations A. van Lamsweerde 27

28 What kind of model-based reasoning? Checking / deriving goal refinements & operationalizations Goal-oriented model animation 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? Checking / deriving goal refinements & operationalizations Goal-oriented model animation 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 A. van Lamsweerde 28

29 Animation Check demo Refinement checking A. van Lamsweerde 29

30 Threat analysis for more complete model ItemOrderedByBuyer 7d ItemReceivedByBuyer ItemOrdered 2d ItemPaid ItemPaid 2d ItemSent ItemSent 3d ItemReceived ShippingCo ItemPaid 1d BELIEF S (ItemPaid) BELIEF S (ItemPaid) 1d ItemSent Seller ItemPaid 8h PaymentReceived PaymentReceived 8h NotificationSent NotificationSent 8h NotificationReceived NotificationReceived BELIEF S (ItemPaid) Seller Threat analysis for more complete model ItemOrderedByBuyer 7d ItemReceivedByBuyer anti-model 2d ItemSent ItemPaid ItemOrdered 2d ItemPaid ItemPaid 2d ItemSent ItemPaid ItemSent 3d ItemReceived ShippingCo 1d BELIEF S (ItemPaid) ItemPaid 8h PaymentReceived ItemPaid 1d BELIEF S (ItemPaid) PaymentReceived 8h NotificationSent NotificationSent 8h NotificationReceived BELIEF S (ItemPaid) 1d ItemSent Seller 1d NotificationReceived NotificationReceived BELIEF S (ItemPaid) Seller 16h FakeNotificSent Attacker A. van Lamsweerde 30

31 Application: Security of Aircraft in the Future European Environment Threats against crew & passengers (External threats) Threats from baggage area Modeling terrorist threats (anti-goal model) RE for on-board detection & reaction system Synthesis of state machines from scenarios & goals A. van Lamsweerde 31

32 The next lectures... L2-L3: Model-based RE goals, objects, agents, operations a systematic model building method 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 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 hazards, threats, conflicts A. van Lamsweerde 32

33 Conclusion 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 hazards, threats, conflicts Conclusion (2) 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 operational requirements A. van Lamsweerde 33

34 Conclusion (3) 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... 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 to Steve Fickas and his group at Univ. Oregon to the EU & Region of Wallonia for significant funding of research A. van Lamsweerde 34

35 More information on the method & associated techniques A. van Lamsweerde, Requirements Engineering - From System Goals to UML Models to Software Specifications. Wiley, on the tools: A. van Lamsweerde 35