Lecture 9: Scenarios & Use Cases resolving later negotiation In - PowerPoint PPT Presentation

Risks Implied by Bad Requirements Speci � cations Structure of Topic Areas preparation of tests , Example : Requirements Engineering • without a description of allowed outcomes, tests are design and implementation , randomly searching for generic errors (like crashes) Softwaretechnik / Software-Engineering • without specification, � systematic testing hardly possible programmers may just “ask around” when in doubt, possibly yielding different interpretations acceptance by Vocabulary e.g. consistent, � difficult integration customer, complete, tacit, etc. Lecture 9: Scenarios & Use Cases resolving later negotiation In the course: Techniques objections or regress (with customer, require- claims, marketing ments design / design / quality quality negotiation negotiation speci- acceptance acceptance Use Cases informal e.g. “Whenever a crash...” implemen- implemen- assurance assurance fication tation tation • without specification, it department, or is unclear at delivery ...) Pattern Language e.g. “Always, if h crash i at t ...” time whether behaviour 2018-06-04 customer developer is an error (developer docu- docu- needs to fix) or correct mentation mentation semi-formal (customer needs to accept and pay) � re-use re-use nasty disputes , additional effort Decision Tables e.g. “ � t, t � � Time • ...” documentation , e.g., the user’s manual , formal Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Live Sequence Charts • without specification, the user’s manual author can only re-use , describe what the system does , not what it should do ( “every observation is a feature” ) • without specification, re-use needs to be based on – 6 – 2018-05-07 – Sreintro – – 1 – 2018-04-16 – Sccontent – Albert-Ludwigs-Universität Freiburg, Germany re-reading the code � risk of unexpected changes • later re-implementations . – 9 – 2018-06-04 – main – – 9 – 2018-06-04 – main – – 9 – 2018-06-04 – main – • the new software may need to adhere to requirements of the old software; if not properly specified, the new software needs to be a 1:1 re-implementation of the old � additional effort 6 /42 28 /45 2 /60 3 /60 Topic Area Requirements Engineering: Content Content • Introduction VL 6 • Scenarios: The Idea • Requirements Specification • Use Cases • Desired Properties • Use Case Diagrams • Kinds of Requirements • User Stories • Analysis Techniques . . • Sequence Diagrams Scenarios • Documents . • A Brief History • Dictionary, Specification • Live Sequence Charts • Specification Languages • LSC Body Syntax : • Natural Language • LSC Model Elements, Locations • Decision Tables VL 7 • Well-Formedness • Syntax, Semantics . . • Completeness, Consistency, ... . • Towards Semantics : Informatik III • Cuts, Firedsets • Scenarios VL 8 (Automata . • Automaton Construction • User Stories, Use Cases Theory) . . • Live Sequence Charts – 9 – 2018-06-04 – Sblockcontent – • Excursion : Symbolic Büchi Automata VL 9 • Syntax, Semantics – 9 – 2018-06-04 – Scontent – . – 9 – 2018-06-04 – main – . . • Definition: Software & SW Specification VL 10 . • Wrap-Up . . 4 /60 5 /60 6 /60

Notations for Scenarios • The idea of scenarios (sometimes without negative or anti-scenarios ) (re-)occurs in many process models or software development approaches. • In the following, we will discuss two-and-a-half notations: • Use Cases and Use Case Diagrams ( OOSE ) • User Stories (part of Extreme Programming ) • Sequence Diagrams (here: Live Sequence Charts (Damm and Harel, 2001)) – 9 – 2018-06-04 – Sscen – – 9 – 2018-06-04 – Sscen – 8 /60 9 /60 Use Case: Definition Use Case Example: ATM Authentication name Authentication goal the client wants access to the ATM http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke) pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered Use Case — A sequence of interactions between an actor (or actors) and a system trig- post-cond. in access denied, card returned or Use Cases gered by a specific actor, which produces a result for an actor. (Jacobson, 1992) exceptional case withheld, welcome screen displayed actors client (main actor), bank system open questions none normal case 1. client inserts card 2. ATM read card, sends data to bank system exc. case 2b card readable, but not ATM 3. bank system checks validity card 4. ATM shows PIN screen exc. case 2c no connection to bank system 5. client enters PIN 6. ATM reads PIN, exc. case 3a card not valid or disabled sends to bank system exc. case 5a client cancels 7. bank system checks PIN exc. case 5b client doesn’t react within 5 s 8. ATM accepts and shows main menu exc. case 6a no connection to bank system – 9 – 2018-06-04 – main – exception case 2a card not readable – 9 – 2018-06-04 – Suc – – 9 – 2018-06-04 – Suc – exc. case 7a first or second PIN wrong exc. case 7b third PIN wrong 2a.1 ATM displays “card not readable” 2a.2 ATM returns card (Ludewig and Lichter, 2013) 2a.3 ATM shows welcome screen 10 /60 11 /60 12 /60