1 / 52

Udledning af krav samt use case modellering

Udledning af krav samt use case modellering. Kravs workflow Use case modellering Avancerede. Kravs workflow. Tyngden i inception og elaboration. Hvad er kravspecifikation?. Kravspecifikation går ud på at beskrive, hvad et systemet skal gøre for brugeren

Download Presentation

Udledning af krav samt use case modellering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related