White Paper mastering the req process

702 views

Published on

White Paper on using the Requirement Process, developed by Volere.

  • Be the first to comment

  • Be the first to like this

White Paper mastering the req process

  1. 1. Introduksjon: veileder til bruk av White PaperetHva 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 norskemarkedet bør man strekke seg etter å kontinuerlig forbedre seg på å gjennomføre prosjekter og samarbeid medkunder. White Paperet skal bidra til å høyne forståelse og kvalitet rundt kravprosessene i et IT-prosjekt. Å høynekvaliteten av kravhåndtering vil kunne gi store gevinster for kunden, teamet og leverandør. Det introduserer leserenfor et rammeverk, utviklet av Suzanne og James Robertson, basert på deres kurs ’Mastering the RequirementProcess’.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 introdusertfor ulike tips og teknikker for håndtering av krav i lys av de viktigste delene av prosjektløpet. Dette er enkle tips ogteknikker som kan tas i bruk umiddelbart uten at det krever noen særlig form for opplæring. White Paperet tar forseg 7 prosesser/deler av et prosjektløp, spesielt utvalgt på grunn av relevansen og gevinsten som kan hentes ut avdisse 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 hanytte av kunnskapen om rammeverket ’Mastering the Requirement Process’.
  2. 2. Mastering the Requirement Process, -et rammeverkHva består dette rammeverket av og hvorfor er det et godtegnet verktøy for ditt IT-prosjekt?• Dette er et rammeverk med konkrete aktiviteter og teknikker ihvert prosessledd som er ment å bidra til kvalitetssikring av IT- Leveranseprosjekter. Rammeverket kan anvendes på ulike stadier iprosjektløpet. Det fungerer som en MAL som kan splittes opp. Testing• Man skal ikke trenge å bruke det slavisk. Rammeverket kan Utvikling Kravogså benyttes som et analyseredskap i å forstå prosjektet, enkunde, utviklingsprosjekt f eks gjennom tilbudsskriving etc. Backlog• Ved å legge et godt fundament gjennom kartlegging ogforståelse av krav, vil man oppnå riktigere utformede og mer Forarbeid til kravpresise krav. Dette fører igjen til et mer presist produkt forkunden, 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 ogmål.
  3. 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øpHer jobber man med (og uten kunde) for å leggefundamentet 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 kravetsbehov for å kartlegge ytterligere hvor flere krav mål/testkriterie hensikt. kommer til.
  4. 4. Rammeverket kan benyttes i gjennom hele prosjektløpet eller for enkelte deler Start Kap. 2, kursheftet
  5. 5. Hvordan kan jeg benytte rammeverket?Det kan benyttes i de fleste prosesser og deler av et prosjektløp men det er mest hensiktsmessig å kvalitetssikreprosjektet med rammeverket i den første halvdelen av prosjektet. Dette legger et godt fundamentet for utlededekrav og vil dermed bidra til å kvalitetssikring. De viktigste prosessene og delene for rammeverket man bør jobbe medog 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 / Interessenter3. Begrensninger / forutsetninger4. Bruk av Use Case for å forstå en organisasjon, business case, virksomhet5. Avdekking funksjonalitet/behov/krav ved hjelp av ulike arbeidsmetoder/fasilitering6. Utleding og utforming av krav7. Målekriterie og involvering av testereI alle de ovenstående punktene og prosessene arbeides med metoder og teknikker som blir presenterti 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 ogkvalitetssikring av kravene ved å benytte mal for utforming av krav eller revidere status/nå-situasjon iprosjektet ved en gjennomgang av prosesstegene.Ikke bare godta en kravspesifikasjon som den er!
  6. 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 oglignende. Sørg for at det er klart og tydelig HVORFOR bestillingen av prosjektet er foretatt. Dette bør være enoverordnet forståelse for alle i teamet. Man kan f eks benytte seg av en kort prosjektbeskrivelse ellerprosjektmandat, denne vil danne bakgrunn for retning av prosjektet og fortelle om hensikten. Det vil ofte gjernelø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 kartleggessammen 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å avdekkedisse elementene?
  7. 7. OmfangÅ definere omfanget av prosjektet/løsningen/produktet er kritisk for å kunne forstå det. Ved å definere omfang defineressamtidig mye av rammene. Ofte er første skritt å definere et prosjektmandat. Neste skritt vil være sette omfang for hvasom skal inngå i arbeidet mot en kravspek. Det må avgrenses HVA som skal inkluderes i kartleggingen av behov og krav, oghva som skal holdes utenfor. Dette kan være å forstå virksomheten, kundens prosesser, organisasjonen og brukerne og derelasjonene den utgjør, i tillegg til å forstå informasjonen og kunnskapen som utgjør kundecaset. Til hjelp med avgrensingkan man benytte seg av å sette opp et Rikt Bilde, se eksempelet under. F eks så holder du eksterne system utenfor detteelementet. 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 hensiktsmessiglø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. 8. InteressenterEr 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. 9. Kontekstkart (mapping): skaff deg en oversikt over 3. partssystemer og andresamhandlende 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. 10. MålbildetProsjektbeskrivelsen inneholder ofte et overordnet mål og definert behov for prosjektet. Målet kan ofte værehårete (urealistisk, vanskelig å forstå eller ikke målbart). Det er derfor viktig å definere et realistisk og testbartmå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 ogbeskrivelsen.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. 11. 3. Begrensninger i rammebetingelser og løsningRammeverket anbefaler å utarbeide en uttømmende oversikt over begrensninger.’Overordnede’ begrensninger er gjerne rammebetingelser for prosjektet, som tid og kost. I denne forbindelseutarbeider 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 somområ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 etså 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 reviewsog lignende. Dette forarbeidet kvalitetssikrer krav og unngår i større grad feilrettinger. Arbeidet kan gjerne gjøressom en iterativ prosess i prosjektet, hvis krav og utarbeidelse av løsningen er lagt opp til et slik løp underveis iprosjektet.Kjør en aktiv analyse hvor du plasserer den informasjonen du har gjennom andreaktiviteter som f eks ’rikt bilde’, ’kontekstkart’ og lignende.Dette gir deg et klarere og en mer enhetlig oversikt, også overfor kunden, enn om duforvalter informasjon som er spredt på ulike steder, ulike dokumenter etc. Analysen kansees på som en kontrollsjekk opp mot backlog og kravspesifiskasjonens utforming.
  12. 12. 4. Use Case for å forstå en virksomhet eller business caseUse Case (UC) er nyttig for å forstå en virksomhet. Det kan være rollebasert UC som tar utgangspunkt i ulike roller ien virksomhet, eller situasjon/handlingsbaserte UC ift en prosess eller arbeidsflyt. Ved å benytte det kartlagte ’rikebildet’ kan man dele dette opp i UC slik at man får inkludert relevant informasjon og detaljer. Kontekstkart er f eksofte 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 UserStory som sier noe om hva og hvorfor for å beskrive delprosesser, handling eller arbeidsflyt. Den tar utgangspunkt i athendelsen 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. 13. 5. Avdekking av funksjonalitet og krav ved hjelp av ulike arbeidsmetoder/fasiliteringDette er et kritisk ledd i kvalitetssikringen av en utviklingsprosess. Rammeverket skiller her tydelig mellom hva somer et krav og LØSNINGEN på kravet. Selve utformingen og hva som utgjør forskjellen vil beskrives ytterligere i nestepunkt, men krav beskriver BEHOV som eksisterer/oppstår for å skulle oppnå et mål eller resultat. Et krav eller enfunksjon beskriver en handling/aktivitet/prosess og gjennom behovskartlegging og workshops avdekkes HVA ogHVORFOR kravet skal eksistere. Det viktigste er ikke bare å avdekke krav, men å gjøre det på en hensiktsmessig måteslik 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 kravunderveis. 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 HVAsom er problemet, før man gyver løs på løsningen. Det er lett å tro at ved mindre prosjekter danner man seg raskt enoversikt. Fallgruben i små prosjekter er ofte at utviklerne blir for ivrig og kjører på med å utvikle løsning, sidenprosjektet 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. Storeprosjekter involverer mange interessenter og krever gjerne utstrakt grad av dokumentasjon som ledd ikvalitetssikringen.• Bruk kontekstkart aktivt for å få en oversikt over hvilke roller/prosesser/samhandling som skal studeres i kartleggingav 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. 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 somer relevant for produktet eller løsningen. Denne metoden er nyttig når du trenger forståelse for og oversikt over etmedium-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, stillerspørsmål, gjør kanskje noe av arbeidet under brukerens påsyn og overvåkning. Denne metoden er effektiv sammenmed modellering (punktet ovenfor) som skjer underveis. Viktig å være observant på at informasjonen fra dagensarbeidsflyt/system skal omsettes ved å tillate seg å stille spørsmålstegn. Hospitanten kan foreslå endringer sombruker kan gi tilbakemelding på . Intervjuer: Veldig nyttig måte å samle informasjon rundt krav på i prosjekter. Er mest effektiv når den benyttessammen med andre teknikker, f eks som modellering. Teknikken fungerer bra hvor brukere er veldig tydelig ogbevisste på hvilke krav som er viktige. Unngå helst å bruke denne isolert alene. Den bør helst anvendes med annenteknikk som utgangspunkt f eks UC eller kontektskart/rikt bilde. Få gjerne bruker til å tegne eller endre modelleneslik at ’skjult’ informasjon lettere kan avdekkes. Workshops (WS): Dette kan være gruppearbeid på UC, ulike former for scenario (scenario er beskrivelse av arbeidsom gjøres, kan være fremtidsscenario, Hva-Hvis scenario, Negative scenarioer). Andre eksempler er kreativitets WSog brainstorming WS som fungerer bra for produkt og konseptutvikling. WS er en effektiv og nyttig måte å samleinformasjon på. Gjennom WS avdekkes gjerne krav fra ulike interessenter som igjen kan bidra til en økt forståelsedeltakerne i mellom. Personas: Er en kunstig (virtuell) bruker, rolle eller karakter som representerer brukere/publikum. Utgangspunktetfor utforming av personas er f eks spørreundersøkelse eller intervju. Nyttig hvis f eks brukere ikke er tilgjengelig ogman 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øvefinne all mulig slags krav som gjelder for alle tenkelige brukere av din løsning/produkt.
  15. 15.  Gapanalyse: Nå-situasjonen opp mot fremtidsversjon. Analysen er rommet i mellom, hvordan komme seg fra A tilB? 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 WSog lignende. De er svært hensiktsmessig for å organisere tanker og systematisere innhold. F eks etter intervjuer ellerWS. 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 lavereterskel 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. 16. 6. Utforming av kravRammeverket 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, aktiviteteller prosess som er nødvendig for virksomheten. De beskriver ofte HVA som skal skje, eller må gjøres. Funksjonellekrav 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 detsystemet 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 ogattraktivt et produkt er selv om det kan være andre produkt som funksjonelt sett er bedre eller mer dekkende forbehovet. 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. 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 sesammenheng 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. 18. En beskrivelse av de viktigste punktene som kravkortet bør inneholde:• Kravnummer: nummeret på kravet• Kravtype: f eks funksjonelt eller ikke-funksjonelt ellertypebenevnelse 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 enrolle, arbeidsområde, interessent osv.• Kravets mål, et testbart målekriterie: kvantifiserbart mål somkravet/løsningen må oppfylle• Prioritet for kravet: f eks Må, Bør, Høy, Medium etc Kundenssignalisering om viktigheten av kravet S. 454, lærebokenEksempel -En online nettbutikk for kjøp av elektronisk musikkskal etableres og utvikles. Eksempelet tar utgangspunkt i at kun kjøpere fra autoriserte land kan handlefra 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 forvarekjøp.Grunnlag for kravet (Rationale) – musikk må ikke leveres til land som ikke har en rettslig avtale i orden for kjøp avmusikk. Dette er viktig på grunn av rettigheter og lisensiering.Opprinnelse – Jan Johansen, Juridisk enhetKravets mål – All nedlastning vil kun gå til godkjente land på en autorisert liste på nedlastningstidspunktet.
  19. 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 avenkelte 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 utviklerteamtilbyr den et konsistent format. Elektronisk versjon finnes også på www.volere.co.ukSe medfølgende mal fra kursmaterialet for ytterligere detaljer. Evt læreboken, se kapittel 10.
  20. 20. 7. Målekriterie (Fit Criterion) og test/sporbarhetHvis et krav ikke kan måles, er det ikke et (gyldig) krav. Malen til utforming av krav innehar spesielt 3 elementer somgjennom dette rammeverket nettopp gjør det til et kvalitetssikret krav. Beskrivelsen som forteller om intensjonen ogHVA 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 kvalitetssikringI tillegg utgjør målekriteriet et benchmark for testerne og vil i mange tilfeller opptre som testscript og beskrive hvakravet skal tilfredsstille.I mange prosjekter involveres testere for sent, spesielt i litt større prosjekter kan dette vise seg svært kritisk oguheldig. Som nevnt innledningsvis er det viktig at alle relevante roller tilknyttet prosjektet har en felles forståelse avløsningen og kravene. Dette gjelder ikke minst testerne og derfor bør de involveres eller ha ansvar for utformingen avmålekriteriet. Slik kvalitetssikrer man forståelse i alle ledd i prosjektet og man reduserer tid og kommunikasjon bruktpå 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 60sek etter at de har valgt et produkt.Eks Målekriterie: Tjenesten skal tilfredsstille ISO 9241 Usability Standard
  21. 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ålekriterieEt 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 benytteseg 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 ibruk 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 endtopplæring.
  22. 22. Beskrivelse av hvordan måleparametre som kan anvendes for ulike ikke-funksjonelle krav Kap.7, kursheftet
  23. 23. Funksjonelle målekriterierEt 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ødvendigehandlingen.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 enkeltevæ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øterkravet.Å 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. 24. Oppsummering• White Paperet introduserer leseren for et rammeverk som utruster IT-prosjekter til og i større gradhåndtere kravprosesser. Dette kvalitetssikrer prosjektløpet fundamentalt og gir store gevinster fordeltakerne, både kunde og leverandør.• 7 utvalgte prosesser/deler av prosjektløpet fremheves ut fra rammeverket og anses som vesentligefor å legge et godt fundament for kravhåndtering og kvalitetssikringen i prosjektet. Leseren har blittintrodusert 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 tilbruk 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

×