Kravspecifikation för hemsida: mall, exempel och checklista

Börja med beslutet, inte funktionslistan

En kravspecifikation ska hjälpa beställaren att välja rätt omfattning och leverantör. Börja därför med varför hemsidan behövs, vilka människor den ska hjälpa och vilket beteende som ska bli möjligt. En lång lista med funktioner utan affärskoppling gör offerten svårare att tolka och ökar risken att olika leverantörer räknar på olika jobb.

Skriv först ett kort beslutsunderlag:

• vilket affärsproblem hemsidan ska lösa,
• vilka målgrupper och centrala användaruppgifter som prioriteras,
• vilka affärshändelser som visar att sidan hjälper,
• vem som äger beslut, innehåll och godkännande,
• vad som uttryckligen ligger utanför projektet.

Undvik garantier om trafik, ranking, leads eller försäljning. Kravet ska beskriva en verifierbar förutsättning eller leverans, inte lova ett utfall som påverkas av marknad, erbjudande och fortsatt arbete.

Formulera mål och användaruppgifter

Ett bra mål kopplar verksamhetens behov till något en besökare ska kunna göra. ”En modern hemsida” är en smakriktning. ”En inköpsansvarig ska kunna förstå erbjudandet, bedöma passform och skicka en kvalificerad förfrågan” är ett användbart jobb.

Dokumentera för varje prioriterad målgrupp:

1. situationen som tar personen till sidan,
2. frågan som måste besvaras först,
3. viktigaste uppgiften personen ska kunna slutföra,
4. vilket bevis som krävs för att våga gå vidare,
5. möjliga hinder, till exempel språk, tillgänglighet eller intern beslutsprocess.

Knyt sedan mätbehovet till affärshändelser som skickat formulär, klick till telefon, startad checkout eller nedladdat underlag. Själva implementationen av samtycke, datalager och spårning hör till ett separat mätjobb; kravspecifikationen ska ange vad verksamheten behöver kunna följa och vem som godkänner definitionerna.

Avgränsa scope så att offerterna avser samma jobb

Scope ska göra projektets gränser synliga. Lista sidtyper och ungefärligt innehållsansvar, inte bara ett löst sidantal. En tjänstesida, kategorihubb, kampanjsida och juridisk sida har olika krav även om de alla räknas som en sida.

Ange minst:

• sidtyper och vilka som kräver unik design eller mall,
• språk och eventuella marknadsvariationer,
• vem som skriver, faktagranskar och godkänner copy,
• befintligt innehåll som ska migreras, rensas eller omdirigeras,
• bild-, video-, logotyp- och rättighetsansvar,
• integrationer och datakällor,
• utbildning, dokumentation, drift och support efter lansering,
• uttryckliga avgränsningar.

Skriv beroenden bredvid omfattningen. Om produktdata, juridisk copy, domänåtkomst eller CRM-beslut måste komma från beställaren ska det synas före tidplan och pris bedöms.

Beskriv funktioner som behov och resultat

Lösningsneutrala funktionskrav anger vad användaren behöver kunna göra och hur det verifieras. De bestämmer inte plattform, plugin eller teknisk implementation innan leverantören har analyserat jobbet.

Skriv hellre ”redaktören ska kunna skapa en tjänstesida från en godkänd mall utan kod” än ”installera plugin X”. Teknik kan vara ett bindande krav när verksamheten har en verifierad arkitektur-, säkerhets- eller förvaltningsorsak. Ange då motivet och vem som äger beslutet.

Varje funktionellt krav bör ha:

• unikt krav-ID,
• behov eller önskat resultat,
• motiv och berörd användare,
• prioritet,
• ansvarig beslutsägare,
• acceptanskriterium,
• kommentar eller beroende.

Sätt acceptanskriterier på kvalitetskraven

Icke-funktionella krav beskriver hur väl lösningen ska fungera. Gör dem testbara och ange testmiljö, urval och ansvar. Ett absolut mål utan mätmetod är inte ett acceptanskriterium.

Tillgänglighet: ange vilka mallar och centrala flöden som ska granskas, vilken standard eller ambitionsnivå som används och hur tangentbord, fokus, formulärfel och kontrast verifieras.

Prestanda: ange representativa sidtyper, mobil och desktop, mätverktyg, testförutsättningar och vilken part som får åtgärda tredjepartsskript. Undvik att göra ett enskilt labbvärde till garanti för alla verkliga besök.

Säkerhet och integritet: ange roller, behörigheter, uppdateringsansvar, backup, återställning, loggning, personuppgifter, formulärdata, samtycke och incidentväg. Rätt ansvarig behöver bedöma juridiska krav; en webbchecklista är inte juridisk rådgivning.

SEO-förutsättningar: kräv redigerbara metadata, en tydlig rubrikhierarki, canonicals, indexeringskontroll, redirects, sitemap, strukturerad internlänkning och hantering av borttagna URL:er. Det skapar tekniska förutsättningar men är ingen rankinggaranti.

Förvaltbarhet: ange vad en redaktör ska kunna ändra, vilka komponenter som är låsta, dokumentation, utbildning, licenser, källfiler och hur lösningen lämnas över.

Prioritera med Must, Should, Could och Won’t

MoSCoW blir användbart när varje nivå får en tydlig betydelse:

• Must: utan kravet kan projektet inte godkännas eller det centrala användarjobbet inte slutföras.
• Should: hög nytta och planerat i scope, men det finns en accepterad tillfällig väg om kravet skjuts upp.
• Could: värdefullt endast om tid och budgetram tillåter efter Must och Should.
• Won’t nu: uttryckligen utanför denna leverans, men dokumenterat för att hindra antaganden.

Om nästan allt är Must saknas verklig prioritering. Be beslutsägaren välja vad som faktiskt stoppar lansering och vad som kan få en senare release.

Kopierbar mall för kravspecifikationen

Kopiera strukturen och fyll i den innan samma underlag skickas till alla leverantörer.

A. Projekt och affär

• Projektnamn och beslutsägare:
• Affärsproblem som ska lösas:
• Primära målgrupper:
• Tre viktigaste användaruppgifter:
• Önskade affärshändelser att kunna mäta:
• Budgetram eller beslutad modell för budgetdialog:
• Önskad lanseringsperiod och fasta beroenden:
• Uttryckligen utanför projektet:

B. Omfattning och ansvar

• Sidtyper, språk och marknader:
• Befintligt innehåll och migrering:
• Copy: producerar / granskar / godkänner:
• Media och rättigheter: producerar / tillhandahåller / godkänner:
• Integrationer, systemägare och åtkomster:
• Drift, support, utbildning och dokumentation:
• Domän, hosting, säkerhet och personuppgifter:

C. Kravtabell

Använd samma fält på varje rad:

Krav-ID | Behov eller önskat resultat | Motiv/användare | Prioritet | Ansvarig | Acceptanskriterium | Kommentar/beroende

D. Leverantörens svar

Be varje leverantör svara per krav-ID med:

Ingår / Ingår med antagande / Tillval / Ingår inte | Föreslagen lösning | Beroende från beställaren | Kostnads- eller tidsdrivare | Kommentar

Be också om projektorganisation, arbetssätt för ändringar, test och godkännande, licenser och tredjepartskostnader, överlämning, support samt vilka antaganden som offerten bygger på.

Ifyllt exempel på en kravrad

Krav-ID: FUN-04 Behov eller resultat: En redaktör ska kunna skapa och publicera en ny tjänstesida från en godkänd mall utan att skriva kod. Motiv/användare: Marknadsteamet behöver kunna förvalta erbjudandet efter lansering utan utvecklarberoende för normal publicering. Prioritet: Must. Ansvarig: Innehållsansvarig godkänner redaktörsflödet. Acceptanskriterium: I staging skapar en utsedd redaktör en sida med rubrik, ingress, bild med alt-text, CTA, metadata och relaterad länk; sidan kan förhandsgranskas, publiceras och återställas utan kod eller administratörsbehörighet. Kommentar/beroende: Beställaren tillhandahåller en redaktör för acceptanstest och godkänd exempelcopy.

Raden är verifierbar utan att låsa CMS eller komponentteknik. Leverantören kan föreslå lösning och samtidigt räkna på samma jobb som konkurrenterna.

Budget, tidplan och ändringshantering

En kravspecifikation behöver inte innehålla ett fabricerat fast belopp. Ange en budgetram om den finns, vilka delar som måste ingå och vilka faktorer som får ändra priset. Be leverantören skilja grundscope, tillval, licenser, drift och antaganden.

Tidplanen ska visa beslutspunkter och beroenden, inte bara ett slutdatum. Ange när innehåll, åtkomster och godkännanden måste finnas. Beskriv också hur en ändring hanteras: vem begär den, hur påverkan på scope, tid och kostnad dokumenteras och vem som godkänner innan arbetet startar.

Är underlaget redo att skickas till webbyrå?

Underlaget är redo när följande kan besvaras ja:

• Affärsmål, målgrupper och centrala användaruppgifter är namngivna.
• Sidtyper, innehåll, språk, migrering och avgränsningar är synliga.
• Funktioner är skrivna som behov med krav-ID och prioritet.
• Tillgänglighet, prestanda, säkerhet, SEO och förvaltning har testbara kriterier.
• Integrationer, data, behörigheter och systemägare är inventerade.
• Innehålls-, media-, beslut- och godkännandeansvar är fördelat.
• Budgetdialog, tidplan, beroenden och ändringsprocess är beskrivna.
• Alla leverantörer får samma svarsfält och antaganden.
• Minst en ansvarig person kan godkänna varje Must-krav.
• Won’t-listan gör det tydligt vad som inte ingår nu.

Om flera punkter saknas bör de lösas före offertförfrågan. Behövs stöd med förstudie, informationsarkitektur, design, utveckling och lansering kan webbyrå för en sammanhållen webbplatsleverans vara nästa steg.

Vanliga frågor