Här är en fråga: när var senaste gången du skrev ner krav innan du började koda?
Om du är som de flesta utvecklare är svaret “aldrig” eller “bara när jag tvingades av företagsprocesser.” Krav känns som busywork. De är långa, tråkiga dokument som blir föråldrade i samma ögonblick utvecklingen startar. Så vi hoppar över dem och hoppar direkt in i kod.
Sedan, tre veckor senare, frågar någon: “Vänta, stödjer vi OAuth och email/password-auth, eller bara en?” Och du inser att ingen faktiskt bestämde. Du byggde baserat på vibes.
Här är sanningen: krav misslyckas inte för att de är en dålig idé—de misslyckas för att de skrivs fel. Traditionella kravdokument är för detaljerade, tar för lång tid att skriva, och ignoreras i samma ögonblick projektet skiftar. Vad du behöver istället är ett Technical Requirements Document (TRD): lättviktigt, specifikt, och faktiskt använt.
Och här är den bästa delen: du kan generera ett på 20 minuter med ChatGPT.
Vad är en TRD (och varför det spelar roll)
Ett Technical Requirements Document är en strukturerad översikt av vad du bygger, vem det är för, och vad framgång ser ut som. Det är inte en 50-sidors waterfall-spec med UML-diagram. Det är ett tydligt, skanningsbart dokument som besvarar dessa frågor:
- Vilket problem löser vi? (“Varför”)
- Vem är detta för? (Användare, intressenter, personas)
- Vad bygger vi? (Kärnfunktioner och scope)
- Vad bygger vi INTE? (Explicita icke-mål för att förhindra scope creep)
- Tekniska begränsningar? (Platform, prestanda, compliance, integrationer)
- Framgångskriterier? (Mätbara utfall, acceptanströsklar)
Det är allt. Inget fluff, inget fyllnadsmaterial. Precis tillräckligt med struktur för att hålla alla samordnade utan att drunkna i byråkrati.
Varför TRD-first slår “bara börja koda”
Förhindrar scope creep: När någon säger “vi borde också lägga till…” kollar du TRD:n. Om det inte finns där är det ett nytt projekt—inte detta.
Samordnar team: Produkt, design och engineering läser samma dokument. Inga fler “Jag trodde vi byggde X”-överraskningar tre veckor in.
Spårar beslut: Varje backlog-objekt refererar till TRD:n. Varje funktion mappar till ett krav. När någon frågar “varför byggde vi detta?” pekar du på sektion 3.2.
Snabbar upp onboarding: Nya teammedlemmar läser TRD:n och förstår projektet på 15 minuter istället för att osmosera kontext över tre veckor.
Gör planering exekverbar: Du planerar inte genom att gissa. Du extraherar arbete från krav. Canvas → Plan → Backlog härleder alla från TRD:n.
Hur man genererar en TRD med ChatGPT
Du behöver inte vara en kravingenjör. Du behöver bara 20 minuter och en bra ChatGPT-prompt.
Steg 1: Samla kontext (5 minuter)
Innan du pratar med ChatGPT, skriv ner:
- Problemet du löser (1-2 meningar)
- Vem det är för (användare, kunder, interna team)
- Nyckelfunktioner (punktlista, grova idéer)
- Begränsningar (tech stack, platform, tidslinje, compliance)
Exempel: “Vi behöver ett realtidsnotissystem för vår SaaS-app. Användare ska få omedelbara varningar för omnämnanden, kommentarer och kritiska händelser. Måste vara GDPR-kompatibel, fungera på webb och mobil, och hantera 10k samtidiga användare. Vi använder Node.js + Postgres.”
Steg 2: Använd denna ChatGPT-prompt (2 minuter)
Du är en specialist på tekniska krav. Generera ett Technical Requirements Document (TRD) baserat på följande projekt:
Problem: [Beskriv problemet]
Målanvändare: [Vem är detta för?]
Nyckelfunktioner: [Punktlista över kärnfunktionalitet]
Begränsningar: [Tekniska, regulatoriska eller affärsmässiga begränsningar]
TRD:n ska inkludera:
1. Executive summary (2-3 meningar)
2. Problembeskrivning
3. Målanvändare och personas
4. Kärnfunktionella krav (numrerad lista)
5. Icke-funktionella krav (prestanda, säkerhet, compliance)
6. Explicita icke-mål (vad vi INTE bygger)
7. Framgångskriterier (mätbara utfall)
8. Tekniska begränsningar och beroenden
9. Risker och antaganden
Formatera som markdown. Var specifik men koncis. Använd SMART-kriterier för framgångsmått.
Klistra in din kontext i prompten och tryck enter.
Steg 3: Förfina outputen (10 minuter)
ChatGPT kommer generera en strukturerad TRD. Nu förfinar du den:
- Lägg till detaljer: Förvandla “måste vara snabb” till “sidladdning under 200ms”
- Trimma fluff: Ta bort uppenbara påståenden som “systemet måste vara stabilt”
- Klargör icke-mål: Ange uttryckligen vad du INTE gör (detta förhindrar scope creep)
- Lägg till tekniska detaljer: Om ChatGPT sa “använd en databas,” specificera Postgres + JSONB-kolumner för flexibelt schema
Steg 4: Granska med ditt team (3 minuter)
Dela TRD:n i Slack/email. Fråga:
- “Missade vi något kritiskt?”
- “Är framgångskriterierna mätbara?”
- “Är icke-målen vettiga?”
Inkorporera feedback. Nu har du en delad sanningskälla som alla godkände.
Ett verkligt exempel: Användarautentiseringssystem
Låt oss gå igenom en riktig TRD för en användarautentiseringsfunktion.
Prompt-input
Problem: Vår app har för närvarande ingen användarautentisering. Användare kan inte spara preferenser, vi kan inte personalisera upplevelser, och vi har ingen åtkomstkontroll.
Målanvändare: SaaS-kunder (B2B) och interna adminanvändare
Nyckelfunktioner:
- Email/password-registrering och inloggning
- OAuth (Google, Microsoft)
- Rollbaserad åtkomstkontroll (admin, användare, gäst)
- Lösenordsåterställning via email
- Sessionshantering med JWT-tokens
Begränsningar:
- Måste vara GDPR-kompatibel (EU-användare)
- Måste integreras med befintlig Node.js/Express-backend
- Måste stödja 10k samtidiga sessioner
- Tidslinje: 3 veckor
ChatGPT-output (kondenserad)
# TRD: Användarautentiseringssystem
## 1. Executive Summary
Bygg ett säkert autentiseringssystem som stödjer email/password och OAuth (Google, Microsoft) med rollbaserad åtkomstkontroll. Måste hantera 10k samtidiga sessioner och följa GDPR.
## 2. Problembeskrivning
Appen saknar användarautentisering, vilket förhindrar personalisering, preferenslagring och åtkomstkontroll. Detta blockerar viktiga produktfunktioner och skapar säkerhets-/compliancerisker.
## 3. Målanvändare
- **Primära:** B2B SaaS-kunder (teammedlemmar, admins)
- **Sekundära:** Interna adminanvändare som hanterar kundkonton
## 4. Funktionella krav
4.1 Användare kan registrera sig via email/password med validering (emailformat, lösenordsstyrka)
4.2 Användare kan logga in med email/password eller OAuth (Google, Microsoft)
4.3 Systemet tilldelar roller (admin, användare, gäst) med distinkta behörigheter
4.4 Användare kan återställa lösenord via säker emailutmaning
4.5 Sessioner hanteras via JWT-tokens (utgång: 24 timmar, refresh tokens: 30 dagar)
## 5. Icke-funktionella krav
5.1 **Säkerhet:** Lösenord hashade med bcrypt (kostnadsfaktor 12), tokens signerade med RS256
5.2 **Prestanda:** Autentiseringsförfrågningar slutförs på <300ms (p95)
5.3 **Skalbarhet:** Stöd för 10k samtidiga sessioner
5.4 **Compliance:** GDPR-kompatibel (samtycke, dataportabilitet, rätt till radering)
## 6. Icke-mål (vad vi INTE bygger)
- Multifaktorautentisering (2FA)—planerat för Fas 2
- Social inloggning utöver Google/Microsoft
- Single Sign-On (SSO) för företag—separat projekt
- Lösenordslösa magic links
## 7. Framgångskriterier
- 95% av registreringsflöden slutförs utan fel
- OAuth-inloggningsframgångsgrad >98%
- Noll obehöriga åtkomstincidenter under första 30 dagarna
- Klara GDPR-audit-checklistan
## 8. Tekniska begränsningar
- Node.js 18+ / Express-backend
- Postgres 14+ för användarlagring
- Redis för sessionscaching
- Måste integreras med befintliga API-rutter (/api/v1/*)
## 9. Risker & antaganden
- **Risk:** OAuth-leverantörs driftstopp påverkar inloggning (Mitigering: Email/password fallback)
- **Antagande:** Användare accepterar 24-timmars sessionutgång
- **Antagande:** Emailleverans (lösenordsåterställning) lyckas inom 2 minuter
Hur TRD:n flödar in i ditt arbetsflöde
När du har en TRD blir allt annat mekaniskt:
TRD → Canvas
- Vision: “Bygg säker, GDPR-kompatibel auth som skalar till 10k användare”
- Mål: “95% registreringsframgång, <300ms auth-latens”
- Intressenter: “B2B-kunder, interna admins, säkerhetsteam”
- Frågor: “Föredrar användare OAuth eller email/password?” (Lägg till användarforskning)
TRD → Plan (Nu/Nästa/Senare)
- Nu:
- Email/password-registrering (TRD 4.1)
- JWT-tokenhantering (TRD 4.5)
- Nästa:
- OAuth-integration (TRD 4.2)
- Lösenordsåterställningsflöde (TRD 4.4)
- Senare:
- 2FA (uttryckligen i icke-mål, Fas 2)
TRD → Backlog
Varje krav blir ett backlog-objekt:
## AUTH-001: Email/Password-registrering
- TRD Ref: Sektion 4.1
- Prioritet: Hög
- Arbete: 3 dagar
- Acceptanskriterier:
- Emailvalidering (RFC 5322-format)
- Lösenordsstyrka: min 12 tecken, 1 versal, 1 siffra, 1 symbol
- bcrypt-hashing (kostnad 12)
- Returnera JWT-token vid lyckad registrering
- Felhantering för dubbla emails
Varje backlog-objekt spåras tillbaka till TRD:n. Inga föräldralösa funktioner. Inga “vi tyckte det skulle vara coolt att lägga till…”-överraskningar.
Vanliga misstag (och hur man undviker dem)
Misstag 1: Vara för vag
Dåligt: “Systemet måste vara snabbt” Bra: “Autentiseringsförfrågningar slutförs på <300ms vid p95”
Använd alltid specifika, mätbara kriterier.
Misstag 2: Hoppa över icke-mål
Om du inte uttryckligen säger vad du INTE bygger, kommer folk anta att det är inom scope. Skriv ner det: “Ingen 2FA i Fas 1. Inga magic links. Inget SSO.”
Misstag 3: Skriva en gång och glömma
Krav utvecklas. När scope förändras, uppdatera TRD:n. När du lägger till en stor funktion, referera den i TRD:n. Håll den levande.
Misstag 4: Göra den för lång
Om din TRD är över 5 sidor har du skrivit en spec, inte ett kravdokument. Komprimera. Använd punktlistor. Länka till externa dokument för detaljer.
Varför detta fungerar
Traditionella krav misslyckas eftersom de är frånkopplade från utförande. Du skriver ett dokument, arkiverar det, och tittar aldrig på det igen. TRD:n är annorlunda eftersom den är sanningskällan som matar allt annat.
- Canvas härled vision från TRD
- Plan extraherar funktioner från TRD
- Backlog-objekt refererar TRD-sektioner
- ADR:er citerar TRD-begränsningar (“Vi valde Postgres enligt TRD 8.1”)
Det är inte dokumentation för compliance—det är grunden för ditt arbetsflöde.
Prova själv
Välj en funktion du är på väg att bygga. Spendera 20 minuter på att generera en TRD med ChatGPT-prompten ovan. Sedan:
- Dela den med en teammedlem och fråga: “Matchar detta din förståelse?”
- Skriv ett backlog-objekt som refererar TRD:n
- När någon föreslår en ny funktion, kolla: “Finns detta i TRD:n?”
Det är allt. Du kommer omedelbart se skillnaden mellan att planera efter vibes och planera med krav.
Kommer i Del 3: Canvas-tänkande: Samordna innan du bygger — Lär dig hur sex lättviktiga filer förhindrar team från att bygga olika visioner av samma produkt, och varför kontextsamordning spelar större roll än kodkvalitet.
Nyckelord: tekniskt kravdokument, TRD, kravhantering, ChatGPT för planering, AI-assisterade krav, mjukvaruprojektplanering