Udledning af krav samt use case modellering

1. Udledning af krav samt use case modellering Kravs workflow Use case modellering Avancerede

2. Kravs workflow Tyngden i inception og elaboration Lektion 5

3. 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 Lektion 5

4. Kravspecifikation - metamodel Lektion 5

5. UP kravs workflow Lektion 5

6. Udvidelse af UP’s kravs workflow Lektion 5

7. 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 Lektion 5

8. 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 Lektion 5

9. Organisering af krav Lektion 5

10. Prioritering af krav (MoSCoW) Lektion 5

11. 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! Lektion 5

12. Use case modellering Aktører Use case Lektion 5

13. Find aktører og use cases Lektion 5

14. 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 Lektion 5

15. 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 Lektion 5

16. 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) Lektion 5

17. 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 Lektion 5

18. Gode og dårlige use cases • Kriterier: • Afsluttede; målet er nået; kaffepause • Små beslægtede opgaver bundtes i én beskrivelse (CRUD) Kontrol: Er alle opgaver med? • Er alle aktørernes opgaver dækket? • Er kritiske opgaver med? • Kan alt data registreres, ændres, slettes (CRUD)? Gode eller dårlige? • Administration af bøger • Registrer bogens titel • Udlån af bog • Ret reservation • Slet reservation Lektion 5

19. Use case diagrammet Lektion 5

20. Ordforklaringer Lektion 5

21. Ø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 Lektion 5

22. UP aktivitet: Detaljer en use case Lektion 5

23. Use case specifikationen Lektion 5

24. Forgreninger ved brug af ”if” Lektion 5

25. Repetitioner ved brug af ”for” Lektion 5

26. Repetitioner ved brug af ”while” Lektion 5

27. Alternative flows Lektion 5

28. Alternative flows relateret til step i normalforløb Lektion 5

29. Alternative flows, der kan starte når som helst Lektion 5

30. Ø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 Lektion 5

31. Sporbarhedsmatrice Lektion 5

32. 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) Lektion 5

33. Avanceret use case modellering Generalisering Include Extend Lektion 5

34. Aktør generalisering Lektion 5

35. 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) Lektion 5

36. Eksempel: Use case generalisering Lektion 5

37. Forældre use casen: FindProduct Lektion 5

38. Børneuse casen: FindBook Lektion 5

39. ”Include” relationen • ”Include” relationen bruges til at modellere repeterende funktionalitet på tværs af forskelligeuse 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. Lektion 5

40. ”Include” relationen visualiseret Lektion 5

41. Eksempler på specifikation af ”base” use cases med ”include” Lektion 5

42. Eksempel på specifikation af ”inclusion” use casen Lektion 5

43. ”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. ”extensionuse 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 Lektion 5

44. ”Extend” relationen visualiseret Lektion 5

45. Eksempel på specifikation af ”base” use case med ”extension points” Lektion 5

46. Eksempel på specifikation af en ”extension” use case Lektion 5

47. IssueFine (multiple segments) Lektion 5

48. Betinget udvidelse Lektion 5

49. Eksempel: Specifikation af betinget ”extension” use case Lektion 5

50. Undgå funktionel dekomposition Lektion 5