User Requirements

• Baso natuurwetenschappen
• Beroepsopleiding

Systems Modelling Language

User Requirements

Na deze module:

• Kan jij correcte use cases opzetten conform 'Effective Use Cases' van Alistair Cockburn
• Kan jij de use cases alloceren aan een systeemarchitectuur
• Kan jij veranderend gedrag op basis van aangeboden inputs modelleren

Casus

Stel je voor - jij bent de bedienaar van de brug en moet

de brug openen als er scheepvaartverkeer aankomt.

Wat doe je terwijl je achter de bedienpost zit?

Beschrijf het scenario in losse stappen die jij doorloopt, 

en hoe het systeem op jouw input dient te reageren. 

Aannames: 

Je hoeft geen rekening te houden met 'dingen' die misgaan. 

Gewoon wat typisch gebeurt, met zo min mogelijk implementatiedetails

Beschrijf de stappen in de volgende vorm:

1. ik doe dit
2. het systeem doet dat
3. ... etc.

Casus

Stel je voor - jij bent een barista en je gaat een kopje koffie maken.

Beschrijf het scenario in losse stappen die jij doorloopt,
en hoe het systeem op jouw input dient te reageren.

Aannames:
Je hoeft geen rekening te houden met 'dingen' die misgaan.
Gewoon wat typisch gebeurt, met zo min mogelijk implementatiedetails
Beschrijf de stappen in de volgende vorm:

1. ik doe dit
2. het systeem doet dat
3. ...etc.

Use Cases - een RE techniek

Definitie:

Een use case beschrijft hoe het systeem zich gedraagt vanuit het perspectief van de gebruiker. Het geeft aan hoe het systeem reageert op een specifiek verzoek van die gebruiker, onder uiteenlopende omstandigheden.

Alternatieve naam voor use cases: User Requirements

Bijzonder geschikt voor interactieve (informatie)systemen

Use Cases zijn een methode om eisen voor het systeem af te leiden vanuit gebruiksscenario's

Notatie

(Primaire) Actor

 - De rol die het gedrag start

Secundaire Actor

 - De rol die het systeemgedrag ondersteunt

Use Case

- beschrijving van het gedrag

Probleem: ISO/IEC 19514:2017 en anderen vertellen niet hoe je use cases goed opzet

(Gaan niet veel verder dan "Open de brug", of "Zet koffie").

Een use case wil je bespreken met de echte gebruiker om zijn wensen vast te leggen.

Wat is een Actor, precies?

Een gebruiker of systeem dat een bepaalde rol speelt.

Actor - Goal Model

Doel: moet van meetbare waarde voor de actor zijn

Formuleren als: actief werkwoord - zelfstandig naamwoord

(bijv. Open de brug, zet Koffie)

De Use Case Workflow

1. Bepaal de scope (zie ook Operationele Omgeving)
2. Brainstorm de actoren
3. Brainstorm de doelen
4. Structureer de doelen
5. Schrijf het succes scenario
6. Bepaal 'exceptions' en variaties

Brainstorm de actoren

Wie gebruikt het systeem?

Wie installeert het systeem?

Wie start het systeem?

Wie zet het systeem uit?

Welke andere systemen gebruiken dit systeem?

Wie/Wat krijgt informatie van dit systeem?

Wie/Wat geeft informatie aan dit systeem?

Brainstorm doelen

• Wat wil de primaire actor nu van het systeem?
• Waarom heeft de primaire actor het systeem nodig?
• Heeft de primaire actor iets nodig van het systeem?

Vaak zijn deze doelen op een te laag niveau / te gedetailleerd. Vragen om het abstractieniveau te verhogen:

• Is dit wat de primaire actor echt wil?
• Waarom doet de primaire actor dat?

Gebruikersdoelen identificeren

koffietest: kan de gebruiker na afronding een koffiepauze nemen?

Casus

Identificeer de actoren voor dit systeem

Identificeer de use case doelen voor dit systeem

Maak een use case diagram

Casus

Identificeer de actoren voor dit systeem

Identificeer de use case doelen voor dit systeem

Maak een use case diagram

Succes-scenario (MSS)

Use Cases zijn een oefening in schrijven, niet tekenen!

Scenario: opeenvolging van actie-stappen die leiden naar het doel

• een interactie tussen actor en systeem
• een validatie om het belang van een belanghebbende te beschermen
• een interne verandering om aan belang van belanghebbende te voldoen

V: Wie zijn die belanghebbenden?

A: de primaire actor, en:

     ...

V: Wat zou een interne verandering kunnen zijn?

Transactie

Internal change is an unfortunate choice of words by Alistair Cockburn: A better wording would have been: state changes in the entities in the problem domain, especially entities that are part of a realised domain. (Things the system must remember about the problem that is solved).  Internal change is not the same as changes to the implementation of the entity!)

Tips voor Effectieve Use Cases

Zorg ervoor dat elke stap de gebruiker dichter bij de realisatie van zijn doel brengt

• Bij de vraag "Waarom deze stap?" moet het antwoord zijn: "Om het doel van de use case te bereiken"

Gebruik standaard en eenvoudige tekstopbouw: onderwerp – werkwoord – entiteit – voorzetselconstituent

• voorbeeld: Het systeem activeert het alarm in de controlekamer.

Wees expliciet wie wat doet

• "het systeem doet ..." of "de <<actor>> doet ..."

Beschrijf wat de bedoeling is, en niet wat letterlijk gebeurt (intent vs. movement)

• Geen interface details als "druk op een knop", maar "geef commando, instrueer, etc"

Beschrijf controles door het systeem als: Het systeem valideert, waarborgt of verzekerd

• Indien mogelijk, beschrijf dit als logische expressies (met probleemdomein entiteiten)

- Begin met 'low precision' use cases en voeg details later toe. Let op: 'low precision' is niet hetzelfde als vaag!)

- Een use case beschrijft een complete user taak, van begin tot eind.

- Een succes scenario bestaat typisch uit [3..9] stappen

Extra Use Case Informatie

Precondities

• Een voorwaarde die waar moet zijn, het systeem controleert maar waarborgt de conditie niet
• Mag gelijk zijn aan de postconditie van een andere use case

Trigger(s)

• Iets wat de use case start
• Kan ook de eerste stap zijn in een use case

Garanties

• Minimale garantie: het systeem waarborgt dat hieraan wordt voldaan, ook bij falen
  
• Succes garantie (ook wel postconditie): toestand van de wereld of systeem

Casus

Beschrijf het main succes scenario

Ook wel happy path/flow, basic path, primary scenario,

nominal scenario, main flow, standard flow of success path

genoemd

Casus

Beschrijf het main succes scenario
Ook wel happy path/flow, basic path, primary scenario,
nominal scenario, main flow, standard flow of success path
genoemd

Excepties & Variaties

Variaties: Er is een alternatief pad dat naar succes leidt

Exception: Het doel van de use case kan niet gehaald worden

Workflow E&V

Voor elke actiestap, bepaal of de stap kan falen

• Kan het falen: kan het systeem dit detecteren?
• Zo ja: moet het systeem dit kunnen afhandelen?

Voor elke af te handelen, gefaalde stap:

Bepaal stappen die na het falen moeten worden uitgevoerd

• Het doel kan alsnog worden gehaald: Variatie
• Het doel is niet meer te halen: Exceptie

'striped trousers'

Nummering strategie

1. De actor doet...

2. Het systeem valideert ...

3. Het systeem doet ...

4. Het systeem doet ...

5. Het systeem presenteert resultaat

2a1. Het systeem doet ...

2a2. Het systeem doet...

(use case eindigt)

3a1. Het systeem doet...

3a2. Het systeem doet...

(use case gaat verder bij 5)

Waar lijkt dit op?

Casus

Analyseer het main succes scenario

Bepaal de excepties en de variaties

Casus

Analyseer het main succes scenario

Bepaal de excepties en de variaties

Use cases - precisie

Use Cases:

1. Actors & Doelen
2. User story, Use Case Brief of MSS
3. Identificatie van excepties en variaties
4. Uitwerking van excepties en variaties

Voor Informatie, Energie of Materiaal:

1. Identificatie en beschrijving in een 'dictionary'
2. Types (zie block + properties, valuetypes of enumeraties)
3. Default waarden, constraints

Use Cases

Use Cases zijn beschrijving van extern zichtbaar gedrag

Use Cases zijn user requirements en kunnen startpunt voor ontwikkeling zijn

Actors behoren tot de context van het systeem

Use Cases verzamelen alle mogelijk scenario's om een doel te bereiken

Use Cases zijn niet "one size fits all": geschikt voor interactieve systemen

Use Cases passen niet goed op autonoom gedrag van systemen

Use Cases zijn een tekstuele tussenstap naar systeeminteracties, een uc is een "plaatje"

Use Cases zijn leesbaar voor niet-technici (...zouden moeten zijn)

Use Cases kunnen dienen als test scenario!

Use Cases kunnen ook beschreven worden m.b.v. alle gedragsdiagrammen (act, sd, stm)

Wat vond je van deze module?

😒🙁😐🙂😃

Use Case structurering

<<include>>:

Importeer een aantal stappen

GEEN functionele decompositie!!!

<<extend>>

Een use case kan worden uitgebreid met 

extra stappen, op een bepaalde plek

onder voorwaarden.

Advies: Maak hier geen gebruik van.