Att hantera krav på ett effektivt sätt är inte bara nödvändigt för att driva lyckade projekt. Väl strukturerad kravinformation ger dessutom ett mycket bra underlag för att fatta välgrundade projektbeslut, och fungerar som styrande dokument genom hela utvecklingsprocessen.

En effektiv kravhantering innebär bland annat att man redan från början av ett projekt tar hänsyn till samtliga intressenter av det nya systemet och att man noggrant strukturerar och prioriterar alla de kravställningar och önskemål som uppkommer. Sedan följer att bryta ner de övergripande kraven till mindre kravkomponenter i ett eller flera steg. Samtidigt måste sambandet mellan dessa informationselement registreras för att inte förlora den viktiga spårbarheten.

I större utvecklingsprojekt växer kravmängden ofta så mycket att det är nödvändigt att införa någon form av verktygsstöd för att klara av kravhanteringen. Med ett kraftfullt verktyg öppnas i sin tur nya möjligheter att utnyttja kravinformationen för att styra och kontrollera utvecklingen på ett tydligt och effektivt sätt.

Genom att kombinera sitt kravhanteringsverktyg med verktyg för ändrings- och konfigurationshantering får man ett komplett stöd för hela produktlivscykeln, och uppnår full spårbarhet från den högsta nivån av kund- och användarkrav till systemets minsta beståndsdelar, som källkodsfiler och testfall.

Det råder en stor brist på kunskap kring kravhanteringens betydelse för en effektiv IT-miljö. Många människor, som är väl insatta i programvaruutveckling och är medvetna om behovet av systemtänkande, har relativt begränsad insikt i vikten av kravhantering i planering, konstruktion och drift av dagens alltmer komplexa system.

[Många beroenden]

Ett typiskt system består inte bara av programvara. Exempelvis innefattar ett banksystem, förutom en databas och programvara, ett eller flera datanätverk, byggnader och, kanske viktigast av allt, människor och arbetsrutiner. Ett sådant system påverkar vad en organisation gör och hur den gör det. Hur systemet påverkar organisationen är komplicerat i sig, men det är också så att ett nytt system nästan alltid är beroende av sin omgivning. Världen är full av system av alla slag, från ’manuella’ system baserade på papper, fax och telefon, till fullt integrerade produktionsstyrningssystem.

Ett nytt system bör därför ses som en komponent eller ett delsystem som noggrant måste anpassas för att passa in i ett större sammanhang, d v s den befintliga systemmiljön. Det nya systemet avgränsas av hur det samverkar med andra system och med människor som använder systemet. De personerna är i regel inte samma personer som specificerar systemet, konstruerar det, eller betalar för det. Det finns många ‘intressenter’ med skilda perspektiv på systemet, och det är kravingenjörens uppgift att skapa ordning bland dessa olika synpunkter, för att skapa en komplett och entydig kravbild som beskriver hela systemet.

Om beställaren låter utvecklarna börja konstruera systemet utan en kravspecifikation och endast med ledning av en informell beskrivning av vad systemet ska kunna göra, är det troligt att systemet varken kommer att kunna kommunicera tillfredsställande med andra system eller förse användarna med de funktioner som krävs.

Sådana problem skulle troligen inte komma att upptäckas förrän huvuddelen av utveckling är avklarad och när den första körbara versionen av systemet är klar. Utvecklarna skulle då hävda, med all rätt, att systemet uppfyller de ursprungliga kraven och eventuella ändringar måste göras i ett tilläggsprojekt mot en ökad kostnad. Systemets användare kommer förmodligen att vara missnöjda över att de inte har fått komma med synpunkter i frågor som direkt påverkar deras arbetssituation.

Beställaren tvingas nu in i ett kostsamt ändringsarbete (och måste dessutom lugna användarna). Med det extra arbetet följer förseningar, ökade kostnader och störningar i systemdriften. Dessutom måste systemet nu uppgraderas för att kunna hantera tidigare oförutsedda uppgifter, vilket kan innebära omfattande förändringar. Många system- och programutvecklingsprojekt har kraschat vid det här laget, då krav och lösningar tycks förändras dagligen. Analysföretaget The Standish Group har noggrant undersökt omfattningen av det här problemet och kommit till slutsatsen att orsaken till största delen är en undermålig kravhantering, som i slutändan kostar stat och industri miljardbelopp (se deras website på www.standishgroup.com).

Första steget i kravhanteringen är att peka ut de grundläggande affärsmålen, samt de nyckelpersoner som bör vara med i den processen. Nyckelpersonerna intervjuas sedan – var för sig, i mindre grupper, eller i en workshop – för att förstå deras synpunkter på det framtida systemet och vad de hoppas få ut av det. Tvetydigheter, skiljaktigheter och intressekonflikter behandlas sedan för att skapa en gemensam definition av de övergripande kraven, eller användarkraven.

Det enklaste sättet att göra detta är att skriva ner, steg för steg, vem som måste göra vad för att uppfylla varje enskilt önskemål. En sådan sekvens av händelser kallas för ett scenario. Ett fullt dokumenterat scenario, komplett med alternativa vägar och nödvändiga detaljer, kallas för ett use case (sv: användningsfall), ett möjligt sätt att använda det framtida systemet. Ett scenario kan man skriva på en godtycklig nivå. Bäst är att börja med den översta nivån av affärsmål för att sedan systematiskt arbeta sig nedåt till mer detaljerade scenarier.

Systemet kommer inte att fungera som det är tänkt när en oväntad händelse avbryter en normal händelsesekvens. Kraven måste därför också täcka undantagsscenarier, vars syfte är att få systemet att återgå till normal drift, eller i värsta fall stoppa systemet innan skada är skedd.

Dokumentet med användarkrav som vi nu tagit fram, definierar tydligt och klart de problem som det framtida systemet kommer att lösa. Det omfattar syfte, användare, terminologi, scenarier och annan information som beskriver vad som krävs av systemet.

Systemutvecklare kan nu ta över och specificera det önskade systemet på ett korrekt sätt. Systemspecifikationen skrivs med en viktig begränsning: den måste uppfylla varje enskild detalj i användarkravdokumentet. Om vi bara arbetar med några få krav är detta enkelt att hantera för hand: det är bara att bocka av varje övergripande krav när det täcks av något eller några krav i systemspecifikationen. Men när kravmängden ökar har man stor nytta av ett kravhanteringsverktyg, som t. ex. Telelogic DOORS.

Med hjälp av ett verktyg är det enkelt att hitta luckor i länkstrukturen mellan Användarkraven och Systemspecifikationen. Varje specifikation som inte kan spåras tillbaka till ett krav kan betraktas som en onödig ’förgyllning’ av systemet. Och varje krav som inte kan spåras framåt till en specifikation kommer att förbises under utvecklingen. Enbart dessa funktioner är ett kraftfullt argument för att använda ett verktyg.

Ett verktyg som DOORS kan dock göra mycket mer för att öka möjligheterna att lyckas med sitt projekt. De flesta projekt har begränsade resurser i fråga om tid och pengar. Man har inte möjlighet att uppfylla alla krav, hur genomtänkta och relevanta de än tycks vara. Därför måste man prioritera kraven för att kunna planera i vilken ordning olika uppgifter ska utföras. Vart och ett av användarkraven kan t. ex. rankas som ’Kritiskt’, ’Användbart’, ’Bra Att Ha’ eller ’Ej Nödvändigt’. Genom att sedan följa länkarna till Systemspecifikationen, får vi snabbt svar på vilka funktioner som bör inkluderas i första versionen av systemet, och vilka vi kan vänta med utan att äventyra systemdriften.

Liknande mekanismer kan användas för att skapa struktur och spåra utvecklingsarbetet mot kraven, eller för att hålla reda på vem som har intresse av olika testresultat, eller förstås för att uppskatta kostnader. Verktyget kan registrera om ett krav är ’Utkast’, ’Förslag’, ’Godkänt’, eller ’Förkastat’. Kraven är nu inte längre lösa textavsnitt, utan noggrant strukturerade konstruktionsobjekt i ett större sammanhang.

Krav upphör inte att vara intressanta när systemutvecklingen startar, och inte heller när den avslutas. Hur vet beställaren när det färdiga systemet kan godkännas? Jo, när alla krav har blivit uppfyllda, vilket påvisas genom testning eller någon annan verifieringsmetod. Testspecifikationer kan dokumenteras på samma sätt som krav. Även de består av en serie uppgifter att följa, tillsammans med önskade testresultat, eller acceptanskriterier. Dessa testuppgifter måste kunna spåras tillbaka till kraven, men när det gäller testning har länkarna syftet att visa att kraven uppfyllts, till skillnad från att styra systemkonstruktionen.

Fig 2 Informationsmodell med två olika typer av länkar

DOORS gör det lätt att definiera en sådan informationsstruktur. Fig. 2 visar en enkel informationsmodell, som beskriver hur ett litet projekt kan strukturera och styra sina krav med hjälp av två olika typer av länkar, kravuppfyllande länkar och verifieringslänkar.

Sambanden mellan tester och krav kan snabbt bli mycket komplexa. Ett enkelt scenario kan testas med hjälp av ett enstaka testfall: man stegar sig igenom en testsekvens och testet blir godkänt om det önskade resultatet uppnås i slutet. Men eftersom det är vanligt att ett scenario grenar sig i alternativa scenarier och undantag, får man många möjliga testfall, vanligtvis fler kombinationer än vad som är möjligt att testa.

Istället kan testingenjörer använda sig av verifieringslänkarna, som visar sambandet mellan testfall och krav, för att kontrollera i vilken utsträckning varje krav och scenario har blivit testat. På så vis kan man försäkra sig om att alla delar av systemet, och det kompletta systemet, kommer att fungera som det var tänkt. Allt detta är beroende av att vi har fullständigt dokumenterade krav, lätt åtkomliga med hjälp av ett kravhanteringsverktyg.

Den här korta vägledningen visar hur ett bra kravhanteringsverktyg som DOORS kan hjälpa till att hantera och dokumentera användarkrav, systemspecifikationer och acceptanstester på ett effektivt sätt, så att de kan fungera som styrmedel i utvecklingen av komplexa system. Bra hanterade krav gör det möjligt att leverera det system som användarna behöver – eller snarare, att säkerställa att produkten som levereras faktiskt uppfyller användarnas krav.

Medan den största tyngdpunkten för kravhantering ligger i början av ett utvecklingsprojekt, så används CM (Change and Configuration Management – ändrings- och konfigurationshantering) för att uppnå en repeterbar process för att hålla reda på systemets alla byggstenar och olika utgåvor av systemet. Tillsammans utgör dessa båda metoder ett kraftfullt instrument för projektstyrning, som är oberoende av vilket slags system projektet syftar till att ta fram och hur det konstrueras. Den gemensamma processen för kravhantering och CM täcker hela projektets livscykel och utgör ett stöd för övriga aktiviteter i projektet.

Ur ett systemutvecklingsperspektiv fungerar kravhantering och CM som väl integrerade komplement till varandra med tydliga syften för respektive metod. I praktiken krävs dock ett moget verktygsstöd för att eliminera det extra administrativa arbete som en manuell hantering skulle innebära.

Telelogics integration mellan dess kravhanteringverktyg, DOORS och dess CM-verktyg, ChangeSynergy och CM Synergy, är ett utmärkt exempel på vilka kraftfulla egenskaper som kan uppnås genom att kombinera kravhantering och CM.

Både kravhanteringsverktyg och CM-verktyg är normalt uppbyggda kring en databas. Kravhanteringslösningar är ofta dokumentbaserade, och med avancerade funktioner för spårbarhet mellan informationselement, medan CM-lösningar är konstruerade för att hantera och strukturera olika versioner och konfigurationer av systemets alla byggstenar.

Genom att kombinera de båda databaserna blir det möjligt att kontrollera all projektinformation genom hela projektets livscykel. Kärnfrågan när det gäller integration av kravhantering och CM är hur man kombinerar de båda verktygens möjligheter så att informationen görs transparent åtkomlig från en enda logisk databas.

Kravhantering och CM kan användas tillsammans för att korta utvecklingstiden och samtidigt säkerställa att den färdiga produkten uppfyller kraven. Projektet stöds i alla dess faser genom att CM hanterar leveransen av systemet, och kravhanteringen ser till att förväntningarna på produkten uppfylls genom hela utvecklingsprocessen. Den sammanlagda styrkan hos kravhantering och CM gör det möjligt att utveckla rätt produkter och introducera dem på marknaden snabbare än någonsin tidigare.

"Extreme Chaos" The Standish Group, 2001

"CHAOS Chronicles II" The Standish Group, 2001