Kravspesifisering (4): Use Cases. Hvorfor passer use cases til krav? Tema / læremål. Gjettekonkurranse: Hva er det mest fundamentale.

Transkript

1 Tema / læremål Use cases Hva er en use case? Hvorfor passer use cases til kravspesifisering? Mens OO- eller prosessmodellering ikke gjør det...? Use case diagrammer (kort repetisjon) Tekstlige use cases Lære å skrive gode use cases Pensumstoff: P12 Kravspesifisering (4): Use Cases Guttorm Sindre, IDI Utdrag fra boka Use Cases: Requirements in Context, Kulak og Guiney, Addison-Wesley, Enda bedre bok Cockburn: Writing Effective Use Cases, A-W, 2001 Hvorfor passer use cases til krav? mens OO- eller prosessmodeller ikke passer... Gjettekonkurranse: Hva er det mest fundamentale poenget? Use cases mindre formelle (enklere diagrammer, naturlig språk), lettere å forstå for kunden Use cases fokuserer direkte på aktørene (dvs brukerne), dermed mer kravrelevante Use cases dekomponerer systemets grense mot omverdenen, mens prosessmodeller (a la DFD) eller OO klassediagrammer (i f.eks UML) dekomponerer systemets indre 1 Hva er en use case? Jacobsons def.: En interaksjonssekvens mellom en aktør og systemet Aktøren gjør noe Systemet responderer Aktøren gjør noe mer Systemet responderer, osv. Utretter noe av verdi aktør : rolle i organisasjonen, evt en enkelt bruker Use case diagrammer (UML) Beskriver ikke interaksjonen Ovalene er derfor ikke use cases Kun oversikt over hvilke use cases man har

2 2 Når bruke use cases? Passer godt til funksjonelle krav Best ved: diskrete tjenester, klart begrensede episoder Svært mange systemer i dag er slik Ikke så bra (men ofte mulig) til: Overordnede krav Batch-systemer, kontinuerlig funksjonalitet Passer dårligere / ikke til Ikke-funksjonelle krav Problemanalyse Design Eksempel: interaksjonssekvens for Risk Erobre territorium Basis-sti: 1. Spilleren forteller hvor han angriper fra og mot. Som default antas at man angriper med maksimalt tillatte antall bataljoner per runde. 2. Systemet presenterer terningene 3. Spilleren fortsetter angrepet ved å trille terningene. 4. Systemet forsvarer seg med 1 eller 2 terninger utifra hva som er optimalt og fjerner bataljoner fra brettet utifra resultatet. (Repeter) Steg 3 og 4 gjentas inntil det ikke er forsvarende bataljoner igjen i det angrepne området. 5. Spilleren flytter bataljoner inn i det erobrede territoriet, minst det antall han angrep med i siste runde. Alternative stier: I steg 1: Spilleren velger å bruke mindre enn max antall bataljoner... I steg 2: Angrepet er umulig, fordi... I steg 3: Spilleren velger å avbryte angrepet... I steg 4: Angriper går tom for bataljoner... Hvorfor bruke use cases? Det tradisjonelle alternativet er kravlister på formen Systemet skal..., jfr P11 Store systemer har mange krav, uoversiktlig Use cases gir en gruppering av krav Hver bolk en nyttig arbeidsoppgave Ett use case = mange skal -krav hvis interaksjonen kan være kompleks (jfr. eks. neste side) Systemet skal... : fokus på systemet Use cases: lettere å holde fokus på brukerens behov, hva som er nyttig å foreta seg med systemet Use case diagrammer Rask repetisjon av symbolikken Hvilke tabber er gjort i diagrammet under? Salgskonsulent Legg inn salgsordre Finn kunde Editer kunde extend Lag ny ordre Lag ny kunde Beregn profitt Legg til ordrelinje extend Kreditt overskredet

3 3 Teksten avslører feilen! Finn kunde: Brukeren velger en kunde ved å skrive inn referansenummer. Systemet viser komplett info om kunden (navn, adresse, tlf.nr, kjøpshistorie) Legg inn salgsordre: Brukeren velger en kunde fra en liste over tilgjengelige kunder. Inkluder Finn kunde. Systemet viser salgsordreskjermbildet, og brukeren registrerer ordren linje for linje. Systemet viser hele tiden det akkumulerte totalbeløpet for ordren. Når brukeren bekrefter å være ferdig, registreres ordren. Dvs, Legg inn salgsordre: Brukeren velger en kunde fra en liste over tilgjengelige kunder. Brukeren velger en kunde ved å skrive inn referansenummer. Systemet viser komplett info om kunden (navn, adresse, tlf.nr, kjøpshistorie). Systemet viser salgsordreskjermbildet, og brukeren registrerer ordren linje for linje. Systemet viser hele tiden det akkumulerte totalbeløpet for ordren. Når brukeren bekrefter å være ferdig, registreres ordren. Regelkatalogen (4.2.8, tab 4.1) Feil i diagrammet Feil bruk av (tidl. uses ) Sekvenser som ikke er felles for flere UC Sekvenser som er systeminterne Både og brukt direkte (eks Finn kunde, se neste side) Bruk av extend Feil retning på pil Inkonsekvent navngiving Anbefaling A: alltid verb substantiv Anbefaling B: verb substantiv for vanlige use cases, men for extend use cases: betingelsen for utførelse Tekstlige use cases Arbeidsmåte (P12, 4.2) Steg 1-5 innledende undersøkelser 6. Finn aktørene 7. Lag fasade use cases Sammen med identifiseringen av use cases vil man også identifisere relevante forretningsregler 8. Innled regelkatalogen Steg 9-11: analyse av risk, osv. Forretningsregler kan Finne aktørene Start med de som skal bruke systemet direkte Rollene kan være uklare på dette tidspunkt For hver aktør, se så etter use cases Begrense måten use cases kan utføres på Ønsker ikke å skrive reglene i selve use case Samme regel kan være relevant for flere use cases Stibeskrivelsen blir tung og vanskelig å forstå hvis forretningsregler skal forklares der Dvs., beskrive i separat del av dokumentet Men med kryssreferanser / hyperlenker fra / til relevante use cases

4 4 Prinsipper for navngiving ( ) Use cases Verb - substantiv Unngå svake begreper (vagt meningsinnhold) jfr tab 4.4, 4.5 Bruk kandidat-liste (tab 4.2) Aktører En person flere roller Aktører kan også være andre systemer Bruk generiske rollenavn (jfr tab 4.3) Mer fleksibelt mhp evt reorganisering Men ikke for generiske (jfr tab 4.3) Roller i prosjektet (tab 4.6) Kravkonsulent: Dokumenterer use cases, evt diagrammer, og forretningsregler Interessent (f.eks bruker) Deltar i intervjuer, gjennomganger av relevante u.c. Kunderepresentant Gjennomganger på høyt plan, status Teknisk arkitekt Deltar i review Prosjektleder Arbeidsplan, problembeskrivelse m.m. Fasade use cases Viser grunnleggende interaksjoner Gir oversikt over hvilke oppgaver som skal støttes Kun en skisse (jfr eks. s. 81, 82) 2-3 setninger, ikke stegnummererte stier Ikke bruk eller extend Relativt få og abstrakte use cases som kan detaljeres videre etter hvert Unngå implementasjonsdetaljer! System context use case (jfr. s. 73) Hele systemet som en use case Unødvendig hvis man har brukt andre modeller i tillegg Denne kan neppe detaljeres videre i en handlingssti (med mindre systemet er veldig enkelt) Gjennomgang (review) ~ gjennomgang av kravspek (P11) Og review av modeller som gjort i øvingsopplegget Team leser use cases, ser etter feil / mangler Ca 5 use cases per time Kravkonsulenter: som har skrevet use cases Designarkitekt: kan anslå arbeidsbyrde, risk mv Domeneekspert: kan avsløre mangler Bruker-gjennomgang Gå igjennom use cases med aktuelle brukere Tidlige og hyppige reviews vil spare inn på tidsbruken senere

5 5 Forklaring av bokas template (jfr s 81) Navn (Name) Iterasjon (Iteration) Hvor langt man har kommet i detaljeringen / finpussingen Sammendrag (Summary) 2-3 setninger som beskriver interaksjonen Basis handlingssti (Basic course of events) Steg for steg, bruker gjør noe, systemet svarer, osv. Den normale, mest vanlige handlingsstien Antar at use casen lykkes Ser bort ifra alle omveier, komplikasjoner, uforutsette unntak o.l. Template, forts. Trigger Betingelser i eller utenfor systemet som utløser u.c. Antagelser (Assumptions) Betingelser som må være sanne for at u.c. kan utføres på normalt vis Men som systemet ikke har kontroll over Prebetingelser (Preconditions) Betingelser som må være sanne for at u.c. kan utføres Og som systemet har kontroll over Postbetingelser (Postconditions) Blir sanne når u.c. fullføres Bør dekke både basis- og alternative stier, men ikke nødvendigvis unntaksstier Templates for use cases Fordel å ha et fast template Dvs. definerte felter som skal med Gjør materialet mer oversiktlig Mindre sannsynlig at noe viktig glemmes Behøver ikke være det i boka Dette er ett av mange mulige forslag Mange felt i tillegg til basis handlingssti Oppnår at selve stibeskrivelsen blir enklere Alternative stier og unntak for seg selv heller enn som if-setninger Antagelser, pre- og postbetingelser, forretningsregler m.m i egne felt, trenger dermed ikke forklares i selve stien Template, forts. Alternative stier (... Paths) Mindre vanlige stier enn basis-stien, men som fortsatt er å betrakte som normale Dvs., u.c. fullføres fortsatt med suksess Unntaksstier (Exception paths) Stier som velges når feil oppstår Her kan u.c. mislykkes Utvidelsespunkter (Extension points) Steg nummer hvor extend use cases tar av fra basisstien

6 6 Template, forts. Relateterte forretningsregler Forretningsregler som omhandler u.c. Og f.eks kan begrense hva som er lovlig utførelse av denne Forfatter Den som har skrevet u.c. Dato Intro til øving 4 Hva skal gjøres? Grupper à 4 stud., ta utgangspunkt i kjent case Lage deler av kravspek Når skrevet Hvordan? Evt med endringslogg som viser ulike stadier Intro, kontekstbeskrivelse 8+ use cases, 20+ ikke-funksjonelle krav Velge beste prosess- og info-modell Evt forbedre modellene litt hvis de ikke stemmer Fordel skriving av presise krav og use cases Gjør internt review + forbedring Relevant pensum P11 (overordnet struktur, trad. kravlister) P12 (use cases) Format: redusert variant av IEEE std Introduksjon Formål med dokumentet Produktets omfang og formål Overordnet beskrivelse (med modeller) Produktperspektiv: kontekst, aktuell maskinvare Produktfunksjoner: kort oversikt over funksjonalitet Brukerkarakteristikker: hva slags brukere Spesifikke krav Funksjonelle krav (use cases) Ikke-funksjonelle krav (kravlister)