Slides - Søren Lauesen - it-kontraktret.dk

IT-Kravspecifikation
med SL-07
Søren Lauesen, oktober 2012
IT-University of Copenhagen
E-mail: slauesen@itu.dk http://www.itu.dk/people/slauesen

2. Traditionelle krav
-
løn og vagtplan på
hospital
Krav 148: Systemet skal kunne registrere den daglige faktiske
arbejdstid for hver medarbejder.
Krav 475: Systemet skal kunne beregne regnskabsmæssige
konsekvenser af en given vagtplan i kroner og øre.
Absolutte krav. Både leverandør A og B siger de opfylder dem.
Krav A's løsning B's løsning
Krav 148.
Registrer arbejdstid
Krav 475.
Regnskabsmæssig
konsekvens
Fang data via
medarbejdernes
eksisterende adgangskort
Send vagtplan. Svar
indenfor 24 timer
Løsningen er
uanvendelig i praksis
Efter kontraktunderskrift leverer A
opslagstavleløsningen i stedet?
Klassisk
IEEE 830
Indtast data fra
afdelingens eksisterende
opslagstavle
Interaktiv løsning: Vis med
farvekoder hvor dyrt det er
at placere medarbejder N
her på planen
Er kravet formelt opfyldt?
Tallene vises ikke

3. Hvad kan vi lære af det?
Kravopfyldelse er ikke ja/nej, men grader af værdi.
Hvad er bedst: God løsning til krav 1 og dårlig løsning til krav 2.
Eller omvendt?
Absolutte/ufravigelige krav er uegnede.
Løsningen skal være en del af kontrakten.

4. Skriv
krav 475
som
use case?
Hovsa-trigger.
Use case 475: Beregn regnskabsmæssig konsekvens af vagtplan Hvad bruges det
Trigger: Brugeren vil beregne konsekvensen til og hvornår?
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
Exception: Ingen vagtplaner i listen
Selvopfunden dialog.
Leverandør B må vrages.
Trivielle detaljer - forført af skabelonen.
Ingen værditilvækst.
Use cases kan ikke fange problemer
med ukendt løsning – men der er de
forretningskritiske behov ofte.
Er use cases krav?
Skrives, men bruges ikke

5. SL-07: Task
Subtask og varianter:
1.
Dan ny vagtplan.
descriptions. Støt arb.opgave
C2: Lav vagtplan
Hyppighed: Hver 14. dag. I nogle afdelinger . . .
Start: Når der er fred i vagten.
Slut: Når der bliver travlt.
Eksempler
C1, C2 . . .
2. Registrer ferie. To slags ferie . . . Systemet kontrollerer feriereglerne.
2p. Nuv. problem: Små lapper Systemet har en tidshorisont på flere
med ønsker mange måneder frem. år.
3. Bemand vagter. Tjek rette Systemet foreslår bemanding af
kompetencer, ferie, overenskomster ubemandede vagter.
og undgå tillæg.
Advarer om brudte regler og unødige
3p. Nuv. problem: Svært at gøre tillæg. Støtter "puslespillet" med
manuelt. Fejl og for mange tillæg.
3a. Vikarer endnu ikke i systemet.
undo og flere forsøgsudgaver.
3b. Skaf medarb. fra anden afdeling. Viser ledige fra andre afdelinger.
4. Send planen til kommentering. En udskrift af planen er nok.
5. Parker planen eller frigiv den.
Udføres af menneske Eksempel på computers
plus computer
del - ikke krav
på
løsning:
Automatisk ud fra sidste plan . . .

6. Leverandørsvar (typisk, men ikke eksemplarisk)
C2: Lav vagtplan
Hyppighed: Hver 14. dag. I nogle afdelinger . . .
Start: Når der er fred i vagten.
Slut: Når der bliver travlt.
Subtask og varianter:
1.
Dan ny vagtplan.
2. Registrer ferie. To slags ferie . . .
2p. Nuv. problem: Små lapper
med ønsker mange måneder frem.
3. Bemand vagter. Tjek rette
kompetencer, ferie, overenskomster
og undgå tillæg.
3p. Nuv. problem: Svært at gøre
manuelt. Fejl og for mange tillæg.
3a. Vikarer endnu ikke i systemet.
3b. Skaf medarb. fra anden afdeling.
4.
5.
Send planen til kommentering.
Parker planen eller frigiv den.
Tilbudt
løsning:
Automatisk ud fra sidste plan. OK.
Systemet kontrollerer feriereglerne.
Op til to år frem.
Støttes. Se skærmbilleder i . . .
Ledige også
fra andre hospitaler.
En udskrift af planen er nok.

7. Kundens
Subtask og varianter:
1.
Dan ny vagtplan.
2. Registrer ferie. To slags ferie . . .
Nuv. problem: Små lapper med
ønsker mange måneder frem.
3. Bemand vagter. Tjek rette
kompetencer, ferie, overenskomster
og undgå tillæg.
Nuv. problem: Svært at gøre
manuelt. Fejl og for mange tillæg.
3a. Vikarer endnu ikke i systemet.
3b. Skaf medarb. fra anden afdeling.
4. Send planen til kommentering.
5.
vurdering af løsning ved teknisk afklaring
C2: Lav vagtplan
Hyppighed: Hver 14. dag. I nogle afdelinger . . .
Start: Når der er fred i vagten.
Slut: Når der bliver travlt.
Parker planen eller frigiv den.
Eksempler
/ løsning:
Automatisk ud fra sidste plan . . .
Systemet kontrollerer feriereglerne.
Kun 12 mdr ud i fremtiden.
Systemet foreslår bemanding af
ubemandede vagter.
Tillægsberegning batch - 24 timer.
Flere udgaver besværligt.
Kan vise ledige fra andre
hospitaler.
Samlet point: 0
(som i dag)

8. Forretningsmæssige mål og hvordan de opnås
Forretningsmæssige
mål
Task
Personaleafdeling:
Automatiser nogle opgaver
Fjern fejlkilder
Overhold 120-dags reglen
Mindre trivielt arb. og stress
Hospitalsafdeling:
Mindre overarbejdsbet. mv.
Hurtigere vagtplanlægning
Bedre plankvalitet
Lavere IT udgifter
Bruger: Planlægger i afdelingen
C1 Månedlig timeregnskab til pers.afd.
C2 Lav vagtplan
Bruger: Medarbejder i afdelingen
C3 Registrer faktisk arbejdstid
C4 Byt vagter
C5 Sygdom hos medarbejder
Bruger: Personaleafdeling
C6 Kontroller vagtplaner
C7 Ændringer af lønsedler
C8 Registrer nye medarbejdere
Ikke hierarkisk
nedbrydning,
men mange-tilmange
Forretningsmæssig værdi
Ansatte: 5000
Overarb.bet: 20% til 10%
IT udgifter nu: 30 mio/år
Sparede Mio DKK
årsværk over 5 år
7 15
7 15
? 5 ? 10
(blød faktor)
(400) 800
7 15
(blød faktor)
50

9. Forretningsproces –
Trin:
1. Indskriv patienten
2.
3.
4.
5.
6.
Stil diagnoser
Planlæg behandling
Udfør behandling
Vurder resultat
Udskriv patient
ikke hierarkisk nedbrydning
Proces 2: Behandlingsforløb
Start: Patienten henvises af egen læge eller kommer akut.
Slut: Patienten er helbredt eller . . .
Løsning:
C1: Indskriv inden ankomst
C2: Indskriv akut
C10: Udfør klinisk session
C10: Udfør klinisk session
C10: Udfør klinisk session
C10: Udfør klinisk session
C3: Udskriv patient . . .

10. SL-07 princip for tasks, sikkerhed, svartider . . .
Nummer og navn på det overordnede krav.
Antagelser leverandøren kan gøre, fx brugerne er sygeplejersker, opgaven
udføres n gange daglig.
Eksempler og baggrundsoplysninger
Kundens behov Løsningseksempel -> tilbudt løsning Kode:
1.
1p.
2.
. . .
Delkrav
Problem i dag
Delkrav
Kravnoter når der ikke er plads i tabellen.
Løsningsnoter når der ikke er plads i tabellen.
Og realistiske
eksempler på alt

11. Kravskabelon SL-07
A. Baggrund og vision, vejledning . . .
B. Overordnede behov
B1. Forretningsmæssige mål
B2. Early proof of concept
B3, B4, B5. Tildelingskriterier mv.
C. Arbejdsopgaver systemet skal støtte
C1. Indskriv patient 1% genbrug
C10. Udfør klinisk session . . .
D. Data systemet skal anvende
D1. Diagnoser
D2. Diagnosetyper
D3. Ydelser . . .
20% genbrug
1% genbrug
E. Andre funktionelle krav
E1. Systemgenerede hændelser
E2. Komplekse beregninger og regler
E3. Udskrifter og rapporter
E4. Udbygning af systemet
30% genbrug
F. Integration med eksterne systemer
G. Teknisk it-arkitektur
G1. Brug af eksisterende HW og SW
G2. Nyt hardware og software . . .
H. Sikkerhed 50% genbrug
H1. Login og 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 80%
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
80% genbrug
J4. Datakonvertering
J5. Installation
K. Kundens leverancer
L. Drift, support og vedligehold
L1. Svartider
L2. Tilgængelighed
L3. Datalagring
L4. Support
L5. Vedligehold
90% genbrug

12. Tilgængelighed (driftseffektivitet) – hvorfor lige 99.8% ?
Systemet er ude af drift når en del af brugerne ikke kan få støttet deres arbejdsopgaver
som normalt. Årsagen til driftsstoppet kan være:
1.
2.
3.
4.
5.
Kundens forhold, fx fejl i kundens udstyr
Udefra kommende fejl, fx strømsvigt
Leverandørens forhold, fx fejl i software eller fejlagtig konfiguration
Planlagt vedligehold
Utilstrækkelig hardware kapacitet
Løsningsnote: Måling af tilgængelighed
Et driftsstop regnes altid for at vare i mindst 20 minutter, selv hvis driften reelt
genetableres inden. Hvis en driftsperiode varer mindre end 60 minutter, regnes den for
en del af driftsstoppet. . . . Der medregnes kun driftsstop som skyldes . . .
Krav til driftstid: Eksempel på løsning: Kode:
1.
2.
Tilgængeligheden skal opgøres periodisk og
der skal tages hensyn til hvor stor en del af
brugerne der oplever driftsstoppet.
I tidsrummet fra 0:00 til 24:00 på alle dage
skal tilgængeligheden være 99,8 %.
Leverandøren: OK.
Det koster 20 mio/år
Tilgængeligheden opgøres
månedligt.
(Jeg ville have foreslået 99,5%.
Det koster kun 5 mio/år.)

13. SL-07: L2. Tilgængelighed (driftseffektivitet)
Systemet er ude af drift når en del af brugerne ikke kan få støttet deres arbejdsopgaver
som normalt. Årsagen til driftsstoppet kan være:
1.
2.
3.
4.
5.
Kundens forhold, fx fejl i kundens udstyr
Udefra kommende fejl, fx strømsvigt
Leverandørens forhold, fx fejl i software eller fejlagtig konfiguration
Planlagt vedligehold
Utilstrækkelig hardware kapacitet
Løsningsnote: Måling af tilgængelighed
Et driftsstop regnes altid for at vare i mindst 20 minutter, selv hvis driften reelt
genetableres inden. Hvis en driftsperiode varer mindre end 60 minutter, regnes den for
en del af driftsstoppet. . . . Der medregnes kun driftsstop som skyldes . . .
Krav til driftstid: Eksempel på løsning: Kode:
1.
2.
Tilgængeligheden skal opgøres
periodisk og der bør tages hensyn til
hvor stor en del af brugerne der . . .
I tidsrummet fra 8:00 til 18:00 på alle
hverdage skal systemet have høj
tilgængelighed.
Open target
Tilgængeligheden opgøres
månedligt.
Her er tilgængeligheden
mindst ___ %.
(Kunden forventer 99,8 %).
99,9% 20 mio/år.
Alternativ:
99,5% 5 mio/år.

14. Nå
forretningsmål
Formål med nyt system:
Effektiv støtte af klinikerne.
Færre fejlmedicineringer.
Løbende forbedring af
arbejdsgange.
Lavere driftsomkostninger.
for EPJ. Fra
Overordnede
løsninger:
Alt nødvendigt data til
rådighed i ét system.
Undgå
manuelle
mellemled. Indtast
ordinationen straks.
Systemet kontrollerer
for . . .
Let at opbygge
standardplaner.
Let at integrere med
nye systemer.
Konkurrenceudsættelse.
Ikke krav til leverandøren, men nyttig viden
SL-07, B1
Relaterede krav:
Støtte til C10.
Systemintegration.
Støtte til C10-C14.
Støtte til C30.
F10 (integration
med nye systemer)
Alle krav.
Tildelingskriterier.

15. Risikable krav: Kan ikke udbedres til sidst
Fra kravskabelon SL-07, B2:
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. Skal ske inden for de første ___ uger
efter kontraktens underskrift (ellers kan kontrakten
opsiges)
Hav en anden leverandører i baghånden:
Ellers er det for tungt at opsige kontrakten og
man vælger at leve med et dårligt system.
Den
der lyver vinder. Han skal stoppes tidligt.
Proof-of-concept
Risiko-reduktion:
Fx testsystem med
simuleret belastning.
Usability test med
mockup.
Få 3. part til at teste
udvidelighed.

16.
Minimumskrav og tildelingskriterier
Regler ved EU udbud:
1. Der skal være minimumskrav. Dårligere tilbud afvises.
2. Der skal beregnes ét godhedstal pr. tilbud. Det højeste tal er vinderen.
3. Leverandørerne skal kende beregningsmetoden på forhånd.
Problemer ved offentlige projekter:
4. Hvilke af de 1000 krav er minimum (ufravigelige)? Umuligt at afgøre.
5. Hvordan skal vi vægte eller prioritere 1000 krav?
Løsning:
6. Fastsæt minimum for kravområder i stedet for enkelt-krav.
7. Tildeling ud fra forretningsmæssig værdi.

17.
B3. Minimumskrav
til elektronisk patientjournal
Point: -2 (ikke støttet), -1 (ubekvemt), 0 (som i dag), 1 (effektivt), 2 (meget effektivt)
Kravområde Min. point Lev. A Lev. B
C1-C4. Indskriv patient -2 1
C10. Udfør klinisk session (*) 0 1
C11-C14. Medicinering 0 2
D. Data. Vurderes via tasks N/A N/A
. . .
F10. Integrer med nyt system (*) 1 1
H1. Login og adgangsret 0 0
H2-H5. Anden sikkerhed -1 -1
I. Brugervenlighed (*) 0 1
J2. Uddannelse 0 0
J4. Datakonvertering 0 1
L1. Svartid (*) 0 0
* Vurderes også
ved det tidlige bevis (proof of concept)

18.
Tildelingskriterie B4:
Nettogevinst i mio
kr. over 5 år
Forretningsmål
5-års Opf.grad Risiko 5-års værdi
potentiale
A B A B A B
1. Effektiv støtte af klinikerne 1000 mio 0.5 30% 350
2. Reducer medicineringsfejl 250 mio 1.0 10% 225
3. Løbende procesforbedring 250 mio 1.0 40% 150
4. Mindre driftsomk
Bruttogevinst
(se omk.)
over 5 år 1500 mio 725
Nettogevinst over 5 år Lev. A Lev. B
Bruttogevinst over 5 år 725
Produktets pris 100
Kundens hardware-udgifter 50
Medarbejderuddannelse 28
Driftsudgifter over
Samlede omkostninger over
5 år 100
5 år 278
Nettogevinst for 5 år 447

19.
Tildelingskriterie B5:
Kravområde
Vægtede point pr. mio
Vægt
Point
A
Point
B
Vægtet
A
C1-C4. Indskriv patient 5 1 5
C10. Udfør klinisk session 50 1.5 75
C11-C14. Medicinering 15 2 30
D. Data. Vurderes via tasks
. . .
(C) N/A
F10. Integrer med nyt system 15 1 15
H1. Login
og adgangsret 0 0
H2-H5. Anden sikkerhed 0 -1
I. Brugervenlighed 10 1 10
J2. Bruger uddannelse (omk.) 0
J4. Datakonvertering 0 1
L1. Svartid 5 0
Vægtede point i alt 100 135
Vægt i forhold til skønnet
potentiale i mio kr.
kr.
Vægtet
B

20.
Resultat: Vægtede point pr. mio
Vægtede point i alt 135
Produktets pris 100
Kundens hardware-udgifter 50
Medarbejder uddannelse 28
Driftsudgifter for 5 år 100
Samlede omkostninger for 5 år 278
Point pr. mio kr. 0,49
kr.
Lev. A Lev. B

21. eTL -
1.
2.
3.
4.
hvorfor
hotline overbelastes
Hvordan tinglyser man skøde på en ejerlejlighed? Muligheder: enfamiliebolig,
andelslejlighed, landbrugsejendom, men ikke ejerlejlighed.
Kur: Ring til hotline en time daglig i tre uger. Svar: Vælg enfamiliebolig - som i loven.
Er det gratis at udføre en prøvetinglysning, og hvor meget afprøver den?
Anmeldelse afvist. Men hvorfor? Prøv igen -
håb på Jackpot?
Hvornår bliver sager udtaget til manuel behandling?
(Nogle skrev "glædelig jul" i feltet meddelelser til tinglysningsmedarbejderen.
Resultat: Sagen blev udtaget til manuel behandling - to måneders behandlingstid).
Hvad sagde kravene om brugervenlighed?
Krav 153: Kvalitetssikring af brugervenlighed. Leverandøren skal under udviklingen
kontrollere den eksterne portals brugervenlighed. . . . Tilbudsgiver skal beskrive
hvordan.
Svar på
krav 153: Test med Rolf Molichs principper (tænke højt med tidlig prototype).
Svar bilag 21, kvalitetssikring, dvs.: Testleder guider testdeltagerne igennem
opgaverne, stiller uddybende spørgsmål, og hjælper hvor det er nødvendigt.
Ændring 32, 30-03-2009: Brugervenlighedstest erstattes af en meget tæt dialog
mellem [leverandørens og kundens eksperter]
Ups !

22. Kravspec: Med
brugerhistorier
Anmeldelse af bodeling
Hans og Grethe blev gift i 1989, men nu skal de skilles. De har i hele ægte-
skabet boet i Hans' ejendom og de har aftalt at Grethe skal blive boende.
Hans logger sig ind på www.e-tl.dk. Frem toner en velkomsttekst. Der er
tekst og tegning for tingbogen over fast ejendom, bilbogen . . . Han kan se et
ikon for informationscenter . . .
Hans klikker på teksten for fast ejendom. Herefter får han vist et login-billede
. . . Hans har sin digitale signatur lagret på sin PC . . . Han bliver bedt om at
oplyse om han vil tinglyse eller forespørge på fast ejendom . . . og sin e-mail
adresse . . . og om han skal arbejde med oplysninger om ejer, pant,
servitutter eller andet.
Han vælger ejer og bliver bedt om at oplyse om det er
- endeligt skøde
- endeligt skøde på flere ejendomme
- skøde betinget af købesummens betaling
- (og fire andre muligheder, herunder bodeling)
I alt 5 A4-sider
for dette eks.
Teksten siger
det ikke er krav.
Færdigt system: 22 skærmbilleder for at tinglyse et skøde

23. Kravspec: Med use
cases
Use case A.5. Egentlig står der bare:
1. Bruger vælger en udfyldt anmeldelse
2. Systemet udfører en prøvetinglysning
3. Brugeren får resultatet
Kontekst: Hvad
skal han bruge
resultatet til?
Andre use cases:
Udfyld anmeldelse
Vedhæft fil
Underskriv digitalt
. . .
Vælg anmeldelse
hver gang

24. Med SL-07 skabelonen. Systemet skal støtte C1 . . .
C1: Tinglys ejerskab
Hyppighed: Få gange i borgerens liv
Bruger: Almindelig borger
Delopgaver og varianter:
1. Udfyld tinglysningsoplysninger (se data
i kapitel D)
1a. Hent evt. en parkeret sag
2. Vedhæft evt. dokumenter
3. Prøvetinglys sagen og se hvad der evt.
skal ændres. Prøvetinglys evt. igen.
3p. Hvad koster det? Også hvis der er fejl?
4. Giv betalingsinformation og send til
tinglysning.
5. Underskriv det nødvendige.
6. Parker evt. sagen.
Valgfri delopgaver
og rækkefølge
Udføres af bruger
+ computer
Dækker kontekst
plus 6 use cases
Eksempler på løsning:
Systemet markerer hvilke data
der skal udfyldes.
Systemet forklarer fejlen i
borgerligt sprog.
Priserne vises på forhånd.
Systemet forklarer hvad der nu
vil ske og hvor lang tid der vil gå.
Systemet bruger digital signatur.
Eksempel på computers
del - ikke krav

25. Nogle projekter der har brugt SL-07
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Administration af
genbrugspladser
Knowledge management i en
kreditforsikringsvirksomhed
Effektiv ansættelse af nye
medarbejdere
Projektstyring i et SW hus
Bookingsystem på hospitaler
Socialministeriet DHUV
Registrering af miljøoplysninger
på Novo Nordisk
Studieportal til den Grafiske
Højskole
Kontrol af arbejdsmiljø
Roskilde kommune EOJ
Afvikling af en Olympiade
Produkt til registrering af
erhvervsmæssig kørsel
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
Knowledge Management i Patentog Varemærkestyrelsen
ITIL support i medicinalvirksomhed
Overvågning af vindmølledrift
CRM til Danske Spil
Knowledge management i globale
projekter
Flight
training service
Kursusadministration, Grundfos
Styring af multinational kuvertering og
print
Administration af aftenskoler
Styring af arbejdsmiljø
Dokumentstyring i medicinalindustrien
GIS-støtte
Skat forskud
til alarmcentral

26. Erfaringer fra Vestsjællands Amt
Traditionelt
Skriv krav
Alle spørges.
Alle finder på ønsker.
Kombineres til een.
Få forstår kravene.
Tid: 25 uger
Vurdér forslag
Alle har en mening.
Politisk valg.
Tid: 10 personmåneder.
Med SL-07
Skriv krav
Triumviratet skriver krav,
specielt arb.opgaver.
Alle kan rette opgaverne
og tilføje eksempler.
Tid: 3 uger (første gang)
Vurdér forslag
Udfør opgaverne med
systemet og giv det en
karakter.
Udvalgte interessenter
spørges. Ingen tvivl.
Tid: 1 personmåned.
1999

27.
Andre erfaringer
Fordele:
1. Meget hurtigere at skrive krav og vurdere tilbud.
2. Systematisk styring fra business case til løsning.
3. Kravene er behov – de siger ikke hvad systemet skal gøre.
4. Velegnet til agil udvikling. Venstre-siderne ændres meget lidt.
5. Leverandørerne får frihed til at bruge det de har og være innovative.
6. Der er en eksemplarisk kravspec at gå ud fra – med realistiske eksempler.
Ulemper:
1. Ser let ud, men første gang bliver det helt i skoven.
2. Kræver 3 * 3 timer at lære (on-the-job training).
3. Leverandørerne svarer som de plejer – ikke godt nok til at sammenligne dem
(trods detaljeret vejledning i kravspecifikationen).
4. Kunderne bruger sjældent tid på at se hvordan tilbuddet opfylder behovene.
5. Kun få konsulenter kender SL-07 metoden.
6. FM gav Statens projektkontor besked på at prøve SL-07, men intet er sket.