Den komplette specifikations-checkliste
En spec er den kontrakt, du ikke skrev under. De klausuler, der mangler i den, er de change orders, du betaler for senere.
Hvad en spec rent faktisk er til
En specifikation er det dokument, du og din leverandør vil række ud efter, når I er uenige. Dens opgave er ikke at se imponerende ud. Dens opgave er at være konkret nok til, at "færdig" har én betydning, og at den person, der betaler, og den person, der bygger, er enige om, hvad de skrev under på.
Den dyreste spec-fejl er udeladelse. Siden om "responsive design" er fin, indtil du finder ud af, at det betyder tre breakpoints, ikke reelt fluid. Siden om "søgning" er fin, indtil du opdager, at den returnerer 50 hardkodede resultater, ikke kataloget. Change orderen for at lukke hvert hul er dyrere end at sætte linjen ind i specen til at starte med.
I omfang — checkliste
Hver sektion her skal optræde i hver spec med et svar på én linje. "Standard" er ikke et svar.
Funktionelt
- User stories med acceptkriterier, ikke blot funktionsnavne.
- Brugerroller og rettigheder, med hvad hver rolle kan og ikke kan gøre.
- Alle entry-points: web, mobilweb, native app, embedded, API.
- Alle indtastningssprog og indholds-locales.
- Alle tilstande for hver skærm: tom, loading, fejl, partiel, succes.
Ikke-funktionelt (hvor omkostningen gemmer sig)
- Performance-budget. LCP, INP, total JS-payload, billedpolitik. Pr. rute, hvis det betyder noget.
- Tilgængelighed. WCAG-niveau (AA er gulvet i EU), keyboard-support, screen reader-test.
- Browser- og enhedssupport. Den faktiske liste, med en cutoff-dato for OS-versioner.
- Responsive omfang. Min/max viewport, understøttede orienteringer, foldables og split-screen.
- Internationalisering. Tal-, dato- og valutaformater; right-to-left hvis relevant.
- Sikkerheds-baseline. Auth-flow, sessionslængde, rate limits, secret-håndtering, GDPR-omfang.
- SLA'er. Uptime-mål, responstid-mål, MTTR-mål.
Integrationer
- Hvert eksternt system, med versionen af API'et i omfang.
- Hvad vi gør, når hver integration er nede eller rate-limited.
- Hvem der ejer legitimationsoplysninger og rotationsplanen.
- Antagelser om webhook-pålidelighed (at-least-once, ordering, idempotency).
Operationelt
- Deployment-topologi og miljøer (preview, staging, production).
- Observability: logs, metrics, traces, alerts, ejerskab.
- Backup, retention og disaster recovery — RPO-/RTO-mål.
- Håndtering af secrets og config: hvor, hvem, rotation.
Uden for omfang, på skrift
En spec uden en eksplicit uden for omfang-sektion er en spec, der vil absorbere hver sen anmodning som en kamp. Vær generøs med denne sektion. "Customer support-værktøjer, admin dashboards ud over X, dark mode, in-product analytics-dashboard, native mobil-app — ikke i denne aftale" er et afsnit, der forhindrer et års skænderier.
Den linjepost, du ikke skrev ned, er den linjepost, du betaler for som en change order.
Acceptkriterier, hver story
Hver user story har brug for acceptkriterier skrevet i formen: "givet X, når Y, så Z." Det format gør storyen testbar. Uden det bliver "færdig" en forhandling mellem den, der betaler, og den, der vil betales.
Kan du ikke skrive acceptkriterierne, kender du ikke storyen godt nok til at estimere den. Det er en undersøgelsesopgave, med sit eget estimat og sin egen leverance, før der skrives kode.
Ændringsproces, i selve specen
Specen skal beskrive, hvordan den ændres. Hvem kan anmode om en ændring. Hvem estimerer den. Hvem godkender den. Hvad sker der med tidsplan og budget. Uden denne sektion bliver hver ændring et nyt møde og en ny forhandling.
- Anmodet på skrift, ikke på gangen.
- Estimeret inden for X arbejdsdage.
- Godkendt af en navngiven rolle, ikke hele interessentlisten.
- Tidsplan- og budgeteffekt angivet eksplicit, ikke absorberet.
Vil du have denne slags vurdering på dit projekt?
Jeg læser hver e-mail inden for én arbejdsdag. Tag et projekt, et tilbud eller et system, du sidder fast i.
De skjulte omkostninger ved softwareprojekter
Ud over det indledende tilbud: vedligeholdelse, hosting, skalering og den reelle samlede ejeromkostning.
15 ting hvert Contentful enterprise-projekt får galt i de første 6 uger
De 15 produktions-huller hvert enterprise Contentful + Next.js-build rammer i de første seks uger — og hvordan du lukker hver enkelt uden at brænde et sprint. En pre-kickoff-checkliste til tech-leads på en Contentful enterprise starter.
REST + GraphQL-hybrider til multi-locale CMS-drevne sites
Hvorfor hverken kun REST eller kun GraphQL er det rigtige valg til et enterprise multi-locale CMS-site, og hvordan du splitter efter ansvar i stedet. Inkluderer cirkulære referencer på fulde REST-payloads, bundle-omkostningen ved GraphQL på klienten, beslutningsmatricen pr. kaldsted, den samlede fetcher, granulære cache-tags, blok-som-fragment-mønsteret, locale-fallback i ét round-trip, Live Preview der overlever, Server Actions til CMA-skrivninger, Algolia Sync API-undtagelsen og migrationsrækkefølgen.