3. december 2018 Hvordan opmærksomheden på indholdet i krav skærpes, så fejl og misforståelser undgås Otto Vinter – Software Engineering Mentor vinter@ottovinter.dk,

Præsentationer af emnet: "3. december 2018 Hvordan opmærksomheden på indholdet i krav skærpes, så fejl og misforståelser undgås Otto Vinter – Software Engineering Mentor vinter@ottovinter.dk,"— Præsentationens transcript:

1 3. december 2018 Hvordan opmærksomheden på indholdet i krav skærpes, så fejl og misforståelser undgås Otto Vinter – Software Engineering Mentor & Kaj Henriksen – Projektleder KMD Projekt- og Konsulentforretningen

2 Præsentationens indhold
Indledning/præsentation Baggrunden for vores case (valg af et workshop format) Workshoppens indhold De grundlæggende begreber i kravspecificering Dokumenter til kravspecifikation og -vedligeholdelse Øvelser baseret på eksempler fra praksis Eksempler fra praksis Resultater fra afholdelsen af workshops Afslutning/spørgsmål

3 KMD – Projekt- og Konsulentforretningen
Udvikle og vedligeholde kunde-specifikke løsninger Eksempler på kunder Skat Nemkonto Q8 E-boks Falck Kriminalforsorgen CMMI certificeret på niveau 2

4 Baggrunden for at højne opmærksomheden på krav
Baggrunden var At etablere et bedre grundlag mellem Q8 og KMD for mindre opgaver, ved at forbedre den ”daglige” gensidige kravspecificeringsdialog At sikre forståelse hos udviklere og brugere for problemer med kravspecifikationer At sikre overholdelse af de CMMI certificerede kravhåndteringsprocesser hos KMD/PKF

5 Kravspecificering ved videreudvikling af systemer
Nyudvikling udgør <20% af totalomkostningerne for et IT system Kontrol med videreudvikling af systemer er derfor essentiel Kravspecificering ved videreudvikling Er en løbende ”daglig” proces Karakteriseres ofte blot som ”småopgaver” Foregår i samarbejde mellem udviklere og brugere Usikkert kendskab til korrekt kravspecificering/kravhåndtering Usikkert system- og domænekendskab Stor mulighed for fejl og misforståelser Men også stor mulighed for at udnytte forhistorien til læring En workshop til læring kan være mere effektivt end kurser

6 Problemet opstår allerede med kravspecifikationen
Analyser af fejlrapporter hos Brüel & Kjær har vist, at 51% af de rapporterede fejl kan henføres til problemer med kravspecifikationen 64% af de kravrelaterede fejl var Usability problemer 28% skyldtes samspillet med software fra eksterne leverandører Kun 22% af problemerne var egentlige funktionalitetsproblemer Med støtte fra EU. Mere information på:

7 Kravworkshoppens indhold
Workshop agenda Teori Introduktion og baggrund (20 min) Kravspecificering – nogle grundlæggende begreber (30 min) Hvilke krav stiller QP til kravspecifikation og -vedligeholdelse (30 min) Pause (10 min) Øvelser Introduktion (10 min) Individuel analyse af kraveksempler (30 min) Gennemgang i plenum af de fundne problemer (40 min) Afslutning (10 min)

8 Kravbeskrivelser En enkelt eller nogle få sætninger i almindeligt men klart sprog: Start med en navneord efterfulgt af et udsagnsord Afregningsformen for kørsel skal ændres så … Undgå synonymer – anvend aftalte/sædvanlige begreber Undgå subjektive ord (lille, høj, let) - brug præcise størrelser mindre end 1%, mindst kr, skal kunne udføres efter en ½ times instruktion Undgå generaliseringer som ”feks.”, ”osv.” Pas på brugen af ”og” og ”eller” matematisk logik og almindelig sprogbrug passer ikke altid sammen Brug med forsigtighed ord som: kan, bør, helst, muligvis

9 De enkelte krav og samlinger af krav skal være
Opnåelige - mulige at opfylde Komplette - både individuelt og samlet Konsistente - ingen indbyrdes modsætninger Modificerbare - ændringer og tilføjelser mulige Nødvendige - udtryk for et reelt behov Verificerbare - muligt at afgøre om de er opfyldt Utvetydige - kun en mulig fortolkning

10 Vigtige elementer til at udtrykke og forstå krav
Beskrivelse Korte, præcise sætninger med bestemmende udsagnsord Rationale Beskrivelse af kravstillers behov og forventninger begrundelser for kravet hvorfor er det opstået, hvad er kravets berettigelse i relation til forretningen Acceptkriterium Beskriv hvordan det kan afgøres, om kravet er opfyldt (godkendt) Prioritet Beskriv vigtigheden i relation til øvrige krav

11 Kravliste (Excel regneark)
Kravidentifikation: * = obligatorisk Kravnummer * et entydigt nummer for hvert krav af hensyn til sporbarhed Versionsnummer * for hvert krav af hensyn til sporbarhed Kravdato * for oprettelse/ændring af krav Status * kravets status (ikke udfyldt eller 'Godkendt') Kilde * reference til kravstiller (interessent fra interessentskema) Kravniveau * kundekrav eller et løsningskrav Beskrivelse * en kort og præcis sætning med et bestemmende udsagnsord Rationale * kravstillers behov, forventninger og begrundelser for kravet (hvorfor er det opstået, hvad er kravets berettigelse i relation til forretningen) Acceptkriterium * hvordan det kan afgøres, om kravet er opfyldt (godkendelseskriterium) Vægt * på baggrund af en vurdering af vigtighed i relation til øvrige krav (skala 10-50, 50 er højest) Initialer * på den der sidst har ændret kravet Kravtype funktionelt eller ikke-funktionelt krav Yderligere dokumentation henvisning til evt. yderlig dokumentation af kravet Andre kommentarer eventuelle uddybende kommentarer og bemærkninger til kravet Ændringsanmodning * reference til ændringsanmodning  Skabelon Kravliste.xls

12 Eksempel fra praksis: Firmabilopgørelse
3. december 2018 Eksempel fra praksis: Firmabilopgørelse For alle Q8-kort, som tilhører en firmabil hos Q8 ønskes nuværende print erstattet af csv-fil, som fremsendes via mail til specificerede mailadresser (skal kunne redigeres) csv-filen skal indeholde følgende felter: - leders login - kortholders navn - Kortnr - Transaktions-dato - Transaktionstidspunkt - Station - Produkt - Antal Liter - Km-stand - Forrige KM-stand - KM kørt - KM/liter - Bemærkning For hvert kort inkluderes 2 total-records. Een for måneden og een for År-til-dato. Man kunne f.eks. bruge Stationsfelt til at angive at der er tale om Måneds-total og År-til-dato Total. For totalerne skal de 2 KM-stand indeholde Km ved periodens start og slut.

13 Resultaterne af workshops
Udviklerne stiller flere spørgsmål til brugerne, før estimat udarbejdes Brugerne begynder at stille spørgsmål til, hvordan de skal udarbejde en kravspecifikation Færre kravændringer i opgaverne efter afholdelse af krav-workshop Deltagerne sætter pris på, at der bruges eksempler fra dagligdagen De bliver mere opmærksomme på vigtigheden af en god kravspecifikation, både brugere og udviklere Større forståelse for, hvorfor det giver god mening af udarbejde rationale og acceptkriterier Det er dog nødvendig at forsætte med initiativer for at fastholde fokus på en god kravspecifikation

14 Software Engineering Mentor
3. december 2018 ? Otto Vinter Software Engineering Mentor & Kaj Henriksen Projektleder KMD-PKF

15 Eksempel fra praksis: ”Fakturabank”
Der laves en ”Fakturabank” på intranettet, hvor servicestationerne selv kan hente brændstofafregninger, fakturaer og kreditnotaer. Fakturabanken deles op i forskellige konti, hvor de særskilte fakturagrupper får deres egen konto. F.eks. Brændstofafregning i en konto og BPA i en anden konto. Løsningen skal sikre, at hver enkelt station kun kan se den specifikke stations fakturaer. Ansatte på hovedkontoret skal have adgang til bilagene for support ved spørgsmål fra servicestationerne Alle bilag skrives ud i PDF-Format. Alle bilag lagres løbende min. 12 måneder i banken.