Bli en bättre kravställare
Det här är ingen komplett genomgång hur man skall skriva en kravspecifikation utan snarare ett hjälpmedel för dig som inte har det som heltidssyssla. Jag hoppas att du med denna bloggpost åtminstone kan ta med dig följande:
- De enda riktiga skallkraven är de regulatoriska
- Det är i princip omöjligt att ta fram alla krav utan stöd från IT avdelningen
- Fokusera på behov i stället för krav
För hur brukar det då gå till?
När man skall implementera nya lösningar så är de så kallade kraven viktiga. Anledningen till att jag skriver ”så kallade” är att det är ganska luddigt vad krav är och att det är mer eller mindre omöjligt att skriva en perfekt kravspecifikation innan man börjar utveckla.
Först och främst pratar vi om skall- och bör-krav men vi pratar också om funktionella och icke funktionella. De icke funktionella kan sedan brytas ner i en mängd olika kravtyper såsom prestanda, säkerhet och användarvänlighet. Sen har vi ju de viktigaste av dem alla, de regulatoriska. Vi bör även titta på informationsflöden, struktur på system, integrationer, olika typer av användare och så vidare. Alla dessa krav skall vara otvetydiga, de får inte vara motsägelsefulla och inte minst mät/testbara för att vi skall kunna säga att de senare har uppfyllts. Känner du redan nu att det går runt i huvudet och tänker att du inte alls hänger med? Då kan du själv tänka dig hur komplext det är att ta fram alla dessa och då helst innan vi ens drar i gång projektet.
Med tanke på hur många olika sätt det finns att formulera och kategorisera krav så är det inte konstigt att de kravdokument vi skall utgå ifrån när vi skall bygga ett nytt system eller uppdatera ett gammalt oftast lämnar mycket kvar att önska.
Inte sällan är det verksamheten, med ytterst lite stöd från IT avdelningen, som sätter ihop dem. Det gör att det oftast finns en slagsida med massor av funktionella krav om hur systemet skall fungera samtidigt som det helt saknas relevanta krav för de så kallade icke funktionella kraven. Icke funktionella krav kan också kallas kvalitetskrav vilket jag anser är en betydligt bättre term för dessa men mer om detta senare.
Men hur skall man göra när man skall skriva ett kravdokument, tex för en upphandling av ett nytt system? Visst kan du ta in en kravanalytiker som hjälper er med detta men det är ändå bra att ha en lite bättre förståelse hur man kan göra.
Jag tog för några år sedan fram en metod för hur man bör dela upp det grundläggande arbetet med att ta fram krav. Den bygger på att vi delar upp kraven i tre huvudgrupper, Regulatoriska, Organisationsspecifika och Projekt/System.
Men innan vi går in på det så bör vi fundera över termen ”krav”. Det är ett väldigt starkt ord som innebär att vi kräver något. Därför har vi lagt till de sk börkraven. Börkrav innebär att det är bra om de uppfylls men vi kan klara oss utan dem. Engelskans ”Requirements” ligger närmare ”Behov” på svenska och det är oftast en mycket bättre term. Jag kommer inte att gå igenom alla de punkter jag listade i inledningen utan mer generellt hur jag tycker att vi skall ta fram dessa krav. Detta gäller såväl för vattenfallsprojekt där vi försöker ta fram alla krav innan, vilket jag inte förordar, som agila projekt, där vi tar fram kraven iterativt.
Regulatoriska krav
Det här är de riktiga skallkraven, dvs de krav du inte kan påverka. Det är saker som lagar, tex GDPR, Patientsäkerhetslagen, Bokföringslagen och många andra. Det kan även vara branschstandarder, API:er hos organisationer vi behöver kommunicera med och andra saker ni inte har någon möjlighet att påverka. Jag räknar med att er organisation har koll på det här så jag går inte in djupare på detta område. Vem i organisationen som har koll på just dessa saker skiftar dock. Ibland är det en juridisk avdelning, en annan är det IT avdelningen, och i en tredje kan verksamheten/projekten få hantera det helt själva. Däremot vill jag trycka på att ni inte skall lyfta ut saker ur dessa dokument och tolka dem för då riskerar ni att det blir fel. Hänvisa i stället till exempelvis lagen och lägg på sin höjd in hur det påverkar er.
Organisationsspecifika utmaningar
IT policyn borde till största delen bestå av börkrav. Här bör allt som begränsar de enskilda användarna och systemen listas, men även de saker som stöttar dem. Det är ju tex en fördel om företaget har väl fungerande rättighetshantering som vi kan ”haka på” det system vi tänker bygga.
Det är också viktigt att posterna i denna policy är motiverade. Annars finns risken att såväl utvecklingsteam som personal letar kryphål i dessa regler vilket kan äventyra tex säkerheten för organisationen. Många har nog hört eller till och med ägnat sig åt det som ibland kallas ”Routa runt en IT avdelning” där man försöker gå runt policyn då man inte förstått meningen med den.
Dessvärre har de IT policys jag läst genom åren i princip alltid varit bristfälliga. Många verkar tro att IT policys skall vara full med pekpinnar om vad man inte får göra men de bör även vara stöttande vilket gör kravarbetet för system mm som skall användas av företaget väsentligt enklare. Vi har ju IT stöd för att underlätta organisationens arbete, inte för att försvåra det.
Krav såsom säkerhet, modularitet, managerbarhet, SLA och mycket annat måste ligga på IT avdelningen och då bör det ju vara lättillgängligt och motiverat.
Det händer ibland att det vi vill implementera strider mot den fastslagna policyn och då är det olämpligt att försöka hitta kryphål. Är den dessutom välmotiverad så är det lätt att förstå varför det som hindrar finns där. Om man då har välmotiverade skäl till varför vi behöver ett avsteg från IT policyn så brukar det inte att vara svårt att få till en kompromiss som fungerar.
Projektet/Systemet
Nu har vi bara kvar det verksamheten/projektet faktiskt bör ha koll på, det vill säga nästan bara funktionella krav. Det är oftast frågan om behov som skall uppfyllas och vi bör fokusera på vad och inte hur. Är det så att vi har möjligheten att arbeta agilt så bör vi alltid börja med att utvecklingsteamet får klart för sig vad som behöver utvecklas. Här är inte detaljer viktiga utan här bör man fokusera på syftet.
På den här nivån gör många felet att skriva långa textdokument där man talar om hur det skall fungera vilket kan vara svårt att omsätta i kod. För att illustrera detta så kan vi tänka oss att olika typer av användare skall ha olika rättigheter i systemet. Om vi förenklar det ytterligare så kan vi specificera vem som får Skapa, Uppdatera och Läsa uppgifter i en databas. Termen för det här är CRUD (Create, Read, Update, Delete). Ganska ofta har jag läst kravdokument där man i löptext förklarat först vad systemägare, sedan, administratörer, kunder osv vad de skall få göra.
För att kunna utveckla detta måste utvecklare då tolka dessa instruktioner, och inte sällan skapar man då först en matris av ovanstående för att få en klarare bild. Det är då vanligt att man märker att vissa rättigheter inte är specificerade. Betyder då det att rollen inte skall ha rättigheter eller att man glömt skriva det? Vad vill jag ha sagt med det här? Jo, oftast är det bättre att göra matriser direkt och skriva en förklarande text. Det här är bara ett exempel på hur man kan förenkla specifikationen för vad som behöver utvecklas. På samma sätt som vi tänker på UX för användare av våra system, så behöver vi tänka på hur vi presenterar kraven för de som skall utveckla systemet.
Kravställare och utförare behöver dela bilden av behov och lösningar mellan varandra, kan de inte det så spelar det ingen roll hur bra kraven är skrivna. Hur man arbetar mer specifikt med att skapa förståelse mellan kravställare och utvecklare får vi ta upp i en annan bloggpost.
Inläggsförfattare
