Att presentera krav i kalkylblad är inte idealiskt för komplexa projekt, men det kan vara en användbar metod för enkla projekt eller som ett preliminärt steg innan du använder mer sofistikerade verktyg som dedikerade kravhanteringssystem. Så här görs det och dess begränsningar:
Hur man presenterar krav i kalkylblad:
Kalkylark (som Excel eller Google Sheets) erbjuder en tabellstruktur som kan organisera kravinformation. Vanliga kolumner kan inkludera:
* id: En unik identifierare för varje krav (t.ex. REQ-001, REQ-002). Detta är avgörande för spårbarhet.
* Kravtyp: Kategoriserar kravet (t.ex. funktionell, icke-funktionell, användarhistoria).
* Beskrivning: Ett tydligt och kortfattat uttalande om vad systemet måste göra eller en egenskap det måste ha. Använd ett tydligt, otvetydigt språk och undvika jargong där det är möjligt.
* Prioritet: Indikerar den relativa betydelsen av kravet (t.ex. hög, medium, låg).
* Källa: Där kravet har sitt ursprung (t.ex. användarintervju, intressentmöte, affärsdokument).
* Status: Spårar framstegen i kravet (t.ex. föreslagna, godkända, implementerade, verifierade).
* rationell/motivering: Förklarar orsaken till kravet.
* Acceptanskriterier: Definierar hur kravet kommer att valideras (t.ex. tester som ska utföras).
* tilldelad: Identifierar vem som är ansvarig för att uppfylla kravet.
* Anteckningar/kommentarer: Utrymme för ytterligare information.
Exempel:
| Id | Kravtyp | Beskrivning | Prioritet | Källa | Status |
| -------- | --------------- | ----------------------------------------- | -------- | ------------------ | ----------- |
| REQ-001 | Funktionell | Systemet ska tillåta användare att logga in. | Hög | Användarintervju | Godkänd |
| REQ-002 | Icke-funktionell | Systemet ska svara inom 2 sekunder. | Hög | Prestationsmål | Godkänd |
| REQ-003 | Funktionell | Systemet ska visa användarprofil. | Medium | Användarhistoria | Implementerad |
Begränsningar av att använda kalkylblad för krav:
* Brist på spårbarhet: Även om du kan lägga till ID, blir länkningskrav till andra artefakter (designdokument, testfall) svårt och felaktigt. Detta gör att hantera förändringar och förstå effekterna av förändringar i utmaningar.
* Svårigheter att hantera komplexa relationer: Kalkylark hanterar inte lätt komplexa förhållanden mellan krav (t.ex. beroenden, konflikter).
* Begränsat samarbete: Samtidig redigering kan leda till versionskontrollproblem.
* Dålig versionskontroll: Att spåra förändringar och återgå till tidigare versioner är svårt.
* Skalbarhetsproblem: Att hantera hundratals eller tusentals krav i ett kalkylblad blir svårt.
* Inga inbyggda rapporteringsfunktioner: Generera rapporter om kravstatus, framsteg etc. kräver manuell ansträngning.
När kalkylblad * är * lämpliga:
* Mycket små projekt: För projekt med ett litet antal krav.
* Preliminära krav Samling: Som ett snabbt sätt att fånga initiala krav innan du använder ett mer robust verktyg.
* enkla krav: Om kraven är enkla och inte har många beroenden eller komplexa relationer.
I de flesta fall erbjuder dedikerade kravhanteringsverktyg betydande fördelar jämfört med kalkylblad för att hantera krav effektivt. För mycket små, enkla projekt kan emellertid ett kalkylblad fungera som ett grundläggande kravdokument.
