Struktureret system udvikling Minimodul 3: Kravspecifikation og accepttest

Transkript

1 Struktureret system udvikling Minimodul 3: Kravspecifikation og accepttest Rasmus L. Olsen, 7 februar

2 Dagens program Introduktion Kravspecifikation Gennemgang af hvad der karakteriserer en god/dårlig kravspec Indhold i en kravspecifikation Relation til use case diagrammer Accepttest Relation til kravspecifikation Opgaver 2

3 SPU V model Kravspec. Programdesign Procesdesign Moduldesign Accepttest Procesintegration Modulintegration Modultest Implementation 3

4 Eksempel MP3 afspiller MP3 afspiller Lytteren Afspil mp3 fil Vis ID-tag info Forstærker anlæg Uploader PC Upload af mp3 filer 4

5 Relation mellem kravspecifikation og use cases 5

6 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! 6

7 Hvorfor kravspecifikation? #1/2 Enig?!? Aftale mellem kunde og leverandør om hvad der skal udvikles (afstemme mål og forventninger) 7

8 Hvorfor kravspecifikation? #2/2 Basis for projektplanlægning Basis for at estimere udviklingsomkostninger Reducere samlede udviklingsomkostninger Prioritering af projekt elementer Grundlag for accepttestspecifikation Har vi nået vores mål? Grundlag for fremtidige ændringer Forbedret portabilitet (til andre afdelinger/ platforme / etc.) 8

9 Hvordan laves en GOD kravspecifikation???? 9

10 IEEE standarder/anbefalinger Paradoks Masser af information/vejledninger om udarbejdelse af kravspecifikation er tilgængelig MEN de bruges IKKE (altid)!!!! m.fl. 10

11 Dagens program Introduktion Kravspecifikation Gennemgang af hvad der karakteriserer en god/dårlig kravspec Indhold i en kravspecifikation Relation til use case diagrammer Accepttest Relation til kravspecifikation Opgaver 11

12 Hvad er en GOD kravspecifikation? IEEE std anbefaler følgende Korrekthed Utvetydig Komplet Konsistent Organiseret efter prioritet/vigtighed Verificerbar Modificerbar Sporbar Uploader Lytteren PC MP3 afspiller Afspil mp3 fil Vis ID-tag info Upload af mp3 filer Forstærker anlæg 12

13 Hvordan udleder vi krav? ATM skal kunne læse Bruger ATM ATM information skal System fra kort Delkrav; kunne visning af PIN 1) Indsætter kort 2) Læser modtage input skal fra ske med * magnet/chipbruger Delkrav; kun tre forsøg 4) Indtaster PIN 3) Spørger om PIN 8) Trykker knap for hæve 10) Indtaster beløb 11) Trykker OK 5) Verificerer PIN og kunde 7) Viser menu 6) Henter muligheder 9) Spørger efter mængde 14) Trykker JA 12) Vis mængde 13) Spørger om udprint 17) Tager kvittering 16) Printer kvittering 19) Tager kort 18) Spytter kort ud 21) Tager penge 20) Spytter penge ud Og så videre og så videre 11) Valider mængde og subtraher 15) Henter historik 13

14 Korrekthed En kravspecifikation er korrekt, hvis og kun hvis ethvert krav i specifikationen ikke er umulige Forkerte parametre på krav - hastighed mindre end 3 DKR/banan??? Måske der menes 3 bananer per sekund? Forkert beskrivelse af den fysiske situation - Operatøren skal have tre arme??? Krav kan kun opfyldes under bestemte betingelse - Når månen, solen og planeterne står i en helt unik position... Hvor tit sker det lige? Kræver operationer der ikke er i overensstemmelse med realiteterne - Windows 7 skal køre på platformen (platformen = Arduino) Referencer til ikke eksisterende funktioner, input eller output 14

15 Utvetydig En kravspecifikation er utvetydig, hvis og kun hvis hvert krav har en mening Undgå udefinerede eller uspecificerede ord: 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? Spillet skal være kompatibelt med DirectX Hvilken version? Stiller versionen således også krav til Windows version? Undgå ord som: tilstræbe, hurtigt, rimelig, så vidt muligt, eventuelt, Hvad vil det sige at være rimelig hurtig? 15

16 Utvetydig Problemer kan være/opstå pga. Sprogbarrierer Er et skib er det en lystyacht, en stor færge eller noget andet Forskellige opfattelser af krav pga. folks forskellig baggrund For flyingeniøren er km/h en realistisk hastighed, mens raketingeniøren er det nærmere 11 km/s!! Krav repræsentationer/formuleringer SCMF skal automatisk vælge en CA der skal fungere som CMN i et PN cluster 1 Pound force eller 1 Newton...?? Mars Orbiter crashede pga. Forveksling Pris : Millioner dollars 16

17 Det tager de sig af 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 + = Det tager de sig af 17

18 Hmmm... Jeg syntes der mangler noget Komplet 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 18

19 Komplethed: Glem ikke det omgivende miljø! Mangler der nogen krav? Er der unødvendige krav i specifikationen? Er det reelt de krav, som kunden egentlig ønsker skal opfyldes? Anvend use case diagrammerne som en slags checkliste 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 19

20 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 Hmmm.. ~10 mio kr ~nm nøjagtig?? Den skal kunne en masse, være af god kvalitet og være billig 20

21 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 21

22 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 22

23 Verificerbar Bare rolig, den er ikke crashet endnu... 23

24 24

25 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 25

26 NB! Advarsel mod modifikationer i krav Forestil jer flg. samtale mellem udvikler og (marketings)chef Windows 95? You're kidding, right? People stopped using Win95 over a decade ago! What? We're building this app with.net 3.0 and we're already 40% done! Have a nice weekend! By the way, I forgot to mention that the application has to be compatible with Windows 95 Oh, and Mac OS 7.6 too. Why didn't you tell us this before we started? You're half done? That's great! Oh, and I forgot to mention we need compatibility with the Atari ST. Gee, thanks. Sorry. I forgot. It's no problem to change it now, right? Ref: 26

27 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) Hvorfor bruger vi krudt på noget der ikke stilles krav til??? 404 Error 27

28 Kravspecifikation er en iterativ proces!! - og det er IKKE nemt 28

29 Check liste (jvf SPU bog side 82) 29

30 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 30

31 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

32 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 32

33 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 MP3 afspiller Afspil mp3 fil Lytteren Vis ID-tag info Forstærker anlæg Upload af mp3 filer Uploader PC 33

34 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 34

35 Indhold af kravspecifikation Eksterne grænseflader Bruger-grænseflade Hardware-grænseflade Kommunikations-grænseflade Software-grænseflade Styring Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering A/DC rutine A/DC 35

36 Indhold af kravspecifikation Krav til ydelse Tidskrav Hukommelsesforbrug Strømforbrug Processorkraft Netværkstraffik Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering 36

37 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 37

38 Indhold af kravspecifikation Design krav Hver kvalitetsfaktors vigtighed vurderes f.eks. skala : 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 38

39 Indhold af kravspecifikation Design krav Hvad der ikke falder under de andre kategorier Lovmæssige krav Produktion Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering Miljøkrav Økonomiske krav 39

40 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 X tid E E L Leverancetid Y tid L Z tid E E E Indledning Generel beskrivelse Specifikke krav Eksterne grænseflade Krav til ydelse Kvalitetskrav Design krav Andre krav Del-levering 40

41 If It s not tested, it doesn t work!!! 41

42 Dagens program Introduktion Kravspecifikation Gennemgang af hvad der karakteriserer en god/dårlig kravspec Indhold i en kravspecifikation Relation til use case diagrammer Accepttest Relation til kravspecifikation Opgaver 42

43 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. 43

44 Indholdsfortegnelse af accepttest Accepttestspecifikationen består af: Indledning Formål Referencer Testens omfang og begrænsninger Godkendelse Testemner Testdesign/test metode 44

45 Eksempler på forskellige typer test Stress-test Volumen-test Bruger-test Sikkerhedstest Test på ydeevne Lagertest Konfigurationstest Kompatibilitetstest Pålidelighedstest Fejlbehandlingstest 45

46 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 46

47 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 47

48 Dagens program Introduktion Kravspecifikation Gennemgang af hvad der karakteriserer en god/dårlig kravspec Indhold i en kravspecifikation Relation til use case diagrammer Accepttest Relation til kravspecifikation Opgaver 48

49 Opgaver Lav eller organiser et system der kan være behjælpelig med krav i jeres projekt. I den process bør i tage relevante spørgsmål op som er gennemgået i forelæsningen. Her er nogle eksempler på spørgsmål: Hvordan sikrer i jer at kravene er konsistente og korrekte? Hvad er relationen til jeres use case diagrammer Hvordan refererer i internt til jeres krav? Hvordan sikrer i jer at man kan følge krav fra use cases til kode eller hardware komponenter? Hvordan håndterer i kravafhængigheder? Hvad sker der når et underkrav ændres? Hvordan indikerer i prioritering af kravene og sikrer sig alle i gruppen er enige og hvis der er en kunde, hvordan sikrer i jer kunden er enig? Hvordan sikrer i jer at kravene kan testes? I jeres minisystem eller organisering, hvordan reltaterer i jeres krav til jeres accepttest? Med udgangspunkt i de use cases i arbejdede med sidst, lav første udkast til en række krav og udnyt jeres struktur/system/organisering fra opgave 1 til at beskrive kravenen. 49