1. Introduksjon: veileder til bruk av White Paperet
Hva er formålet med White Paperet?
Formålet er å spre kunnskap og øke kompetanse ute i prosjekter. Som en seriøs og relevant leverandør i det norske
markedet bør man strekke seg etter å kontinuerlig forbedre seg på å gjennomføre prosjekter og samarbeid med
kunder. White Paperet skal bidra til å høyne forståelse og kvalitet rundt kravprosessene i et IT-prosjekt. Å høyne
kvaliteten av kravhåndtering vil kunne gi store gevinster for kunden, teamet og leverandør. Det introduserer leseren
for et rammeverk, utviklet av Suzanne og James Robertson, basert på deres kurs ’Mastering the Requirement
Process’.
Hvorfor er dette rammeverket et viktig verktøy?
Det bidrar til en felles og økt forståelse blant de involverte i prosjekter, samt kvalitetssikring av funksjonalitet og krav.
Å benytte seg av rammeverket reduserer misforståelser, lavere risiko for feilretting og overskridelser på tid og kost.
I tillegg vil det lede til færre misfornøyde kunder og utviklingsteam.
Hva kan man forvente å få ut av White Paperet?
I tillegg til økt kunnskap og utruste deltakere i IT-prosjekter til å ta flere kvalitetshevende grep, vil man bli introdusert
for ulike tips og teknikker for håndtering av krav i lys av de viktigste delene av prosjektløpet. Dette er enkle tips og
teknikker som kan tas i bruk umiddelbart uten at det krever noen særlig form for opplæring. White Paperet tar for
seg 7 prosesser/deler av et prosjektløp, spesielt utvalgt på grunn av relevansen og gevinsten som kan hentes ut av
disse prosessene.
Hvilken målgruppe er White Paperet ment for?
Det passer aller roller og deltakere i et IT-prosjekt, samt salgs og markedsapparat. Både kunde og leverandør vil ha
nytte av kunnskapen om rammeverket ’Mastering the Requirement Process’.
2. Mastering the Requirement Process, -et rammeverk
Hva består dette rammeverket av og hvorfor er det et godt
egnet verktøy for ditt IT-prosjekt?
• Dette er et rammeverk med konkrete aktiviteter og teknikker i
hvert prosessledd som er ment å bidra til kvalitetssikring av IT- Leveranse
prosjekter. Rammeverket kan anvendes på ulike stadier i
prosjektløpet. Det fungerer som en MAL som kan splittes opp. Testing
• Man skal ikke trenge å bruke det slavisk. Rammeverket kan Utvikling
Krav
også benyttes som et analyseredskap i å forstå prosjektet, en
kunde, utviklingsprosjekt f eks gjennom tilbudsskriving etc. Backlog
• Ved å legge et godt fundament gjennom kartlegging og
forståelse av krav, vil man oppnå riktigere utformede og mer Forarbeid til krav
presise krav. Dette fører igjen til et mer presist produkt for
kunden, færre feilrettinger og endrede krav. Kravene blir lettere
å teste og gir større grad av kundetilfredshet. Et godt forarbeid danner grunnlag for
alle fasene gjennom prosjektet.
Likeledes vil et dårlig arbeid med
• Rammeverket tilbyr veldefinerte krav og utforming av kravspesifisering, påvirke og komplisere
’kravkort’ hvor et måle og -testkriterie brukes. Dette vil tilføre arbeidet i de ulike fasene.
synlighet og målbarhet på om kravet innfrir funksjonalitet og
mål.
3. Livsløpet til et krav
Test
Mål/
testkriterie
Krav / Backlog (BL) til utvikling –
’Kvalitetssikret’
Fundament: mål, analyse og behov,
spesifisering/utforming av krav og kravarbeid med
kunden
Prosjektløp / Sprint
Kort beskrivelse av figuren ovenfor:
Arbeidsløpet kan sees på som en sprint,
del av prosjektet eller et prosjektløp
Her jobber man med (og uten kunde) for å legge
fundamentet som vil sikre gode krav. Definerer Ved utforming av Dette fører til at testere,
mål, behov og utforming av krav. Denne leder til utviklere og kunden har en
Krav krav/BL
krav og BL men underveis kan det også være felles forståelse på hvorvidt
inkluderes man har oppnådd kravets
behov for å kartlegge ytterligere hvor flere krav mål/testkriterie hensikt.
kommer til.
4. Rammeverket kan benyttes i gjennom hele prosjektløpet eller for enkelte deler
Start
Kap. 2, kursheftet
5. Hvordan kan jeg benytte rammeverket?
Det kan benyttes i de fleste prosesser og deler av et prosjektløp men det er mest hensiktsmessig å kvalitetssikre
prosjektet med rammeverket i den første halvdelen av prosjektet. Dette legger et godt fundamentet for utledede
krav og vil dermed bidra til å kvalitetssikring. De viktigste prosessene og delene for rammeverket man bør jobbe med
og kvalitetssikre er:
1. Hva er bakgrunnen for prosjektet? Hva er behovet? Business Case?
2. Fundament for krav og funksjonalitet:
• Goal / Mål
• Scope / Omfang
• Stakeholders / Interessenter
3. Begrensninger / forutsetninger
4. Bruk av Use Case for å forstå en organisasjon, business case, virksomhet
5. Avdekking funksjonalitet/behov/krav ved hjelp av ulike arbeidsmetoder/fasilitering
6. Utleding og utforming av krav
7. Målekriterie og involvering av testere
I alle de ovenstående punktene og prosessene arbeides med metoder og teknikker som blir presentert
i White Paperet. Prosessene følger en naturlig rekkefølge i prosjektet.
Når du ser dette symbolet betyr det tips eller teknikk som kan benyttes!
Du kan komme inn på de ulike delene av prosjektløpet og likevel ta rammeverket i bruk.
F eks om du starter opp i et prosjekt hvor kravspesifikasjon foreligger, jobb med kunden i utforming og
kvalitetssikring av kravene ved å benytte mal for utforming av krav eller revidere status/nå-situasjon i
prosjektet ved en gjennomgang av prosesstegene.
Ikke bare godta en kravspesifikasjon som den er!
6. 1. Hva er bakgrunnen for prosjektet, bestillingen?
Det er alltid en hensikt og motivasjon bak igangsetting av et prosjekt som skal lede til en løsning, produkt, system og
lignende. Sørg for at det er klart og tydelig HVORFOR bestillingen av prosjektet er foretatt. Dette bør være en
overordnet forståelse for alle i teamet. Man kan f eks benytte seg av en kort prosjektbeskrivelse eller
prosjektmandat, denne vil danne bakgrunn for retning av prosjektet og fortelle om hensikten. Det vil ofte gjerne
lønne seg med en beskrivelse av nå-situasjonen som supplerer og klargjør motivasjonen.
2. Fundamentet som kravene bygger på
Dette er sammensatt av typisk 3 faktorer; mål / målbildet, omfang og Interessenter. Disse defineres og kartlegges
sammen med kunde.
Omfang: definerer utstrekningen / graden av
Omfang
hva som kreves i behovskartlegging og arbeidet
med prosjektet. Hva skal prosjektet omfatte.
Prosjektbeskrivelse.
Mål: definerer og
måler hensikten for Mål Interessenter Interessenter: Enhver person som har en
prosjektet. Hva skal interesse, involvering eller rolle i
det føre til? kravene.
I ethvert prosjekt er det kritisk at involverte kjenner til de 3 faktorene. Hvordan kan du så avdekke
disse elementene?
7. Omfang
Å definere omfanget av prosjektet/løsningen/produktet er kritisk for å kunne forstå det. Ved å definere omfang defineres
samtidig mye av rammene. Ofte er første skritt å definere et prosjektmandat. Neste skritt vil være sette omfang for hva
som skal inngå i arbeidet mot en kravspek. Det må avgrenses HVA som skal inkluderes i kartleggingen av behov og krav, og
hva som skal holdes utenfor. Dette kan være å forstå virksomheten, kundens prosesser, organisasjonen og brukerne og de
relasjonene den utgjør, i tillegg til å forstå informasjonen og kunnskapen som utgjør kundecaset. Til hjelp med avgrensing
kan man benytte seg av å sette opp et Rikt Bilde, se eksempelet under. F eks så holder du eksterne system utenfor dette
elementet. Dette kommer du tilbake til i kontekstmapping og interessenter.
En mangelfull forståelse av omfang kan lett føre til uklarheter, og lede til en mindre presis og hensiktsmessig
løsning for kunden.
Sett opp et
Rikt Bilde hvor du
Eksempelet til mapper opp VIKTIGE
venstre på et prosesser, aktiviteter og
Rikt Bilde, faktorer for virksomhetens
illustrerer et arbeid. Dette bildet vil hjelpe
deg å ikke kun forstå kunden,
kundecase som men også definere de
kartlegger arbeid eksterne systemene og viktig
med samhandling/informasjon.
strøing/avising Dette bildet avgrenser
av veier. omfanget slik at du får
klarhet i de faktorene og
prosessene du skal fokusere
på for å kunne lage din
løsning/produkt for kunden.
S. 44, læreboken
8. Interessenter
Er hvem som helst som har en interesse i løsningen, produktet etc.
De kan bygge det, bruke det, være affektert av det, inneha kunnskap man trenger for å lage det, eie det etc.
Fravær av involverte interessenter medfører mangler i krav, og derfor økt risiko for en feil og upresis løsning.
Sett opp et
interessentkart,
som illustrert til
venstre, hvor du
inkluderer aktører og
interessenter fra
kjerneteamet og ut til
eksterne
elementer/aktører på
utsiden av prosjektet.
Kartet bidrar til
oversikt, økt forståelse
og vil hjelpe deg med
definering og
forståelse av mål og
målbildet.
Kap. 2, kursheftet
9. Kontekstkart (mapping): skaff deg en oversikt over 3. partssystemer og andre
samhandlende løsninger/applikasjoner. Dette kan også være et Use Case.
Data generert av arbeidsmiljø
Eksternt
Eksternt system
Sett opp et
system
kontekstkart som
kartlegger Bruker
samhandling for en så
fullstendig oversikt
som mulig. Bruker Produktet
Eksternt
Arbeidsmiljøet
system
Datainput fra ytre miljø
10. Målbildet
Prosjektbeskrivelsen inneholder ofte et overordnet mål og definert behov for prosjektet. Målet kan ofte være
hårete (urealistisk, vanskelig å forstå eller ikke målbart). Det er derfor viktig å definere et realistisk og testbart
mål. Målet(ene) skal fortelle hva prosjektet skal lede til, eks forbedre arbeidsflyt&prosesser, effektivisere drift /
produkt eller skape gevinst, tilpasse seg nye lover og regler etc. Et ”Målkort” supplerer prosjektmandatet og
beskrivelsen.
Målbildet hjelper deg å prioritere og styre ditt arbeid mot de kravene som vil være riktig og viktigst, for å oppnå
mest mulig hensiktsmessig og lønnsom løsning for kunden!
Definer
målet som noe testbart
og etterprøvbart PAM
(Purpose, Advantage,
Measurement) som
signaliserer tydelig HVORFOR
prosjektet kjøres (behovet),
HVA skal det bidra til, oppnås
og HVORDAN ser man
løsningens effekt og måler
hvorvidt det oppfyller de
andre to kriteriene. HVA skal
være ”målbart”, (setning, tall,
kalkyle, modell, graf etc).
Kap. 2, kursheftet
11. 3. Begrensninger i rammebetingelser og løsning
Rammeverket anbefaler å utarbeide en uttømmende oversikt over begrensninger.
’Overordnede’ begrensninger er gjerne rammebetingelser for prosjektet, som tid og kost. I denne forbindelse
utarbeider man også egen risikoanalyse/matrise som benyttes løpende med korrektive tiltak underveis i prosjektet.
Dette er en viktig form for kvalitetssikring (rammeverket tar ikke for seg og fokuserer ikke på risikoanalyse som
område i utstrakt grad).
Andre begrensninger og forutsetninger som er konkret knyttet opp mot krav og løsningen, ’løsningsbegrensninger’,
kartlegges blant annet gjennom å benytte ’rikt bilde’, ’kontekstmapping’ eller de kan oppstå underveis. Ved å gjøre et
så grundig forarbeid som mulig, unngår man i størst mulig grad at uventede forutsetninger dukker opp underveis,
spesielt etter at løsningen er designet og kravene foreligger.
Løsningsbegrensninger kan avdekkes ved å inkludere personer med kunnskap om samhandlende system,
roller/brukere, ledelse/produkteier, foreta avklaringer og ikke basere seg antakelser og forutsetninger, kjøre reviews
og lignende. Dette forarbeidet kvalitetssikrer krav og unngår i større grad feilrettinger. Arbeidet kan gjerne gjøres
som en iterativ prosess i prosjektet, hvis krav og utarbeidelse av løsningen er lagt opp til et slik løp underveis i
prosjektet.
Kjør en aktiv analyse hvor du plasserer den informasjonen du har gjennom andre
aktiviteter som f eks ’rikt bilde’, ’kontekstkart’ og lignende.
Dette gir deg et klarere og en mer enhetlig oversikt, også overfor kunden, enn om du
forvalter informasjon som er spredt på ulike steder, ulike dokumenter etc. Analysen kan
sees på som en kontrollsjekk opp mot backlog og kravspesifiskasjonens utforming.
12. 4. Use Case for å forstå en virksomhet eller business case
Use Case (UC) er nyttig for å forstå en virksomhet. Det kan være rollebasert UC som tar utgangspunkt i ulike roller i
en virksomhet, eller situasjon/handlingsbaserte UC ift en prosess eller arbeidsflyt. Ved å benytte det kartlagte ’rike
bildet’ kan man dele dette opp i UC slik at man får inkludert relevant informasjon og detaljer. Kontekstkart er f eks
ofte en grei måte å visualisere et UC på i tillegg til tekst. Ved store prosjekter bør man dele opp UC i Business Events
(BE) som er selvstendige hendelser/prosesser som skjer innenfor UC. BE kan sees på som en form for utvidet User
Story som sier noe om hva og hvorfor for å beskrive delprosesser, handling eller arbeidsflyt. Den tar utgangspunkt i at
hendelsen avgir en gevinst, oppnår et resultat eller fører til en relevant aktivitet som beskriver sammenhengen i UC.
Data generert av arbeidsmiljø
Mange prosjekter benytter seg ikke av en systematisk
tilnærming som denne metoden, kontekstkart, for å Eksternt
Eksternt
system
forstå en virksomhet. Det resulterer ofte i at relevant system
informasjon utelates. Kommer man inn i et prosjekt Bruker
og har behov oversikt, vil denne systematiske
tilnærmingen være klargjørende. Bruker Produk
tet
Kontekstkart bør også anvendes som kvalitetssikring Eksternt
system Arbeidsmiljøet
og teknikk for en allerede ferdig utformet kravspek
som leverandøren mottar, ved tilbudsskriving eller for Datainput fra ytre miljø
å generelt forstå kunden/virksomheten.
= Business Event
13. 5. Avdekking av funksjonalitet og krav ved hjelp av ulike arbeidsmetoder/fasilitering
Dette er et kritisk ledd i kvalitetssikringen av en utviklingsprosess. Rammeverket skiller her tydelig mellom hva som
er et krav og LØSNINGEN på kravet. Selve utformingen og hva som utgjør forskjellen vil beskrives ytterligere i neste
punkt, men krav beskriver BEHOV som eksisterer/oppstår for å skulle oppnå et mål eller resultat. Et krav eller en
funksjon beskriver en handling/aktivitet/prosess og gjennom behovskartlegging og workshops avdekkes HVA og
HVORFOR kravet skal eksistere. Det viktigste er ikke bare å avdekke krav, men å gjøre det på en hensiktsmessig måte
slik at HVORFOR er synlig og forståelig.
Man skal ikke kun avdekke kravene, arbeidet skal resultere i et riktig sett av krav.
Alt for mange kravspesifikasjoner kvalitetssikres i for liten grad slik at det utvikles unødvendig , upresise eller feil krav
underveis. Dette punktet tar kort for seg ulike metoder for innsamling og avdekking av krav og funksjonalitet.
Hva er viktig å tenke på ved analyse og kartlegging?
• Tilpass arbeidet ift størrelsen på prosjektet. Ved små prosjekter er det viktig å få med seg essensen i HVA
som er problemet, før man gyver løs på løsningen. Det er lett å tro at ved mindre prosjekter danner man seg raskt en
oversikt. Fallgruben i små prosjekter er ofte at utviklerne blir for ivrig og kjører på med å utvikle løsning, siden
prosjektet i seg selv tilsynelatende tenderer til å være enklere å håndtere.
• I mellomstore og store prosjekter vil intervjuer, workshops, ’rike bilder’, UC være viktig å ta seg tid til. Store
prosjekter involverer mange interessenter og krever gjerne utstrakt grad av dokumentasjon som ledd i
kvalitetssikringen.
• Bruk kontekstkart aktivt for å få en oversikt over hvilke roller/prosesser/samhandling som skal studeres i kartlegging
av krav.
• Ikke vær for produktsentrert eller kun prosessentrert i analysen, prøv å se ting utenfra og inn. Det er er lettere å
tenke nytt og se nye muligheter hvis prosesser hektes til resultatet for omverdenen eller utenfra.
• Oppgaven er å omsette kunnskapen som brukere og interessenter forteller om systemet og virksomheten til krav.
Også nye krav som hjelper og forbedrer virksomheten og dens brukere/interessenter.
14. Kort oversikt på litt ulike kartleggingsteknikker (se læreboken for utfyllende beskrivelse):
Modellering av prosess/arbeidsflyt på nå-situasjonen: Ikke i ned til den minste detalj men med fokus på hva som
er relevant for produktet eller løsningen. Denne metoden er nyttig når du trenger forståelse for og oversikt over et
medium-stort ’arbeidsområde’ eller del av virksomheten som ikke er dokumentert.
Hospitering: Observere en bruker i sitt arbeid for å forstå hva og hvorfor arbeidet gjøres. Man observerer, stiller
spørsmål, gjør kanskje noe av arbeidet under brukerens påsyn og overvåkning. Denne metoden er effektiv sammen
med modellering (punktet ovenfor) som skjer underveis. Viktig å være observant på at informasjonen fra dagens
arbeidsflyt/system skal omsettes ved å tillate seg å stille spørsmålstegn. Hospitanten kan foreslå endringer som
bruker kan gi tilbakemelding på .
Intervjuer: Veldig nyttig måte å samle informasjon rundt krav på i prosjekter. Er mest effektiv når den benyttes
sammen med andre teknikker, f eks som modellering. Teknikken fungerer bra hvor brukere er veldig tydelig og
bevisste på hvilke krav som er viktige. Unngå helst å bruke denne isolert alene. Den bør helst anvendes med annen
teknikk som utgangspunkt f eks UC eller kontektskart/rikt bilde. Få gjerne bruker til å tegne eller endre modellene
slik at ’skjult’ informasjon lettere kan avdekkes.
Workshops (WS): Dette kan være gruppearbeid på UC, ulike former for scenario (scenario er beskrivelse av arbeid
som gjøres, kan være fremtidsscenario, Hva-Hvis scenario, Negative scenarioer). Andre eksempler er kreativitets WS
og brainstorming WS som fungerer bra for produkt og konseptutvikling. WS er en effektiv og nyttig måte å samle
informasjon på. Gjennom WS avdekkes gjerne krav fra ulike interessenter som igjen kan bidra til en økt forståelse
deltakerne i mellom.
Personas: Er en kunstig (virtuell) bruker, rolle eller karakter som representerer brukere/publikum. Utgangspunktet
for utforming av personas er f eks spørreundersøkelse eller intervju. Nyttig hvis f eks brukere ikke er tilgjengelig og
man tilegner attributter for karakteren som matcher publikum el brukere av din løsning, produkt eller lignende.
Hvorfor nyttig? – fordi det er mer hensiktsmessig å ha en imaginær karakter som målgruppen din enn å prøve
finne all mulig slags krav som gjelder for alle tenkelige brukere av din løsning/produkt.
15. Gapanalyse: Nå-situasjonen opp mot fremtidsversjon. Analysen er rommet i mellom, hvordan komme seg fra A til
B? Hvordan gjør vi ting i dag og hvordan kan vi gjøre ting i fremtiden?
Tankekart: Effektive og oversiktelige for bruk som ide-myldring, se sammenheng, ta notater, dokumentasjon i WS
og lignende. De er svært hensiktsmessig for å organisere tanker og systematisere innhold. F eks etter intervjuer eller
WS.
Wiki, blogger og diskusjonsforum: Involverer brukere men krever større grad av administrering og overvåkning.
Egner seg best i større prosjekter. Folk liker å bidra og hvis bidragene til dels er anonymisert kan dette være en lavere
terskel for enkelte roller eller brukere som er viktig for å avgi informasjon.
Til høyre er en
oppsummert tabell
over de mest utbredte
kartleggingsteknikkene
som kort beskriver
styrken til hver enkelt
teknikk. For mer
detaljert informasjon
om teknikkene, se
læreboken.
Kap. 3, kursheftet
16. 6. Utforming av krav
Rammeverket skiller mellom to typer krav, funksjonelle krav og ikke-funksjonelle krav.
Funksjonelle krav beskriver hva løsningen/produktet må gjøre for å tilfredsstille eller utføre et type arbeid, aktivitet
eller prosess som er nødvendig for virksomheten. De beskriver ofte HVA som skal skje, eller må gjøres. Funksjonelle
krav oppstår ofte fra UC som f eks kan beskrive en prosessflyt. Det er f eks egnet å detaljere i trinn.
Ikke-funksjonelle krav er KVALITETER eller EGENSKAPER som løsningen/produktet ditt må ha. Hvor godt utføres det
systemet el løsningen skal gjøre?Det er disse kravene som avgjør om løsningen eller produktet er attraktivt,
brukervennlig, raskt, stabil etc. Ikke-funksjonelle krav har gjerne attributter som utgjør forskjellen på hvor godt likt og
attraktivt et produkt er selv om det kan være andre produkt som funksjonelt sett er bedre eller mer dekkende for
behovet. Eksempler på produkter og løsninger som har hatt suksess på basis av ikke-funksjonelle krav er Apple,
Samsung, Amazon, Gmail etc.
Det er flere typer Ikke-funksjonelle krav, se under. For fyldig beskrivelse, se læreboken:
S. 175, læreboken
17. Hvordan beskrive krav og bruke ’Kravkort’
Ofte er spesifikasjoner en liste av krav som eventuelt er gruppert. De kan være kort beskrivende og utformet
som user stories, men mangler ofte en litt mer nyansert detaljering som kan utgjøre forskjellen på å forstå eller se
sammenheng i kravet. Et kravkort/kravkorttabell vil hjelpe deg med å visualisere oversikt. Under følger et eksempel,
se læreboken for ytterligere detaljer.
• Kravnummer *
• Kravtype*
• Basert på UC, scenario eller personas*
• Beskrivelse av kravet, HVA*
• Beskrivelse (Rationale) på HVORFOR*
• Utløper det fra en rolle,
arbeidsområde, interessent?*
• Kravets mål, et testbart målekriterie*
• Rating fra brukere
• Andre krav som kan skape konflikt
• Prioritet for kravet, f eks Må, Bør,
Høyt, Medium etc *
• Med mer
De viktigste elementene i kravkortet er
merket med * og beskrives kort på
neste side.
S. 454, læreboken
18. En beskrivelse av de viktigste punktene som kravkortet bør inneholde:
• Kravnummer: nummeret på kravet
• Kravtype: f eks funksjonelt eller ikke-funksjonelt eller
typebenevnelse som sikkerhetskrav el brukervennlighet
• Hva kravet er utledet fra: UC, sub-UC el prosessdel av UC,
scenario eller personas
• Beskrivelse: på HVA som skal gjøres av systemet, produktet,
løsningen etc.
• Grunnlaget for kravet: HVORFOR og HVORDAN det bidrar, altså
hensikten. Tilfører forståelse for kravets eksistens.
• Opprinnelse, hva eller hvem skal det tjene: oppstod kravet fra en
rolle, arbeidsområde, interessent osv.
• Kravets mål, et testbart målekriterie: kvantifiserbart mål som
kravet/løsningen må oppfylle
• Prioritet for kravet: f eks Må, Bør, Høy, Medium etc Kundens
signalisering om viktigheten av kravet
S. 454, læreboken
Eksempel -En online nettbutikk for kjøp av elektronisk musikk
skal etableres og utvikles. Eksempelet tar utgangspunkt i at kun kjøpere fra autoriserte land kan handle
fra nettbutikken. Noen av hovedelementene på kravkortet:
Beskrivelse – produktet/løsningen skal verifisere at kjøperen har logget seg på fra et land som er autorisert for
varekjøp.
Grunnlag for kravet (Rationale) – musikk må ikke leveres til land som ikke har en rettslig avtale i orden for kjøp av
musikk. Dette er viktig på grunn av rettigheter og lisensiering.
Opprinnelse – Jan Johansen, Juridisk enhet
Kravets mål – All nedlastning vil kun gå til godkjente land på en autorisert liste på nedlastningstidspunktet.
19. Rammeverket tar også for seg en mal som kan benyttes for utleding av krav:
Denne kan være nyttig å bruke som veiviser og man kan også velge å benytte seg av
enkelte og ikke samtlige av trinnene i malen. Det vil imidlertid være nyttig å gå igjennom punktene for
å sikre forståelse og flyt i forhold til bakgrunnen for bruken av malen. For utviklere og utviklerteam
tilbyr den et konsistent format. Elektronisk versjon finnes også på www.volere.co.uk
Se medfølgende mal fra kursmaterialet for ytterligere detaljer. Evt læreboken, se kapittel 10.
20. 7. Målekriterie (Fit Criterion) og test/sporbarhet
Hvis et krav ikke kan måles, er det ikke et (gyldig) krav. Malen til utforming av krav innehar spesielt 3 elementer som
gjennom dette rammeverket nettopp gjør det til et kvalitetssikret krav. Beskrivelsen som forteller om intensjonen og
HVA som skal skje eller ønskes. Rationale, beskrivelse på HVORFOR gjør at kravet i seg selv blir lettere å forstå
(kontekst). HVORFOR er ikke bare til hjelp for utforming av målekriteriet for kravet, men er også et verktøy for å
avdekke når flere krav egentlig bare er ett. Det siste av elementene er målekriteriet (Fit Criterion).
Målekriteriet har 2 hensikter;
1. Det skal reflektere at løsningen tilfredsstiller kravet.
2. For å kunne teste hvorvidt løsningen imøtekommer kravet, må det være mål og -testbart.
Testere og kvalitetssikring
I tillegg utgjør målekriteriet et benchmark for testerne og vil i mange tilfeller opptre som testscript og beskrive hva
kravet skal tilfredsstille.
I mange prosjekter involveres testere for sent, spesielt i litt større prosjekter kan dette vise seg svært kritisk og
uheldig. Som nevnt innledningsvis er det viktig at alle relevante roller tilknyttet prosjektet har en felles forståelse av
løsningen og kravene. Dette gjelder ikke minst testerne og derfor bør de involveres eller ha ansvar for utformingen av
målekriteriet. Slik kvalitetssikrer man forståelse i alle ledd i prosjektet og man reduserer tid og kommunikasjon brukt
på misoppfattelser av krav.
Altfor ofte er krav for vage og tvetydige, for eksempel:
Alle aspektene av tjenesten? Hvor enkelt? Denne kunden? Hvem som helst? Snakke eller også lese?
Beskrivelse, HVA: Tjenesten skal enkelt kunne brukes av en kunde som ikke er engelsk-språklige Også andre språk?
Eks Målekriterie: 90% av brukerne som ikke har engelsk som morsmål, skal være i stand til å foreta et kjøp innen 60
sek etter at de har valgt et produkt.
Eks Målekriterie: Tjenesten skal tilfredsstille ISO 9241 Usability Standard
21. Målekriterer utformes for ikke-funksjonelle og funksjonelle krav. Disse er gjerne litt ulike hverandre.
Under følger en kort forklaring og beskrivelse på hva som skiller de og hva man bør være obs på.
Ikke-funksjonelt målekriterie
Et ikke-funksjonelt krav er gjerne en egenskap eller attributt som løsningen, tjenesten eller produktet må ha.
Målekriteriet er derfor målbarheten av denne egenskapen eller attributten.
Eksempel på et usability-krav, tatt med utgangspunkt fra et case om avising av veier (tidligere benyttet).
Beskrivelse, HVA: tjenesten skal være intuitiv.
Rationale, HVORFOR: ingeniørene og sjåførene må finne tjenesten intuitiv og lett å bruke, ellers vil de ikke benytte
seg av den.
Målekritere 1: ingeniørene og sjåførene skal kunne lage en avisingsplan innen 10 min etter at de har tatt tjenesten i
bruk uten å benytte seg av en brukermanual.
Ønsker man å presisere dette ytterligere kan målekriteriet omformuleres. Beskrivelsen ’intuitivt’ kan f eks bety lett å
lære:
Målekriterie 2: 9 ut av 10 brukere skal etter kun 1 dagskurs kunne utføre en gitt liste av oppgaver etter endt
opplæring.
22. Beskrivelse av hvordan måleparametre som kan anvendes for ulike ikke-funksjonelle krav
Kap.7, kursheftet
23. Funksjonelle målekriterier
Et funksjonelt krav er noe løsningen, tjenesten, produktet skal gjøre eller utføre.
Målekriteriet til funksjonelle krav må derfor spesifisere hvordan du skal vite at det har oppfylt den nødvendige
handlingen.
Eksempel, tatt med utgangspunkt fra et case om avising av veier (tidligere benyttet).
Beskrivelse, HVA: tjenesten skal lagre data fra værstasjonene.
Rationale, HVORFOR: værdata er nødvendig for å kunne planlegge og utforme avisningsplaner.
Målekriterie: lagrede værdata i tjenesten skal være identisk med overført værdata, målt og lagret fra den enkelte
værdatastasjon.
Kort oppsummert om målekriteriet:
Målekriterer er ikke en test men et benchmark som testerne kan bruke for å fastlå hvorvidt løsningen møter
kravet.
Å kvantifisere et krav er en fordel siden det betyr at du og kunden utarbeider den samme forståelsen for kravet.
Målekriteriet er derfor et viktig og avklarende kommunikasjonsutgangspunkt.
Målekriteriet skal aldri (formuleres) som løsningen. Eksempel: løsningen skal kunne håndtere verbal kommando.
Dette er ikke er målekriterie men snarere en løsning.
Målekriterier kan også være grafer, tabeller, verdier og lignende.
Til sist, involver testere ved utforming av målekriterier, spesielt i mellomstore og større prosjekter.
24. Oppsummering
• White Paperet introduserer leseren for et rammeverk som utruster IT-prosjekter til og i større grad
håndtere kravprosesser. Dette kvalitetssikrer prosjektløpet fundamentalt og gir store gevinster for
deltakerne, både kunde og leverandør.
• 7 utvalgte prosesser/deler av prosjektløpet fremheves ut fra rammeverket og anses som vesentlige
for å legge et godt fundament for kravhåndtering og kvalitetssikringen i prosjektet. Leseren har blitt
introdusert for tips og teknikker som lett setter han eller hun i stand til å umiddelbart ta de i bruk.
• For å sikre ytterligere dypere forståelse og kompetanse anbefales læreboken, kursheftet, og maler til
bruk av rammeverket ’Mastering the Requirement Process’.
Husk at du kan benytte rammeverket og malene både helhetlig og som bestanddeler.
Det er godt egnet som analyseverktøy og derfor relevant å benytte selv om man
kommer inn i et prosjekt etter at en kravspesifikasjon er utarbeidet av kunden.
For ytterligere informasjon om rammeverket, bakgrunnsinformasjon og verktøy se
www.volere.co.uk
