Vanliga rubriker i krav

2009-05-12 Artikelbanken Kravhantering Läst 11191 gånger

Varje krav består av mycket information som vanligen delas upp i separata underrubriker. Om ett kravhanteringsverktyg används delas informationen upp i olika fält. Några exempel är rubrik, beskrivning och prioritet. I den här artikeln beskrivs ett antal vanligt förekommande sådana rubriker som du kan använda för att jämföra med hur kraven dokumenteras i din organisation.

Tekniken att dela upp ett krav i underrubriker är tillämplig för många olika typer av kravdokument, exempelvis kravspecifikationer, funktionsspecifikationer och designspecifikationer. Skillnaden mellan dokumenten är att kraven beskrivs på olika detaljnivå. I början är kraven inte så detaljerade, men när kraven bryts ned inför konstruktion, blir kraven alltmer detaljerade. Formatet med olika underrubriker kan dock vara lika i de olika dokumenten.

Exempel på krav

 

ID 3.1
Rubrik Spara kund
Beskrivning Handläggare ska kunna spara kunder. När kunden sparas ska ett meddelande visas. Om handläggaren avbryter registreringen ska systemet återgå till huvudsidan.
Prioritet Hög
Motivering Den här funktionen är en kärnfunktion som kommer att användas av alla användare.
Beroenden
Systemdel Kund
Författare Ulf Eriksson
Källa

 

Översikt till vanliga rubriker i krav

  • Rubrik
    En kort beskrivning av kravet. Rubriken bör tydligt visa vad kravet handlar om, utan att läsaren ska behöva läsa igenom hela kravet för att förstå vad det handlar om. Exempel: ”Uppläggning av kunder”, ”Avisering via e-post”. Kravets rubrik är ofta det som visas i olika listor och sammanställningar när ett verktyg för kravhantering används. Rubriken är ofta några få ord, upp till någon mening lång.
  • Beskrivning
    Fullständig beskrivning av kravet, ofta flera rader som beskriver vem som är tänkt att använda funktionen, hur dettas ska göras och vad som ska hända om ett fel inträffar. Beskrivningen omfattar ofta ett 20-tal rader. Det är dock vanligt att beskrivningen är för kortfattad och endast omfattar några få rader.
  • Identitet/ID
    Tack vare den unika identiteten går det inte att förväxla kravet med andra krav. Identitet är ofta ett löpnummer, där kraven numreras från 1 och uppåt, men det kan också vara en kombination av bokstäver och siffror, exempelvis K01 för det första kravet inom kundmodulen. Varje ID-nummer får bara förekomma en gång. ID-numret används för att skapa korsreferenser, till exempel för att indikera att ett krav är ett underkrav till ett annat.
  • Ändringslogg
    Ändringsloggen uppdateras varje gång ett krav ändras. Den innehåller ofta namn på ansvarig, datum för ändring och orsak till ändringen. Det är bäst att logga ändringar i anslutning till varje krav. En vanlig lösning är att notera ändringar i dokumentets historik överst i dokumentet, men det tenderar att bli alltför kortfattat.
  • Källa
    Källan beskriver vem kravet kommer från. Om kravet har kommit från en handläggare på ett kontor kan namnet på handläggaren skrivas här. Det kan också vara namnet på en avdelning eller person inom organisationen som är upphov till att kravet existerar. Anledningen till att dokumentera källan är att göra det möjligt att gå tillbaka och ställa frågor, alternativt visa lösningsförslaget för källan. Källa är inte samma sak som författare.
  • Författare
    För- och efternamn på den som har skrivit kravet. Bra att ha när den som läser kravet har frågor.
  • Motivering
    Motiveringen beskriver anledningen till att kravet existerar, till exempel med en kalkyl som visar på vinsterna, en beskrivning av vad som är mindre bra med den nuvarande funktionaliteten, tidsvinster som kommer att göras med det nya systemet etc.
  • Status
    Status visar vad som händer med kravet för tillfället. Exempel på status är föreslaget, godkänt, under utveckling, under testning, implementerat och uppskjutet. Det är även möjligt att ange att kravet är ett kommande krav som inte är aktuellt för den nuvarande versionen men kommer att bli aktuellt senare.
  • Prioritet
    Kravets prioritet, exempelvis baserat på en skala som Must, Should, Could och Won’t, hög, medel, låg, eller liknande.
  • Länkar
    Referenser till andra dokument som kan behöva läsas för att förstå kravet. Länken kan gå till något företags webbsida eller till intranätet, det kan vara en hänvisning till en standard eller till en process såsom orderprocessen.
  • Beroenden
    Beskrivning av kravets relationer till andra krav. Ett krav är normalt beroende av andra krav. Ett krav kan bestå av andra krav, vara ett underkrav till ett annat krav eller så kan läsaren behöva läsa ett annat krav för att förstå kravet.
  • Systemversion
    I vilken version av det kommande systemet kravet planeras införas.
  • Systemdel/funktionsområde
    Den del i systemet som kravet hör till.
  • Regler
    Beskrivning av verksamhetsregler, affärsregler och lagstyrda regler. Regler kan kortfattat beskrivas i kravet men längre beskrivningar bör beskrivas i andra dokument och hänvisas till från kravet för att undvika att kravspecifikationen drunknar i information. Till regler kan även höra beskrivning av behörighetsstrukturen i systemet.
  • Kommentarer
    Övrig information som kan vara av intresse.
  • Ändringslogg
    Ofta en tabell med datum, författare och en beskrivning av den ändring som är gjord. Det här är viktig information, inte minst eftersom testfall så småningom kommer att skapas. Testfallen refererar till kravet och om kravet ändras, kanske testfallets förutsättningar blir ändrade. Därför bör varje ändring av kravet loggas. Det är enkelt att underhålla ändringsloggen om ett kravhanteringsverktyg används.

 

Avslutning

Med en bra kravmall med rätt underrubriker blir det lättare att skriva krav av hög kvalitet. Det räcker dock inte med en bra mall, det behövs också bra sätt att formulera och granska kraven. Kraven måste också vara baserade på intressenternas behov och insamlade med hjälp av olika insamlingstekniker. I kursen ”Effektiv kravhantering” lär vi ut en kravhanteringsprocess från insamling till förvaltning.

Hur mycket information som behövs i varje krav varierar och beror på vilka krav som ställs på dokumentationen. Det är ovanligt att alla de föreslagna detaljerna används i alla krav. Ibland återfinns informationen på någon annan plats i kraven. Kravets källa kanske framgår i kravets beskrivning i stället för att beskrivas under en särskild rubrik. Fördelen med att ha fler rubriker är att det minskar risken att författaren missar att ange informationen. Nackdelen med fler rubriker är att kraven blir mer omfattande.

Tips för vidare läsning

  • Boken ”Kravhantering för IT-system” av Ulf Eriksson behandlar på ett praktiskt sätt hur man skriver bra krav.
  • Faktabanken på vår hemsida. Innehåller kostnadsfria dokument om kravhantering och test.

 

Här finns artikeln som PDF.

Dela artikeln