Struktureret system udvikling Minimodul 2: Kravspecifikation og accepttest Rasmus L. Olsen, 27 februar 2008
Kursusoversigt og tidsplan Mm1: Introduktion til kursus, UML og use cases (13/2, 2008) Mm2: Kravspecifikation og accepttest (27/2) Mm3: SPU og UML (5/3) Mm4: Design af system (12/3) Mm5: Test design og planlægning (26/3)
Dagens program Opsummering fra sidst Kravspecifikation Accepttest
SPU V model Kravspec. Programdesign Procesdesign Moduldesign Accepttest Procesintegration Modulintegration Modultest Implementation
Eksempel MP3 afspiller MP3 afspiller Lytteren Afspil mp3 fil Vis ID-tag info Forstærker anlæg Uploader PC Upload af mp3 filer
Relation mellem kravspecifikation og use cases
Nogen Spørgsmål?
Dagens program Opsummering fra sidst Kravspecifikation Accepttest
Målet er at. Målet er : IKKE en god kravspecifikation i sig selv MEN et godt produkt Hvorfor så ikke spare kravspecifikationen? Svarer til ønsket om blive millionær satse på at vinde i lotteriet eller arbejde hårdt/smart!
Hvorfor kravspecifikation? #1/2 Enig?!? Aftale mellem kunde og leverandør om hvad der skal udvikles (afstemme mål og forventninger)
Hvorfor kravspecifikation? #2/2 Basis for projektplanlægning Basis for at estimere udviklingsomkostninger Reducere samlede udviklingsomkostninger Grundlag for accepttestspecifikation Grundlag for fremtidige ændringer Forbedret portabilitet (til andre afdelinger/ platforme / etc.)
Hvordan laves en GOD kravspecifikation?
IEEE standarder/anbefalinger Paradoks Masser af information/vejledninger om udarbejdelse af kravspecifikation er tilgængelig MEN de bruges IKKE (altid)!!!! m.fl.
Hvad er en GOD kravspecifikation? IEEE std 830-1998 anbefaler følgende Korrekthed Utvetydig Komplet Konsistent Organiseret efter prioritet/vigtighed Verificerbar Modificerbar Sporbar
Korrekthed En kravspecifikation er korrekt, hvis og kun hvis ethvert krav i specifikationen er noget produktet skal overholde Mangler der nogen krav? Er der unødvendige krav i specifikationen? Er det reelt de krav, som kunden egentlig ønsker skal opfyldes? Glemte krav vdr. resonans On November 7, 1940, at approximately 11:00 AM, the first Tacoma Narrows suspension bridge collapsed due to wind-induced vibrations. Situated on the Tacoma Narrows in Puget Sound, near the city of Tacoma, Washington, the bridge had only been open for traffic a few months. (from http://www.enm.bris.ac.uk/research/nonlinear/tacoma/tacoma.html)
Utvetydig En kravspecifikation er utvetydig, hvis og kun hvis hvert krav har en mening Undgå udefinerede ord: Eksempel: genstartstid på motoren skal være min. 10 min. Hvad er genstartstid? Inkluderer det motoren først stopper, eller er det fra når motoren starter igen? Undgå ord som: tilstræbe, hurtigt, rimelig, så vidt muligt, eventuelt, Problemer kan være/opstå pga. Sprogbarrierer Eks Forskellige opfattelser af krav pga. folks forskellig baggrund Eks Krav repræsentationer/formuleringer Eks
Komplet En kravspecifikation er komplet hvis og kun hvis den inkluderer flg. elementer Indeholder alle betydende krav, hvad enten de hentyder til funktionalitet, ydelse, design begrænsninger, eller eksterne grænseflader. Specifikation af både gyldig og ugyldig input og output Referencer og figurtekst til samtlige figur, tabeller og diagrammer samt definitioner af samtlige termer og måleenheder TBD: To Be Determined Er ok så længe der itereres i udviklingsfasen Det er en god ide at beskrive hvorfor et krav er TBD og hvad der skal til for at ændre TBD til noget konkret Er IKKE ok når produktet afleveres
Konsistent En kravspecifikation er konsistent, hvis og kun hvis ingen underliggende krav er i konflikt med hinanden eller overordnede krav To type inkonsistens Forskellige navne (stophane vs. Lukkeventil) Direkte konflikt (blinkende rød lampe vs. konstant lysende rød lampe) Brug præcist og ikke varierende sprog Hmmmm.. Den skal kunne en masse, være af god kvalitet og være billig
Organiseret efter prioritet/vigtighed En kravspecifikation er prioriteret hvis hvert krav har et nummer tilknyttet, der indikerer vigtigheden af kravet Kræver enighed mellem kunde og leverandør Kunden skal nøjere overveje sine enkelte krav Udviklere skal identificere tidskrav til enkelte opgaver Det er vigtigt at bussen er gul Det er vigtigt hjulene og styring kan klare terræn kørsel
Verificerbar En kravspecifikation er verificerbar hvis og kun hvis hvert krav opstillet kan verificeres Eksempler Ikke målbar: Resultatet af målingen skal være klar uden nævneværdig forsinkelse Programmet må ikke crashe! Intuitiv brugergrænseflade Målbar Resultatet skal i 70% af tilfældene foreligge inden 3 sek. og i 100% af tilfældene efter 7 sek. Programmet skal køre som forventet (overholde funktions bestemte krav) i mindst 99% af anvendelsesperioden Højst 5% af en given test gruppe må finde brugerfladen uoverskuelig
Modificerbar En kravspecifikation er modificerbar, hvis og kun hvis, dens struktur og stil er lavet således at ændringer, tilføjelser og fjernelse af krav ikke leder til inkonsistens eller redundans. Der VIL ske ændringer i krav under projektforløbet! Anvend struktur såsom Indholdsfortegnelse/indeks og logisk numerering Undgå redundans eller afhængige krav Separer krav i stedet for at blande krav sammen
Sporbar Et krav er sporbar hvis det er muligt at spore tilbage hvorfra kravet stammer Baglæns sporbarhed: Hvis krav kan henføres til tidligere specifikationer Forlæns Mulighed for at referere til krav fra fremtidige dokument (entydig identifikation af krav)
Kravspecifikation er en iterativ proces!! - og det er IKKE nemt
SPU check liste (jvf SPU bog side 82)
Bemærkninger Kravspecifikation skal beskrive hvad systemet skal gøre, og ikke hvordan det skal implementeres. Derfor, undgå Designkrav Projektkrav Det er OK at vende tilbage til krav og justere Man bliver klogere under projektforløbet Nogle krav giver pludselig ingen mening Nogle krav viser sig at være urealistiske
Indholdsfortegnelse af krav specifikation Indholdsfortegnelse er kun vejledende - Skal tilpasses de enkelte tilfælde (jeres projekter) Indledning Generel beskrivelse Specifikke krav Ekstern grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering Se SPU-UML note eller IEEE Std. 830-1998
Indhold af kravspecifikation - Indledning Produktets navn Målet for udvikling Identifikation af leverandør og kunde Regler for indføring af ændringer Liste med reference dokumenter Læsevejledning Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Generel beskrivelse Beskrivelse af det totale system Hovedfunktioner vha. Use Cases Begrænsninger Fremtid Brugerprofiler Krav til udviklingsforløb Kundeleverance Forudsætninger (HW, SW, kunderepræsentant) Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Specifikke krav Definitioner Detailkrav identificerbar reference/begrundelse prioritering levetid Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Eksterne grænseflader Bruger-grænseflade Hardware-grænseflade Kommunikations-grænseflade Software-grænseflade Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Krav til ydelse Tidskrav Programstørrelse Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Kvalitetskrav Pålidelighed Vedligeholdelses-venlighed Udvidelsesvenlighed Brugervenlighed Genbrugbarhed Integritet Effektivitet Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Design krav Hver kvalitetsfaktors vigtighed vurderes f.eks. skala 1.. 5 1: ukritisk, 2: ikke særlig vigtig, 3: vigtig, 4: meget vigtig, 5: særdeles vigtig eller MoSCoW skala: Must Should Could Won t Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Design krav Hvad der ikke falder under de andre kategorier Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
Indhold af kravspecifikation Design krav Hvis projektet er opsplittet i del-leveringer definition af de enkelte leverancer hvilke specifikke krav der skal være opfyldt af den enkelte leverance Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering
If It s not tested, it doesn t work!!!
Accepttest Formål : Demonstrere overfor kunden, at produktet er som specificeret i kravspecifikationen. Udførelse : Planlægges, specificeres, designes og udføres af en uafhængig tester eller eventuelt af kunden selv. Generelt: des mere automatiserede en test er, jo bedre test gennemførelse Godkendelse : Godkendt accepttest er ofte betingelse for betaling af de sidste rater.
Indholdsfortegnelse af accepttest Accepttestspecifikationen består af: Indledning Formål Referencer Testens omfang og begrænsninger Godkendelse Testemner Testdesign/test metode
Eksempler på forskellige typer test Stress-test Volumen-test Bruger-test Sikkerhedstest Test på ydeevne Lagertest Konfigurationstest Kompatibilitetstest Pålidelighedstest Fejlbehandlingstest Mere om test og design af test i mm5
Men husk: planlæg jeres test ordentligt! Chernobyl, 26. April, 1986 : - En beslutning var taget om at teste værkets evne til at producere elektricitet nok til at drive værkets sikkerhedssystem i det tilfælde den eksterne el forsyning forsvandt. - En lang række af omstændigheder ikke taget i betragtning under testen, ledte til nedsmeltningen af reaktor 4 på kraftværket - Konsekvenserne ses stadig i dag og er meget virkelige på mange mennesker. En del er også døde som direkte og indirekte følgevirkning
Opsummering En god kravspecifikation har følgende karakteristika Korrekthed Utvetydig Komplet Konsistent Organiseret efter prioritet/vigtighed Verificerbar Modificerbar Sporbar Kravspecifikation leder op til accepttest Det er IKKE let at lave en god kravspecifikation, og kræver iterationer
Et ord om review process og andre informationer Foreslået delegering af review: Gruppe 410 og 411 reviewer Gruppe 412 Gruppe 411 og 412 reviewer Gruppe 413 Gruppe 412 og 413 reviewer Gruppe 414 Gruppe 413 og 414 reviewer Gruppe 415 Gruppe 414 og 415 reviewer Gruppe 410 Gruppe 415 og 410 reviewer Gruppe 411 Sørg for at være konstruktive og ikke destruktive i jeres kritik Det er meningen i skal hjælpe hinanden! Reviews vil indgå som en del af opgaveregning Skabelon til udfyldning af review vil blive tilgængelig på kursets hjemmeside snart PDP: Vi skal holde en individual eksamen for jer, men jeg anbefaler at i deltager i opgaveregningen trods alt
Opgaver Opstilling af krav til jeres projekt baseret på use case fra sidste gang Fortsættelse af analysedokument