En introduktion till kravhantering och kravteknik samt relaterade dokument som jag har skrivit i ämnet.
Datorer av olika storlek finns överallt i samhället, i tvättmaskiner såväl som i samhällskritiska system som ser till att vi dygnet runt har tillgång till el och vatten. I lastbilar, personbilar och tåg finns datorer som är osynliga för användarna, men som ändå styr vitala funktioner som aktivering av bromsar och styrservon. De system som vars avsedda funktionalitet, eller frånvaro av den, i hög grad påverkar människors säkerhet och hälsa, egendom eller den omgivande miljön kallas ofta för kritiska system.
Oavsett om systemen är av kritisk natur eller ej är fungerande kravhantering en förutsättning för att åstadkomma ett system som motsvarar verksamhetens behov. Studier och rapporter visar gång på gång att brister i kravarbetet är den vanligaste orsaken till försenade projekt med skenande kostnader. En populärvetenskaplig beskrivning till varför det lätt blir fel återfinns i min essä om vådan av att beställa it-system utan en tydlig kravspecifikation.
Om du uppskattar Dilbert rekommenderar jag även den här strippen från 1997 som illustrerar ett av skälen till att det slarvas med kravarbetet, nämligen trycket från omgivningen att producera något som ger intryck av att produkten snart är färdig.
Både kravteknik och kravhantering omfattar allt från att göra en initial intressentanalys där man identifierar vilka intressenter som är relevanta för systemet till att hantera förändringar i systemet efter att det är färdigt och har börjat användas. Mellan dessa punkter ska bland annat kraven formuleras och analyseras så att de inte står i konflikt till varandra eller mot övergripande mål för systemet.
Skillnaden mellan kravhantering och kravteknik är för mig att kravteknik är en ingenjörsdisciplin med tillhörande vetenskapsområde, medan kravhantering omfattar alla olika aktiviteter inom kravområdet oavsett om de bedrivs ingenjörsmässigt eller ej. Därmed inte sagt att ingenjörsmässig kravhantering är det som behövs i alla lägen, men för kritiska system är det nästan alltid en förutsättning.
Som vetenskapsområde ses kravteknik (på engelska requirements engineering
) ofta som en en deldisciplin till antingen systems engineering (svensk översättning saknas) eller programvaruteknik (på engelska software engineering
). Den sistnämnda ses i sin tur som en deldisciplin till systems engineering.
För att exemplifiera hur disciplinerna hänger ihop kan vi tänka oss att vi ska bygga en bärraket som placerar en satellit i omloppsbana. Systems engineering kommer att användas för att hantera helheten, inklusive integrationen av de olika delarna. Programvaruteknik kommer att användas för att omhänderta den mjukvara som kommer att ingå i systemet, och kravteknik kommer att användas för att hantera kraven på både mjukvaru- och systemnivån.
Ett område inom kravtekniken som jag tycker är lite extra intressant är hur man uttrycker krav. Man kan exempelvis använda formella notationer där man med matematisk precision entydigt kan beskriva önskade egenskaper, vilket är särskilt attraktivt för kritiska system där underförstådda krav eller antaganden annars kan ge livsfarliga konsekvenser. En beskrivning av olika formalitetsgrader för krav finns att läsa i min exjobbsrapport.
Jag är övertygad om att en effektiv kravprocess som tidigt fångar upp relevanta intressentkrav och löpande genom projektet följer upp i vilken grad dessa krav realiserats kommer att leda till färre spektakulära it-misslyckanden. Genom att effektivt använda den kunskap och de metoder som finns tillgängliga inom kravtekniken kommer vi istället att få se fler projekt som blir klara i tid, utan att överskrida budget, och som dessutom levererar den funktionalitet och kvalitet intressenterna behöver.
Trots vikten av en välfungerande kravhanteringsprocess så är en sådan i sig otillräcklig för att åstadkomma användbara och ändamålsenliga it-system. Kravhanteringen kan inte bedrivas fristående från de projekt som nästan alltid är arbetsformen för att skapa de nya systemen. Projekt- och kravarbetet måste ske integrerat; det spelar ingen roll hur bra kravspecialisterna är om inte projektet bedrivs på ett strukturerat sätt. Mer om detta går exempelvis att läsa i min essä Tio framgångsfaktorer för lyckade it-projekt
Jag driver webbplatsen Svensk kravterminologi som syftar till att vara den auktoritativa källan till de svenska termerna inom kravtekniken. Krav handlar till stor del om kommunikation, och för fungerande kommunikation krävs ett gemensamt språk.
Essän innehåller sex kriterier som kännetecknar ett framgångsrikt it-projekt, samt tio faktorer som är särskilt viktiga för att åstadkomma sådana projekt. Essän avslutas med en checklista som kan användas som en snabb hälsoindikator för ett projekt.
Den elaka tvillingen eller mörka spegelbilden av essän "Tio framgångsfaktorer för lyckade it-projekt".
En kort populärvetenskaplig förklaring till varför det är viktigt med kravspecifikationer.
Min exjobbsrapport, som handlar om olika sätt att uttrycka krav för elektroniksystem i tunga fordon. Det handlar dock betydligt mer om krav än om lastbilar.