Kravspecifikation

Når man udvikler et nyt tech-produkt, bliver man hele tiden klogere. En sensor viser sig måske ikke at kunne levere den forventede præcision. En kommunikationsteknologi bruger mere strøm end forventet. En mekanisk løsning fylder for meget. Eller kunder, der tester en tidlig prototype, viser, at en funktion, man troede var vigtig, faktisk betyder mindre end noget helt andet.

Derfor ser vi ikke kravspecifikationen som et statisk dokument, der skrives én gang og derefter forsvares resten af projektet. Vi ser den som et levende værktøj, der definerer rammerne for produktet og giver projektteamet et fælles billede af, hvad der skal udvikles, hvordan det skal fungere, og hvornår en løsning kan betragtes som godkendt.

Det betyder ikke, at krav skal være løse eller uklare. Tværtimod. Gode krav skal være så konkrete, at de kan forstås, prioriteres og testes. Hvis et produkt eksempelvis skal holde et år på batteri, fungere inden for et bestemt temperaturområde eller reagere inden for en defineret tid, skal det fremgå tydeligt. Hvor det er muligt, kobler vi krav til acceptkriterier og test, så man senere kan dokumentere, om kravet faktisk er opfyldt.

Men krav kan ændre sig. Det kan ske af tekniske årsager, fordi udviklingen afdækker nye muligheder eller begrænsninger. Det kan også komme fra markedet. Når kunder eller brugere får mulighed for at teste prototyper undervejs, kommer der ofte værdifuld feedback, som bør påvirke produktets næste version. Det er netop en af fordelene ved at teste tidligt frem for først at præsentere kunden for det færdige produkt.

Det afgørende er derfor ikke at undgå ændringer. Det afgørende er at håndtere dem kontrolleret.

Når et krav ændres, skal man forstå konsekvensen. Påvirker ændringen elektronikken, softwaren eller mekanikken? Kræver den ny test? Påvirker den produktionsprisen, certificeringen eller tidsplanen? Er den nødvendig for første launch, eller kan den vente til en senere release? En struktureret kravspecifikation gør det muligt at stille de spørgsmål og træffe beslutningen på et oplyst grundlag.

Vi arbejder derfor med prioritering af krav. Ikke alle krav behøver at være opfyldt i første version. Nogle er fundamentale for produktets funktion eller sikkerhed. Andre er vigtige for brugeroplevelsen, og nogle kan være ønsker, der med fordel gemmes til en senere version. Det gør det muligt at holde fokus på launch og undgå, at udviklingsbudgettet bliver brugt på funktioner, som endnu ikke er nødvendige.

Her passer en agil projektmodel godt til teknisk produktudvikling. Hos Move kan vores MoveForward-model bruges til at dele projektet op i overskuelige faser, hvor krav, risici og tekniske valg løbende kan valideres. De største usikkerheder kan undersøges tidligt, og resultaterne kan bruges til at justere både kravspecifikation og den videre plan.

Kravspecifikationen bliver på den måde ikke kun et dokument til udviklerne. Den bliver et fælles styringsværktøj for management, produktteam, udviklere og senere test og produktion. Den kan skabe forbindelse mellem forretningsmål, brugerbehov, tekniske løsninger og konkrete tests.

Målet er ikke den perfekte kravspecifikation på dag ét. Målet er at have de rigtige krav på det rigtige tidspunkt og en proces, der gør det muligt at blive klogere uden at miste retning, budget eller kontrol over projektet.