Kravspesifisering (5): Use Cases, forts. 1.1 identifiser/oppsummer hver u.c. Tema / læremål. 1. Del opp i detaljerte use cases

Transkript

1 Tema / læremål Hvordan skrive gode tekstlige use cases? Primært basert på P12 kap 5: The Filled Iteration 1. Del opp i detaljerte use cases 2. Lag fylte (filled) use cases 3. Samle og dokumentere ikke-funksjonelle krav 4. Legg til forretningsregler 5. Test use case ne 6. Utsett noe Metoderetningslinjer Hvordan finne informasjon Kravspesifisering (5): Use Cases, forts. Guttorm Sindre, IDI Hvordan skrive gode handlingsstier 1.1 identifiser/oppsummer hver u.c. Nye intervjuer med interessenter / brukere Macro pieces of functionality Hvordan noe gjøres fra kundens / brukerens synsvinkel Koherent funksjonalitet Forretningsperspektiv, ikke datateknisk perspektiv Avsluttet arbeidsoppgave, oppnådd noe nyttig Skriv sammendrag for hver identifisert u.c. Må vise formålet med u.c. Viktigste steg Resultater som oppnås Ikke strev med include, extend, generalisering Kandidatliste i stadig endring 1 1. Del opp i detaljerte use cases Utgangspunkt: use cases på fasade-nivå Noen av disse for generelle Må deles opp i flere use cases Sentrale (og vanskelige) spørsmål Hvor omfattende bør en use case være? Hva er naturlig oppdeling av funksjonalitet? Mer detaljerte steg 1. Identifiser og oppsummer hver use case 2. Mer detaljer i diagram (hvis dette brukes) 3. Gjennnomgå granulariteten 4. Repeter steg i, ii, iii som nødvendig

2 2 1.3 granularitet = omfang for individuelle u.c. vs applikasjonen For fingranulært: mister relasjon til forretningsmål For grovgranulært: lange / komplekse stier, vanskelig å forstå, vanskelig å designe Må avgjøres fra prosjekt til prosjekt, u.c. til u.c. Komplekse funksjoner, stor risk: mer fingranulært Enkle funksjoner, liten risk: mer grovgranulært Passe granularitet Overordnet syn, god oversikt over funksjonaliteten Videre nedbrytning bedrer ikke forståelsen Enkelt å endre detaljer i u.c. (f.eks stibeskrivelser) Liten nok til at en person kan jobbe med en u.c. Handlingssti ferdig implementasjon på et par uker 2.1 identifiser triggere Impuls / hendelse som utløser u.c. Spør: Når starter denne u.c? Hvilken impuls / hendelse forårsakes den av? Kan være flere triggere Tips Be interessenten om å forklare prosessflyten Bruk aktiv setningsform, enkel betingelse Relater til forretningen, ikke programsystemet Ha automatiseringsgrensen klart for deg Eks.: The build manager asks the developer to build a product release The system detects a work file in the inbound processing queue 2. Lag fylte use cases 1. Identifiser triggere 2. Identifiser prebetingelser 3. Foredle u.c navn 4. Foredle aktører i diagram 5. Spesifiser basis handlingssti 6. Indiker repetisjon 7. Dokumenter unntak 8. Språkvask 2.2 identifiser prebetingelser Tilstand syst. må være i for at u.c gjennomføres Dvs som vi antar må ha skjedd før u.c starter Spør: Hva må skje før du kan gjøre dette? Hva må du gjøre før du kan utføre denne arbeidsoppgaven? Hva er input til u.c. (informasjon, hendelse) Og hvordan blir denne u.c. oppmerksom på det F.eks: aktør taster inn data hvor kom disse fra? Ikke sett samme betingelse både som prebetingelse og unntak Alle prebetingelse må kunne tilfredsstilles Av annen u.c., aktør eller en systemaktør

3 2.3-4 foredle u.c-navn og aktører 3 U.c.-navn uttrykker primæraktørens mål Den som starter (og gjerne stort sett utfører) u.c. Spør: Hvem er primæraktøren? Dennes viktigste mål her? Vanskelig? Undersøk kompletteringskriterier Unngå svake ord, jfr seksjon 4.3 Aktører: kan være flere Spør: Hvem gjør hva? Hvilke roller er involvert? Hvordan er interaksjonen mellom dem? Dokumenter info i aktørprofiler 2.5 Basis handlingssti, forts. Avdekket prosess kan være kompleks, eks s 93 Men hvert steg skal være enkelt å lese Retningslinjer for gode handlingsstier (en del i tillegg til det som står i boka): 1. Stilregler 2. Strukturregler 3. Innholdsheuristikker 4. Unngå internt design 5. Unngå UI-design 2.5 spesifiser basis handlingssti Nummererte instrukser som vekselvis sier Hva aktøren skal gjøre Hva systemet skal gjøre inntil målet er oppnådd Rett linje gjennom prosessen Anta at alt forløper normalt og ender med suksess Spør: Hvordan oppnår aktøren målet? Nevn alle steg du kan tenke på... Fra manuell prosess, bruk av gammelt system Eller nytt tenkt system: Bruk fantasien! Gå så i detalj på hvert steg Hvis flere aktører: Hvem gjør hva? Gode handlingsstier: 1. Stilregler 1. Hver setning på ny nummerert linje. Alternativer / unntak i separate seksjoner, ref.nr må stemme 2. Unngå pronomen hvis mer enn en aktør 3. Unngå adjektiv og adverb 4. Unngå negasjoner 5. Gi forklaringer hvis nødvendig 6. Alle verb i presens 7. Logisk sammenheng gjennom beskrivelsen 8. Hver handling skal ha fornuftig respons

4 Gode handlingsstier: 2. Strukturregler 4 Bruk i hovedsak følgende setningsstrukturer 1. Subjekt verb objekt 2. Subjekt verb objekt preposisjonsledd 3. (Subjekt passiv) kun hvis vanskelig å få til de to ovenstående Understrek refererte navn på andre use cases Innholdsheuristikker, forts. 3. Konsistent struktur Er alternative stier adskilt fra hovedstien? Konsekvent språkbruk? Stemmer nummereringen av steg overens? 4. Vurdering av alternativer Separasjon: egen seksjon for alternative stier? Er alternativene troverdige? Nummerering: stemmer nummer oppgitt i alternative stier med nummer i hovedstien? Gode handlingsstier: 3. Innholdsheuristikker 1. Dekning Fullførelse: blir oppgaven ferdig? Rasjonalitet: får man svar på problemet? Omfang: har man med alt som trengs for å gi svar? Skop: kun relevant info for problemet, eller ekstra detaljer (f.eks design, eller irrelevante opplysninger) 2. Sammenheng Logisk rekkefølge: klar logisk sti? Logisk sammenheng, både lokalt og globalt? Ensartet abstraksjonsnivå? Gode handlingsstier: 4. Unngå indre design Anbefalt Ikke Brukeren gjør noe Systemet gjør noe Brukeren gjør noe Systemet gjør noe... Brukeren gjør noe Systemet gjør noe Systemet gjør noe mer, og noe mer,... (dette vil være et symptom på meldinger til interne objekter eller interne funksjoner i systemet, ikke av interesse for brukeren Brukeren kan evt gjøre to ting på rad...

5 5 Gode handlingsstier: 5. Unngå UI-design Unngå indre design, forts. Vær på vakt mot alle begreper som antyder en viss arkitektur, f.eks. Klient, tjener, databasen, protokollen... Interrupt, polling,... som antyder visse løsningsmåter Uttrykk hva brukeren, hva systemet da skal svare Systemet finner kundens data ved binærsøk... Ikke hvordan input skal gis, hvordan resultater skal presenteres Systemet omformer kundens web-input til en SQLquery som sendes til... Dvs. unngå: eller visse valg av prog.språk, plattform e.l. Alt som indikerer visse input-måter (f.eks. Bruker trykker TAB-tasten,...taster inn ønsket reisemål, velger...fra meny,... snakker i mikrofonen ) Metodekall, API-kall, exception,... eller spesifikke visnings- eller signaliseringmåter (f.eks....presenterer dataene på tabellform,...viser en rullegardinsmeny med mulige handlinger,...gir et beep for å indikere feil ) Essential use cases (Constantine) Fokuser på brukerens intensjon, ikke konkret handling 2.6 indiker repetisjon Eksempel: Minibank, Ta ut penger Ikke-essensiell: Essensiell: 1. Sys leser kort, ber om PIN 1. Br identifiserer seg 2. Br taster inn PIN 2. Sys sjekker id., tilbyr valg 3. Sys sjekker PIN, gir meny 4. Br velger Uttak 5. Sys ber om beløp 6. Br gir inn beløp 7. Sys viser beløp 8. Br bekrefter ønske om uttak 3. Br velger Uttak 4. Sys ber om beløp 5. Br velger beløp 6. Sys gir penger 7. Br tar penger if-setninger 9. Sys returnerer kort 10. Br tar kort unngås ved å putte alternative stier for seg 11. Sys gir penger 12. Br tar penger Repetisjon Kan ikke like lett skilles ut som egen sti, separat beskrivelse Må derfor skrives i selve hovedstien Trenger ikke være noe problem for forståelsen, så lenge nummerering brukes på en klar måte Spør: Hva er betingelsen for å avslutte repetisjonen? Vil antall repetisjoner være likt hver gang? Oversett dette til krav som UI-designere og datadesignere vil vite å forholde seg til

6 6 2.8 Språkvask Godt språk viktig for leseligheten Og dermed for felles forståelse av kravene Anbefalinger Aktiv form, ikke passiv Enkel setningsstruktur, bruk minst mulig undersetninger Unngå svake ord (jfr tidligere) Unngå teknisk sjargong Domeneterminologi: Forklar begreper i egen seksjon av dokumentet 5. Test the filled use cases Her: test = gjennomgang (review) Intern review Identifiser vage punkt som må avklares med interessentene Review med brukere scenario = en mulig sti gjennom et use case (s 103-4) Definer ulike scenarier (dvs ulike kombinasjoner av input-data) som gir ulike veier gjennom u.c. Er beskrivelsen spesifikk nok? Klart hva man skal gjøre i hvert tilfelle? Spesifiserte handlinger for unntak? NB: Brukere snakker ofte i form av scenarier heller enn use cases 2.7 dokumenter unntak basert på input utenfra Ikke programvareunntak Ikke for usannsynlige (men avh av type system) Spør: Hva gjør aktøren hvis...? Unngå pseudokode-stil Uttrykk spesifikt Hvilket steg i basis-sti man tar av fra Hvilket man fortsetter med etter unntaket Om unntaket fører til at u.c. Avsluttes Hvis unntaket blir digert, vurder separat u.c. Like stort som en vanlig u.c.? Eller har igjen unntak på egen hånd? 3. Ikke-funksjonelle krav Identifisering Kommer også opp i intervju med interessenter Identifiser parallelt med funksjonelle krav Krav til responstider o.l.? Misnøye med eksisterende system? Prioriter gjerne kravene Dokumentering Beskriv kravet, m evt unntak Kryssref til use cases det er relevant for Jfr template s 97, eksempel s 98

7 7 Metoderetningslinjer IPA-filter Når skal man bruke include, når prebetingelse og når antagelse (jfr tab 5.3) White space filter Gå igjennom forretningsprosesser En dag på jobben Ukeslutt, månedsslutt, kvartalsslutt, årsskifte... interaksjoner som ikke er beskrevet? Abstraksjonsfilter For abstrakte u.c.: leserne forstår ikke interaksjonen For detaljerte: gjentar samme info mange steder Test abstraksjonsnivå på brukere og designere Oppsummering, use cases Hvorfor disse passer til kravspek Men ikke til problemanalyse eller design Problemanalyse: pros- eller info-modellering (forelest av Sølvberg), OO-modellering (P10, P13) Design: pros- eller info-modellering Hvordan skrive use cases Stegvis forfining (fasadeiterasjon fylt iterasjon) Template for innhold som bør være med Hvordan skrive gode handlingsstier Å skrive gode use cases er vanskelig Trenger både talent og erfaring Neste gang: kravspek og hyllevare (P14) 6. Utsett dette Finne felles oppførsel, slå sammen u.c., include Behandle programvareunntak Design Use case skal ikke inneholde unødvendige antagelser om hvordan prosessering gjøres internt i programmet, hva slags maskinvareutstyr / plattform / arkitektur som brukes, e.l. Heller ikke antagelser om skjermbilder, inputmåter,... Hvorfor ikke design her? Mange mulige design, hvis u.c tilfeldigvis antyder ett, kan et annet (og kanskje bedre) bli oversett Krav, arkitekturdesign og UI-design er ulike kompetanseområder Mer om øving 4 Har ingen kunde å snakke med om use cases Tenk deg selv som sluttbruker Hva ville være naturlige arbeidsoppgaver på jobben Er beskrivelsen konkret nok til at du som bruker ville kjenne igjen dine praktiske gjøremål?...og ville du utifra denne beskrivelsen føle deg rimelig trygg på å få et system som støttet jobben din heller enn å gjøre den vanskeligere? Tenk deg selv som designer Ville du visst hva du skulle lage utifra beskrivelsen Og uansett Se kritisk etter steg som foregriper designet...og etter tungt, uklart eller dårlig språk