Kravspecifikation för webbapplikationer: innehåll och struktur
En kravspecifikation för en webbapplikation beskriver vad systemet ska göra och under vilka villkor. Utöver funktionerna behövs webbspecifika krav: vilka webbläsare som ska stödjas, användarroller och behörigheter, prestanda under last och integrationer mot befintliga system – plus tydliga avgränsningar av vad som inte ingår.
En kravspecifikation för en webbapplikation är skillnaden mellan att beställa något förutsägbart och att hoppas på det bästa. Men en webbapp har krav som ett vanligt program saknar – webbläsare, samtidiga användare, integrationer. Här är vad specen bör innehålla och hur du håller den från att svälla ur kontroll.
Webbspecifika icke-funktionella krav
De flesta kan lista vad en applikation ska göra. Det som oftare glöms är kraven på hur väl den ska göra det – de icke-funktionella kraven. För en webbapplikation är just de avgörande, eftersom de springer ur att tjänsten körs i en webbläsare hos många olika användare samtidigt.
En checklista över det som bör stå med:
- Webbläsar- och enhetsstöd. Vilka webbläsare ska fungera, och ska applikationen vara användbar på mobil och surfplatta eller främst på dator?
- Prestanda under last. Hur snabbt ska sidor svara, och hur många samtidiga användare ska systemet klara utan att bli segt?
- Säkerhet. Hur hanteras inloggning, lösenord och känslig data, och vilka krav gäller kring dataskydd?
- Tillgänglighet. Ska applikationen uppfylla en tillgänglighetsnivå, och i så fall vilken?
Poängen är att dessa krav måste vara uttalade. Står det inte att applikationen ska klara hundratals samtidiga användare, är det ingen som byggt för det – och det upptäcks i värsta fall först när trafiken kommer.
Roller och behörigheter begripligt
En webbapplikation har nästan alltid olika typer av användare: en vanlig användare, en administratör, kanske en läsbehörig gäst. Vem som får se och göra vad är en av de vanligaste källorna till missförstånd, och därför värt att dokumentera tydligt.
Nyckeln är att beskriva roller i termer av vad de ska kunna göra, inte i teknisk jargong. Ett enkelt och effektivt grepp är en tabell som ställer roller mot funktioner, så att även en icke-teknisk beslutsfattare direkt ser vem som får vad.
| Roll | Får göra |
|---|---|
| Gäst | Läsa öppet innehåll, inte logga in |
| Användare | Logga in, hantera sina egna data |
| Administratör | Hantera alla användare och innehåll |
Med rollerna nedskrivna på det här sättet blir behörigheterna inte en gissning under utvecklingen. Alla – beställare och utvecklare – utgår från samma bild av vem som får göra vad.
Prestanda och integrationer
Två webbspecifika områden förtjänar särskild eftertanke, eftersom de ofta underskattas.
Prestanda under last handlar om hur applikationen beter sig när den används på riktigt. En sida som är snabb för en ensam testare kan bli oanvändbart seg när hundra personer är inne samtidigt. Kravspecen bör därför ange en förväntad belastning och hur systemet ska svara vid den – annars finns inget att bygga eller testa mot.
Integrationer är kopplingar mot system som redan finns: ett affärssystem, en betaltjänst, ett inloggningssystem. Varje integration är ett eget litet delprojekt med egen testning, och de har en tendens att bli mer komplexa än de först ser ut. Ett konkret exempel: en webbapp som ska visa lagersaldo i realtid är helt beroende av en pålitlig koppling mot lagersystemet – fungerar inte den, spelar resten av applikationen mindre roll. Sådana beroenden hör hemma i specen från början.
Avgränsningar som håller scope creep borta
Den kanske viktigaste delen av en kravspecifikation är inte vad som ingår, utan vad som inte gör det. Utan tydliga avgränsningar smyger sig omfattningen uppåt – små tillägg som var för sig verkar rimliga men tillsammans spränger både budget och tidsplan. Det kallas scope creep, och det sänker fler projekt än tekniska problem gör.
Motmedlet är enkelt men underanvänt: en uttrycklig lista över vad som ligger utanför projektet, plus en överenskommen process för hur ändringar och tillägg hanteras när de dyker upp. Då blir varje nytt önskemål ett medvetet beslut med en prislapp, i stället för något som glider in obemärkt. En bra spec sätter alltså både ramen och reglerna för hur ramen får ändras.
Att hitta rätt detaljnivå är en konst i sig – för lite och man bygger fel, för mycket och man tappar flexibilitet. En kort förstudie är ofta det bästa sättet att landa rätt. Vill ni ha hjälp att ta fram en kravspecifikation som håller, ingår det i våra tjänster. Hör av dig så tittar vi på vad ert projekt behöver.
Vanliga frågor
Vad är skillnaden mellan funktionella och icke-funktionella krav?
Funktionella krav beskriver vad systemet ska göra – vilka funktioner användaren ska kunna utföra. Icke-funktionella krav beskriver hur väl det ska göras: prestanda, säkerhet, tillgänglighet och webbläsarstöd. För en webbapplikation är de icke-funktionella kraven ofta de som glöms bort, trots att de i hög grad avgör om resultatet blir användbart.
Vilka webbspecifika krav behöver en kravspec för webbapp?
Vilka webbläsare och enheter som ska stödjas, hur applikationen ska bete sig på mobil, prestanda när många använder den samtidigt, säkerhet kring inloggning och data, samt integrationer mot befintliga system. Det är krav som inte uppstår för ett skrivbordsprogram men är helt centrala på webben, och de bör stå uttryckligen i specen.
Hur dokumenterar man användarroller begripligt?
Beskriv varje roll utifrån vad den ska kunna göra och inte göra, inte i teknisk behörighetsjargong. En enkel tabell med roller mot funktioner gör det tydligt för alla, även icke-tekniska beslutsfattare. Poängen är att alla ska förstå vem som får se och göra vad, så att behörigheter inte blir en gissning under utvecklingen.
Vad är scope creep och hur förhindrar man det?
Scope creep är när omfattningen sakta växer under projektets gång med små tillägg som var för sig verkar rimliga men tillsammans spränger budget och tidsplan. Det motverkas med tydliga avgränsningar i kravspecen – en uttrycklig lista över vad som inte ingår – och en överenskommen process för hur ändringar hanteras.
Behöver man en fullständig kravspec innan utvecklingen börjar?
Inte nödvändigtvis i minsta detalj, men huvuddragen bör vara klara: syfte, roller, de viktigaste flödena, webbspecifika krav och avgränsningar. Ett vanligt misstag är att antingen specificera för lite och bygga fel, eller låsa varje detalj i förväg och tappa flexibilitet. En förstudie hjälper att hitta rätt nivå för just ert projekt.