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.