Kravspecifikation til webapplikationer: indhold og struktur
En kravspecifikation til en webapplikation beskriver hvad systemet skal gøre og under hvilke betingelser. Ud over funktionerne er der brug for webspecifikke krav: hvilke browsere der skal understøttes, brugerroller og rettigheder, ydeevne under belastning og integrationer med eksisterende systemer. Dertil kommer klare afgrænsninger af hvad der ikke er med.
En kravspecifikation til en webapplikation er forskellen på at bestille noget forudsigeligt og at håbe på det bedste. Men en webapp har krav som et almindeligt program ikke har: browsere, samtidige brugere, integrationer. Her er hvad specifikationen bør indeholde og hvordan du forhindrer at den løber løbsk.
Webspecifikke ikke-funktionelle krav
De fleste kan opremse hvad en applikation skal gøre. Det der oftere bliver glemt, er kravene til hvor godt den skal gøre det: de ikke-funktionelle krav. For en webapplikation er netop de afgørende fordi de udspringer af at tjenesten kører i en browser hos mange forskellige brugere på samme tid.
En tjekliste over hvad der bør være med:
- Browser- og enhedsunderstøttelse. Hvilke browsere skal virke, og skal applikationen kunne bruges på mobil og tablet eller primært på computer?
- Ydeevne under belastning. Hvor hurtigt skal siderne svare, og hvor mange samtidige brugere skal systemet kunne klare uden at blive langsomt?
- Sikkerhed. Hvordan håndteres login, adgangskoder og følsomme data, og hvilke krav gælder for databeskyttelse?
- Tilgængelighed. Skal applikationen leve op til et bestemt tilgængelighedsniveau, og i så fald hvilket?
Pointen er at disse krav skal være formuleret eksplicit. Står der ikke at applikationen skal kunne klare hundredvis af samtidige brugere, er der ingen der har bygget til det, og det opdager man i værste fald først når trafikken kommer.
Forståelige roller og rettigheder
En webapplikation har næsten altid forskellige typer brugere: en almindelig bruger, en administrator, måske en gæst med læseadgang. Hvem der må se og gøre hvad, er en af de mest almindelige kilder til misforståelser og derfor værd at dokumentere tydeligt.
Nøglen er at beskrive rollerne ud fra hvad de skal kunne gøre, ikke i teknisk jargon. Et enkelt og effektivt greb er en tabel der stiller roller over for funktioner, så selv en ikke-teknisk beslutningstager straks kan se hvem der må hvad.
| Rolle | Må gøre |
|---|---|
| Gæst | Læse åbent indhold, ikke logge ind |
| Bruger | Logge ind, håndtere sine egne data |
| Administrator | Håndtere alle brugere og alt indhold |
Når rollerne er skrevet ned på den måde, bliver rettighederne ikke et gæt under udviklingen. Alle, både kunde og udviklere, tager udgangspunkt i det samme billede af hvem der må gøre hvad.
Ydeevne og integrationer
To webspecifikke områder fortjener særlig omtanke fordi de ofte bliver undervurderet.
Ydeevne under belastning handler om hvordan applikationen opfører sig når den bliver brugt for alvor. En side der er hurtig for en enkelt tester, kan blive ubrugeligt langsom når hundrede personer er inde på samme tid. Kravspecifikationen bør derfor angive en forventet belastning og hvordan systemet skal reagere ved den. Ellers er der intet at bygge eller teste op imod.
Integrationer er forbindelser til systemer der allerede findes: et ERP-system, en betalingsløsning, et loginsystem. Hver integration er et lille delprojekt i sig selv med sin egen test, og de har en tendens til at blive mere komplekse end de ser ud til i første omgang. Et konkret eksempel: En webapp der skal vise lagerbeholdningen i realtid, er helt afhængig af en pålidelig forbindelse til lagersystemet. Virker den ikke, betyder resten af applikationen mindre. Den slags afhængigheder hører hjemme i specifikationen fra starten.
Afgrænsninger der holder scope creep væk
Den måske vigtigste del af en kravspecifikation er ikke hvad der er med, men hvad der ikke er. Uden klare afgrænsninger sniger omfanget sig opad: små tilføjelser der hver for sig virker rimelige, men som tilsammen sprænger både budget og tidsplan. Det kaldes scope creep, og det sænker flere projekter end tekniske problemer gør.
Modmidlet er enkelt, men bliver brugt for lidt: en eksplicit liste over hvad der ligger uden for projektet, plus en aftalt proces for hvordan ændringer og tilføjelser håndteres når de dukker op. Så bliver hvert nyt ønske en bevidst beslutning med et prisskilt i stedet for noget der glider ubemærket ind. En god specifikation sætter altså både rammen og reglerne for hvordan rammen må ændres.
At finde det rette detaljeniveau er en kunst i sig selv. For lidt, og man bygger forkert. For meget, og man mister fleksibiliteten. En kort forundersøgelse er ofte den bedste måde at ramme rigtigt på. Vil I have hjælp til at udarbejde en kravspecifikation der holder, er det en del af vores ydelser. Kontakt os, så ser vi på hvad jeres projekt har brug for.
Ofte stillede spørgsmål
Hvad er forskellen på funktionelle og ikke-funktionelle krav?
Funktionelle krav beskriver hvad systemet skal gøre, altså hvilke funktioner brugeren skal kunne udføre. Ikke-funktionelle krav beskriver hvor godt det skal gøres: ydeevne, sikkerhed, tilgængelighed og browserunderstøttelse. For en webapplikation er det ofte de ikke-funktionelle krav der bliver glemt, selv om de i høj grad afgør om resultatet bliver brugbart.
Hvilke webspecifikke krav skal en kravspec til en webapp have med?
Hvilke browsere og enheder der skal understøttes, hvordan applikationen skal opføre sig på mobil, ydeevne når mange bruger den samtidig, sikkerhed omkring login og data samt integrationer med eksisterende systemer. Det er krav der ikke opstår for et desktopprogram, men som er helt centrale på nettet, og de bør stå eksplicit i specifikationen.
Hvordan dokumenterer man brugerroller forståeligt?
Beskriv hver rolle ud fra hvad den skal kunne og ikke kunne, ikke i teknisk rettighedsjargon. En enkel tabel med roller over for funktioner gør det tydeligt for alle, også for ikke-tekniske beslutningstagere. Pointen er at alle skal forstå hvem der må se og gøre hvad, så rettighederne ikke bliver et gæt under udviklingen.
Hvad er scope creep, og hvordan forhindrer man det?
Scope creep er når omfanget langsomt vokser i løbet af projektet med små tilføjelser der hver for sig virker rimelige, men som tilsammen sprænger budget og tidsplan. Det modvirkes med klare afgrænsninger i kravspecifikationen, dvs. en eksplicit liste over hvad der ikke er med, og en aftalt proces for hvordan ændringer håndteres.
Skal man have en fuldstændig kravspecifikation før udviklingen går i gang?
Ikke nødvendigvis ned i mindste detalje, men hovedtrækkene bør være på plads: formål, roller, de vigtigste flows, webspecifikke krav og afgrænsninger. En almindelig fejl er enten at specificere for lidt og bygge forkert eller at låse hver detalje på forhånd og miste fleksibiliteten. En forundersøgelse hjælper med at finde det rette niveau for netop jeres projekt.