190 likes | 408 Views
Krav og usecases. Larman kap. 5 og 6 (del1). Krav. Mangelfuld kravspecifikation og håndtering af krav er en af de store risiko momenter i software udvikling. Men løsningen er ikke at anvende en vandfaldsmodel, for at forsøge at specificere og stabilisere alle krav i den første fase.
E N D
Krav og usecases Larman kap. 5 og 6 (del1) Poul Henriksen
Krav • Mangelfuld kravspecifikation og håndtering af krav er en af de store risiko momenter i software udvikling. • Men løsningen er ikke at anvende en vandfaldsmodel, for at forsøge at specificere og stabilisere alle krav i den første fase. • Krav ændres – signifikant • I store projekter ændres op til 40 - 50% af kravene • I middel store projekter ændres ca. 25 % • Derfor skal SW udvikles iterativt med løbende feedback og tilpasning til ændrede krav. Poul Henriksen
Problemer i SW projekter Poul Henriksen
Iterativ forfinelse af krav • I de tidlige iterationer bliver der lavet meget arbejde med at kortlægge krav • I de senere iterationer bliver der lavet mindre arbejde med krav. • Kravene bliver mere stabile. Poul Henriksen
Kategorisering af krav • FURPS+ modellen : • Functionality • Usability • Grænseflade, hjælp, dokumentation • Reliability • Fejlfrekvens, recoverbility… • Performance • Response time, resurce forbrug… • Supportability • Adaptability, maintainability, internationalization Poul Henriksen
Kategorisering af krav • + i FURPS+ (alt andet…) • Design constraints • Implementation requirements • Interface requirements • Physical requirements Poul Henriksen
Alternativ opdeling af krav • Funktionelle krav • Ikke funktionelle krav Poul Henriksen
Krav i UP • Artefakter til beskrivelse af krav i UP : • Vision dokumentet • Omfang af systemet • Business case • Vision med systemet • Use-case modellen • Supplementary specifications • Alle andre krav • Bl.a. ikke funktionelle krav Poul Henriksen
Use-cases og aktører • Et artefakt til at udtrykke funktionelle krav • En use case fortæller historien om, hvordan en aktør anvender systemet til at nå sit mål. • Eks. “ process sale” • Aktør : en person eller et system med opførsel, som er involveret ien usecase. • Der er forskellige aktører : • dem der bruger vores system • Ex. en “cashier” der anvender vores system • dem der bruges af vores system. • Ex. når systemet anvender andre systemer (eksterne services) til at udføre en bestemt opgaver.F.eks. Håndtering af betaling vha. kreditkort. Poul Henriksen
Use-cases • Et scenarie er en specifik sekvens af aktioner mellem aktøren og systemet • Et konkret eksempel på en use-case. • En use-case er samling af relaterede succes og mislykkede scenarier. • Fokus : • Beskriv handlinger som giver brugerne konkret nytte af systemet, ikke kun en liste af funktioner som systemet skal tilbyde. • Beskriv hvad, ikke hvordan (dvs. blackbox use-case) Poul Henriksen
Use-case er TEKST • Use-case er TEKST dokumenter, ikke diagrammer. • Use-case modellen er den skrevne tekst. • Det er de centrale elementer i en use-case • Der findes desuden use-case diagrammer i UP. Poul Henriksen
Use-case formater • Formater • Brief • Typisk kun et afsnit med hoved scenariet • Casual • Uformelt, flere afsnit der dækker forskellige scenarier • Fully dressed • Den mest udbyggede. Alle skridt er detaljeret beskrevet og der er tilhørende afsnit med preconditioner, m.m. Poul Henriksen
Eksempel use-case • S. 50 – 53 Poul Henriksen
Valide use-cases • Hvad er en brugbar (valid) use-case? • Fokus på EBP (Elementary business processes). • EBP : • A task performed by a person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. Poul Henriksen
Valide use-cases • Er dette valide use-cases ? • Forhandling af leverandør kontrakt. • Håndtering af retur varer. • Log in. • Ikke alle use-cases overholder EBP testen. • Kun de dominerende use-cases • Lav uses-cases på lavere niveau • Hvis de gentages i flere use-cases • Ofte defineres use-cases på et for lavt niveau • Hoved scenariet vil typisk bestå af 5 -10 skridt Poul Henriksen
Navngivning • Navngiv use-casen efter det mål den skal opfylde. • Navnet skal starte med et udsagnsord. • Undtagelse fra reglen : en use-case til et mål. • CRUD (create, read, update, delete) • Samles i en use-case : • Manage <X> Poul Henriksen
User goal-level use-cases • EBP kaldes user-goal level use-cases • Skal opfylde et mål som brugeren har med at anvende systemet. • Procedure • Find brugernes mål • Definer en use-case for hver. Poul Henriksen
Find aktører, mål og use-cases • Larman s. 63 Poul Henriksen