Formål
Formålet med kravhåndtering af at styre krav i relation til projekter og udbud, og gøre det i et EA perspektiv og i en livscyklus.
Formålet med kravhåndtering er overordnet, at sikre en organisation dokumenterer, kontrollerer og opfylder behovene og forventningerne hos sine kunder og interne eller eksterne interessenter.
Input
Kravhåndtering modtager input fra de fleste af de andre aktiviteter i metoderammen.
Nedenstående figur illustrerer hvordan nogle af de vigtigste leverancer fra arbejdet med forretning, information og applikationer bliver til funktionelle krav.
Output
- Output på EA niveau er et sæt fælles krav, som kan lagres og udstilles i et fælles kravbibliotek. Dette kan fungere som en slags fælles kravbank. Det væsentligste indhold er her de tværgående principper, og ikke funktionelle krav som f.eks. krav til teknologivalg, sikkerhed og drift.
- Output på projektniveau er en eller flere kravspecifikationer.
- Både på EA og projektniveau er der desuden behov for løbende at håndtere dokumentation af ændringsønsker.
Metode
Kravtyper
Vi taler grundlæggende om tre typer af krav:
- Funktionelle krav – de funktioner, som systemet skal kunne udføre og dermed de funktioner, som en bruger skal kunne anvende.
- Ikke-funktionelle krav – forskellige begrænsninger
- Løsningsmål – retningslinier til at vælge den rette løsning
Med hensyn til det funktionelle krav er det vigtige, at man beskriver hvad man ønsker af systemet og ikke hvordan systemet skal løse opgaven. Dette er derfor primært forretningsarkitektur og forretningens opgave. Overlad det så vidt muligt til leverandøren og teknikerne at finde ud af hvordan. Man behøver ikke teknisk indsigt for at specificere krav – måske tværtimod.
Med hensyn til de ikke-funktionelle krav drejer det sig om dels om begrænsninger på løsningen, også kaldet performancekrav. De er typisk mere tekniske og vedrører eksempelvis interoperabilitet, sikkerhed, åbenhed, fleksibilitet og skalerbarhed (som er de fem principper, som anbefales i hvidbogen om it-arkitektur). En anden type ikke funktionelle krav er hvad man kan kalde projektkrav, som handlker om begrænsninger i relation til tid, penge, ressourcer, proces, metode osv.
Digitaliseringsstyrelsen har lavet en taksonomi over typer af krav, som du kan tage udgangspunkt i når du skal strukutere dine krav.
På løsningsniveau:
En kravspecifikation er en almindeligt anvendt type dokument, der samler mange OIO EA leverancetyper i ét dokument. Praktisk taget alle OIO EA fra aktiviteterne A til C kan indgå i en kravspecifikation – jo mere den ønskede arkitektur er specificeret, jo bedre kan en leverandør tilpasse sit tilbud til den.
På EA og løsningsniveau:
Kravhåndtering spænder i princippet over hele OIO meteodrammens struktur – fra vision, overordnede mål, udfordringer og målbillede over det det forretningsmæssige og tekniske modelleringsarbejde til de mål og begrænsninger der fastlægges i gap anayse og migrationsplanlægning. Kravhåndteringens opgave er at samle allle relevante krav op på en struktureret måde
Kravhåndtering omfatter planlægning af kravformulering, koordinering (integration, konflikløsning, ændringer),implementering (i projekter, kontrakter, organisation og løsninger) og er koblet tæt til governance, herunder fastlæggelse rammer (regler, procuderer og dækningsgrad) for anvendelse og overholdelse af krav.
Sporbarhed er et væsentligt element i krahåndteringen. det er således væsenrligt at tage stilling til hvordan opfyldelse af krav skal dokumenteres og rapporteres både til projekt og EA-funktion. Det omfatter compliance, fuldstændighed, dækning og konsistens.
Kravhåndtering fordrer kommunikation mellem EA funktionen og projekter, og mellem et projektteams medlemmer og interessenter. Kommunikationen skal i princippet håndtere ændringer i hele projektforløb.
Evnen til at håndtere krav på EA niveau er af stor betydning for en organisations modenhed – og omvendt.
Gode råd
Det er en god idé med en tæt, løbende kommunikation mellem de forskellige interessenter både på EA og projektniveau. Ellers risikerer man, at tingene klumper sig sammen og at bliver til uhåndterbare problemer.
Virkeligheden er at mange projekter er forretningsdrevet i en grad, så de ikke har tid til at lave use cases, være i dialog med brugerne eller koordinere med EA-funktionen. Derfor en en kultur med en tæt, løbende kommunikation med interessenter og EA-funktion, og en stærk governanceramme afgørende for god kravhåndtering.