Sådan laver I en kravspecifikation for jeres app
Skal I have udviklet en app, men er I i tvivl om, hvad den egentlig skal kunne? Så er en kravspecifikation det første vigtige skridt. Den hjælper jer med at sætte ord på, hvad appen skal kunne, og den giver vores projektledere og udviklere et langt bedre grundlag for at rådgive jer, estimere omfanget og sætte gang i projektet.
Hos itpilot får vi løbende henvendelser om app-udvikling. Nogle har kun en idé på tegnebrættet, mens andre allerede har lavet en detaljeret kravliste. Uanset hvor langt I er, hjælper vi jer videre.
Når I henvender jer, kan I forvente et professionelt forløb - fra idé til færdigudviklet app (læs mere om processen her). Vi udarbejder altid kravspecifikationen sammen med jer, og vi sørger for, at den bliver et brugbart arbejdsredskab gennem hele udviklingsprocessen.
Hvis I vil forberede jer inden I kontakter os, kan I med fordel tage udgangspunkt i listen nedenfor. Den rummer typiske emner, der er relevante i arbejdet med en kravspecifikation, både når det gælder funktioner, flows, brugertyper, tekniske krav og test. Det er ikke sikkert, alle punkter er relevante for netop jeres app, men det er en god ramme til at skabe overblik – både for jer selv og for os, når vi skal rådgive jer og give en realistisk prisindikation.
Hvad er en kravspecifikation, og hvorfor er den vigtig?
En kravspecifikation er en struktureret beskrivelse af, hvad en app skal kunne, hvordan den skal fungere, og hvilke rammer der gælder. Selvom det lyder teknisk, handler det i praksis om at skabe overblik og undgå misforståelser allerede fra start.
En god kravspecifikation sikrer, at alle parter er enige om, hvad der skal udvikles, og hvordan appen skal fungere. Det skaber fælles forventninger og gør det lettere at planlægge, prioritere og samarbejde.
Undervejs i et udviklingsprojekt opstår der ofte nye idéer, og det er helt naturligt. Nogle idéer kan måske integreres undervejs, andre kan kræve ændringer i scope og budget. Her fungerer kravspecifikationen som et vigtigt værktøj: Den gør det tydeligt, hvad der oprindeligt er aftalt, og hvad der eventuelt er nye ønsker eller tilføjelser.
Hvad bør en kravspecifikation indeholde?
En kravspecifikation kan se ud på mange måder alt afhængigt af, hvilken type app I skal have udviklet, hvem målgruppen er, og hvordan appen skal bruges. Der findes ikke én rigtig opskrift. Alligevel er der nogle grundelementer, som næsten altid er relevante at overveje.
For at gøre det lettere at komme i gang, har vi samlet en liste over typiske elementer og spørgsmål. Listen er ikke en tjekliste, der nødvendigvis skal udfyldes punkt for punkt, men den kan give jer et godt udgangspunkt for at få styr på funktioner, flows, krav og forventninger.
Listen er også en hjælp til os: Jo bedre vi forstår jeres behov og prioriteter, desto bedre kan vi rådgive jer og give en realistisk prisindikation for udviklingsarbejdet.
Indled kravspecifikationen med en kort og klar beskrivelse af, hvad appen skal kunne. Hvad er det overordnede formål med appen, og hvem skal bruge den? Det er her, I sætter rammen for resten af projektet – både i forhold til funktion, målgruppe og forretningsværdi. Jo tydeligere formål og kontekst, jo nemmere bliver det at træffe de rigtige tekniske og designmæssige valg.
- Hvad er appens formål? (fx “forenkle booking af lokaler”, “holde styr på medarbejdernes arbejdstid/arbejdsopgaver”, “forbinde bilejere med værksteder”, ”forenkle dokumentationsarbejdet for arbejdsopgaver”)
- Hvem er appens primære målgruppe?
- Hvilket problem skal appen løse?
- Hvilken type app er der tale om? (native, webapp, hybrid mv.)
- Skal appen bruges internt i virksomheden, eller er det et kommercielt produkt?
- Hvilke platforme skal appen fungere på? (iOS, Android, browser, tablet osv.)
Her beskriver I de grundlæggende rammer og forudsætninger, som appen skal udvikles under. Det kan være alt fra strategiske hensyn til sprogkrav, tilgængelighed, designmanualer eller en bestemt lanceringsdato. Disse forhold er ofte styrende for projektets retning og omfang og bør derfor være tydeligt formuleret fra start.
- Skal der tages hensyn til en eksisterende forretningsmodel, strategi eller branding?
- Hvilket sprog skal appen være på? Skal den understøtte flere sprog?
- Er der krav om tilgængelighed (WCAG, skærmlæsere, farvekontraster)?
- Skal appen følge bestemte designmanualer eller tekniske standarder?
- Skal appen lanceres på et bestemt tidspunkt?
- Har I et budget eller en økonomisk ramme for projektet?
Dette afsnit danner kernen i kravspecifikationen. Her beskriver I, hvilke funktioner og handlinger appens brugere skal kunne foretage. Det gælder både basale funktioner (som login og profil) og mere specifikke flows (som bookinger eller opgavestyring). Det er også her, I definerer brugerroller og forskelle i adgang eller funktionalitet. Vær så konkret som muligt, da det er med til at skabe en fælles forståelse og afstemme forventningerne til løsningen.
- Hvilke funktioner skal appen indeholde? (fx login, profil, kalender, søgning, notifikationer, betaling)
- Skal der være forskellige brugerroller (fx administrator, redaktør, bruger, partner)?
- Hvad kan hver rolle se og gøre?
- Er der brug for onboarding af nye brugere?
- Hvilke flows er centrale? (fx “opret en booking”, “indsend en opgave”, “bestil en tid”)
- Skal brugeren kunne modtage beskeder eller påmindelser (push eller e-mail)?
- Skal appen fungere offline i visse situationer?
I dette afsnit samles alle de tekniske og driftsmæssige krav, der ikke handler om funktionalitet, men som har stor betydning for appens kvalitet og stabilitet. Det kan være krav til ydeevne, oppetid, sikkerhed, offline-funktionalitet og vedligeholdelse. Disse krav er ofte afgørende for en robust og langsigtet løsning – især hvis appen skal bruges i kritiske eller professionelle sammenhænge.
- Skal appen kunne håndtere mange samtidige brugere?
- Skal der være høj oppetid (f.eks. 99,9%)?
- Er der krav til svartid og performance?
- Hvordan skal appen opdateres og vedligeholdes?
- Skal appen kunne fungere offline/delvist offline?
- Hvilke krav har I til sikkerhed (datakryptering, session timeout, adgangskontrol)?
- Skal appen kunne versionstyres, og ønskes der mulighed for rollback?
Hvis appen skal udveksle data med andre systemer, er det vigtigt at afklare, hvilke integrationer der er nødvendige. Det kan være alt fra login med MitID til integrationer med ERP-systemer, betalingsløsninger eller kalendere. Her bør det også fremgå, om der findes eksisterende API’er, og om der er adgang til dokumentation. Tydelige krav til integrationer sikrer, at systemet hænger sammen med jeres øvrige it-landskab.
- Skal appen hente eller sende data til andre systemer? (ERP, CRM, betalingsgateway, kalendersystemer, mv.)
- Skal brugeren kunne logge ind via fx Microsoft, Google eller MitID?
- Er der eksisterende API’er, som skal bruges, og har I dokumentation?
- Skal appen kunne håndtere webhooks eller synkronisering med eksterne databaser?
- Er der behov for integration med hardware (fx Bluetooth-enheder, QR-scannere, kamera)?
Husk også at notere, hvis nogle integrationer først skal implementeres i en senere fase – det kan være med til at styre projektets scope og prioriteter.
Data er ofte kernen i en app og samtidig et område med mange krav og hensyn. I dette afsnit beskriver I, hvilke typer data appen skal håndtere (fx persondata, lokationsdata, følsomme oplysninger), hvordan data lagres og beskyttes, samt hvordan I overholder lovgivning som GDPR. Det er også vigtigt at afklare, hvem der har adgang til hvad, og om brugeren selv skal kunne administrere sine data.
- Hvilke typer data håndteres? (persondata, lokationsdata, følsomme oplysninger?)
- Hvor lagres data – lokalt, i skyen eller på egne servere?
- Skal der være samtykke og informeret brug af data (GDPR)?
- Skal brugere kunne slette eller eksportere egne data?
- Hvem har adgang til hvilke data?
- Skal der være logning af handlinger i systemet?
- Skal data anonymiseres, pseudonymiseres eller krypteres?
Appens design og brugeroplevelse har stor betydning for, om den bliver en succes. I denne sektion beskriver I jeres ønsker og krav til det visuelle udtryk og den måde, brugeren navigerer i appen på. Har I en designretning, I ønsker at følge? Skal der laves wireframes eller mockups, eller har I allerede nogle klar? Det er også her, I kan beskrive navigation, skærmopbygning og inspiration fra andre løsninger.
- Har I idéer til, hvordan appen skal se ud? (farver, stil, tone of voice)
- Skal I bruge wireframes eller mockups, og har I evt. allerede noget på tegnebrættet?
- Er der lignende apps, I er inspireret af?
- Hvilke elementer skal være tilgængelige på forsiden/skærmbilledet?
- Hvordan skal navigationen fungere? (bundmenu, burger-menu, swipe osv.)
- Skal layout tilpasses forskellige skærmstørrelser?
- Skal I have hjælp til UX/UI-design fra os?
En god kravspecifikation bør ikke kun opremse funktioner, men også beskrive, hvordan appen bruges i praksis. Brugsscenarier (use cases) og flows viser konkrete situationer, hvor appen skal løse en opgave set fra brugerens perspektiv.
Det hjælper både jer og udviklingsteamet med at forstå behovene bedre, spotte mangler og sikre sammenhæng i funktionerne. Brug også denne sektion til at illustrere komplekse flows og identificere kritiske trin, hvor brugeren kan opleve forvirring eller fejl.
- Brugsscenarier for hver brugergruppe (fx elev, lærer, administrator)
- Trin-for-trin flows for vigtige handlinger (fx oprette booking, afmelde deltagelse, indsendelse af dokumentation)
- Forventet brugeradfærd og kontekst (hvor, hvornår og hvorfor bruger man appen)
- Beskrivelse af edge cases og undtagelser
- Relation til funktionelle krav og hvordan flows understøtter disse
Tidlig afklaring af teststrategi og kvalitetskrav gør det lettere at udvikle en stabil og sikker løsning. Dette afsnit handler om, hvordan vi i fællesskab skal sikre, at appen fungerer korrekt, og at kravene faktisk bliver opfyldt.
- Krav til automatiske og manuelle tests
- Roller og ansvar for test (fx leverandør vs. kunden)
- Brugertests og testscenarier baseret på use cases
- Forventninger til stabilitet og fejlmargin ved aflevering
- Krav til testdata og testmiljøer
- Acceptkriterier og godkendelsesproces
Jeres kravspecifikation skal ikke være perfekt
… men det betaler sig at tænke tingene igennem.
Vi forventer ikke, at I har styr på alle detaljer, når I kontakter os, og I behøver bestemt ikke have en færdig kravspecifikation klar. Men det er en fordel, hvis I på forhånd har gjort jer nogle overvejelser om, hvad appen skal kunne, og hvem der skal bruge den.
Jo mere I har tænkt igennem, desto nemmere er det for os at forstå jeres behov og komme med kvalificerede input – både når det gælder funktionalitet, arkitektur, tekniske valg og videreudviklingsmuligheder.
Som nævnt tidligere udarbejder vi altid den endelige kravspecifikation i tæt samarbejde med jer. Det sikrer, at vi har et fælles udgangspunkt, inden vi går videre til design, udvikling og test.
Skal vi hjælpe jer med at udvikle en app?
Hos itpilot har vi mange års erfaring med at udvikle apps, både som selvstændige løsninger og som en del af større systemer. Vi hjælper jer hele vejen fra idé og kravspecifikation til design, udvikling og implementering.
Uanset om I har en konkret idé eller blot er i gang med de første overvejelser, tager vi gerne en uforpligtende snak om jeres muligheder. Kontakt os i dag for en uforpligtende snak, så finder vi sammen ud af, hvordan jeres app-projekt bedst kommer i mål.
Ring til os på 87 25 07 87 eller udfyld kontaktformularen.
