IT-Kravspecifikation Søren Lauesen, Februar 2010 IT-University of Copenhagen E-mail: slauesen@itu.dk http://www.itu.dk/people/slauesen

Kravspecifikationens rolle og kravenes niveauer

3. Hvad bruges en kravspecifikation til? Interessenter Underforståede behov & krav Behov “Elicitation” Analyse Kontrakt Kravspec Validering Design Sporbarhed: Forlæns . . . Baglæns . . . Kravstyring: Ændringer . . . Program Verificering Test Drift & vedl.h.

Projekttype Kunde Leverandør 4. Projekttyper Projekttype Kunde Leverandør In-house Afdeling IT afdeling Produktudvikling Marketing Udvikl. afd. Efter regning Virksomhed SW hus Standard/ramme Virksomhed IT virksomhed Udbud Virksomhed IT virksomhed Fastpris-projekt Virksomhed SW hus Underleverandør Leverandør IT virksomhed Ukendt In-house? Standard/ramme?

5. Kontekstdiagram - hvad skal leveres? Bruger grupper Datakrav: Hvad skal registreres? Platform: HW, OS, DB 30% 15% System Kvalitetskrav: Hvor hurtigt? Hvor brugervenligt? Vedligehold? Eksterne systemer: Eksisterende og nye Grænseflader Funktionskrav, brugergrænseflade: ? Funktioner: Skal kunne vise ... Man skal kunne vælge ... ? Skærmbilleder og hvad hver knap gør ? Arbejdsopgaver der skal støttes (een af de mange slags use cases) Funktionskrav, eksterne systemer: Skal være integreret med ... Tredjepart skal kunne integrere med ... Hjælp til læseren: Forretningsmæssige mål Baggrund ...

6. Kravskabelon SL-07 A. Baggrund og vision, vejledning . . . B. Overordnede behov B1. Forretningsmæssige mål B2. Proof of concept C. Arbejdsopgaver systemet skal støtte C1. Indskriv patient C2. Klinisk session . . . D. Data systemet skal anvende D1. Diagnoser D2. Diagnosetyper . . . D10. Data i eksisterende systemer E. Andre funktionelle krav E1. Komplekse beregninger og regler E2. Udskrifter og rapporter E3. Udbygning af systemet F. Integration med eksterne systemer G. Teknisk it-arkitektur G1. Brug af eksisterende HW og SW G2. Nyt hardware og software H. Sikkerhed H1. Adgangsret for brugere H2. Sikkerhedsadministration H3. Sikring mod tab af data H4. Sikring mod utilsigtet brugeradfærd H5. Sikring mod trusler I. Brugervenlighed og design I1. Indlæring og effektivitet i daglig brug I2. Tilgængelighed og Look-and-Feel J. Andre krav og leverancer J1. Andre standarder der skal følges J2. Uddannelse J3. Dokumentation J4. Datakonvertering J5. Installation K. Kundens leverancer L. Drift, support og vedligehold L1. Svartider L2. Tilgængelighed L3. Datalagring L4. Support L5. Vedligehold

Støt arbejdsopgave (task) 1 til . . . Funktionskrav Bedste bud: Støt arbejdsopgave (task) 1 til . . .

8. Eks: Traditionelle krav - løn og vagtplan på hospital Krav 47: Det skal være muligt at knytte en kode omkring vagttype (forvagt, bagvagt mv.) til den enkelte medarbejder. Krav 144: Leverandøren skal opdatere systemet så det følger nye overenskomster senest en måned efter frigivelsen. Krav 475: Systemet skal kunne beregne regnskabsmæssige konsekvenser af en given vagtplan - i timer og i kroner. Krav 479: Systemet skal advisere hvis en vagtplan indebærer samlet anvendelse af en vikar ud over tre måneder. Krav 669: Systemet skal give forståelige meddelelser i klar tekst ved fejl og vejlede i hvad brugeren bør gøre. Erfaringer: Kravene opfyldes, men arbejdsopgaverne støttes dårligt. De forretningsmæssige mål nås ikke. For dyrt - ingen frihed til leverandøren.

9. Skriv det som use cases? Use case 475: Beregn regnskabsmæssig konsekvens af vagtplan Trigger: Brugeren vil beregne konsekvensen Precondition: Brugeren er logget på 1. Systemet viser en liste af vagtplaner 2. Brugeren vælger en vagtplan 3. Brugeren vælger "Beregn konsekvens" 4. Systemet beregner konsekvensen 5. Systemet viser konsekvensen Verificerbart, men en god dialog? Hvad skal det bruges til? Computer-centric use case Ingen værditilvækst med sådan en use case

10. Eksempel på arbejdsopgave C2: Lav vagtplan Hyppighed: Hver 14. dag. I nogle afdelinger . . . Svært: Ferieperioder. Kunden: Hjælp - vi har købt det gale system Delopgaver og varianter: 1. Dan ny vagtplan. 2. Registrer ferie. To slags ferie . . . 3. Bemand vagter. Tjek rette kompetencer, ferie, overenskomster og undgå tillæg. 3a. Vikarer endnu ikke i systemet. 3b. Skaf medarb. fra anden afdeling. 4. Send planen til kommentering. 5. Ret planen og frigiv den. Eksempler / løsning: Automatisk ud fra sidste plan . . . Systemet kontrollerer feriereglerne. Systemet har en tidshorisont på flere år. Systemet foreslår bemanding af ubemandede vagter. Advarer om brudte regler og unødige tillæg. Støtter "puslespillet" med undo og flere forsøgsudgaver. Viser ledige fra andre afdelinger. En udskrift af planen er nok. Nuv. problem: Små lapper med ønsker mange måneder frem. Nuv. problem: Svært at gøre manuelt. Fejl og for mange tillæg. Udføres af menneske plus computer Eksempel på computers del - ikke krav

11. Mål-domæne-analyse for amtets løn og vagtplan 1.1 Månedlig timeregnskab til pers.afd. Bruger: Medarbejder i afdelingen Bruger: Planlægger i afdelingen 2.1 Registrer faktisk arbejdstid 3.3 Registrer nye medarbejdere 2.3 Sygdom hos medarbejder Bruger: Personaleafdeling 3.2 Ændringer af lønsedler 3.1 Kontroller vagtplaner 1.2 Lav vagtplan 2.2 Byt vagter Forretnings- mæssige mål Arbejds opgaver Personaleafdeling: Automatiser nogle opgaver Fjern fejlkilder Overhold 120-dags reglen Mindre trivielt arb. og stress Hospitalsafdeling: Mindre overarbejdsbet. mv. Hurtigere vagtplanlægning Bedre plankvalitet

12. Reparations-skibsværft. Bedste alternativ? R1. Vores forkalkulationer skal ramme indenfor 5% R2. Systemet skal registrere og bruge erfaringsdata ved arbejdsopgaverne: - Omkostningsregistrering - Tilbudsberegning R3. Systemet skal have en registre- ringsfunktion og en genfindings- funktion for erfaringsdata R4. Systemet skal have skærmbilleder som vist i bilag xx Krav på mål- sætnings-niveau Krav på domæne-niveau produkt-niveau design-niveau Det rigtige valg afhænger af leverandørens rolle, fx: - ERP leverandør - SW-hus uden forretningsviden - PriceWaterhouseCoopers

13. Eks: Forretningsmål og krav til et hotelsystem Datamodel D1. Gæster D2. Værelser D3. Ydelser Verificerbart? Forretningsmæssige mål: - Markedet med små hoteller. - Meget lettere at installere og bruge end eksisterende systemer. - Tilkoblet eksisterende Web-booking systemer. Tasks T1.1. Book værelse T1.2. Check ind T1.3. Check ud T1.4. Skift værelse T1.5. Registrer ydelser, morgenmadsliste Krav: R1: Opbevar data svarende til datamodel. R2: Støt tasks T1.1 til T1.5. . . . R7: Brugbart med 10 minutters instruktion.

14. Traditionelle krav (produkt-niveau) Systemet skal have: R1: En funktion til at finde ledige værelser R2: En funktion til at registrere gæstens navn og adresse R3: En funktion til at tildele et værelse til en gæst R4: . . . Verificerbare Use case 1.3: Tildel værelse til en gæst Trigger: Brugeren vil give gæsten et værelse Precondition: Værelset skal være ledigt og gæsten registreret 1. Bruger angiver dato, gæst og værelse 2. Systemet sætter værelsestilstand til checkin eller booked . . . 3. Systemet sætter værelsestilstandens ejer til at være gæsten . . . Hvornår bliver den udført? Computer-centric use case

Men elendig task-støtte 15. Skærmbilleder til funktionerne Find ledigt værelse Ledig fra 22-08-2008 Type (alle) Ledig til 23-08-2008 Opfylder kravene Men elendig task-støtte Søg F3 Værelse Pris 11 Dobbelt Bad 80 22 Enkelt Toilet 60 24 Dobbelt Toilet 60 Registrer gæst Navn John Smith Gæst ID: 083245 Adresse 12 Ringway Rd. Coburg . . . Gem F2 Fortryd Esc Tildel værelse Vær. nr. 24 Ankomst 22-08-2008 Gæst ID 083245 Afrejse 23-08-2008 Tildel F2 Fortryd Esc

Hierarkisk nedbrydning? 16. Forløb (forretningsproces, høj-niveau task) Forløb 1: Et ophold på hotellet Aktør: Gæsten Start: . . . Trin: 1. Vælg et hotel. Problem: Vi er ikke synlige nok. 2. Booking. Problem: Sprog og tidszoner. Gæsten vil have naboværelser. 3. Check ind. Problem: Gæsten vil have to nøgler. 4. Modtag services. 5. Check ud. Problem: Lang kø om morgenen. 6. Refundér udgifter. Problem: Private services. Løsning: ? Task 1.1: Book (Web-booking) Task 1.2: Check ind Task 1.5: Registrer ydelser Task 1.3: Check ud Hierarkisk nedbrydning? Kun i simple tilfælde

17. Kompleks opgave – ikke hierarkisk Forløb 2: Behandlingsforløb Start: Patienten henvises af egen læge eller kommer akut. Slut: Patienten er helbredt eller . . . Trin: Løsning: 1. Indskriv patienten 2. Stil diagnoser 3. Planlæg behandling 4. Udfør behandling 5. Vurder resultat 6. Udskriv patient T1: Indskriv inden ankomst T2: Indskriv akut T10: Klinisk session T3: Udskriv patient . . .

Datakrav Data-model Data dictionary Data-formler Virtuelle vinduer Eksisterende skærmbilleder Ingen er bedst

19. E/R datamodel R1: Systemet skal opbevare følgende data: En-til-mange (1:m) Hver gæst er koblet til nul eller flere ophold navn, adresse1, adresse2, adresse3, pasnummer Gæst navn, pris Gæster Service type Ophold Service opholdsnr, bet.form objekt dato, antal Vær. tilstand Ophold dato, antalPersoner, tilstand ( booket | optaget | rep. ) Vær. Hvert ophold er koblet til én gæst værnr, antalSenge, type pris1, pris2 klasse From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

attribut i datamodellen 20. Data dictionary = Databeskrivelse D1: Klasse: Gæst [a, b ... henviser til de gode råd] Gæsten er den person eller det firma der skal betale regningen. En person har en eller flere opholds-records. Et firma behøver ikke have nogen [b, c]. “Kunde” er et andet ord for gæst, men i databasen bruger vi kun gæst [a]. Personerne der bor i værelset kaldes også gæster, men de er ikke gæster i database-forstand [a]. Eksempler p. En gæst der overnatter én nat. q. Et firma med medarbejdere der overnatter nu og da, hver af dem med sit eget navn i det registrerede ophold [e]. r. En gæst med flere værelser i løbet af opholdet. Attributter 1. navn: Tekst, 50 tegn [h] 2. pasnr: Tekst, 16 tegn [h] Der mangler et attribut i datamodellen Anbefalinger for klasser. Forklar: a) Navn brugt i systemet vs. navne i domænet b) Koblinger til andre klasser c) Tilfælde hvor koblingerne mangler d) Særlige forhold ved oprettelse og sletning e) Typiske og usædvanlige eksempler

21. Data-formler Fra dataflow diagrammer (Yourdon) booking ønske = gæstedata + periode + vær.type gæstedata = gæstenavn + adresse + betalingsform + [pasnummer] pasnummer = bogstav + {ciffer}*8 vær.tilstand = { frit | booket | optaget | repareres } XML <gæst><navn>John Hansen</navn> <adresse><vej>Nørrebrogade</vej> . . . </adresse></gæst>

22. Virtuelle vinduer = Datavisning uden "knapper" Ophold Oph.nr: 714 Gæst: John Simpson Adresse: 456 Orange Grove Victoria 3745 Betaling: Visa Morgenmad 23/9 I På Værelse rest. vær. 11 2 12 1 13 1 1 Produkt ant.pers 22/9 Vær. 12, enkelt 1 500 23/9 Morgenmad, rest. 1 40 23/9 Vær. 11, dobbelt 2 800 24/9 Morgenmad, på vær 2 120 24/9 Vær. 11, dobbelt 2 800 Registrer morgenmad Serviceliste Breakf. rest. 4 Breakf. room 6 . . . Book, check ind . . . Prisændring Værelser Priser 22/9 23/9 24/9 25/9 11 Dobbelt Bad 800 600 O B 12 Enkelt Toil. 500 O O B B 13 Dobbelt Toil. 600 500 B B B Book, check ind . . . Prisændring

23. Datakrav - hvad er så bedst? Mulige former: Egnet? Via use cases eller arbejdsopgaver E/R eller UML klassemodel Databeskrivelse - data dictionary Skærmbilleder eller virtuelle vinduer XML, Dataflow Svært at overskue. Gentages mange steder. Fint for tekniker. Dårligt for bruger. Fint for tekniker. OK for ekspertbruger. Fint for bruger. Data-relationer uklare for tekniker. Håbløst for bruger. Data-relationer uklare for tekniker.

(ikke-funktionelle krav) Kvalitetskrav (ikke-funktionelle krav) Svartid Usability Sikkerhed . . .

25. Kvalitetsmatrix (ud fra McCall's faktorer) Glem det Mindre Som vi Kritisk Vigtig plejer vigtig 25. Kvalitetsmatrix (ud fra McCall's faktorer) Kvalitets- faktorer for hotelsystem Årsag: 1. Svært at køre hotellet når systemet er nede. Check ind er fx umuligt når man ikke kan se værelsets status. 2. Vi går mest efter små hoteller. De har utrænede vikarer. 3. Kunderne har mange slags regnskabssystemer. Vigtigt med smertefri integration. 4. Integration med regneark, etc. ligegyldig. Den indbyggede statistik burde være nok. 5. Skal være meget lettere at installere end eksisterende systemer. Ideelt skal en receptionist kunne gøre det selv. Drift Sikkerhed x Fejlfrihed x Oppetid 1 Brugervenlighed 2 Svartid mv. x Ændring Retbarhed x Testbarhed x Udvidelighed x Overførsel Flytbarhed x Integration 3 4 Genbrugelighed x Installerbarhed 5 From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

26. Svartidskrav R10: Når man går fra et felt til det næste, skal man kunne taste indenfor 0,2 s. Når man går fra et skærmbillede til det næste, skal man kunne taste indenfor 1,3 s. Visning af en rapport på skærmen skal ske indenfor 20 s. Ellers nedsættes tastetiden Mental skiftetid Ellers skifter man task Skal gælde i 95% af tilfældene ved spidsbelastning, dvs.: 20 brugere arbejder med sagsbehandling (arbejdsopgave T12) og 100 brugere med kundesupport (arbejdsopgave T10) R20: Visning af simple rapporter på skærmen skal ske indenfor 20 s i 95% af tilfældene. Det må aldrig tage over 80 s. Urealistisk

27. Åbent mål (target) Bedst mulig er 40 s? R2: Systemet skal beregne en belægningsprognose indenfor 20 s. Ingen prøver 20 s R3: Systemet skal beregne en belægningsprognose indenfor 40 s. Åbent mål men hvor vigtigt? R4: Systemet skal beregne en belægningsprognose indenfor ___ s. R5: Systemet skal beregne en belægningsprognose indenfor ___ s. (Kunden forventer 20 s.) Åbent mål + forventning Krav til svartider Når man går fra et felt til det næste skal brugerens tastehastighed ikke nedsættes. Visning af simple rapporter skal ske inden brugeren taber tålmodigheden. Eksempel på løsning Man kan taste inden ___s. (Kunden forventer 0,2 s) Rapporten skal være synlig inden ___s. (Forventer 20 s) Formulering i kravskabelon SL-07:

28. Usability / brugervenligheds problemer Eksempler: Systemet gør som programmøren har tænkt, men brugeren: P1. Kan ikke finde ud af at starte søgningen. Finder endelig ud af at bruge F10. P2. Tror han har fuldført opgaven, men glemte at klikke på Opdatér. P3. Ser rabatkode-feltet, men kan ikke finde ud af den kode han skal bruge. P4. Siger det er tåbeligt at skulle bruge 6 skærme til at udfylde 10 felter. P5. Vil udskrive en liste af rabatkoder, men det kan systemet ikke. Alvorlighed: 1 Manglende funktion (strengt taget ikke brugervenlighed) 2 Task failure 3 Irriterende, besværligt 4 Mellem-problem (lykkes efter længere tid) 5 Lille problem (lykkes efter kort tid) Kritisk problem = Manglende funktion, task failure, irriterende - oplevet af mange brugere

29. Den bedste kravtype - afhænger af . . . Tidlig udvikling Købe et system Sen udvikling Forstå hvad der sker Effektivt at bruge Subjektiv tilfreds Let at huske Let at lære Tidtagning Problemtælling Tastetrykstælling Meningsmåling Forståelighedsmåling GUI standard God Nyttig Kun indikationer ? ?

Skaffe kravene og teste dem

31. Hvilke teknikker hvornår? Viden om Teknik Mørke felter: Mest egnet Nuværende arbejde Nuværende problemer Mål & kerneproblemer Fremtidens løsninger Realistiske muligheder Effekt & risiko Commitment Konfliktløsning Kravspecifikation Prioriteter Fuldstændighed Viden om Interessent-analyse (Gruppe) interview Observation Vis-mig-hvordan Dokumentstudie Spørgeskema Brainstorm Fokusgruppe Domæne-workshop Design-workshop Prototyping Pilot-forsøg Lignende firmaer Spørg leverandører Forhandling Risiko-analyse Cost / benefit Mål-domæne-analyse Domæne-krav-analyse Teknik Mørke felter: Mest egnet

32. Statusindikator på kravspecifikationen Hvor meget ved vi om: (skala 0-5) 3/10 27/10 . . . Nuværende arbejde Nuværende problemer Mål & kerneproblemer Fremtidens løsninger Realistiske muligheder Effekt og risiko Commitment Konfliktløsning Kravspecifikation Prioriteter Fuldstændighed

33. Afprøvning Installationsprøve: Systemtest: Anvendelsesprøve: (Deployment test) Overtagelsesprøve: (Acceptance test) Driftsprøve: (Operational test) Hardware, software, eksterne produkter. Test grundlæggende funktioner. Test alle krav. (Undtagen dem der vedrører drift) Stress-test, specielle tilfælde, etc. (Der bruges specielt opsat databaseindhold) Produktionsdata (datakonvertering). Test med rigtige opgaver og rigtige brugere. = System test + Deployment test. Test resterende krav, fx svartider i drift, oppetid, hot-line . . .

34. Kilder til test cases Analyse Brugere Støt opg. 1-8 Domænekrav Brugertest . . . Beta test Udfør opgave Check ind fra gaden Check ind booket Skærmbilleder: . . . Knapper: . . . Design Designspec Test cases: Inspicer skærme Prøv funktioner Find gæst, mange match Find gæst, ingen match Program Kode Branch test, tom løkke Dato tom, navn ok Dato ok, navn tom Grænsetest, ulovlig værdi Værelse 1000 Værelse a7% Tester's tricks

35. Test af kvalitetskrav Højst 5 kritiske problemer Svartider højst 1,3 s Usability test Performance test Kvalitetskrav Svært at udbedre til sidst Fra kravskabelon SL-07: Risikable krav: - Effektiv støtte til grundlæggende arbejdsopgaver - Rimelig svartid med det planlagte antal brugere - Rimelig brugervenlighed - Mulighed for egen / 3. parts udvidelse af systemet Leverandøren skal tidligt demonstrere at disse krav kan opfyldes. Kan ske inden for de første __ uger efter kontraktens underskrift ( . . . hævebeføjelse) Proof-of-concept Risiko-reduktion: Fx testsystem med simuleret belastning. Usability test. Få 3. part til at teste udvidelighed.

Ekstra plancher: Integration Sikkerhed Kravtyper Vedligehold

37. Integrationskrav: Elektronisk patientjournal Kontekstdiagram F1. SKS Koder EPJ-system Klinik Rekvisition Svar F2. LabsysX Dobbelt linie: Leverandøren integrerer F10. Nye eksterne systemer Patient- administration

38. Simpel integration - periodisk overførsel er nok SKS-tabellerne omfatter koder for såvel diagnoser som ydelser og bruges derfor ved de fleste arbejdsopgaver. Tabellerne er bl.a. tilgængelige som zip-tekstfiler med fast feltbredde fra Sundhedsstyrelsens web-site. Datavolumen: SKS-tabellerne udgør op til 100.000 records à ca. 100 tegn. Integrationsbehov: Eksempler på løsning: Kode: 1. EPJ-systemet skal anvende SKS-data der er rimeligt aktuelt. Systemet overfører data hver ___ dag. (Kunden forventer 7 dage). 1p. Det sker at de nye SKS-koder giver problemer, fx at de er i konflikt med lokale koder. 2. I særlige tilfælde kan der være behov for større dataaktualitet. Driftsafdelingen kan starte en dataoverførsel.

39. Integration med eksisterende system LabsysX bruges i forbindelse med arbejdsopgave C10. De tekniske grænseflader til LabsysX er beskrevet i . . . Hyppighed: Totalt leveres der op til 400 prøveresultater pr. døgn. Leverandøren bedes beskrive den tilbudte grad af integration gennem følgende krav. Grad af integration: Eksempler på løsning: Kode: 1. Brugeren starter LabsysX gennem EPJ-systemet, logger dernæst ind på LabsysX hvor han indtaster patientens cpr og bestiller ydelsen gennem LabsysX's skærmbilleder. (En lav grad af integration) 1p. Det er besværligt og risikabelt at skulle logge ind igen og angive patientens cpr. Bruger-ID og cpr overføres automatisk. 2. Brugeren bestiller LabsysX ydelsen gennem EPJ-systemets skærmbilleder på samme måde som for andre ydelser. EPJ-systemet bruger API grænsefladerne til LabsysX. 3. EPJ-systemet kan advisere brugerne om færdige eller udeblevne resultater på samme måde som for andre ydelser. 4. Data fra LabsysX overføres . . . Grader af integration

40. Integration med nye systemer Kunden forventer at nye eksterne systemer kan integreres af tredjepart, fx. . . Interfaces - EPJ som server: Eksempel / løsning: 1. Det nye system kan hente og Kan gøres med messages, API, etc. opdatere EPJ-data beskrevet i ... 2. Det nye system kan bruge EPJ funktionalitet, inkl. advisering ... Interfaces - EPJ som klient: 3. EPJ systemet kan hente og Kan gøres med messages, API, etc. opdatere data i det nye system. 4. EPJ systemet kan bestille ydelser og advare via det nye system. Dokumentation og rettigheder: 5. EPJ grænsefladerne skal doku- Leverandøren bedes angive hvor menteres så et SW-hus kan forstå meget uddannelse et SW-hus dem og finde dem egnet til formålet. behøver 6. Tredjepart skal have ret til at bruge grænsefladerne. 7. Svartiderne for funktionerne skal Afhængigheder af datavolumen og være dokumenteret. platform bør angives.

41. Sikkerhed og trusler CIA + A: Wire tapping Nysgerrige øjne System Lønseddel Wire tapping Disk crash Trusler Ødelægger Forebyggelse Input, fx Fx Fejltagelse Integritet Logisk kontrol Ulovlig brug Ægthed Password . . . Wire tapping Fortrolighed Kryptering CIA + A: Confidentiality = fortrolighed Integrity = integritet Availability = tilgængelighed + Authenticity = ægthed Lagring/proces Disk crash Tilgængelighed Dublerede diske Programfejl Integritet Testmetoder Virus sletter data Tilgængelighed Antivirus . . . Output, fx Kabelbrud Tilgængelighed Multiple linier Bedrageri Fortrolighed Revision Virus sender data Ægthed Kryptering . . . From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

42. Risikovurdering (security risk assessment) Antagelser: Tabe databasen med alle bookinger: 1.000.000 Tabe computer- adgang 1 dag: 50.000 On-line booking uden dækning: 3.000 Bedrager der fjerner fakturagrundlag 1.000.000 Adm. rod når fakturaer ikke printes 2.000 Beløb i kr. Gange pr. Tab Tab år pr. gang pr. år 10 3.000 30.000 0.3 1000.000 300.000 1 50.000 50.000 0.1 1000.000 100.000 0.2 1000.000 200.000 1 1000.000 1000.000 Trussel Input Fup-booking Lagring Disk crash Comp. crash Sabotage Bedrageri Virus Output Printerfejl From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

43. Sikkerhedskrav vedr. trusler R1: Beskyt mod tab af databasen. Estimeret tab skal være < 1 pr. 50 år. R2: Beskyt mod disk crash. Estimeret tab skal være < 1 pr. 100 år. R3: Systemet skal bruge dublerede diske (RAID disks). R4: Systemet skal beskytte mod virus der sletter/ødelægger filer. Antal angreb der ikke undgås < ______. R5: Systemet skal have antivirus og firewall mod virus. R6: Systemet skal følge god regnskabspraksis. Leverandøren skal sørge for certificering. R7: Systemet skal forhindre at brugere sletter fakturaer før de overføres til regnskabssystemet. R8: Leverandøren skal som en option tilbyde at systemet tjekker creditkort og tilbageholder beløb. R9: Leverandøren skal vedlægge en risikovurdering og foreslå beskyttelsesforanstaltninger. From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

44. Vedligehold, fejlrettelse - fra requirements SL-07 Krav til afhjælpning af fejl: Eksempler på løsning: Kode: 1. Leverandøren fører en log over såvel rapporterede fejl som ændringsønsker. 2. For alle rapporterede fejl vurderer leverandøren hurtigt om fejlen er kritisk for kundens arbejdsopgaver, om den midlertidigt kan omgås, eller om den permanent kan omgås (afvises) . Alt 1: Superbruger vurderer. Alt 2: Kundens IT afdeling vurderer. Leverandøren udfører vurderingen inden for ___ timer i perioden 8:00-18:00, alle hverdage. (Kunden forventer 3 timer). 3. Kritiske fejl afhjælpes hurtigt. Kritiske fejl afhjælpes inden for __ timer. (Kunden forventer24 timer). 4. Parterne mødes regelmæssigt for dels at kontrollere vurderingerne af fejlene, dels at afgøre hvad der skal rettes eller forbedres og hvad det skal koste. Parterne mødes ____ (Kunden forventer månedlige møder).

45. Vedligehold, forbedring - fra skabelon SL-07 Krav til forbedring af systemet: Eksempler på løsning: Kode: 5. Leverandøren skal installere nye versioner og releases af det leverede software uden unødig forsinkelse. Installationen sker inden for ___ dage efter at det er frigivet til brug i Danmark. (Kunden forventer 30 dage). 6. Inden for en periode af 3 år skal leverandøren tilbyde ændringer og udbygninger af software til en fast pris pr. function point. Prisen pr. function point er ______ Dkr. 7. Uenighed om beregningen af function points skal afgøres af . . .

46. Tre af kravenes dimensioner Kravområde Dialog-funktion Data Integration Platform Svartid Sikkerhed Brugervenlighed Love & regler Support Vedligehold Forretn. mål Domæne Produkt Design Proces Kravniveau Ja-nej Talskala Point (fx 0:5) Kan ikke vurderes Målemetode