Kravspesifikasjon – den umulige kunsten å beskrive noe som ikke finnes

Reading time:

Kravspesifikasjonen er dokumentet som fullstendig beskriver det som ikke ennå finnes, på en måte som gjør at ingen kan misforstå den. Den perfekte kravspesifikasjonen – gitt at noe sånt faktisk kan lages – er så utfyllende, entydig, gjennomtenkt og forståelig at hvem som helst skal kunne lage det den beskriver. Kravspesfikasjonen er jo også ofte laget for nettopp det: at man kan innhente tilbud fra flere leverandører og sammenligne det som effektivt skal være samme leveranse ut fra pris; siden alle leverandørene skal levere det samme er det bare prisen som skiller.

Sammenlign dette med hvordan prosjekter faktisk fungerer: etterhvert som man begynner å lage noe, lærer man hvor lite man egentlig visste om problemområdet. Etterhvert som brukere begynner å klikke på knapper ser man hva de egentlig trenger. Prosjekter er en læringsprosess, og kunnskapen man får underveis i prosjektet har enorm verdi. En «god» kravspesfikasjon eksisterer i en verden der dette ikke skjer, der lærdom man får underveis i prosjektet håndteres gjennom avviksprosesser (bare smak på det ordet…). En god kravspesifikasjon lar deg sette apekatter til å gjennomføre, men hvem vil egentlig jobbe sammen med apekatter (bortsett fra dyrepassere)?

Det finnes en rekke alternativer til den tradisjonelle kravspesifikasjonen når man skal lage programvare; de fleste har en ting til felles: tillit. Uten tillit mellom den som kjøper og den som leverer kan ikke engang den beste kravspesifikasjonen redde prosjektet. Og videre: om vi forutsetter et tillitsforhold mellom partene, trenger vi da den tradisjonelle kravspesfikasjonen?

En annerledes tilnærming

Jeg skal ikke gå i dybden på alternativene til kravspesifikasjonen her, det er antakelig mer enn nok stoff for en annen artikkel. Men en tidligere kollega av meg har skrevet en ganske annerledes måte å spesifisere et websystem som jeg synes var veldig interessant. Børre Austmann jobber i Human-Etisk Forbund (HEF), og ble for noen år siden med i en arbeidsgruppe for å utvikle et system HEF ønsket å lage for håndtering av deltakere i Humanistisk konfirmasjon og andre seremonier.

Etter å ha laget en omfattende og detaljert rapport til HEFs hovedstyre, fikk gruppen grønt lys for å gå videre, men samtidig signaler om at fremtidige innspill ikke måtte være så omfattende og detaljerte. Børre satte seg da ned og skrev et scenario fra år 2009 – altså noen år fram i tid – som beskrev hvordan noen oppdiktete personer forholdt seg til Humanistisk konfirmasjon.

Lene er 14 år, og har bestemt seg for Humanistisk konfirmasjon. Om påmeldingen beskriver scenariet blant annet:

I august åpner Lene på nytt nettsidene for å fylle ut påmeldingsskjemaet som hun finner på en link fra Grenland lokallags hjemmeside. Skjemaet er flersidig og oversiktlig. Første side er spørsmål om Lene – navn, fødselsdag, adresse, hennes mobil og epost, skole og klasse hun går i. Hun kan også velge om hun vil ha skjemaet på bokmål eller nynorsk. Hun velger bokmål. Språket i skjemaet og all korrespondanse vil være på det målføret hun har valgt.

HEF brukte dette scenariet som grunnlag til å innhente tilbud fra forskjellige leverandører, og fikk som tilbakemelding fra dem at dette var en spennende og annerledes måte å jobbe på.

Det elektroniske påmeldingsskjemaet kom allerede fire måneder senere. I dag melder nær 99% av konfirmantene seg til Humanistisk konfirmasjon på nett. HEFs ansatte i fylkene sparer til sammen massevis av timer i året på at manuelle prosesser er automatisert, timer de kan bruke på andre ting. Men det viktigste er kanskje at samarbeidet mellom HEF og leverandøren deres fortsatt er basert på tillit, og at begge parter er fornøyd med og stolt av det de har laget.

Scenario = brukerhistorier?

De som har jobbet med brukerhistorier kjenner dere kanskje igjen i denne måten å spesifisere på. Brukerhistorier er kjent fra smidig utvikling, og gir en måte for kunden å beskrive bruksområder av et system som skal lages. Extremeprogramming.com definerer blant annet brukerhistorier slik:

[User stories] are in the format of about three sentences of text written by the customer in the customers terminology without techno-syntax.

I extreme programming bruker man brukerhistorier som grunnlag for akseptansetester, og er dermed en del av estimeringsprosessen: brukerhistorien konkretiseres i form av akseptansekriterier, som relativt entydig brukes for å oppnå enighet mellom kunden og leverandøren om at leveransen er ferdig. Scenariene som er beskrevet her er både lenger enn og har en mer litterær/emosjonell form og en lavere detaljeringsgrad enn en brukerhistorie.

Til slutt, siste avsnitt fra scenariet, der Lene (konfirmanten) og Reidar (fylkessekretæren) ser tilbake på seremonien:

Av kurslederen fikk hun en rose, en klem og kursbevis da hennes navn ble ropt opp. Rosa og klemmen sto det ingenting om i konfirmantbasen – men det var fra denne Reidar hadde kjørt ut kursbeviset hennes på fylkeskontorets skriver – rett fra nettet noen dager før, mens han sjøl løste sudokuen i Telemark Arbeiderblad.

4 thoughts Kravspesifikasjon – den umulige kunsten å beskrive noe som ikke finnes

  1. Christian sier:

    Interessant! Som en forlengelse av ideen om å designe et system ut fra noe annet enn en utopisk kravspesifikasjon kom jeg plutselig til å tenke på dette innlegget.

    Innlegget gir en innføring til A/B-testing samt presenterer en Rails-plugin for å gjøre akkurat det. Disse gutta har dratt det langt og kaller det å jobbe med A/B-tester som primærdriver «Experiment driven development». Man kan også se det som en alternativ måte å angripe et prosjekt på: Formuler noen forretningsmål og noen eksperimenter som baserer seg på teorier om hvordan disse kan innfris. Sett igang, styr skuta etter resultatene fra eksperimentene. Man kan aldri lage en kravspek i forkant som gir deg svarene en slik angrepsvinkel gir deg.

  2. Marius sier:

    @Christian: Herre for en ide! Eller rettere sagt: ideen er vel ikke så ny, men det å gjøre det så enkelt å prøve inn ideer, samle resultater og vurdere suksess er virkelig inspirerende! Dette er vel en av tingene mange kunne tenke seg å prøve, men som virker vanskelig å komme igang med.

    Jeg er med!

  3. Karl Philip sier:

    Jeg har samme erfaringer med kravspesifikasjoner. Uansett hvor nøye man beskriver løsningene, så dukker det alltid opp masse underveis.

    Jeg tror innlegget dit samsvarer veldig godt med Jack Welch sitt budskap om strategi:
    «Choose a general direction and implement like hell»

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

Du kan bruke disse HTML-kodene og -egenskapene: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>