Kravspecifikation för app: mall, exempel och checklista

Börja med problemet och beslutet

En kravspecifikation ska skapa ett gemensamt beslutsunderlag före discovery, offert eller utvecklingsstart. Börja inte med en önskelista över teknik. Beskriv vilket problem som finns i dag, vem som upplever det och vilken förändring appen ska möjliggöra. ”Vi behöver en modern app” går inte att testa. ”En fälttekniker ska kunna registrera ett slutfört uppdrag där täckningen saknas och synkronisera det senare” avgränsar däremot ett verkligt användarjobb.

Sammanfatta först:

• verksamhetsproblemet och varför det behöver lösas nu,
• primära användargrupper och deras mobila situation,
• de tre viktigaste användarresorna,
• önskad effekt och vilka händelser verksamheten behöver kunna följa,
• beslutsägare, sakägare och den som godkänner release,
• vad som uttryckligen inte ingår i första versionen.

Skilj effekt från leverans. Kravet kan ange att en händelse ska loggas med en godkänd definition, men bör inte garantera adoption, intäkt eller annan effekt som även beror på införande, marknad och användarbeteende. Uppge inte ett påhittat pris eller slutdatum. Dokumentera budgetram, tidsfönster och fasta beroenden endast när de faktiskt är beslutade.

Kartlägg användare, roller och mobil kontext

En app används ofta under andra villkor än ett internt system på stor skärm. Beskriv om användaren går, kör, bär handskar, har svag uppkoppling, delar enhet eller behöver agera snabbt. Ange enhetstyper och operativsystem som ska stödjas först efter att användarbehov och förvaltningsförmåga är kända.

För varje roll dokumenteras:

1. vad personen försöker få gjort,
2. när och var uppgiften utförs,
3. vilken information personen behöver se eller registrera,
4. vilka rättigheter rollen har,
5. vanliga fel, avbrott och återupptaganden,
6. vad som är känsligt eller säkerhetskritiskt.

Skilj slutanvändare från administratör, support, systemägare och eventuell granskare. En rollmatris bör visa vem som får läsa, skapa, ändra, exportera och radera data. Om svaret saknas skrivs TBD, ansvarig och sista beslutsdatum; behörighet får inte lösas genom ett dolt antagande.

Beskriv användarresor och user stories

Börja med ett fåtal sammanhängande flöden i stället för fristående skärmar. Ett flöde ska ha startläge, användarens steg, systemets svar, felvägar och ett tydligt slutläge. Ta med första användning, inloggning, huvuduppgift, återhämtning efter avbrott och utloggning eller kontoborttagning där det är relevant.

En user story kan skrivas: ”Fältteknikern behöver kunna spara en rapport utan nät för att undvika dubbelarbete.” Den förklarar behovet men är inte komplett utan acceptanskriterier. Lägg till databehov, prioritet, ansvar och verifiering. Skisser eller en klickbar prototyp kan förtydliga flödet, men ska versionsmärkas och inte automatiskt betraktas som godkända krav.

Appspecifikt exempel:

Story: Medlemmen behöver kunna aktivera notiser för ändrad bokning utan att samtidigt godkänna marknadsföring. Motiv: Driftinformation och marknadsmedgivande är skilda val. Avgränsning: Personliga erbjudanden ingår inte i första release. Beroende: Beställaren fastställer meddelandekategorier och ansvarig granskar integritetsflödet.

Skriv funktionella krav utan onödig tekniklåsning

Funktionella krav beskriver vad användaren eller systemet ska kunna göra. Skriv ”användaren ska kunna återuppta ett avbrutet utkast” hellre än att bestämma en specifik lokal databas. Teknik kan vara bindande om en verifierad arkitektur-, säkerhets-, distributions- eller förvaltningsorsak finns. Ange då orsaken och vem som äger beslutet.

Varje kravrad bör innehålla:

• unikt krav-ID,
• behov eller önskat resultat,
• berörd roll och motiv,
• prioritet,
• acceptanskriterium,
• ansvarig godkännare,
• beroenden, antaganden och status.

Gruppera exempelvis konto och autentisering, profil, sökning, huvudflöde, aviseringar, betalning, delning, administration och support. Det betyder inte att alla grupper måste ingå. Tvärtom ska en tydlig Won’t-lista hindra att funktioner smyger in som underförstått scope.

Gör kvalitetskraven testbara

Icke-funktionella krav beskriver hur väl appen ska fungera. Orden ”snabb”, ”säker” och ”skalbar” är otillräckliga utan mätmetod, testmiljö, urval och ansvar.

Prestanda och tillförlitlighet: ange centrala flöden, representativa enheter, nätförhållanden, datamängd och hur starttid, svarstid, krascher eller återhämtning mäts. Ett labbtest är inte en garanti för alla verkliga enheter.

Offline och synkronisering: ange vad som kan läsas och ändras utan nät, hur länge data lagras lokalt, hur användaren ser synkstatus och hur konflikter hanteras. Bestäm också vad som händer om appen stängs under en pågående uppladdning.

Säkerhet och integritet: inventera personuppgifter, lagringsplatser, autentisering, sessionshantering, kryptering, loggar, export, radering, incidentväg och åtkomst för support. Juridiskt och säkerhetsmässigt ansvariga behöver bedöma tillämpliga krav; mallen är inte juridisk rådgivning.

Tillgänglighet: ange centrala flöden och hur exempelvis skärmläsare, dynamisk textstorlek, fokusordning, kontrast, rörelse, felmeddelanden och alternativa inmatningssätt verifieras på valda plattformar.

Kompatibilitet och distribution: definiera stödda versioner och enheter, orientering, uppgraderingsväg, appbutikskonton, signering, granskningsansvar och hantering av utfasade versioner. Appbutikens godkännande bör inte beskrivas som garanterat.

Skalbarhet och drift: ange rimliga testscenarier, övervakning, larm, backup, återställning och ansvar. Skriv TBD – produktägare beslutar efter verifierad volymdata om underlaget ännu saknas.

Inventera data, integrationer och autentisering

En app är sällan isolerad. Lista API:er, identitetsleverantörer, betalning, kartor, meddelandetjänster, analys, backend och administrativa system. För varje beroende anges systemägare, miljöer, dokumentation, åtkomst, dataformat, begränsningar, testdata och vem som bekostar eller godkänner tredjepartstjänsten.

Beskriv datan per flöde: källa, mottagare, ändamål, känslighet, lagring, gallring och felhantering. Ange vad användaren ser när en integration är otillgänglig. Hemliga nycklar, verkliga personuppgifter eller produktionsåtkomster ska inte klistras in i kravdokumentet.

Autentisering behöver omfatta registrering eller tilldelning av konto, inloggning, återställning, eventuell multifaktor, sessionslängd, spärr och avslut. Om organisationen ännu inte valt identitetslösning anges behovet, beslutets ägare och när valet måste vara klart.

Prioritera första release med MoSCoW

Prioritering gör scope förhandlingsbart utan att förlora kärnan:

• Must: utan kravet kan kärnresan eller releasegodkännandet inte slutföras.
• Should: hög nytta och planerat, men en accepterad tillfällig väg finns.
• Could: tas bara med om tid och budgetram återstår efter Must och Should.
• Won’t nu: uttryckligen utanför denna release och dokumenterat för framtida bedömning.

Om nästan allt är Must har teamet inte prioriterat. Be beslutsägaren identifiera minsta sammanhängande release, inte minsta antal skärmar. En app som kan logga in men inte slutföra huvuduppgiften är ingen användbar första release. Ange även avgränsningar som surfplatteanpassning, offline, betalning, flera språk eller avancerad administration när de inte ingår.

Skriv verifierbara acceptanskriterier

Ett acceptanskriterium ska kunna ge ett tydligt godkänt eller underkänt resultat. Ange förutsättning, handling och observerbart utfall samt relevant enhet, miljö och roll. Undvik kriterier som ”fungerar bra” eller ”har modern UX”.

Ifylld kravrad: Krav-ID: OFF-03 Behov/resultat: Fältteknikern ska kunna spara en slutförd rapport när nät saknas och synkronisera den senare. Prioritet: Must. Godkännare: Produktägaren godkänner tillsammans med utsedd fälttekniker. Acceptanskriterium: På en stödd testenhet i flygplansläge fyller användaren i obligatoriska fält, bifogar en testbild och väljer Spara. Rapporten visas som ”Väntar på synk”. När nätet återkommer och synk startas lagras rapporten en gång i testmiljön, status ändras till ”Synkroniserad” och användaren kan öppna samma innehåll efter omstart. Beroende: Test-API och regel för synkroniseringskonflikt ska vara beslutade före acceptanstest.

Komplettera med negativa fall: ogiltig data, nekad behörighet, timeout, dubbla tryck och avbruten uppladdning. Leverantören bör ange hur kriteriet testas och vilket underlag beställaren måste tillhandahålla.

Hantera okänt och TBD utan att gissa

Okända uppgifter är normala före discovery. De blir risker först när de göms. Skriv inte ett påhittat svar för att dokumentet ska se komplett ut. Använd en beslutslogg med:

TBD-ID | Fråga | Varför beslutet behövs | Ansvarig | Underlag som krävs | Senast beslutsdatum | Påverkat krav | Status

Klassificera varje TBD som blockerande före offert, blockerande före utveckling eller möjlig att besluta senare. Exempel: TBD-07 | Minsta stödda Android-version | Produktägare | Enhetsstatistik och förvaltningspolicy | Före tekniskt lösningsförslag | KOMP-02 | Öppen.

Be leverantörer prissätta eller planera osäkerhet öppet: vilket antagande de använder, hur alternativ påverkar omfattningen och när beslutet krävs. En tydlig TBD är bättre än att olika leverantörer gör olika tysta antaganden.

Kopierbar mall för kravspecifikation av app

Kopiera följande struktur och fyll i samma version innan den skickas till leverantörer.

A. Projekt och effekt

• Projektnamn, dokumentversion och beslutsägare:
• Problem och nuläge:
• Primära användare och mobil kontext:
• Tre viktigaste användarresor:
• Önskad effekt och mätbara händelser:
• Budgetram eller modell för budgetdialog:
• Önskat releasefönster och fasta beroenden:
• Utanför första release:

B. Plattform, UX och data

• Plattformar, versioner och enheter – beslutat eller TBD:
• Roller och behörigheter:
• Flöden, skisser, prototyp och grafisk identitet:
• Offline, synkronisering och aviseringar:
• Data, personuppgifter, lagring och gallring:
• API:er, integrationer, systemägare och åtkomst:
• Autentisering och kontolivscykel:
• Tillgänglighet, säkerhet, prestanda och tillförlitlighet:

C. Kravtabell

Krav-ID | Behov/resultat | Roll/motiv | Prioritet | Acceptanskriterium | Godkännare | Beroende/antagande | Status

D. TBD- och beslutslogg

TBD-ID | Fråga | Beslutsägare | Krävt underlag | Deadline | Påverkade krav | Status

E. Leverantörens svar

Krav-ID | Ingår / antagande / tillval / ingår inte | Föreslagen lösning | Beställarberoende | Tids- eller kostnadsdrivare | Testmetod | Kommentar

Be även om team och ansvar, arbetssätt för discovery och ändringar, designleverabler, test och release, tredjepartslicenser, källkod och immateriella rättigheter, appbutikskonton, dokumentation, överlämning, drift, support och vidareutveckling. Juridiska villkor ska granskas av rätt kompetens.

Kontroll före offertförfrågan

Underlaget är redo att jämföras när följande kan besvaras ja:

• Problem, användare, roller och huvudresor är tydliga.
• Första release och Won’t-listan bildar en begriplig gräns.
• Varje viktigt krav har ID, prioritet, ägare och acceptanskriterium.
• Offline, felvägar, aviseringar och enhetskontext är bedömda.
• Plattformar och kompatibilitet är beslutade eller märkta TBD.
• Data, integrationer, API:er och autentisering har ägare.
• Säkerhet, integritet, tillgänglighet och prestanda har testmetod.
• Skisser och prototyper har status och versionsnummer.
• Budget- och tidsuppgifter är verkliga ramar, inte fabricerade löften.
• Leverantörer får identiska svarsfält och synliga antaganden.
• Lansering, appbutiker, drift, support och överlämning är fördelade.
• Varje blockerande TBD har ansvarig och deadline.

Om flera punkter saknas bör de lösas i en avgränsad discovery innan ett fast scope jämförs. För stöd från behovsanalys och UX till teknik, test och release kan apputveckling med sammanhållen leverans vara nästa steg.

Vanliga frågor