Ved du, hvad en god kravspecifikation betyder for pålideligheden af elektronik?
Danske elektronikvirksomheder spilder vigtige udviklingsressourcer på ikke at specificere præcist, hvad der skal udvikles. Spilder din virksomhed også ressourcer på det? Her er nogle centrale overvejelser, I kan gøre jer for at få overblik over, hvad der skal udvikles.
En stærk kravspecifikation, som er kendt af alle projektdeltagere og kommunikeret til alle underleverandører, er et vigtigt værktøj til at udvikle pålidelige og robuste produkter, som opfylder relevante krav fra myndigheder, kunder og din virksomhed.
I specifikationsfasen er det afgørende, at ressourcer og viden er på plads for at sikre, at krav er verificér- og testbare.
Hvilket udgangspunkt har I?
Der kræves meget forskellige teknikker til at udarbejde en god kravspecifikation, alt efter om det drejer sig om:- helt nyt produkt,
- ny teknologi til at lave jeres eksisterende produkt,
- nye features til eksisterende produkt,
- nye applikation eller nye omgivelser.
Hvis der derimod er tale om ét af de andre tilfælde, er det en god idé at tage udgangspunkt i en eksisterende kravspecifikation.
Dækker jeres kravspecifikation både hardware og software?
I kan spare megen tid og mange penge i udviklingsprocessen ved at fastlægge entydige succeskriterier og specifikke referencestandarder for hvert krav, som relaterer sig til:- hardware
- software
- mekanik
- levetid
- brugsmiljø
Bruger I agil softwareudvikling?
I princippet indgår kravspecifikation ikke i agil softwareudvikling, men rigtig mange virksomheder har god gavn af at have en overordnet kravspecifikation, inden de går i gang med udviklingen af software. Det giver et godt overblik over, hvor man skal hen.Herefter kan man specificere med blandt andet user stories, som man typisk kan holde rede på ved hjælp af et værktøj, som fx Jira.
Review jeres krav og spar vigtige ressourcer
Spar endnu en væsentlig del af ressourcerne ved at gennemføres review af jeres krav. Review’et bør gennemføres i samarbejde med nogen, der er eksterne i forhold til projektet, da man nemt bliver hjemmeblind. Det kan enten være andre i jeres virksomhed eller en uvildig tredje part.Under review’et vurderes blandt andet, om kravene er:
- dækkende
- tydelig adskilt fra kommentarer, implementering, baggrund mv.
- testbare
- specificeret for det relevante produktniveau og ikke blander fx system- eller komponentniveau
- indbyrdes konsistente