Så kravställer du molntjänster

2010-12-15 Artikelbanken Kravhantering Läst 11202 gånger

Du har säkerligen hört termen Cloud Computing eller som vi oftare säger på svenska - molnet. Det är ett av de mest populära samtalsämnena i IT-världen idag. Något som dock inte diskuteras så ofta är hur molnet påverkar och förändrar kravhanteringsarbetet. Det vill jag därför diskutera i denna artikel.

Hur påverkar molnet kravhanteringen?

Det korta och bekväma svaret är, inte så mycket. Med växande erfarenhet och insikt i området så växer dock några betydande skillnader fram. Dessa skillnader består främst i att fokus flyttas till VAD tjänsten skall göra medan hur den gör det är tjänsteleverantörens ansvar. Det andra stora området att fokusera på vid utnyttjandet av molnbaserade tjänster är integrationen med våra befintliga system.

Dessa två områden diskuterar vi vidare uppdelat i två delar. Den första delen behandlar kravställning vid val av en mjukvara som en tjänst (Software as a Service eller SaaS som jag kommer att benämna det i resten av artikeln). I den andra delen kommer vi att diskutera hur vi kravställer då vi använder oss av molnbaserade stödtjänster vid utveckling av vår applikation. Dessa stödtjänster benämns ofta som PaaS (Platform as a Service).

Val av mjukvara som en tjänst (SaaS)

Mjukvara som en tjänst är kompletta applikationer som erbjuds i form av en webbaserad tjänst till slutanvändare. Detta innebär att slutanvändaren inte köper några permanenta licenser eller installerar någon programvara. Användaren betalar istället för den tiden man använder/är ansluten till tjänsten. Exempel på SaaS tjänster är säljstöd, dokumenthantering, ritverktyg, tidrapportering, lönesystem, presentationsverktyg m.m. som nås via en webb-läsare.

VAD skall utföras?

Du som tidigare har varit inblandade i att kravställa och införa standardsystem kommer att märka att framtagningen av funktionella krav på en verksamhetsnivå inte påverkas av att tjänsten levereras via molnet. Har du dokumenterade verksamhetskrav som beskriver VAD som skall utföras så kan dessa med andra ord användas vid val av tjänst/applikation oberoende av om du väljer en molnbaserad tjänst eller inte. Har du däremot krav som beskriver HUR det skall utföras så går dessa krav förmodligen inte att använda vid val av molntjänst. Det positiva med detta är att verksamhetskrav som beskriver HUR i allmänhet är någonting som vi skall undvika och komma bort ifrån.

Inlåsning

Det är även viktigt att hålla de funktionella kraven på VAD-nivå för att möjliggöra ett eventuellt byte av tjänsteleverantör i framtiden. Av samma anledning är det även viktigt att hålla kraven aktuella och uppdaterade i en förvaltningssituation. Vi måste alltid med kort varsel kunna hantera ett byte av tjänst för att inte hamna i en beroendeställning till tjänsteleverantören.

För att uppnå målet med utbytbara tjänster så gäller det även att säkerställa att du inte blir inlåst i den tjänst du har valt. Kravställ därför att data skall kunna läsas ut och flyttas till en eventuell ny tjänsteleverantör. Har du stora mängder eller komplex data kan det här vara lämpligt att frångå VAD regeln och faktiskt kravställa HUR data skall kunna exporteras ut ur tjänsten.

Integration

I nästan samtliga fall så skall den valda tjänsten integrera och utbyta information med såväl andra tjänster som med dina befintliga system. Detta leder till att det är mycket viktigt att modellera hur tjänsten integrerar med övriga system i verksamhetsflödet. Detta görs exempelvis genom att modellera verksamhetsprocesserna med de olika samverkande tjänsterna/systemen i separata simbanor (Swimlines).

simbanor

För att även få grepp om hur informationen flödar mellan de olika tjänsterna/systemen i verksamhetsprocessen så bör man även ta fram en kompletterande informationsmodell för varje verksamhetsprocess. Är det fler än fyra olika tjänster/system inblandade så är det till stor hjälp med en systemsambandskarta för att lättare identifiera alla integrationspunkter.

Detaljkraven rörande driftplattformar, tekniska miljöer, backuphantering och redundans kan du däremot med gott samvete sluta fundera på. Det är tjänsteleverantörens huvudbry och regleras därför oftast med olika SLA (Service Level Agreement) och inte med hjälp av detaljerade krav.

Kravhantering vid användning av PaaS tjänster

Bygger du en applikation/tjänst som använder sig av en eller flera PaaS, en så kallad ”Mash-up”, så gäller det samma områden som ska fokuseras på som vid kravställning av en SaaS-lösning. Skillnaden är förstås att fokuset på verksamhetsprocessen och informationsflödet blir ännu större då antalet ingående tjänster blir så många fler.

Amazon

Ett bra exempel på en ”Mash-up” som använder sig av många olika PaaS är e-handels-sajten Amazon. Om vi studerar hur Amazon är uppbyggt så ser vi att bland annat produktens pris, bilden på produkten, kundvagnen och betalningslösningen är olika PaaS som Amazon använder sig av. Vid kravställning av denna typ av applikationer/tjänster så använder jag prototyper flitigt, eftersom det blir extra kraftfullt då kravställningen ofta handlar om flöden och arbetsätt. Prototyperna kan ibland till och med göras direkt med fungerande PaaS-tjänster vilket ger en mycket snabb och tydlig feedback på kravställningen.

Utbytbara tjänster

De olika PaaS som en och samma ”Mash-up” använder sig av levereras ofta av olika leverantörer. Vi vill dock inte vara beroende av ett stort antal leverantörer för att säkerställa vår applikations fortlevnad. Detta innebär att de ingående stödtjänsterna i ännu större utsträckning behöver vara utbytbara. För att kunna uppnå detta så behöver vi ofta kompletter verksamhetskraven, verksamhetsprocessen och informationsmodellen med mera detaljerad kravställning.

Kravtekniker

Beslutsträd är en kravställningsteknik som jag gärna använder mig av i dessa sammanhang. Det ger en mycket tydlig visuell bild av affärsflödena och de val som driver flödet framåt. Utifrån beslutsträdet väljer jag sedan ut lämpliga scenarios eller användningsfall som får tjäna som provskott och visualisering av att verksamhetsprocessen fungerar som tänkt. Kombinera gärna scenarion och användningsfallen med att ta fram persona på aktörerna för att ytterligare öka den visuella förståelsen.

För att slutkunden skall få en enhetlig upplevelse av vår applikation/tjänst så måste vi även kravställa utseendet på stödtjänsterna. Detta görs lämpligen så generellt som möjligt då vi inte vill skriva dessa krav specifikt för varje ingående tjänst. Ofta kan det här fungera bra med att ta fram en grafisk profil för applikationen/tjänsten. Eventuellt kan det till och med räcka med organisationens grafiska profil om en sådan finns.

Skiljer sig ett moln projekt ifrån ett traditionellt?

När du bestämmer dig för att nyttja befintliga tjänster som distribueras via molnet så påverkar det ofta projektet på ett sådant sätt att utvecklingstiden blir mycket kort. Det gör att man som kravställare får ett snabbt kvitto på om resultatet blev det som vi förväntade oss.

Den snabba utvecklingstiden möjliggör även att vi till en betydligt lägre kostnad kan ha rörliga krav och prova oss fram till en optimal lösning. Vid dessa fall så skall man dock inte glömma att dokumentera de slutgiltiga processerna och informationsmodellerna för förvaltningens skull.

Sammanfattning

Fokusera på VAD du vill utföra. HUR är inte din huvudvärk längre!

Nästa steg

Konsultbolag1 erbjuder kursen Kravledning där vi bland mycket annat går igenom hur du arbetar med kravhantering i molnet utifrån ett ledarskapsperspektiv. Vill du istället lära dig hur du praktiskt utvecklar och skriver krav för tjänster i molnet så erbjuder vi kursen Kravdesign – att utveckla och skriva bra krav.

För vidare läsning rekommenderar jag att du läser "Molnets" påverkan på krav- och testarbete, Smarta Scenarer - för en bättre IT-beställning och Personas - din bild av slutanvändaren.

KONTAKTA OSS

Har du frågor? Vill du ha hjälp med områden inom kravhantering och test?
Hör av dig till oss! Vi hjälper dig gärna. 

Kontakt 

Dela artikeln