Kravspecifikation för webbplats: innehåll, ansvar och godkännande

Beskriv vilka kunder webbplatsen är till för, vad de behöver förstå och vilken handling de ska kunna genomföra. Ett kontaktformulär kan vara en funktion, men det behöver vara tydligt vilka ärenden formuläret ska samla in och vem som tar hand om dem.

Ange vad projektet ska förändra jämfört med dagens läge. Skilj ett dokumenterat problem från ett önskemål så att ni kan prioritera när budget eller tid är begränsad.

Markera vad som krävs för lansering och vad som kan komma senare. Ange budgetram, önskad tidpunkt och beroenden, till exempel när texter, översättningar eller ett externt bokningssystem finns tillgängliga. Då blir det möjligt att bedöma vad som måste vara klart innan nästa del kan godkännas.

Illustrativt exempel: ett tjänsteföretag vill få förfrågningar om rätt uppdrag. Ett nödvändigt krav kan vara att besökaren ser vilka tjänster som erbjuds och kan skicka en förfrågan till rätt mottagare. En avancerad offertkalkylator kan vara en senare förbättring om en vanlig förfrågan löser lanseringens uppgift. Prioriteringen behöver motiveras av verksamhetsbehovet, inte av vilken funktion som ser mest imponerande ut.

Ange också vilket underlag problembeskrivningen bygger på. Kundfrågor kan visa att tjänsternas gränser är otydliga. En kontroll av formuläret kan visa att meddelanden inte når mottagaren. Skriv inte att en ny funktion kommer att öka konverteringen om det bara är en hypotes; beskriv i stället vilket beteende ni vill förbättra och hur det kan följas upp.

Gör en lista över de överenskomna sidorna och vilken fråga varje sida ska besvara. Skriv vem som lämnar faktaunderlag, vem som skriver och vem som godkänner. Bilder, kundcitat och resultat behöver tillstånd och verifierbara källor där det är relevant.

En ämneskarta fördelar frågor mellan sidor och avsnitt. Den gör överlappningar synliga: två frågor kan ibland besvaras på samma sida.

Skilj ett krav från en för tidigt låst lösning. Kravet kan vara att en kund ska kunna skicka rätt typ av förfrågan och få en bekräftelse. Exakt fältplacering och komponentval kan prövas i designarbetet, så länge funktionen och kontrollen är tydliga.

Vad måste vara klart innan innehållet kan godkännas?

Varje innehållsdel behöver ett underlag, en ansvarig och ett tydligt besked om vad som är godkänt. Anteckna vilka texter, bilder och översättningar som saknas, när de behövs och vem som avgör om de är färdiga. En tom innehållsruta är inte ett godkännande av kommande text.

Om webbplatsen ska finnas på flera språk, ange vilka sidor som ska finnas på respektive språk vid lanseringen. Bestäm vem som översätter, kontrollerar sakuppgifter och godkänner språket. En tekniskt färdig språkväxlare innebär inte att samtliga sidor är översatta eller att kontaktvägarna fungerar på varje språk.

Dokumentera också vilket befintligt material som ska behållas, skrivas om eller tas bort. Om samma leverantör både skriver och bygger behöver omfattningen ändå ange vem som lämnar verksamhetens fakta. Antalet sidor beskriver inte ensamt arbetsmängden: en ny text, en granskad översättning och ett importerat artikelarkiv är olika leveranser.

Skriv kraven så att någon kan kontrollera om de är uppfyllda. Skilj önskat beteende från hur resultatet ska testas och vem som får godkänna det.

Hur skriver ni ett testbart krav?

Ett testbart krav anger vad som ska fungera, under vilka förutsättningar och vilket utfall som räknas som godkänt. ”Formuläret ska fungera bra” lämnar kontrollen öppen. Ett mer användbart krav är att ett provärende från den överenskomna mobilmiljön når rätt mottagare och ger besökaren en bekräftelse. Använd tabellen som underlag för egna krav:

Tabellen är ett arbetsexempel, inte en beskrivning av funktioner som automatiskt ingår i ett SOVRA Digital-paket. Varje krav behöver få en ansvarig person och en överenskommen kontroll.

Vem utför kontrollen och vem godkänner?

Koppla varje krav till en utförare, en granskare och ett observerbart utfall. Illustrativt exempel för kontaktformuläret: beställaren bekräftar mottagaradress och vilka ärenden som ska tas emot, utföraren implementerar funktionen och en utsedd granskare skickar ett provärende. Kravet är uppfyllt först när rätt mottagare får rätt uppgifter och besökaren får ett korrekt besked.

Dokumentera rollerna i kravunderlaget, inte bara i en mötesanteckning. Om samma person har flera roller behöver det fortfarande framgå vem som får godkänna leveransen. Ett test kan annars lyckas tekniskt utan att någon har kontrollerat om resultatet motsvarar verksamhetens behov.

Vilka fel behöver testet kunna upptäcka?

Testa både en lyckad uppgift och relevanta fel som ska kunna hanteras. Ett formulär som fungerar med perfekta testuppgifter kan fortfarande lämna besökaren utan hjälp när ett obligatoriskt fält saknas eller ett meddelande inte kan skickas.

För samma illustrativa kontaktformulär kan ni avtala om ett test med giltiga uppgifter, ett test där ett obligatoriskt fält lämnas tomt och ett test av den avtalade felhanteringen vid utebliven leverans. Besökaren ska förstå vad som behöver rättas och inte få besked om en lyckad förfrågan när leveransen har misslyckats. Den tekniska lösningen och testmiljön behöver bestämmas i projektet.

W3C:s vägledning om formulärvalidering beskriver hur obligatoriska uppgifter och fel behöver göras begripliga. Vägledningen betonar också att validering i webbläsaren inte ensam säkerställer säkerheten. Kravunderlaget behöver därför ange vilka kontroller utföraren ansvarar för; en lyckad visuell testning ersätter inte teknisk kontroll.

Skilj projektkostnaden från domän, hosting, licenser, redigering och tekniskt underhåll. Ange vilka konton och rättigheter som behöver hanteras, vilka instruktioner som ska lämnas och vem som ansvarar för framtida ändringar.

Beskriv hur ofta innehållet ska ändras och vem som ska göra det. Det ger underlag för valet av redigeringslösning.

Vad behöver ingå i överlämningen?

Överlämningen behöver göra det möjligt för den ansvariga personen att förvalta webbplatsen och veta vem som hanterar ett problem. Bestäm vilka av följande uppgifter som är relevanta för projektet och ange en ansvarig för varje del:

• Konton och behörigheter: vem äger och administrerar domän, hosting, publiceringssystem och anslutna tjänster?
• Redigering: vilka innehållstyper får beställaren ändra och vilken instruktion eller genomgång ska ingå?
• Drift och återställning: vem följer upp fel, hanterar säkerhetskopior och kontrollerar att en avtalad återställning går att genomföra?
• Kostnader och avtal: vad är en engångskostnad, vad återkommer och vilken part betalar respektive tjänst?
• Fortsatta ändringar: hur anmäls ett fel och hur beställs innehåll eller funktioner som ligger utanför den godkända omfattningen?

Listan är ett stöd för ansvarsfördelning, inte ett påstående att drift, utbildning eller löpande underhåll alltid ingår i ett webbprojekt. Om arbetet slutar vid godkänd leverans behöver ansvar efter den tidpunkten ändå framgå.

Skriv när struktur, innehåll och design ska godkännas och hur ändringar utanför omfattningen hanteras. Inför lansering ska överenskomna krav kunna följas tillbaka till en kontroll, ett utfall och en ansvarig person.

För varje avtalad kontroll kan ni spara kravets ID, testmiljö, utförda steg, förväntat resultat, faktiskt resultat och godkännare. Notera datum och vilken version som testades. Om en senare ändring påverkar samma funktion behöver den relevanta kontrollen göras igen; ett tidigare lyckat test beskriver den tidigare versionen.

Godkännande av innehåll, teknisk leverans och tillstånd att publicera behöver vara tydligt åtskilda när de sker vid olika tidpunkter. En korrekt förhandsvisning betyder inte automatiskt att ansvarig beställare har godkänt att sidan blir offentlig. Dokumentera kvarstående fel, vem som hanterar dem och vilket beslut som krävs före lanseringen.

Hur skiljer ni fel från nya önskemål?

Ett fel är en avvikelse från ett överenskommet krav; ett nytt behov behandlas som en ändring av omfattningen. Protokollet behöver ange vilket krav som berörs, vad som observerades och vad som behöver göras före godkännande. När önskemålet inte ingår i underlaget ska påverkan på omfattning, tid och kostnad bedömas innan det läggs till.

Illustrativt exempel: om ett avtalat formulär inte skickar till den angivna mottagaren behöver avvikelsen utredas mot kravet. Om beställaren i stället vill att formuläret också ska skapa ett ärende i ett nytt CRM-system är det en ytterligare funktion som behöver bedömas. Använd överenskommelsen och det observerade beteendet som underlag; avgör inte frågan enbart utifrån hur liten ändringen ser ut.

Vad behöver kontrolleras vid byte av webbplats?

När ett webbplatsbyte ändrar befintliga URL:er behöver de gamla adresserna kopplas till avsedda nya destinationer och kontrolleras efter flytten. Ange vem som tar fram adresslistan, vem som genomför ändringarna och vem som testar utfallet. Ta med viktiga kontaktflöden och sidor som måste vara fortsatt tillgängliga. SOVRA Digitals sida om webbutveckling beskriver arbetsgång och grundomfattning; den slutliga leveransen bestäms i offerten.

När URL:er ändras rekommenderar Google att gamla och nya adresser kartläggs, omdirigeringar genomförs och flytten följs upp. Googles vägledning om webbplatsflyttar ger underlag för den tekniska planen. Ett nytt utseende kräver inte i sig att fungerande adresser ändras.

Kravet kan därför vara att varje överenskommen gammal adress får den avsedda destinationen och att viktiga interna länkar pekar rätt. Kontrollera också att sidor som ska vara offentliga inte har kvar en spärr från testmiljön. Det är kontroller av leveransen, inte ett löfte om oförändrade positioner i sökresultaten.

Om kraven gäller innehåll på små skärmar visar guiden till mobilanpassning exempel på uppgifter och utfall som går att kontrollera. Använd exemplen för att formulera era egna krav, inte som en automatisk lista över vad varje webbprojekt omfattar.