Kravspesifisering (2): Validering av kravspek er

Transkript

1 Ø Ø SIF Informasjonssystemer Grunnkurs, 2002 Læremål Kravspesifisering (2): Validering av kravspek er Guttorm Sindre, IDI Forstå Kvalitetskriterier for kravspesifikasjoner Viktige steg i prosessen for å validere kravspesifikasjoner Praktiske ferdigheter i å Validere kravspesifikasjoner i samarbeid med andre Men selvsagt ikke perfekt etter dette kurset! Oversikt over forelesningen 1. Hva menes med validering i denne teksten? 2. Kravspek-gjennomganger (reviews) Prosess, deltagere, sjekklister 3. Prototyping + utvikling av brukermanualer 4. Modellvalidering 5. Kravtesting 1. Hva menes med validering i denne teksten? Skiller mellom analyse og validering Beskrevet de riktige kravene? ihht kundens behov! "! # $ #! % & ')( 2 3 * , - 6 ( 7.( 682 3/ 9 : ; < = >? = : 0 1 z{ }8~ { ƒ ˆ Š Œ Ž Š ˆ š œ ž Ÿ š ª «± ² ³ ± ³ µ Beskrevet kravene riktig? ihht standarder / retningslinjer A)B C D E F B GB H I J K L M N OQP R S T S U L R h)i j k l m i ni o p q r s t u vw x y Ç È É Ê Ë Ì Í Î Ï Ð Ñ Ò Ñ Ð Ó Ô Ñ Õ Ö VW X Y Z [ W \W ] ^ _ ` a b c d a e c f g ¹Qº» ¼ ¼ ½ ¾ À Á  ¾ Ã Ä Å Æ Feil, løsninger, hovedproblem Input og output til aktiviteten (fig 4.1) Feil som kan oppdages i kravspek Manglende samsvar med kvalitetsstandarder Dårlig formulerte / tvetydige krav Feil i analysemodeller / problembeskrivelser Kravkonflikter / feil som ikke ble oppdaget tidligere Løsning: fikse problemene før dokumentet vedtas Rene dokumentproblemer: enkelt Rette feilen i dokumentet Manglende forståelse: verre Nødvendig med ny problemanalyse / kravinnhenting? Hovedproblem mhp validering av kravspek øúùîû ü ý þ ùîÿ ù!" # $% & ' $( & ) % $* +, -./ :9 ;=<>?<@:A B C D E F G8D H F I J ÚÜÛ Ý Þß àâá ã ßQä å æçèý éëê ì íîíîïñðîòîó ô õ ö Ikke noe å sammenligne med (kun kundens behov ) 1

2 L N M Validering krever tid! 2. Kravspek-gjennomganger (reviews) Har et kravdokument Ser ferdig ut Dessuten langt, tidkrevende å lese, mange ulike personer må involveres Fristende å storme videre til design aldri tid til å gjøre noe skikkelig, alltid tid til å gjøre det om igjen Dette kan føre til Merarbeid på senere stadier: Omgjøring av krav omgjøring av design Heller: finne mest mulig feil før kravspek vedtas Spare arbeid Redusere irritasjon (i prosjektet, eller hos kunden) Lese igjennom dokumentet for å finne feil Også aktuelt for design, kode etc. Ofte mer effektivt enn testing! Hvorfor?? Krav kan ikke testes, review et vanlig valg Review-prosessen (jfr fig 4.2) Selve møtet 1. Planlegg review Velg deltagere, finn tid og sted 2. Distribuer dokumenter Kravspek ++ distribueres til deltagere 3. Forbered review Deltagere ser igjennom materialet hver for seg Konflikter? Utelatelser? Avvik fra standarder? Hold review-møte Diskusjon av individuelle kommentarer Beslutninger om tiltak 5. Oppfølging av tiltak 6. Revider kravspek-dokumentet Ordstyrer bør ikke ha vært involvert i å lage kravspek-dokumentet Sekretær: notere problemer og vedtak Underveis: Kravansvarlig presenterer ett og ett krav Spør om kommentarer / problemer Problemer samles opp, diskuteres Enighet om aksjoner Anslått tidsforbruk krav per time, samme for forberedelse Dvs: 400 krav validert av 4 persons team: 50 timeverk O Mulige aksjoner som kan vedtas Forhåndssjekking (4.1.1) 1. Oppklaring Kravet er dårlig formulert, eller detaljer er utelatt. Forbedre formuleringen. 2. Manglende informasjon Innhent mer info fra interessenter / andre kilder 3. Konflikt Noen krav er i konflikt med hverandre. Interessenter må forhandle seg frem til en løsning. 4. Urealistisk krav Kravet kan ikke implementeres med gitt teknologi / innen gitte rammer. Må spørre interessenter om kravet skal slettes eller forenkles. Formål: redusere arbeidet til reviewere Fjerne banale feil før review, så denne kan konsentrere seg om mer alvorlige feil Rask sjekk, 1 person Skrivefeil, dokumentformat š p qkr ls mt n o œ ž Ÿ š u v w x y z { } ~} } ƒ Œ Œ Ž ˆ ƒ Š ³ µ ³ ª «µ ±² P Q R S TUQ V Q W XY Z [ \ ] ^ _ ` a Mulige resultat Returnere dokumentet til kravspek-teamet Videresende til review med feil markert b c d e fg h cg i d cj 2 K

3 Å velge deltagere til review (4.1.2) Sjekklister for review Bør ideelt ha Representant(er) for brukere og kunde Ekspert(er) på problemområdet Designer(e) Kravutvikler(e) Fordeler med personer med ulik bakgrunn Ulik kunnskap, ulike evner Kan i fellesskap oppdage flere problemer Ulike grupper kan få forståelse for hverandres behov, redusert krangel ved kravkonflikter Anbefalt gruppestørrelse: 3-10 Evt også møtes på nettet? (ikke nevnt i boka) Mer generelle enn for kode Bør være forståelige for brukere / kunder Gjerne organisasjonsspesifikke basert på prosjekttype og erfaringer Ikke for lang! (< 10 punkter) Eksempel Overordnede kvalitetsmål (fig 4.4) Konkrete spørsmål som kan stilles (fig 4.5) Overordnede kvalitetsmål (1) Overordnede kvalitetsmål (2) Forståelighet Kan leserne forstå hva kravet betyr? Redundans Unødig gjentak av info? Kompletthet Krav som mangler? Info som mangler ihht dok.format? Tvetydighet Begreper / fraser som kan tolkes på flere måter? Vær særlig obs på terminologi avhengig av fagfelt Konsistens Motsigelser mellom krav? Organisering Fornuftig struktur på dokumentet? Annen struktur bedre for forståelse? Samsvar med standarder Er dok. i samsvar med standarder? Evt avvik rettferdiggjort? Sporbarhet Lenker mellom relaterte krav? Lenker til bakgrunnsinfo for avgjørelser? Konkrete spørsmål (fig 4.5) 3. Prototyping (4.2) Unik id (sporbarhet, samsv. Std) Terminologi definert (forståelighet) Krav selv-inneholdt (forståelighet, kompletthet) Begrep brukt ulikt (tvetydighet) Samme tjeneste etterspurt (konsistens, redundans) flere steder? Ulike krav? Referanser til stede? (kompletthet) Relaterte krav gruppert? Eller ref. til hverandre? (organisering, sporbarhet) Vanskelig å forstå krav bare ved å lese dem Prototyper: viser eksempler på kjøring Eliminere misforståelser Ideer til nye krav Valideringsprototype Mål: gi forsmak på realistisk praktisk systembruk Lurt hvis man alt har en innhentingsprototype Ellers neppe verdt kostnad Må være mer komplett enn innhentingsprototype Dvs. videreutvikling nødvendig L M 3 ¹

4 Aktiviteter i prototypebasert validering 1. Velg testere Sluttbrukere med ulike jobber Ikke teknologi-entusiaster 2. Lag test-scenarier Tilfeldig lek med prototypen lite effektivt Må dekke div. vanlige arbeidsoppgaver Sekvenser av handlingssteg som skal utføres 3. Utfør scenarier La bruker jobbe uten hjelp, men observer! 4. Dokumentér problemer / endringsbehov rapportskjema N Annen bruk av prototyper Basis for utvikling av systemtester Handlingssteg her ~ scenarier for prototypebruk (eksekverbar) Back-to-back testing mot ferdig system (eksekverbar) nødleveranse Hvis system ikke blir ferdig innen fastsatt tid Men farlig fristelse! altfor mange prosjekter ender opp med å levere noe som egentlig skulle være en bruk-ogkast prototype... Metoder for prototyping (kap 3) Papir-prototype Magisk ( Wizard of Oz ) prototype Eksekverbar prototype O Utvikling av brukermanualer (4.2.1) 4. Modellvalidering Kan gjøres allerede for prototype Bør inneholde flg info: Hvilken funksjonalitet som er implementert Hvordan denne kan nås gjennom UI Hvilke deler som ikke er implementert Hvordan man skal komme opp etter kræsj Om nødvendig: installasjonsinstrukser Tidlig skriving av brukermanual Nyttig også uten prototype Framtvinger reformulering av krav Forklaringsproblemer: symptom på kravproblemer Systemmodeller inngår gjerne som del av kravspek-dok. F.eks. Prosess-, info-, use case-, objektmodeller Disse bør også valideres Er hver modell internt konsistent? Er ulike modeller konsistente med hverandre? Stemmer modellene med problemområdet / kundens behov? Teknikker for modellvalidering Review, omformuleringer Manuelt... Semi-automatisert... Automatisk Omformulering: DFD tekst 5. Kravtesting (4.4) Navn på prosess Inputs, kilder Navn på hver inn-flyt, og hvor denne kommer fra Selve transformasjonen Hva som gjøres for å konvertere inputs til outputs Outputs Navn på hver ut-flyt, og hvor denne går Kontrollflyt Evt unntaks- eller kontrollinformasjon som er inkludert i modellen Konkret eksempel: fig Betydning: Ikke å teste kravet (først mulig etter implementasjon) Men å vurdere om det er testbart......ved å foreslå mulige tester (test cases) Spørsmål Hvilket bruksscenario kan teste kravet? Inneholder kravet nok info til å definere test? En test nok, eller trengs flere? Kan kravet omformuleres så det blir klarere hva slags tester som er nødvendig? Problemer med å formulere test er symptom på problem med selve kravet 4 º

5 ¼ Rapportskjema for kravtesting Oppsummering Bør inneholde flg info: 1. Kravets ID 2. Relaterte krav (ref.) 3. Testbeskrivelse 4. Kravproblemer 5. Kommentarer, anbefalinger Noen krav er vanskelige å foreslå tester for 1. Systemkrav (dvs systemet som helhet) 2. Eksklusive krav (som sier hva som ikke skal skje) 3. Noen ikke-funksjonelle krav ½ F.eks. Pålitelighet, sikkerhet,... Har gått igjennom Hva krav-validering er Noen retningslinjer for god kravspek Noen teknikker for krav-validering Neste gang OO og krav 5»