Minimodul 2: Kravspecifikation og accepttest - kom.aau.dkkom.aau.dk/~rlo/lectures/systemDesign08/mm2.pdf · - En beslutning var taget om at teste værkets evne til at producere elektricitet

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 sidstKravspecifikationAccepttest

SPU V model

Kravspec.

Programdesign

Procesdesign

Moduldesign

Implementation

Procesintegration

Accept-test

Modultest

Modulintegration

Eksempel – MP3 afspiller

“Lytteren”

MP3 afspiller

Afspil mp3 fil

Vis ID-tag info

Upload af mp3 filer

PC

Forstærkeranlæg

“Uploader”

Relation mellem kravspecifikation og use cases

Nogen Spørgsmål?

Dagens program

Opsummering fra sidstKravspecifikationAccepttest

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

Aftale mellem ”kunde” og ”leverandør” om hvad der skal udvikles (afstemme mål og forventninger)

Enig?!?

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

m.fl.

• Paradoks• Masser af information/vejledninger om udarbejdelse af

kravspecifikation er tilgængelig• MEN de bruges IKKE (altid) !!!!

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 ispecifikationen 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?

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)

Glemte krav vdr. resonans

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

Den skal kunne en masse, være af

god kvalitet og være billig

Hmmmm…..

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 vigtigthjulene og styringkan klare terræn

kørselDet er vigtigt

at bussen er gul

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

IndledningGenerel beskrivelseSpecifikke kravEksterne grænsefladeKrav til ydelseKvalitetskravDesign kravAndre kravDel-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)


Indhold af kravspecifikation – Specifikke krav

• Definitioner• Detailkrav

• identificerbar• reference/begrundelse• prioritering• levetid


Indhold af kravspecifikation – Eksterne grænseflader

• Bruger-grænseflade• Hardware-grænseflade• Kommunikations-grænseflade• Software-grænseflade


Indhold af kravspecifikation – Krav til ydelse

• Tidskrav• Programstørrelse


Indhold af kravspecifikation – Kvalitetskrav

• Pålidelighed• Vedligeholdelses-venlighed• Udvidelsesvenlighed• Brugervenlighed• Genbrugbarhed• Integritet• Effektivitet


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



• Hvad der ikke falder under de andre kategorier



Hvis projektet er opsplittet i del-leveringer• definition af de enkelte leverancer• hvilke specifikke krav der skal

være opfyldt af den enkelte leverance

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

Documents

Minimodul 2: Kravspecifikation og accepttest - kom.aau.dkkom.aau.dk/~rlo/lectures/systemDesign08/mm2.pdf · - En beslutning var taget om at teste værkets evne til at producere elektricitet