Software Systems Design – 2 Requirements capture and modelling Renate van Luijk Klaas Sikkel Software SystemsDesign - 21

Today’s topic Software SystemsDesign - 22 Requirements Elicitation Requirements Elicitation

Contents First hour Use Case Diagrams (basic) Description of requirements, use cases, actors, terms Use Case Diagrams (extended) Use Case Descriptions (extended) Second hour Interviewing stakeholders Software SystemsDesign - 23

Use case diagram (simple version) Software SystemsDesign - 24

(Case study from last Lecture) De Nederlandse Bond Voor Sport wil een systeem voor het bijhouden van overtredingen. Daarbij gelden de volgende regels. Als een speler tijdens een wedstrijd een overtreding begaat kan de scheidsrechter een waarschuwing geven of een gele of rode kaart tonen. Is een gele of rode kaart gegeven, dan voert de scheidsrechter na afloop in het systeem in wat de overtreding was en welke kaart er gegeven is. Waarschuwingen worden niet ingevoerd. De strafcommissie beoordeelt binnengekomen overtredingen en kent een straf toe. Zowel de vereniging als de speler worden per brief op de hoogte gesteld van de toegekende straf. Software SystemsDesign - 25

Use case diagram Top-level description of system functionality Easy enough to be understood by non-IT staff UCD contains – Actors – Use cases Described as imperative sentences Linked to a single actor Software SystemsDesign - 26

Use case description (short) Software SystemsDesign - 27 Use caseDescription Voer over- treding in Na afloop van de wedstrijd voert de scheidsrechter de overtreding (gele of rode kaart) in, voorzien van een toelichting Bepaal straf De strafcommissie bekijkt een overtreding en bepaalt een passende straf

Requirements list Software SystemsDesign - 28 Nr RequirementUse case(s) 1 Invoeren welke gele en rode kaarten zijn uitgedeeld Voer over- treding in 2 Bepalen welke straf aan een overtreding wordt toegekend Bepaal straf Als scheidsrechter wil ik … Als strafcommissie wil ik …

Requirements list The requirements list states requirements and their corresponding use cases – Please note how the requirements are written Starting with an infinitive verb Can be turned into a user story by adding “As I want to …” as a prefix – This is the format used by Bennett. If you want to write complete user stories: fine Software SystemsDesign - 29

Actor list Software SystemsDesign ActorDescription Scheids- rechter Leidt de wedstrijd, kent bij een overtredingen een waarschuwing, gele of rode kaart toe Strafcom- missie Bepaalt staf bij een gele/rode kaart, rekening houdend met rapport van de scheidsrechter en dossier van de speler

Glossary Software SystemsDesign TermDescription OvertredingOngeoorloofd handelen door een speler Waarschuwing Terechtwijzing bij een overtreding, heeft geen consequenties Rode kaart Signaleert een ernstige overtreding. De speler moet het veld verlaten en krijgt een straf opgelegd Gele kaartSignaleert een minder ernstige over- treding. Bij één gele kaart mag de speler doorspelen, maar hij krijgt wel een straf

Extensions to Use Case Diagrams Extension Inclusions Generalization See following slides for examples See Bennett et al., section 6.6 for full text Software SystemsDesign - 212

Extension Software SystemsDesign - 213

Inclusion Software SystemsDesign - 214

Software SystemsDesign - 215

Generalization Software SystemsDesign - 216

Software SystemsDesign - 217

Use case model Use case model consists of: – Use case diagram – Actor list – Use case descriptions (in short or extended form) Strongly related to Use Case Model are: – Requirements List – Glossary Software SystemsDesign - 218

Use case description (short) Software SystemsDesign Use caseDescription Voer over- treding in Na afloop van de wedstrijd voert de scheidsrechter de overtreding (gele of rode kaart) in, voorzien van een toelichting

Use case description (extended) Software SystemsDesign Actor ActionSystem Response 1Start applicatie2Toon invulvelden 3 Vul naam speler en naam vereniging in 4 Toon alle gegevens van speler 5Vul westrijdgegevens, kaartsoort en toelichting in 6Sla op en stuur bericht aan stafcommissie Alternatief: Stap 4: Toon lijst als er meer dan één speler matcht Stap 4A: Selecteer speler van lijst Use case description: Voer overtreding in

Further reading Bennett et al. – Chapter 6 – Chapter A2 Software SystemsDesign - 221

Interview vaardigheden “The scientist is not a person who gives the right answers, he's one who asks the right questions.” Claude Lévi-Strauss

Structuur interview KOP: Kennismaking en opening Middenstuk: beantwoorden van de “echte” vragen STAART: Afsluiting + afspraken follow up

Interview KOP Doel: – Wederzijdse kennismaking – “Rapport” verkrijgen – Werkcontract vaststellen: hebben we hetzelfde doel voor ogen? – Werkwijze verduidelijken Middelen – Nette introductie, evt “small talk” – Open, uitnodigende houding – “Pitch”: wat kom je doen – Bevestiging / akkoord

Interview STAART Doel: – Samenvatten – Werkcontract bevestigen – Afspraken vervolg Middelen – Parafraseren en bevestiging vragen – IJken op non-verbaal gedrag

Interview I Je werkt voor bedrijf “Spray” dat muurschilderingen realiseert, de klant heeft een muurtekening in gedachten, maar er moet nog wel een schets komen. Achterhaal de afbeelding. 1 duo neemt interview af – Let op goede opening en afronding! Helft “publiek” maakt tekening Helft “publiek” observeert interview om feedback te kunnen geven

Feedback interview I Wat ging goed en wat kon beter?

Uitkomst Interview I

Lastige types: geslotenheid of weerstand Oorzaken: Staat niet achter de opdracht Verbergt misschien iets… Voelt zich “gewoon” niet lekker Reacties: Geduldig zijn, (her)vinden van “rapport” Let op eigen lichaamstaal (niet gaan spiegelen!) Subtiel uitvragen en ombuigen naar “wanneer wel”? Heb “beste alternatief zonder overeenstemming” achter de hand

De kracht van vragen stellen Open vragen: Sporen aan tot nadenken Betrekken gesprekspartners Vragen mening en verhogen motivatie Gesloten vragen: Leiden tot actie Verminderen communicatiefouten Vormen controle / bevestiging

Actief luisteren

Interview II Je werkt voor bedrijf “Spray” dat muurschilderingen realiseert, de klant heeft een muurtekening in het hoofd, maar er moet nog wel een schets komen. Achterhaal de afbeelding. 1 duo neemt interview af – Extra aandacht voor middenstuk Helft “publiek” maakt tekening Helft “publiek” observeert interview om feedback te kunnen geven

Feedback interview II Wat ging goed en wat kon beter?

Uitkomst Interview II

Lastige types: grenzen stellen De geïnterviewde neemt controle over De geïnterviewde praat te veel Oorzaken: – Meer tijd dan jij, behoefte aan contact – Probeert iets anders te verbergen – Wil iets belangrijks kwijt Reacties: – Initiatief terugnemen Aantal gesloten vragen stellen Werkcontract herhalen – Voortgang bewaken relatie bewaken Niet te abrupt onderbreken Oorspronkelijke vraag terughalen Prioriteiten stellen

Samenvattend: vijf principes 1.Bereid goed voor 2.Zorg voor een goede “werkrelatie” met de geïnterviewde 3.Stel relevante vragen die uitnodigen om informatie te delen. 4.Luister en observeer actief 5.Verifieer je bevindingen Aanbevolen: Skill Sheets D2 t/m D6