Transcript ppt

Udledning af krav samt use case
modellering
Kravs workflow
Use case modellering
Avancerede
Kravs workflow
Tyngden i
inception og
elaboration
13-04-2015
Lektion 5
2
Hvad er kravspecifikation?


Kravspecifikation går ud på at beskrive, hvad et
systemet skal gøre for brugeren
Kravspecifikation har flere formål, hvilket stiller
forskellig krav til beskrivelsesform og
detaljeringsniveau:
◦ Beslutningsgrundlag for ledelsen
◦ Kontraktgrundlag mellem virksomhed og systemudvikler
◦ Designgrundlag for systemudvikler
13-04-2015
Lektion 5
3
Kravspecifikation - metamodel
13-04-2015
Lektion 5
4
UP kravs workflow
13-04-2015
Lektion 5
5
Udvidelse af UP’s kravs workflow
13-04-2015
Lektion 5
6
Formulering af krav (1)


UML indeholder ingen anbefalinger til hvordan kravene
skal beskrives
[Arlow og flere andre] anbefaler ”feature stile”:
◦ <id><Systemet>skal<funktion>

Eksempler:
◦ K1-3: Systemet skal kunne registrere og udskrive oplysninger om
kunder, varer og ordre
◦ K4: Systemet skal kunne overvåge, at varer leveres som aftalt
◦ K5: Systemet skal kunne håndtere betaling
◦ K6: Systemet kunne understøtte såvel bestilling fra web’en som
intern i forretningen
◦ K7: Der skal kunne søges efter forskellige kriterier
13-04-2015
Lektion 5
7
Formulering af krav (2)

Eksempler fortsat
◦ K15: Svar tiden ved afgivelse af en ordre skal være under 2
sek.
◦ K16: Vareoplysninger og prislister skal altid være
tilgængelig, ligesom en ordre altid skal kunne registreres,
selvom serveren går ned
◦ K17: Der skal være sikkerhed for, at uvedkommende ikke
får adgang til data
◦ K18: Systemet skal afvikles i klient-server arkitektur
13-04-2015
Lektion 5
8
Organisering af krav
13-04-2015
Lektion 5
9
Prioritering af krav (MoSCoW)
13-04-2015
Lektion 5
10
Hvordan finder vi krav?

Brugerens opfattelse af den virkelighed det kommende
system skal understøtte, kan udledes ved:
◦ Interviews
 Forestil dig ikke en løsning
 Stil kontekst frie spørgsmål
 Lyt
 Tro ikke, du kender svaret
 Ha’ tålmodighed
◦ Spørgeskema
◦ Workshop

Hent ideer fra prototyper og eksisterende systemer!
13-04-2015
Lektion 5
11
Use case modellering
Aktører
Use case
13-04-2015
Lektion 5
12
Find aktører og use cases
13-04-2015
Lektion 5
13
Hvad er en aktør?

En aktør er en rolle, som en ekstern
entitet (person, andet system osv..)
indtager ved direkte interaktion med
systemet:
◦ en bruger rolle f.eks. ekspedient, sælger,
lagermedarbejder
◦ andre it-systemer
◦ et apparat f.eks. en temperaturføler

Primære aktører får deres mål opfyldt gennem
use casen
13-04-2015
Lektion 5
14
Find aktører




Tag udgangspunkt i hvem/hvad bruger systemet og
hvilken rolle spiller de? - Generaliser
Brug en tids aktør til tidsafhængige funktioner
Aktørerne navngives, og de beskrives ud fra et
forretningsperspektiv
Eksempel:
◦ Navn: Ekspedient
◦ Opgave: Står for at modtage og registrere ordrer fra
kunder
13-04-2015
Lektion 5
15
Hvad er en use case?
En use case er en specifikation af en
handlingssekvens mellem en ekstern aktør
og systemet
 Omfatter et normalt forløb, alternative
forløb samt fejlscenarier
 Use cases fortæller en historie om,
hvordan en aktør bruger et system med
henblik på at opfylde et mål, og illustrerer
de funktionelle krav gennem den historie,
der fortælles
 Startes altid af en aktør
 Er altid skrevet ud fra aktørens syn (view)

13-04-2015
Lektion 5
16
Find use cases
Se på aktører og kravslisten
Fokus i afgrænsningen af use cases skal være, at
use casen skal give aktøren en observerbar
nytteværdi (kaffe pause testen: fortjener aktøren
at holde kaffepause efter use casen er afsluttet?)
 En hyppig fejl er at use cases fastlægges på et
for lavt niveau, fx er Udskriv bekræftelse som
regel en del af noget andet
 Triviel funktionalitet kan samles i en CRUD use
case (Create, Read, Updata, Delete) – idet der
ellers vil være mange uinteressante use cases
med et enkelt trin


13-04-2015
Lektion 5
17
Gode og dårlige use cases
 Kriterier:
 Afsluttede; målet er nået; kaffepause
 Små beslægtede opgaver bundtes i én beskrivelse (CRUD)
Gode eller dårlige?
◦ Administration af bøger
◦ Registrer bogens titel
◦ Udlån af bog
◦ Ret reservation
◦ Slet reservation
Kontrol: Er alle opgaver med?
 Er alle aktørernes
opgaver dækket?
 Er kritiske opgaver
med?
 Kan alt data
registreres, ændres,
slettes (CRUD)?
13-04-2015
Lektion 5
18
Use case diagrammet
13-04-2015
Lektion 5
19
Ordforklaringer
13-04-2015
Lektion 5
20
Øvelse: Find use cases

I et ordrestyringssystem er der følgende
aktører:
◦ Ekspedient der har kontakten til kunderne og
tager imod ordre
◦ Lagermedarbejder der sørger for pakning og
afsendelse af varer, samt bestilling og
modtagelse af nye varer
◦ Bogholder der sørger for modtagelse af
betalinger og håndtering af restancer

Kom med forslag til use cases
13-04-2015
Lektion 5
21
UP aktivitet: Detaljer en use case
13-04-2015
Lektion 5
22
Use case specifikationen
13-04-2015
Lektion 5
23
Forgreninger ved brug af ”if”
13-04-2015
Lektion 5
24
Repetitioner ved brug af ”for”
13-04-2015
Lektion 5
25
Repetitioner ved brug af ”while”
13-04-2015
Lektion 5
26
Alternative flows
13-04-2015
Lektion 5
27
Alternative flows relateret til step i
normalforløb
13-04-2015
Lektion 5
28
Alternative flows, der kan starte
når som helst
13-04-2015
Lektion 5
29
Øvelse: Specifikation af use case
I skal nu specificere use casen: Afgiv ordre,
web i forbindelse med bestilling af
blomster
 Lad jer fx inspirere af interflora

13-04-2015
Lektion 5
30
Sporbarhedsmatrice
Krav
K1
K2
K3
……
UC1
x
x
UC2
Use case
UC3
UC4…
x
x
13-04-2015
Lektion 5
31
Use cases i det videre forløb


Udgangspunkt for af finde systemets klasser og
deres relationer samt modellering af systemets
interaktion
Udgangspunkt for formulering af testcases til
accepttest
◦ Accepttesten kan således planlægges allerede når use
casene er formuleret, selvom den først udføres efter
systemet er færdig kodet

Danner sammen med skærmbilleder udgangspunkt
for brugervejledning (er en slags vejledning i sig
selv)
13-04-2015
Lektion 5
32
Avanceret use case modellering
Generalisering
Include
Extend
13-04-2015
Lektion 5
33
Aktør generalisering
13-04-2015
Lektion 5
34
Use case generalisering

Generaliseringsformer:
◦ Arv. Forældrenes egenskaber nedarves
uændret til børnene.
◦ Tilføjelse. Nye funktioner ud over forældrenes
tilføjes
◦ Overskrivning. Forældrenes egenskaber
overskrives (o)
13-04-2015
Lektion 5
35
Eksempel: Use case generalisering
13-04-2015
Lektion 5
36
Forældre use casen: FindProduct
13-04-2015
Lektion 5
37
Børne use casen: FindBook
13-04-2015
Lektion 5
38
”Include” relationen






”Include” relationen bruges til at modellere
repeterende funktionalitet på tværs af forskellige
use cases
Formål: Reduktion af redundans, så man ikke skal
skrive de samme ting mange gange
Det, der er fælles, modelleres i en ”inclusion” use
case, som inkluderes i ”base” use cases.
Vises i use case diagrammet ved en ”include”
relation (stiplet pil fra ”base” use cases til
”inclusion” use casen med teksten ”include”)
”Include” samt navnet på ”inclusion” use casen
skrives i det relevante step i specifikationen på
´”base” use casene.
En use case er kun komplet, hvis alle use cases,
der inkluderes er medtaget.
13-04-2015
Lektion 5
39
”Include” relationen visualiseret
13-04-2015
Lektion 5
40
Eksempler på specifikation af
”base” use cases med ”include”
13-04-2015
Lektion 5
41
Eksempel på specifikation af
”inclusion” use casen
13-04-2015
Lektion 5
42
”Extend” relationen




”Extend” relationen bruges til at udvide
funktionaliteten i en eksisterende use case
med noget mere
Vises i use case diagrammet ved en ”extend”
relation og et ”extension” point, der relateres
til den use case, der skal inkluderes, dvs.
”extension use casen”
I specifikationen af den use case der udvides,
”base” use casen, inkluderes en betingelse og
en reference til ”extension” use casen ved et
extension punkt
”Base” use casen er komplet i sig selv
13-04-2015
Lektion 5
43
”Extend” relationen visualiseret
13-04-2015
Lektion 5
44
Eksempel på specifikation af ”base”
use case med ”extension points”
13-04-2015
Lektion 5
45
Eksempel på specifikation af en
”extension” use case
13-04-2015
Lektion 5
46
IssueFine (multiple segments)
13-04-2015
Lektion 5
47
Betinget udvidelse
13-04-2015
Lektion 5
48
Eksempel: Specifikation af betinget
”extension” use case
13-04-2015
Lektion 5
49
Undgå funktionel dekomposition
13-04-2015
Lektion 5
50
Øvelse: Avancerede strukturer

I ordre systemet er følgende use cases
identificeret:
◦ Søg vare
◦ Afgiv ordre
Hvordan kan de relateres?
 I ordre systemet kan endvidere betales på
flere forskellige måder
 Kan man bruger strukturer til håndtering
af det?

13-04-2015
Lektion 5
51
Opgave: Restaurant Godbid
Kom med forslag til use cases
 Specificer use casen: Afgiv bestilling

13-04-2015
Lektion 5
52