Kravspesifikasjon for webapplikasjoner: innhold og struktur
En kravspesifikasjon for en webapplikasjon beskriver hva systemet skal gjøre, og under hvilke betingelser. I tillegg til funksjonene trengs det webspesifikke krav: hvilke nettlesere som skal støttes, brukerroller og tilganger, ytelse under last og integrasjoner mot eksisterende systemer, pluss tydelige avgrensninger av hva som ikke inngår.
En kravspesifikasjon for en webapplikasjon er forskjellen mellom å bestille noe forutsigbart og å håpe på det beste. Men en webapp har krav som et vanlig program mangler: nettlesere, samtidige brukere, integrasjoner. Nedenfor går vi gjennom hva spesifikasjonen bør inneholde, og hvordan du hindrer at den vokser ut av kontroll.
Webspesifikke ikke-funksjonelle krav
De fleste kan liste opp hva en applikasjon skal gjøre. Det som oftere blir glemt, er kravene til hvor godt den skal gjøre det, altså de ikke-funksjonelle kravene. For en webapplikasjon er nettopp de avgjørende fordi de følger av at tjenesten kjører i en nettleser hos mange ulike brukere samtidig.
En sjekkliste over det som bør være med:
- Støtte for nettlesere og enheter. Hvilke nettlesere skal fungere, og skal applikasjonen være brukbar på mobil og nettbrett eller først og fremst på datamaskin?
- Ytelse under last. Hvor raskt skal sidene svare, og hvor mange samtidige brukere skal systemet tåle uten å bli tregt?
- Sikkerhet. Hvordan håndteres innlogging, passord og sensitive data, og hvilke krav gjelder for personvern?
- Universell utforming. Hvilket nivå skal applikasjonen oppfylle? For nettløsninger rettet mot brukere setter regelverket et minstenivå, også for private virksomheter.
Poenget er at disse kravene må stå eksplisitt. Står det ikke at applikasjonen skal tåle hundrevis av samtidige brukere, er det ingen som har bygget for det, og i verste fall oppdages det først når trafikken kommer.
Roller og tilganger på en forståelig måte
En webapplikasjon har nesten alltid ulike typer brukere: en vanlig bruker, en administrator, kanskje en gjest med lesetilgang. Hvem som får se og gjøre hva, er en av de vanligste kildene til misforståelser, og derfor verdt å dokumentere tydelig.
Nøkkelen er å beskrive rollene ut fra hva de skal kunne gjøre, ikke med teknisk sjargong. Et enkelt og effektivt grep er en tabell som stiller roller opp mot funksjoner slik at også en beslutningstaker uten teknisk bakgrunn ser med en gang hvem som har tilgang til hva.
| Rolle | Får gjøre |
|---|---|
| Gjest | Lese åpent innhold, ikke logge inn |
| Bruker | Logge inn, håndtere sine egne data |
| Administrator | Håndtere alle brukere og alt innhold |
Med rollene skrevet ned på denne måten blir ikke tilgangene gjettverk underveis i utviklingen. Alle, både kunden og utviklerne, tar utgangspunkt i det samme bildet av hvem som får gjøre hva.
Ytelse og integrasjoner
To webspesifikke områder fortjener ekstra oppmerksomhet fordi de ofte undervurderes.
Ytelse under last handler om hvordan applikasjonen oppfører seg når den faktisk blir brukt. En side som er rask når én person tester den, kan bli ubrukelig treg når hundre personer er inne samtidig. Kravspesifikasjonen bør derfor angi en forventet belastning og hvordan systemet skal svare ved den belastningen. Ellers finnes det ingenting å bygge eller teste mot.
Integrasjoner er koblinger mot systemer som allerede finnes: et ERP-system, en betalingstjeneste, et innloggingssystem. Hver integrasjon er et eget lite delprosjekt med egen testing, og de har en tendens til å bli mer komplekse enn de ser ut til ved første øyekast. Et konkret eksempel: En webapp som skal vise lagerbeholdning i sanntid, er helt avhengig av en pålitelig kobling mot lagersystemet. Fungerer ikke den, spiller resten av applikasjonen mindre rolle. Slike avhengigheter hører hjemme i spesifikasjonen fra starten av.
Avgrensninger som holder scope creep unna
Den kanskje viktigste delen av en kravspesifikasjon er ikke hva som inngår, men hva som ikke gjør det. Uten tydelige avgrensninger kryper omfanget oppover: små tillegg som hver for seg virker fornuftige, men som til sammen sprenger både budsjett og tidsplan. Det kalles scope creep, og det feller flere prosjekter enn tekniske problemer gjør.
Botemiddelet er enkelt, men lite brukt: en eksplisitt liste over hva som ligger utenfor prosjektet, pluss en avtalt prosess for hvordan endringer og tillegg håndteres når de dukker opp. Da blir hvert nytt ønske en bevisst beslutning med en prislapp, i stedet for noe som glir inn ubemerket. En god spesifikasjon setter altså både rammen og reglene for hvordan rammen kan endres.
Å finne riktig detaljnivå er en kunst i seg selv. Med for lite bygger man feil, og med for mye mister man fleksibilitet. En kort forstudie er ofte den beste måten å treffe riktig på. Vil dere ha hjelp til å utarbeide en kravspesifikasjon som holder, inngår det i tjenestene våre. Ta kontakt, så ser vi på hva prosjektet deres trenger.
Ofte stilte spørsmål
Hva er forskjellen på funksjonelle og ikke-funksjonelle krav?
Funksjonelle krav beskriver hva systemet skal gjøre, altså hvilke funksjoner brukeren skal kunne utføre. Ikke-funksjonelle krav beskriver hvor godt det skal gjøres: ytelse, sikkerhet, universell utforming og nettleserstøtte. For en webapplikasjon er det ofte de ikke-funksjonelle kravene som blir glemt, selv om de i stor grad avgjør om resultatet blir brukbart.
Hvilke webspesifikke krav trenger en kravspesifikasjon for en webapp?
Hvilke nettlesere og enheter som skal støttes, hvordan applikasjonen skal oppføre seg på mobil, ytelse når mange bruker den samtidig, sikkerhet rundt innlogging og data, samt integrasjoner mot eksisterende systemer. Dette er krav som ikke oppstår for et skrivebordsprogram, men som er helt sentrale på nettet, og de bør stå eksplisitt i spesifikasjonen.
Hvordan dokumenterer man brukerroller på en forståelig måte?
Beskriv hver rolle ut fra hva den skal kunne gjøre og ikke gjøre, ikke med teknisk sjargong om tilganger. En enkel tabell med roller mot funksjoner gjør det tydelig for alle, også for beslutningstakere uten teknisk bakgrunn. Poenget er at alle skal forstå hvem som får se og gjøre hva. Da blir ikke tilgangene gjettverk underveis i utviklingen.
Hva er scope creep, og hvordan forhindrer man det?
Scope creep er når omfanget sakte vokser i løpet av prosjektet gjennom små tillegg som hver for seg virker fornuftige, men som til sammen sprenger budsjett og tidsplan. Det motvirkes med tydelige avgrensninger i kravspesifikasjonen (en eksplisitt liste over hva som ikke inngår) og en avtalt prosess for hvordan endringer håndteres.
Trenger man en fullstendig kravspesifikasjon før utviklingen starter?
Ikke nødvendigvis i minste detalj, men hovedtrekkene bør være klare: formål, roller, de viktigste arbeidsflytene, webspesifikke krav og avgrensninger. En vanlig feil er enten å spesifisere for lite og bygge feil, eller å låse hver detalj på forhånd og miste fleksibilitet. En forstudie hjelper dere med å finne riktig nivå for akkurat deres prosjekt.