Kravspecifikation til forretningssoftware: fra behov til dokumenteret krav

Standarder som kravfundament – ikke en løs ønskeliste

En standard er en detaljeret teknisk beskrivelse af en fremgangsmetode, et produkt, en prøvningsmetode eller en ydelse. Det er Sikkerhedsstyrelsens definition. I en kravspecifikation til forretningssoftware er den brugbar, fordi en standard beskriver noget konkret og efterprøvbart.

Guiden går trinvist fra forretningsbehov til dokumenteret krav. Trin 1 giver et forretningsbehov, Trin 2 et emneområde, Trin 3 en valgt standard, Trin 4 en standardreference med udgave og Trin 5 et formuleret krav med attributter. Hvert trin efterlader et resultat, som næste trin bygger på.

En standard erstatter ikke et løst ønske om, at systemet »skal være sikkert« eller »skal understøtte kvalitet«. Man henviser til en udgivet standardtekst i stedet for kun at beskrive kravet med virksomhedens egne ord. Referencen peger på en fælles, ekstern tekst, som kunde, leverandør og eventuel tredjepart kan slå op i og vurdere imod.

I Danmark er Dansk Standard det centrale standardiseringsorgan. Dansk Standard udarbejder danske standarder, implementerer europæiske og internationale standarder og udgiver standarder i Danmark. Derfor er Dansk Standard det naturlige udgangspunkt for at finde standarder til kravspecifikationen.

Standarder kan være danske, europæiske eller internationale. De danske mærkes DS, de europæiske EN, og de internationale kommer fra ISO, IEC og IEEE. Mange danske standarder svarer 100 procent til en europæisk eller international standard som EN eller ISO.

Der findes over 27.000 forskellige standarder, så emneområdet skal vælges først. Ellers risikerer kravspecifikationen at blive en løs ønskeliste i stedet for et dokumenteret kravfundament.

Til forretningssoftware findes en navngiven standard for kravarbejdet: ISO/IEC/IEEE 29148-2018. Den indeholder bestemmelser om processer og produkter for kravengineering til systemer og softwareprodukter og -tjenester gennem hele livscyklussen. Standarden definerer konstruktionen af et godt krav og angiver attributter og karakteristika for krav.

Standarden definerer desuden information items for kravengineering og deres indhold. Den behandler den iterative og rekursive anvendelse af kravprocesser gennem hele livscyklussen og giver supplerende vejledning til kravarbejdet i ISO/IEC/IEEE 12207 og ISO/IEC/IEEE 15288. Den kan anvendes sammen med dem eller uafhængigt.

Attributter og karakteristika hører til det enkelte krav, ikke til dokumentet som helhed. De gør det muligt at følge og efterprøve hvert krav for sig gennem hele livscyklussen. Både kravets form og kravdokumentets indhold er dermed adresseret i standarden.

Dansk Standard udgiver standarder, vejledninger, håndbøger og guides på tværs af fagområder og yder rådgivning. Organisationen er Danmarks standardiseringsorganisation og varetager både national og international standardisering. Den tilbyder også rådgivning og uddannelse med udgangspunkt i standarder og best practice.

Fakta om standarder i kravspecifikationer

Behovsafdækning med standarder som systematisk redskab

Trin 1 i guiden er at afdække behovet systematisk. Behovsafdækningen er ofte der, hvor et softwareprojekt går galt: behovene beskrives hver for sig, og først sent opdager man, at væsentlige områder er udeladt.

Sikker digital beskriver standarder som et systematisk redskab til cyber- og informationssikkerhed. De giver organisationer et godt udgangspunkt, der »allerede er velafprøvet og gennemtænkt, i stedet for at de selv skal starte fra bunden«.

Det rækker videre end sikkerhedsområdet. Når behov skal omsættes til krav, giver en standard en ramme, som mange aktører har arbejdet med før. Rammen dækker emner, den enkelte virksomhed måske ikke selv ville have tænkt på, og gør det lettere at argumentere for, hvorfor et bestemt krav er med.

I en kravspecifikation til forretningssoftware kan standarder bruges på to niveauer. Som kilde til hvilke emneområder der bør afdækkes, og som dokumenteret reference for de enkelte krav. Det første sikrer bredden i afdækningen, det andet sporbarheden i det færdige kravdokument.

Trin 1 kan opdeles i fire handlinger. Beskriv forretningsbehovet. Vælg emneområde. Find den navngivne standard for området. Brug standardens information items som tjekliste for kravdokumentets indhold.

En brugbar struktur kan tage udgangspunkt i SRS-indhold som eksterne grænseflader, funktioner, brugervenlighed, ydeevne, data, designbegrænsninger, standardoverholdelse og systemets kvalitetsattributter. Dalus' SRS-arbejdsgang viser desuden felter for begrundelse, kilde, prioritet, status, verifikationsmetode, tildeling og relationer til overordnede krav (Dalus Workflows).

Behovsafdækningen er ikke en enkelt workshop. Standarden behandler den iterative og rekursive anvendelse af kravprocesser gennem hele livscyklussen, så krav ikke kun bygger på enkelte workshops, men gentages, efterhånden som krav og løsning bliver klarere.

Når behovet er afdækket, er Trin 1 færdigt. Resultatet er et forretningsbehov, som næste trin kan oversætte til et emneområde.

Fra forretningsbehov til relevante standardområder

Trin 2 i guiden er at oversætte forretningsbehovet til et emneområde. Vejen fra forretningsbehov til standard går typisk gennem et emneområde, og emneområdet bestemmer, hvilken standard der er relevant.

Et behov om at håndtere salg i en webshop kan omsættes til et funktionelt krav. Kravet kan for eksempel beskrive, hvordan prisen beregnes for de varetyper, virksomheden sælger.

Adskil funktionelle krav fra kvalitetskrav. Sikkerhed, ydeevne og brugervenlighed er eksempler på kvalitetsattributter; virksomheden må beskrive sine konkrete forventninger til hvert område.

Et ydeevnekrav kan angive den datamængde, der skal behandles inden for en bestemt periode, både ved normal- og spidsbelastning. NASA's SRS-materiale nævner disse forhold som interne datakrav (NASA Software Engineering Handbook).

Et forretningsbehov om dokumenterede krav peger mod ISO/IEC/IEEE 29148-2018. Den er den navngivne standard for kravengineering til systemer og software. Emneområdet er derfor kravengineering, ikke kun kvalitetsledelse eller sikkerhed.

En standard kan ikke beskrive virksomhedens egne processer, data og forretningsregler. Skriv derfor virksomhedens arbejdsgange som særskilte krav.

Trin 2 kan gennemføres ved at skrive behovet i én sætning. Spørg om behovet handler om kvalitetsledelse, cyber- og informationssikkerhed eller kravengineering. Svaret peger på emneområdet.

Skriv behovet som en konkret arbejdssituation, og navngiv de data og beslutninger, der indgår. For en webshop kan det betyde, at virksomheden beskriver sine egne regler for prisberegning.

Notér for hvert krav, om det beskriver en funktion eller en kvalitetsforventning. Sikkerhed, ydeevne og brugervenlighed er eksempler på kvalitetsområder, som kan gøres til krav.

Når behov og kravområder er beskrevet, vælger virksomheden en relevant standardreference og noterer den præcise udgave. Kravene skal samtidig indeholde virksomhedens egne regler, så de kan vurderes i forhold til de konkrete behov.

Fra forretningsbehov til testbare krav og sporbarhed

Tag udgangspunkt i et konkret behov fra virksomheden. Beskriv den ønskede arbejdsgang, før den omsættes til funktionelle krav, som senere kan verificeres.

Et konkret krav kan beskrive, hvilke felter og funktioner en løsning skal indeholde. Formuleringen gør det tydeligt, hvad løsningen skal kunne.

Et acceptkriterium kan være, at en funktion kontrollerer, at de nødvendige oplysninger er korrekt udfyldt, før brugeren kan gennemføre handlingen. Verificér kravet ved test; test er en af de verifikationsmetoder, NASA's SRS-materiale nævner (NASA Software Engineering Handbook).

Sporbarheden kan vises som en kæde: Behovet beskrives først; kravet formuleres, så det dækker behovet; testen kontrollerer kravet. NASA's kravmanual siger, at testprocedurer skal afprøve hvert krav og være direkte sporbare til kravspecifikationen (MSFC General-Purpose Software Development and Management Requirements Manual).

Registrér prioritet og status for hvert krav, så det fremgår, hvilke krav der er prioriteret, og hvor de står i forløbet; sådanne felter indgår i Dalus' SRS-arbejdsgang (Dalus Workflows). Ved ændringer kan virksomheden føre en ændringslog med årsag, beslutning og berørte krav.

Versionsstyring af standarder i kravdokumentationen

En standardhenvisning skal gøre det muligt at finde den tekst, kravet bygger på. Et eksempel på en præcis reference er ISO/IEC/IEEE 29148:2018(E), 2018 (NASA Software Engineering Handbook).

Skriv standardens betegnelse og udgave ved hvert standardbaseret krav. Så kan kunde og leverandør vurdere kravet mod samme tekst, og verifikationen kan knyttes til den samme reference.

Når en kravspecifikation henviser til en standard, er det afgørende at være opmærksom på versionen. En henvisning uden version eller udgave kan senere pege på et andet indhold, end både kunde og leverandør regnede med.

Registrér standardens fulde betegnelse, udgave og den tekst, der er bindende, i kravdokumentationen. Det gør det lettere at holde kravets reference og den senere verifikation samlet.

Hvis et krav afhænger af en bestemt formulering i en standard, skal kravdokumentet pege på den præcise udgave. En upræcis henvisning gør det uklart, hvilken tekst kravet skal vurderes imod.

Angiv også, hvilken udgave af standardteksten der gælder, hvis kravet bygger på en bestemt sproglig formulering. Både krav og verifikation skal henvise til den samme standardreference.

En konkret reference er ISO/IEC/IEEE 29148:2018(E), 2018, som NASA's SRS-materiale henviser til (NASA Software Engineering Handbook). Skriv betegnelsen og udgaven, så henvisningen ikke står som en ubestemt forkortelse.

I webshoppen kan man købe danske, europæiske og internationale standarder. Dansk Standard leverer også nationale standarder fra andre lande.

Trin 4 er netop at skrive standardens betegnelse og den bindende udgave ind i kravdokumentet. Uden udgave er kravet ikke entydigt dokumenteret.

Fra standardreference til dokumenteret krav i forretningssoftware

Standarder bruges i kravspecifikationen som dokumenteret reference. Man henviser til en udgivet, teknisk beskrivelse af en fremgangsmetode, et produkt, en prøvningsmetode eller en ydelse og angiver præcist, hvilken standard og hvilken udgave der er tale om. Referencen gør kravet efterprøvbart og giver parterne et fælles opslagsværk at diskutere ud fra.

Trin 3 er at vælge den standard, der dækker emneområdet. Trin 4 er at skrive standardens betegnelse og den udgave, der er bindende, ind i kravdokumentet. Trin 5 er at formulere det enkelte krav med de attributter, standarden angiver.

Samtidig skal skellet mellem standardbaserede krav og virksomhedens egne behov være tydeligt. En standard beskriver det generelle og velafprøvede – den fælles ramme – men den kender ikke den enkelte virksomheds processer, data og forretningsregler.

Kravene til forretningssoftware vil derfor typisk bestå af to lag. Standardbaserede krav, der kan henvises til en ekstern tekst, og virksomhedsspecifikke krav, der alene kan beskrives af virksomheden selv. Kravdokumentet bør skelne mellem de to lag, så det er tydeligt, hvad der er hentet fra en standard, og hvad der er virksomhedens eget behov. Det letter tilbudsgivningen, leverandørens løsningsvalg og den senere verifikation.

I praksis kan kravdokumentet opdeles i standardbaserede og virksomhedsspecifikke kravlinjer. Standardbaserede linjer angiver standardens betegnelse og udgave. Virksomhedsspecifikke linjer angiver virksomhedens egen regel for processer, data og forretningsregler.

En kravlinje kan sættes op med felterne kravtekst, behov eller kilde, begrundelse, prioritet, status, tildeling, relation til overordnet krav og verifikationsmetode. Felterne indgår i Dalus' arbejdsgang for en SRS (Dalus Workflows).

Skriv hvert krav som en tydelig forventning, der kan kontrolleres, og undgå uklare ord som »hurtig« eller »god«. Knyt begrundelse, kilde og verifikationsmetode til kravet, så læseren kan se både baggrunden og måden, det skal efterprøves på (Dalus Workflows).

Attributterne følger det enkelte krav gennem hele livscyklussen. Derfor kan kravet formuleres, godkendes og senere efterprøves mod den samme standardtekst.

Vælg verifikationsmetode ud fra det, kravet handler om. NASA's SRS-materiale nævner test, inspektion, analyse og demonstration som metoder til verifikation (NASA Software Engineering Handbook).

Dokumentet kan struktureres med afsnit om eksterne grænseflader, funktioner, brugervenlighed, ydeevne, data, designbegrænsninger, standardoverholdelse og systemets kvalitetsattributter (Dalus Workflows). Hvert krav får sin egen kravtekst og felter for kilde, prioritet, status, tildeling, overordnet krav og verifikationsmetode.

Prioritér kravene, og registrér deres status, så teamet kan se, hvilke der er vigtigst, og hvad der er besluttet; disse felter indgår i Dalus' SRS-arbejdsgang (Dalus Workflows). Ved en ændring noteres årsagen, beslutningen og de berørte krav i en ændringslog.

Et funktionelt krav kan beskrive en konkret handling, systemet skal kunne udføre. Virksomheden beskriver sine konkrete regler i særskilte krav.

Et ydeevnekrav kan formuleres: »Systemet skal behandle [datamængde] inden for [tidsperiode] ved normal- og spidsbelastning.« NASA's SRS-materiale nævner datamængde inden for en angivet tidsperiode samt normal- og spidsbelastning som forhold, krav kan beskrive (NASA Software Engineering Handbook).

Et dokumenteret krav bør angive standardens betegnelse og den udgave, der er bindende. Hvis den danske standard kun er et godkendelsesblad, bør kravet pege på den udenlandske standardtekst, der faktisk indeholder kravene.

Hold en sporbarhedskæde for hvert krav: fra behov til kravtekst og videre til verifikationen. Kæden kan koble et behov til de krav, der dækker det, og til den test, der kontrollerer dem. NASA's kravmanual fremhæver, at testprocedurer skal kunne spores direkte til kravspecifikationen (MSFC General-Purpose Software Development and Management Requirements Manual).

Ved henvisning til ISO/IEC/IEEE 29148-2018 bør både standardbetegnelse og årstal med. Standarden er publiceret i 2018 og afløser 29148-2011. Dermed undgås en uklar henvisning til en tidligere udgave.

Følg rækkefølgen fra forretningsbehov til kravområde, standardreference med udgave og virksomhedsspecifikke krav. Giv hvert krav en kilde, prioritet, status og verifikationsmetode, og forbind det med den test, der kontrollerer det (Dalus Workflows; MSFC General-Purpose Software Development and Management Requirements Manual).

En kravspecifikation til forretningssoftware skal rumme både funktioner og kvalitetskrav samt virksomhedens egne regler for processer og data. Kravene bør vise, hvordan behov kan omsættes til krav, acceptkriterier og test.