Kort svar
Vad ska en kravspecifikation för en app innehålla?
Vem appen är till för, vilka uppgifter de ska kunna utföra, vilken data som finns i botten, vilka system den ska prata med och vad som ska vara klart till lansering. Beskriv flöden och regler — inte tekniska val.
Fem tydliga sidor ger bättre offerter än trettio sidor funktionslista. Har du inget alls skrivet är det heller inget hinder: då formulerar vi omfattningen tillsammans i förstudien.
Beskriv uppgifter, inte funktioner
En funktionslista säger "appen ska ha en kalender". Det går att bygga på tio olika sätt, varav nio är fel. Ett flöde säger i stället: "En montör ser dagens jobb i tidsordning, öppnar ett jobb, markerar det som påbörjat, fotograferar resultatet och stänger det med en kommentar." Där finns skärmarna, datan, behörigheterna och de fall som kan gå fel.
Skriv fem till tio sådana flöden. De blir grunden för både offerten och testningen.
Innehållet, punkt för punkt
| Del | Vad du skriver | Varför |
|---|---|---|
| Bakgrund | Vad ni gör i dag och varför det inte fungerar | Utvecklaren kan föreslå enklare lösningar än den ni tänkt er |
| Målgrupp | Vilka som ska använda appen och i vilken situation | Avgör design, offline-krav och hur mycket utbildning som behövs |
| Användarflöden | Fem till tio flöden i löpande text | Den viktigaste delen — här ligger omfattningen |
| Roller | Vem får se och göra vad | Behörigheter är en stor kostnadsdrivare |
| Data | Vilka begrepp som finns: kund, order, jobb, faktura | Datamodellen styr allt annat |
| Integrationer | Vilka system, om de har API, vem som äger dem | Vanligaste orsaken till förseningar |
| Icke-funktionella krav | Antal användare, svarstider, offline, datalagring inom EU | Påverkar arkitekturen mer än funktionerna gör |
| Avgränsning | Vad som uttryckligen inte ska ingå | Gör offerter jämförbara |
| Tidplan och budget | Målbild och ram | Utan ram får du förslag i fel storleksordning |
Vad du inte ska skriva
- Teknikval. Kräv inte ett visst ramverk eller en viss databas om det inte finns ett verkligt skäl — det är utvecklarens jobb att föreslå och motivera.
- Pixelnivå. Skisser är utmärkta, men lås inte varje färg och marginal innan flödena är beslutade.
- Allt på en gång. Markera vad som ska med till lansering och vad som är önskemål längre fram.
- Ord som 'användarvänlig' och 'modern'. De går inte att bygga och inte att testa mot.
Sätt prioritet på varje krav
Använd tre nivåer: måste, bör, kan. Regeln är att "måste" ska rymmas i den budget ni angett. Kan allt inte rymmas är det ett svar i sig — då är det en avgränsad MVP ni ska beställa, inte hela plattformen.
Så använder vi kravspecen
Först en genomgång
Vi läser och kommer tillbaka med frågor, ofta obekväma sådana: vad händer om två personer ändrar samma post, vem äger kunddatan, vad ska hända med gamla ärenden. Svaren ändrar oftast omfattningen — till det bättre.
Sedan ett prisspann
Vi svarar med ett spann, inte en exakt siffra, och beskriver vad som skulle ta det upp eller ner. Hur spannen ser ut kan du läsa på sidan om pris för apputveckling.
Därefter en förstudie
För större projekt gör vi en betald förstudie på en till två veckor: flöden, skisser, datamodell och en fast prisbild. Den är avsevärt billigare än att upptäcka missförstånd i vecka tio.
Skickar du samma kravspec till flera leverantörer: be alla svara med samma avgränsning och samma antaganden. Annars jämför du en offert som inkluderar publicering och förvaltning med en som inte gör det, och den billigaste vinner av fel skäl.
Vad du får med dig
- Skriv användarflöden i löpande text i stället för funktionslistor.
- Ta med roller, datamodell, integrationer och en tydlig avgränsning.
- Lås inte teknikval eller design innan flödena är beslutade.
- Prioritera i måste, bör och kan — och låt budgeten avgöra var gränsen går.