Funksjonelle og ikke-funksjonelle krav for netthandelsnettsted | Elogisk

De sier vellykkede bedrifter begynner med en idé. Vi sier at de alle begynner med funksjonelle og ikke-funksjonelle krav til e-handelsnettsteder.

Funksjonelle og ikke-funksjonelle krav er bærebjelken i prosjektet ditt. De artikulerer dine behov og ønsker og spesifiserer oppgavene for utviklingsteamet ditt. Du kan begynne å skrive dem ned like etter at du har utstedt RFP for e-handel å ha et klart bilde av nettstedet ditt når du velger en leverandør.

Alle våre prosjekter hos Elogic starter med en kort avklaring av kundens funksjonelle og ikke-funksjonelle krav til netthandelsprosjektet. Med mindre en klient sender en liste direkte til oss, utsteder vi et dokument som de skal fylle ut (se det som en nedlastbar bonus på slutten av artikkelen!). På denne måten er vi sikre på at vi forstår deres forretningsbehov, samtidig som kunden kan justere prosjektbudsjettet og omfanget og levere positive netthandelsopplevelser på nettsiden.

I denne artikkelen vil vi forklare forskjellen mellom funksjonelle og ikke-funksjonelle krav til netthandelssystemer og presentere en liste over de vanligste basert på våre kunders virkelige eksempler. Vi vil også dele noen tips om hvordan du organiserer kravene og hvordan de skal se ut.

Funksjonell vs ikke-funksjonell: Definisjon og forskjeller

Hovedforskjellen mellom funksjonelle og ikke-funksjonelle krav til e-handelsnettsteder ligger i deres omfang og formål.

Funksjonelle krav (FR) er hva av nettstedet ditt. Det handler om funksjonene og kjernedriften til e-butikken din som gjør det mulig for en bruker å handle på nettstedet. De kan implementeres som en enkelt nettsidefunksjon og danner grunnlaget for hele programvareutviklingsprosessen. 

Funksjonelle krav til et nettsted eksempler: Legg til følgende produktfiltreringsfunksjoner i nettbutikken vår for oppussing av hjemmet: pris, popularitet, effekthastighet (Watt), oppvarmingsområde (m2) og bruk (bad, kjøkken, osv.).

Ikke-funksjonelle krav (NFR) er hvordan av nettstedet ditt. Navngitte kvalitetsattributter til et system, danner brukeropplevelse og innebærer noen globale, abstrakte forventninger fra produktet. Ikke-funksjonelle krav til netthandelssystemer kan komme fra en sum av funksjonelle krav til et netthandelsnettsted og implementeres som en sum av nettfunksjoner.

Ikke-funksjonelle krav til eksempler på nettsteder for netthandel: Produktene skal være lette å finne og ha en tiltalende visning på nettstedet.

Insider tips: Justering og justering av kravene kan endre omfanget og budsjettet til prosjektet ditt.

Det anbefales ikke å spare på funksjonelle krav til netthandel som utgjør kjernen i prosjektet, så ikke vær redd for å se mange av dem i spesifikasjonsdokumentet for nettstedet ditt. Men pass på å legge sammen de ikke-funksjonelle kravene som vil øke kostnadene for prosjektet ditt. 

Les mer: Hva er forskjellen mellom e-handel og M-handel?

Hvis du har råd til det - flott! Butikken din vil være en kundemagnet som gir optimal brukeropplevelse. Hvis du derimot har trangt budsjett, bør du vurdere å legge til de essensielle ikke-funksjonelle kravene som vil tilfredsstille brukerne dine. Ideelt sett vil du finne den gyldne middelvei mellom funksjonelle og ikke-funksjonelle krav til et e-handelsnettsted og balansere dem med tanke på dine forretningsmål og mål.

Funksjonelle krav: Kjernen på nettstedet ditt

Ansvarlig for oppførselen til netthandelssystemet, funksjonelle krav kan være svært forskjellige avhengig av ens forretningsbehov og nisje. For eksempel lar motenettsteder vanligvis enkelte produktattributter velges av kunden (f.eks. farge, størrelse osv.); reiseselskaper kan kreve en chatbot som gir hjelp til brukeren; luksusvarer og smykker online virksomheter trenger en zoomefunksjon på en produktdetaljside (PDP).

Her er noen få sett med funksjonelle krav som må ha som gjelder for alle e-handelsnettsteder.

FR #1: Tredjepartsintegrasjoner

List opp all tredjepartsprogramvare som skal integreres via API som skal inkluderes på netthandelsnettstedet. Dette kan være de nye systemene du ønsker å legge til eller de eksisterende du er fornøyd med og bruker nå.

Dette kravet gjelder både systemer som effektiviserer forretningsdriften (som ERP, CRM, PIM) og fleksible betalingsgatewayer for kundene dine. Spesifisering av antall tredjepartsintegrasjoner vil gjøre din e-handelsarkitektur strukturert og klar for virksomhetsskalering i fremtiden.

FR #1 eksempler: 

• Nettstedet skal være integrert med Odoo ERP-system og Svea betalingsløsninger.
• PayPal Direct, PayPal Plus og Amazon Pay vil være prioritert betaling i butikken.

FR #2: Mobilvennlighet

Det er ingen hemmelighet at responsive mobilapper gir mer trafikk til nettstedet. I følge Statista, har antallet kundekonverteringer på mobile enheter også nådd de på stasjonære datamaskiner i USA. Så å investere i en mobil-responsiv funksjon på nettstedet ditt kan tjene deg mer enn noen få dollar, pluss lojale kunder som handler fra sofaen deres.

Studer målgruppen din og spør om enhetene deres. Spesifiser hvordan plasseringen av de essensielle knappene og alternativene på nettsider skal endres for en bedre handleopplevelse (insidertips: Plasser betalingsknappen innenfor kundens tommelfinger rekkevidde, for de fleste foretrekker å surfe på internett med bare én hånd fra mobile enheter). Ditt mobil-første funksjonskrav bør være presist for ikke å forvirre utviklerne.

FR #2 eksempels:

• PDP bør tilpasses skjermene til Apple iPhone 6s og nyere.
• Butikken min skal støtte talesøk av produkter på mobil via Alexa Mobile Accessory (AMA) Kit (note: dette er et av Amazons funksjonelle krav).

FR #3: Produktattributter

Din PDP vil inneholde ulike produktegenskaper, og utviklingsbyrået bør vite om dem for å implementere de tilsvarende funksjonene. Vil kunden kun kunne velge produktstørrelse og farge? Bruker du videoer på en PDP? Vil noen produktattributter vises i en meny (som i megameny)? Hvis det er mulig, skriv ut en liste over alle produktattributter nettstedet ditt skal ha og overgi det til utviklerne.

Produktattributter på vår klients PDP: størrelse, kjolelengde, mengde og farge. Kilde: Amsale.

FR #3 eksempler: 

• Nettstedet skal støtte enkle og pakkede produkttyper.
• Produktbilder på produktdetaljsiden bør ha muligheten til å zoome inn.

FR #4: Bestillings- og betalingsflyt

Dine funksjonskrav til et netthandelssystem bør spesifisere hvordan bestillingene behandles i butikken din og om denne funksjonaliteten skal optimaliseres. Spesielt angi om du vil at kunden skal registrere seg for å foreta et kjøp eller aktivere gjestekasse. List opp ordrestatusene du ønsker å ha (synlig både for kunden og butikkadministratoren). Forklar hvordan du vil administrere B2B-ordrer. Kort sagt, prøv å være så detaljert om bestillings- og betalingsflytfunksjonene som mulig. 

Dette er også delen der du nevner rabattpolicyen din og kampanjekodene du oppgir i handlebutikken din, hvis noen. Enten de skal håndteres i kassen eller direkte på PDP, bør du inkludere et eget funksjonskrav for dem.

FR #4 eksempler: 

• Nettstedet skal vise følgende ordrestatuser: bekreftet, behandlet, sendt, returnert.
• Etter at kunden er registrert på nettsiden, bør de få ett ekstra års garanti på den kjøpte bestillingen.

FR #5: Sosial deling

I e-handel går online tilstedeværelse sammen med sosiale medier. Å tillate en bruker å dele nettstedets innhold på sosiale medier fører til høyere merkevarebevissthet og bringer deg nærmere eksisterende og potensielle kunder. Undersøk målgruppen din og identifiser deres favoritt sosiale medienettverk. La forbrukerne dine dele produkter, blogginnlegg og inspirerende bilder ved å legge til en tilsvarende knapp på nettstedet ditt.

FR #5 eksempler: 

• Produktinformasjonen vår bør deles på Facebook, Instagram, Pinterest og Linkedin.
• Brukerkommentarer fra Facebook skal vises på produktdetaljsiden på siden "Kundeanmeldelser".

Vi følger selv den sosiale delingspraksisen hos Elogic. Hvis du føler deg sjenerøs (og litt smartere etter å ha lest denne artikkelen), hvorfor ikke dele den på sosiale medier!

Ikke-funksjonelle krav: Din nettside-flair

Som nevnt tidligere, artikulerer ikke-funksjonelle krav kvalitetsattributtene til nettstedet som bygger en positiv brukeropplevelse og optimal nettsideytelse. Bibelen til forretningsanalytikere - BABOK — skiller mellom NFR-er for selgere (f.eks. vedlikeholdbarhet, skalerbarhet, gjenbrukbarhet) og for brukere (f.eks. brukervennlighet, sikkerhet, tilgjengelighet). Etter vår mening er de alle like viktige på forskjellige stadier av forretningsreisen din: Ettersom butikken din skalerer, kan dine ikke-funksjonelle krav øke.

Her er noen grunnleggende typer ikke-funksjonelle krav for e-handelsnettsteder som bør gjøre det til nettstedets spesifikasjonsdokument for alle digitale virksomheter.

NFR #1: Brukervennlighet

Uansett størrelsen på virksomheten din, vil du at nettstedet skal være intuitivt og enkelt å bruke. Det tar omtrent 0.05 sekunder for brukere å finne ut om nettstedet ditt er verdt tiden og oppmerksomheten deres. Så du vil definitivt jobbe med hjemmesidedesign, handlingsfremmende oppfordringer og enkel betaling for å komme forbi disse millisekundene med undergang. Nettstedets brukervennlighet er også definert av

• hvor enkelt en bruker kan nå målet sitt på et enkelt sidebesøk;
• hvor raskt de utfører oppgavene i butikken;
• hvor minneverdig og intuitiv designet er;
• antall og tidspunkt for feil brukere gjør.

NFR #1 eksempler: 

• En kunde bør enkelt finne det riktige produktet for dem, forstå hvilke problemer det løser, og foreta et kjøp uten å kontakte oss.
• Ingen flertrinns utsjekking: brukere må nå "legg til i handlekurv"-knappen i ett trinn fra PDP.

NFR #2: Sikkerhet

Sikkerhet er viktig når du håndterer pengetransaksjoner og sensitive data. Enkle programvarekrav for netthandelsnettsteder som SSL-sertifisering og personvernpolitikk vil innpode tillit til nettstedet ditt og konvertere kundene til merkevaren din. Det handler også om forskjellige administratorroller som lar deg kontrollere hvem som kan opprette, se, kopiere, endre eller slette informasjon. Avhengig av bedriftens beliggenhet, betyr sikkerhet også å overholde reglene for kundedatabeskyttelse (eksempelvis: GDPR i Europa).

Det er mange faktorer som spiller inn når det kommer til sikkerhet; å spesifisere dette ikke-funksjonelle kravet betyr å ta det første skrittet til forebygging av e-handelssvindel.

NFR #2 eksempler: 

• Bare systemdataadministratoren kan tildele roller og endre tilgangstillatelser til systemet.
• Nettstedet må være motstandsdyktig mot alle typer angrep, inkludert DDoS- og XSS-angrep.

NFR #3: Ytelse

Hvis målet ditt er å øke trafikken til nettstedet ditt, bør ytelse være prioritet NFR i spesifikasjonsdokumentet. Denne NFR finnes ofte i truser fra store bedrifter eller nettsteder med eldre arkitektur: de vil at e-butikkene deres skal lastes raskt uansett antall integrasjoner og salgssesonger.

Sett opp hastighetsreferansen, et maksimalt antall SKU-er som skal legges til, eller en annen ytelsesindikator som passer for virksomheten din. Ikke inkluder leveringstid for tredjepartssystem; utviklerne dine kan ikke gjøre mye hvis en bestemt virksomhet er avhengig av et API-kall til en annen database.

NFR #3 eksempel: Nettstedets hjemmeside skal lastes på mindre enn 4 sekunder på iOS 10+, Safari på 4G.

NFR #4: Vedlikehold

Det er allment kjent at den vanskelige delen av å planlegge et forretningsbudsjett er å ta hensyn til driftskostnadene ved vedlikehold av virksomheten. Å strebe etter å gjøre nettstedet vedlikeholdbart fra den første utviklingsfasen betyr å kutte tid og kostnader for å identifisere og løse systemfeilene i fremtiden. Hvor trist det enn kan virke, er det ingen unnslippe fra fremtidige problemer, og du kan se mange signaler på hvordan vedlikeholde et e-handelsnettsted. Men din oppgave er å gjøre systemet enkelt å vedlikeholde helt fra det lanseres.

NFR #4 eksempel: Fordi vi ønsker å vokse, skal nettstedet fjerne all backend-kompleksiteten for interne ingeniører for å gjøre endringer i systemet i fremtiden.

NFR #5: Skalerbarhet

Hvis du ser etter en fremtidssikker løsning, bør skalerbarhet være ditt valg. Dette kravet definerer hvordan nettstedet kan vokse og utvide funksjonaliteten uten å påvirke ytelsen. Du bør kunne legge til mer minne, servere eller diskplass for å fullføre flere transaksjoner på nettstedet ditt.

På serversiden vil du kanskje legge til lokaliseringsfunksjoner i tilfelle du planlegger å gå inn i nye markeder og selge produkter internasjonalt. Totalt sett står denne NFR for smertefri forretningsutvidelse og har både maskinvare- og programvareimplikasjoner.

NFR #5 eksempler: 

• Vårt hovedmål for de neste to årene er internasjonalisering, så nettstedet skal ha flere butikkvisninger for hvert land vi selger til.
• Butikken skal utvides til å støtte 500k+ SKUer på en enkelt server uten negativ innvirkning på nettsidens lastehastighet.

Utforming av din første brief

Så du har bestemt deg for noen funksjonelle og ikke-funksjonelle krav til et e-handelsnettsted; hva nå? Du presenterer dine behov og synspunkter på prosjektet på papir! 

Når en klient kontakter oss i Elogic for tjenester for utvikling av netthandel, vi ønsker å gi en kortfattet beskrivelse. Det hjelper kundene våre med å gjøre opp en mening om kravlisten deres for netthandel og gi oss et klart bilde av hva de ønsker å se. I likhet med RFP er en brief organisert i et regneark med kategorispesifikke spørsmål i faner. Avhengig av typen prosjekt (nettstedsutvikling fra bunnen av, replattforming, utvikling av tilpasset modul, etc.), vil briefen inneholde ulike spørsmål som tar sikte på å avdekke ulike forretningsbehov.

Tips for å dokumentere funksjonelle og ikke-funksjonelle krav til nettstedet for netthandel

For å avslutte denne diskusjonen, vil vi gjerne dele tre nøkler til riktig formulerte krav til netthandelsnettsteder.

1. Vær spesifikk. Dette tipset kan være åpenbart, men må understrekes. Ikke la din bevissthetsstrøm ta over kortene og kombinere mange krav til ett. Hold dem i stedet granulerte og artikuler dem nøyaktig. Tro oss, å gå fra "vi ønsker å bruke en ERP og en PIM" til "Nettstedet skal bruke SAP ERP og Fishbowl Inventory" gjør mye forskjell for utviklere.

2. Gjør dem målbare. KPIer er subjektive og varierer fra virksomhet til virksomhet. Men du må finne dine og skrive dem inn i dine krav. Ikke bare si et generisk "Jeg vil ha en hurtiglastende nettside", men spesifiser din ideelle lastetid i et bestemt brukstilfelle. Snakk tall når det er mulig, og legg til et mål til kravet ditt når du kan. Utviklerne dine vil teste funksjonen mye raskere mot den angitte referansen, og du vil alltid holde fingeren på pulsen til prosjektet.

3. Juster kravene til utvikling av e-handelsnettsteder med forretningsmål. Du kan legge sammen mange spesifikasjoner og bruke hele budsjettet på nettsidens funksjoner; men med mindre de alle er kartlagt med et større mål i tankene, vil sluttproduktet ditt være utilfredsstillende.

Til slutt, få funksjonelle og ikke-funksjonelle krav til et e-handelsnettsted til å fungere for deg, ikke omvendt. Hvis du fyller ut kort og tydelig formulerer spesifikasjonene dine, vil du spare tid og krefter. Svar på utviklernes spørsmål før de i det hele tatt stiller dem og gå live raskere!

Hvis du er interessert i å utvikle en e-handelsbutikk på en hvilken som helst plattform eller oppgradere, optimalisere eller integrere den eksisterende, Elogisk er her for deg.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Bil / elbiler, Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• BlockOffsets. Modernisering av eierskap for miljøkompensasjon. Tilgang her.
• kilde: https://elogic.co/blog/functional-and-non-functional-requirements-for-ecommerce-websites/