Krav på en e-handelsprogramvaru-plattform

Det är en bra idé att definiera dina krav utifrån den service, funktion eller egenskap som användaren kommer att behöva. Det är en bra idé att försöka sätta dig själv i användarens ställe när du definierar dina krav. Behöver du lägga till produkter i en kundvagn, köpa varor med ett kreditkort eller söka upp en order och få leveransinformationen? Tänk mer specifikt på kundresan och inte den slutliga destinationen.

Övergripande sett kan du skilja på två olika typer av krav. Funktionella krav definierar vad den enskilda funktionen eller egenskapen kräver. Ett krav kan vara möjligheten att besöka en webbutik eller att jämföra olika produkter. Sedan finns det icke-funktionella krav som definierar hur en lösning ska bete sig - till exempel att den kundvända funktionaliteten måste svara inom 2 sekunder.

När du har koll på vilka krav dina funktioner måste uppfylla kan du nu börja designa själva användarresan, som du vill leda din kund genom. Nu måste vi tänka, "Vi har våra krav och vet vad som behöver hända. Nu måste vi bestämma hur vi kommer dit".

Vi tittar ibland blint på strukturen hos mjukvaran utan att involvera användaren, men det viktigaste när du bygger din webbutiksplattform är att uppfylla användarens behov. Samtidigt är utvecklingsteamet beroende av användarna för att kunna utveckla produkten genom att följa deras steg. Därför kan det vara fördelaktigt att vända 180 grader och se funktionen från användarens perspektiv. På så sätt får du insikt i huruvida den specifika funktionen du bygger är värdefull för användaren som stöter på den.

INVEST-strategin är utmärkt att följa när du förbereder din användarhistoria. INVEST står för sex faktorer som kan bidra till en effektivare användarhistoria. Låt oss försöka sammanfatta definitionen:

(I)ndependent

Den specifika användarhistorien måste kunna fungera och utvecklas oberoende av andra användarhistorier.

(N)egotiable

Din användarhistoria måste vara förhandlingsbar och inleda dialog med kunden.

(V)aluable

Affärsvärdet av varje användarhistoria bör vara lätt igenkännbart, och var och en bör representera något värde för en specifik typ av användare.

(E)stimable

Det bör vara lätt att uppskatta, och användarhistorien bör möjliggöra att utvecklingsteamet bedömer komplexiteten i arbetet och ansträngningen som krävs.

(S)mall

Användarhistorier måste vara tillräckligt små för att kunna slutföras inom en sprint.

(T)estable

Det måste vara möjligt att testa lösningen för att säkerställa att den har utvecklats korrekt.

Vi har kort beskrivit de sex faktorerna som utgör INVEST-strategin. Om du använder strategin och identifierar de sex faktorerna har du en bra utgångspunkt för att förbereda användarhistorien. Viktigast av allt är användarhistorier kopplingspunkten mellan utvecklingsteamet och affärsinriktade personer som inte är lika tekniska. Att arbeta från en användarhistorieperspektiv gör beslutsfattande enklare, eftersom parter från olika fält är involverade.

Hur tar vi oss då från start till mål? Vi kan enkelt dela upp processen i delar som nämnts ovan.

1. Vad är det användaren vill uppnå på din webbplats?

2. Utveckla de funktionella kraven som gör detta möjligt.

3. Förbered de icke-funktionella kraven för att styra vad som behöver hända genom olika funktioner.

4. Förbered användarhistorien.

Letar du efter en ny partner med ett team av techexperter? Eller har du frågor om något gällande e-handelsstrategi?

Kom i kontakt med vår VD, Lotten Holmgren.

lotten@kruso.se

+46735124970