Hur hänger livscykelperspektiv och kravhantering egentligen ihop?

Effektivt kravarbete inom IT-utveckling och andra typer av projekt blir allt viktigare. Kravarbetet är dessutom något som berör hela organisationen. Tiden när kravhantering endast var något för IT-avdelningen är sedan länge förbi.

Som projektledare förutsätts du ofta ha en förståelse för hur kravhantering fungerar i de inledande faserna i projekt. Men för den som inte dagligen arbetar med krav kan detta stora och komplexa ämne vara svårt att tränga igenom. En bra början och introduktion till området kan därför vara att få klart för sig vad som menas de olika kravtyperna – funktionella och icke-funktionella krav.

Ett annat begrepp som används flitigt i det här sammanghanget är begreppet livscykelperspektiv. Det här inlägget handlar om att försöka förklara vad funktionella och icke-funktionella krav är för något och hur de hänger ihop med begreppet livscykelperspektiv.

En normal livslängd för ett IT-system är kanske 5–10 år. Under den tidsperioden kommer organisationens processer och behov att utvecklas och förändras. Det gör att systemet successivt måste anpassas och utvecklas för att kunna hantera de förändringar som sker. Men att ändra, bygga på och vidareutveckla system kan vara både problematiskt och kostsamt. Därför bör man ta höjd även för de krav som inte finns initialt, men som kan komma att bli verklighet i takt med att förändringar sker inom och utanför organisationen.

Ett väl utfört kravarbete beaktar och omfattar systemets hela tilltänkta livscykel, dvs från den första lanseringen av systemet tills systemet ska skrotas. Ett arbete som kräver extra tankemöda, resurser och tid initialt. En konsekvens av det är kanske att tidpunkten för en första lansering av systemet måste skjutas något på till förmån för den tid som det extra kravarbetet tar.

Eftersom många projekt genomförs under tidspress med krav från ledningen på en snabb time to market så ägnas ofta för lite tid åt kravarbetet. Fokus läggs enbart på de krav som finns på den första versionen av systemet. Hela idén med att tänka på ett systems hela livscykel redan från början är att det i slutändan kommer att löna sig, något som ofta visar sig vara en sanning.

Vad menas då med funktionella och icke-funktionella krav? Här kommer en kort beskrivning.

En vanlig definition av funktionella krav vid systemutveckling är: ”De tjänster och funktioner som systemet ska tillhandahålla användaren”. Exempel på funktionella krav på ett system är möjlighet att registrera en betalning, kunna skriva ut en faktura, beräkna ett resultat etc. Funktionella krav är oftast de mest uppenbara och därför något som automatiskt får stort fokus i de inledande projektfaserna.

Icke-funktionella krav kan ses som egenskaper på ett system utöver förväntad funktionalitet. En vanlig definition är: ”Med icke-funktionella krav avses egenskaper som systemet bör uppfylla, men som inte kan karaktäriseras som tjänster, såsom tillförlitlighet, användbarhet, effektivitet, kapacitet och säljbarhet”.

Tycker du fortfarande inte att det är tydligt vad icke-funktionella krav är? Här följer 13 olika typer av vanliga icke-funktionella krav med en kort förklaring av varje krav:

1. Underhållsbarhet avser frågor som har med ett systems förvaltning att göra, såsom korrigering av fel, förbättring av prestanda, anpassning till ny IT-utrustning och konfigurationshantering. Underhållsbarhet kan åstadkommas på olika sättt ex genom att upprätta en god dokumentation av systemet och dess handhavande. Det är också viktigt att bygga systemet i så fristående komponenter som möjligt, för att få kontroll över sidoeffekter och följdverkningar av uppdateringar.

2. Flexibilitet avser möjligheter att ändra och bygga ut system. Vanligtvis uppnås detta genom att systemet struktureras i komponenter som kan bytas ut och ändras.

3. Utrustningsoberoende avser möjlighet att flytta programvara mellan olika datorer och plattformar. Detta är viktigt exempelvis då organisationer utvecklas, decentraliseras eller startar samarbete med andra organisationer, vilket ofta medför att olika typer av plattformar måste kunna samverka.

Utrustningsoberoende kan åstadkommas på olika sätt, exempelvis genom att ett system struktureras så att bearbetning av affärslogik och bearbetning som är relaterad till teknik separeras.

4. Återanvändbarhet avser möjlighet att i framtida projekt kunna återanvända analysresultat, design, system, program eller delar av program, för att uppnå kostnadsbesparingar vid framtida utveckling. Dessutom kan man oftast lita på att beprövade komponenter är korrekta. Återanvändbarhet kan åstadkommas på olika sätt, exempelvis genom att bygga systemet i komponenter och begränsa samband mellan komponenterna.

5. Interoperabilitet avser möjlighet för system att kommunicera med andra system eller annan utrustning. Det kan bl a åstadkommas genom att vanligt förekommande tekniker och utrustning utnyttjas och att man ansluter sig till gällande standarder av olika slag. Vidare bör man sträva efter en öppen design.

6. Att följa vedertagna standards är viktigt inför utvidgningar och samarbete med andra system.

7. Testbarhet avser möjlighet att kunna testa ett system. Att testa ett konventionellt administrativt system är oftast relativt enkelt, men att testa realtidsförlopp och samverkan och tidsmässig synkronisering mellan olika system och annan utrustning kan ibland vara svårare. Ett sätt att åstadkomma testbarhet är att frilägga kritiska delar och att skapa tydliga kontrollstrukturer i ett system.

8. Korrekthet avser huruvida ett system uppfyller specifikationen och tillfredsställer användarens önskemål.

9. Tillförlitlighet avser huruvida ett system utför operationerna på rätt sätt och att data är korrekta. Detta kan ha olika betydelse i olika typer av system. I ett datorspel är det inte av avgörande betydelse, men i ett säkerhetskritiskt system, t ex ett system som övervakar och styr flygtrafik, är det av största betydelse. Det kan exempelvis åstadkommas genom att olika typer av avstämningar och kontroller införs.

10. Effektivitet avser prestanda och ett systems förmåga att utnyttja IT-utrustningens möjligheter. Prestanda kan avse lagringsvolymer, bearbetningshastigheter och kommunikationshastigheter.

11. Säkerhet avser skydd mot otillbörlig åtkomst av program och data. Detta uppnås genom olika typer av tekniska skydd, exempelvis brandväggar, men en medveten och utbildad personal är också viktigt i detta sammanhang.

12. Användbarhet avser exempelvis enkelhet att använda ett system och enkelhet för användaren att lära sig detsamma. Det kan bl a åstadkommas genom att prototyper skapas, som de blivande användarna kan testa och pröva i utvecklingsprocessen.

13. Tillgänglighet är viktigt i exempelvis övervakningssystem och kan bl.a. åstadkommas genom att systemet eller delar därav dubbleras.

Av de 13 kravtyperna ovan har de sex första direkt att göra med framtiden, dvs de bör ses i ett livscykelperspektiv. Återigen kan sägas att det vid nyutveckling kostar lite mer och tar lite längre tid om sådana krav skall tänkas ut och beaktas, men att det ofta lönar sig i långa loppet.

De övriga sju icke-funktionella kraven kan också vara viktiga att beakta i ett livscykelperspektiv. Det kan gälla t ex kravet på användbarhet. Vid användarens bristande medverkan i kravprocessen, kan brister i systemet uppstå, t ex att viktiga affärshändelser inte hanteras på ett riktigt sätt eller att systemet är för krångligt utformat.

En siffra som nämns inom IT är att då ett system är nyutvecklat har man sett endast 25% av livscykelkostnaden. Övriga 75% uppstår under systemets livslängd och då gäller det att man tagit höjd för detta ifrån början. Inte sällan inträffar det att ett system måste skrotas redan efter något år därför att det är så oflexibelt byggt att det är mer lönsamt att börja om från början för att kunna möta de nya kraven.

Fokus i det här inlägget har varit på IT-utveckling. Men du som inte arbetar med IT utan i andra typer av projekt kan troligen också se fördelarna med att beakta både funktionella och icke-funktionella krav och att i möjligaste mån försöka blicka över hela livscykeln så tidigt som möjligt i projektet. Se även våra tips nedan som avser kravarbetet generellt.

• Medvetandegör betydelsen av professionellt kravarbete och etablera en process för att ta fram och dokumentera krav
• Låt kravarbetet få ta tid, det lönar sig på lång sikt
• Engagera så många som möjligt i kravarbetet, inte minst med tanke på livscykelperspektivet.
• Engagera även de som har inblick i kommande planer som påverkar organisationens framtid
• Se till att systemet passar in i en föränderlig framtid, avseende t ex affärsutvecklingsplaner, val av tekniska plattformar, leverantörssamarbeten och strategier för systemutveckling