1 / 18

Krav og usecases

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.

noreen
Download Presentation

Krav og usecases

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. Krav og usecases Larman kap. 5 og 6 (del1) Poul Henriksen

  2. 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

  3. Problemer i SW projekter Poul Henriksen

  4. 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

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

  6. Kategorisering af krav • + i FURPS+ (alt andet…) • Design constraints • Implementation requirements • Interface requirements • Physical requirements Poul Henriksen

  7. Alternativ opdeling af krav • Funktionelle krav • Ikke funktionelle krav Poul Henriksen

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

  9. 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

  10. 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

  11. 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

  12. 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

  13. Eksempel use-case • S. 50 – 53 Poul Henriksen

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

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

  16. 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

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

  18. Find aktører, mål og use-cases • Larman s. 63 Poul Henriksen

More Related