I rollen som mentor med bakgrunn i informasjonssystemer står jeg ofte overfor mange spørsmål tilknyttet IT løsninger, disse omhandler blant annet hvordan skal de utvikles og hva det koster å utvikle dem. Det er jo ingen fasit på dette, og fremgangsmåte kan være veldig ulik fra en ide til en annen. Det viktigste for å kunne fortelle noe om IT løsningen man ønsker seg er å utarbeide en kravspesifikasjon. Kravspesifikasjon i IT er noe som beskriver behov, avgrensing og definisjon av et system. Man må selv forstå hva og hvordan den IT løsning man ønsker seg vil se ut, og hva den krever. Det er derfor veldig viktig for egen forståelse og oversikt at man utarbeider en kravspesifikasjon. En tredjepart som skal utvikle en IT løsning for deg er nødt til å forstå problemet, helst med veldig lik oppfatning som deg for å få et produkt som speiler din oppfatning. Dette er noe som heller dessverre ikke er så enkelt, og det er her en god kravspesifikasjon utgjør sin nytte.

Elementer som er viktig og gode å ha med i en kravspesifikasjon er kartlegging av behov, analyse og funksjonalitet, design, teknisk kartlegging og arkitektur, og metodikk. Innenfor hvert av disse elementene finnes det verktøy og metoder som kan hjelpe deg forme dem. Jeg vil her nevne noen som kan være til god nytte.

Kartlegging av behov handler om det å konkretisere og få definert behovene. Ønsker for hva løsning skal kunne gjøre, mål for hva det skal nytte og hjelpe med, begrensninger den vil gi og har for ideen, prioriteringer du har ved løsningen og viktige elementer, samt hva er din nåsituasjon og hva vil løsningen supplere med. En interessent analyse kan også være nyttig ved dette punktet.

Analyse og funksjonalitet tar for seg hvilke funksjoner som er nødvendig og er behov for i løsningen. For å kartlegge funksjonaliteten man ser for seg og ønsker kan brukerhistorier være en god metode. Her tar man en bruker igjennom den ønskede IT løsningen i historier. Det er to hovedmåter å gjøre dette på:

1. Som en X, vil jeg at Y, slik at Z.

2. For å unngå Z, som en X, ønsker jeg Y.

 Det vil her komme frem viktigste rute og funksjonalitet for de historier man ser av størst relevans. Et annet verktøy kan være rike bilder. Rike bilder tegner opp et helhetlig bilde av hvordan bruker interagerer med system og produkt. Andre viktige metoder og verktøy er liste over funksjonalitet og MoSCoW for å prioritere; Must have, Should have, Could have og Won’t have.

 Design er den delen som beskriver utseende for din IT løsning. For å komme frem til dette er det god fremgangsmåte å gjøre dette, hvor alle stegene er viktig å gjennomføre. Først vil man lage papirskisser for hvordan det grovt vil se ut, inkludert de forskjellige rom. Neste steg er å digitalisere papirskissene til digitale mockups. Dette kan gjøres ved hjelp av photoshop, css, eller på nett ved hjelp av FluidUI, Mockups, Marvelapp o.l., og mange andre digitale verktøy. Til slutt vil man utvikle en digital prototype, en funksjonell løsning på design delen. Dette kan kalles for et funksjonelt design, hvor man kan klikke seg gjennom løsningen, men uten at det skjer noen databehandling bak.

 Teknisk kartlegging er hvordan IT løsning på baksiden skal bygges opp. Det er mange veier og metoder for å utvikle en app eller IT løsning, men vi lever i en stadig utviklende verden hvor man er nødt til å håndtere endring. Arkitektur av en IT løsning er essensielt for at funksjoner skal kunne kommunisere, samhandle og være åpen for nye framtidige muligheter og endringer. Flytdiagram er godt kjent blant mange, og er en veldig god metode for å kartlegge flyten i et system, en handling trigger en annen, den andre trigger potensielt to til, og så videre. Dataflow diagram er heller noe annerledes, det forklarer nærmere hvor hen i systemet dataen flyter, mellom database, bruker og system. Andre metoder og verktøy som er viktig å ha med er ER-diagram, state chart, sequence diagram og klassediagram.

 Metodikk vil ta for seg hvordan løsningen burde utvikles. Som oftest deles dette opp i smidig utvikling og plan-dreven utvikling. Smidig utarbeider seg i sammenheng med utviklingen og tar med seg endringer underveis. Plan-dreven utarbeider er større og grundigere plan for hele systemet og utfører denne tilnærmet til punkt og prikke til ferdig produkt.

 Ingen vei er lik for noen under utvikling av en IT løsning, men å ta med seg elementene nevnt ovenfor kan man komme langt i å utarbeide en god kravspesifikasjon. Det finnes flere elementer som er viktig å ha med, men disse dekker en større andel.

Av Øistein Syversen Fongaard, studentmentor i UiA Nyskaping.