Der er mange forskellige måder at lave en kravspecifikation på. Hos Diviso har vi, over årene, forfinet hvordan vi udarbejder kravspecifikationer og nedenfor finder du nogle af de punkter vi typisk har med i en specifikation.

1. Formål og mål
   Det er vigtigt at definere formålet med løsningen og hvilken forretningsværdi den skal skabe. Dette kan hjælpe med at fokusere på de krav, der er vigtigst for at opnå målene.

2. Målgruppe
   Det er nyttigt at identificere målgruppen for løsningen, da dette kan påvirke designet og funktionerne i løsningen.
   Det kan være nyttigt at lave en persona for at beskrive typiske brugere af løsningen.

3. Projekt-deltagere
   Vi skriver typisk et lille afsnit omkring hvem projekt-deltagerne i projektet er - både hvem virksomheden er og hvem de enkelte personer og hvad deres rolle er.
   På den måde er det hurtigt og nemt at danne sig et overblik over hvilke deltagere/interessenter der er i projektet og deres kontakt-oplysninger også lige ved hånden

4. Teknisk setup
   I afsnittet "teknisk setup" beskriver vi typisk kravene til hosting-miljøerne - hos os vil det typisk være windows-miljøer for både hosting og database. Det er også i dette afsnit at vi kort opsummere hvilke "systemer" løsningen består af, eksempelvis "Frontend", "Backend", "API", "App" osv.

5. Overordnede krav
   Her bør du specificere de overordnede krav til løsningen, herunder de funktioner og kapaciteter, der er nødvendige, samt eventuelle tekniske krav, f.eks. kompatibilitet med specifikke enheder (skal appen kunne bruges på telefon, tablet, uden internet-forbindelse og lignende)

6. Detaljerede specifikationer
   Gå i dybden med de enkelte krav og beskriv dem så detaljeret som muligt. Det kan være nyttigt at opdele kravene i forskellige kategorier, f.eks. funktionskrav, ydeevnekrav og brugergrænsefladekrav.
   
   Funktionskrav beskriver de specifikke funktioner, der skal være tilgængelige i appen. Det kan være alt fra simple handlinger som at tilføje en opgave til en to-do-liste til mere komplekse funktioner som at integrere med andre systemer eller tjenester.

   Når du specificerer funktionskrav, bør du være så detaljeret som muligt og tænke på, hvad brugeren skal gøre for at udføre den pågældende funktion. Det kan være nyttigt at opdele funktionskravene i mindre dele og beskrive hver enkelt trin i processen.

   Her er et eksempel på en funktionskravspecifikation:

   Funktion: Tilføjelse af en opgave til en to-do-liste

   1. Brugeren skal kunne trykke på en knap for at åbne en formular til at tilføje en ny opgave
   2. Formularen skal indeholde et tekstfelt, hvor brugeren kan indtaste titlen på opgaven
   3. Formularen skal indeholde et dropdown-menu, hvor brugeren kan vælge en prioritet for opgaven (høj, medium, lav)
   4. Formularen skal indeholde en knap til at tilføje opgaven til listen
   5. Når opgaven er tilføjet, skal den vises på listen med den valgte prioritet.

   Det er vigtigt at huske, at funktionskravene skal være realistiske og afstemt med de øvrige krav i kravspecifikationen. Det kan også være nyttigt at inkludere eksempler på, hvordan funktionskravene skal bruges i appen, f.eks. gennem brugerhistorier eller scenarier.

7. Prioritering
   Det kan være umuligt at opfylde alle kravene på én gang, så det er vigtigt at prioritere dem. Markér de krav, der er absolut nødvendige, og de krav, der kan tilvælges hvis der er tid og budget til dem.

8. Test og validering
   Det er vigtigt at teste og validere kravene for at sikre, at de er komplette og realistiske. Det kan være nyttigt at involvere brugere og andre interessenter i denne proces. Vi tester og validerer kravene inden vi går i gang med estimering og eventuel udvikling, ved at drøfte dem, punkt for punkt.

9. Ændringer og opdateringer
   En kravspecifikation er en levende dokument, der kan ændres og opdateres undervejs i udviklingsprocessen. Det er derfor en god idé at dokumentere ændringer og opdateringer i kravspecifikationen.
   Der findes mange forskellige værktøjer til kravspecifikationer - hos os er de mest brugte Word og Excel.
   Versioneringen/historikken på specifikationerne klarer vi ved hjælp af Sharepoint og navngivning.