Krav (ingeniørvidenskab)

Inden for ingeniørvidenskab er et krav en betingelse, der skal være opfyldt, for at udbyttet af en arbejdsindsats er acceptabelt. Det er en eksplicit, objektiv, klar og ofte kvantitativ beskrivelse af en betingelse, der skal opfyldes af et materiale, design, produkt eller en tjeneste.

En kravspecifikation er et sæt krav, der typisk bruges af udviklere i designfasen af produktudviklingen og af testere i deres verifikationsproces.

Med iterativ og trinvis udvikling såsom agil softwareudvikling udvikles krav parallelt med design og implementering. Med vandfaldsmodellen færdiggøres kravene før design eller implementering påbegyndes.

Krav bruges inden for mange ingeniørområder, herunder ingeniørdesign, systemudvikling, softwareudvikling, virksomhedsdesign, produktudvikling og procesoptimering.

Krav er et relativt bredt begreb, der kan beskrive enhver nødvendig eller ønsket funktion, attribut, evne, egenskab eller kvalitet af et system, for at det har værdi og nytte for en kunde, organisation, bruger eller anden interessent.

Udtrykkets oprindelse

Udtrykket krav har været i brug inden for softwareudvikling siden mindst 1960'erne.

Ifølge Guide to the Business Analysis Body of Knowledge® version 2 fra IIBA (BABOK) er et krav:

1. En betingelse eller evne, som en interessent har brug for for at løse et problem eller nå et mål.
2. En betingelse eller evne, der skal opfyldes eller besiddes af en løsning eller løsningskomponent for at opfylde en kontrakt, standard, specifikation eller andre formelt pålagte dokumenter.
3. En dokumenteret repræsentation af en tilstand eller evne som i (1) eller (2).

Denne definition er baseret på IEEE 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology.

Produkt- versus proceskrav

Krav kan siges at relatere til to områder:

• Produktkrav foreskriver egenskaber ved et system eller produkt.
• Proceskrav foreskriver aktiviteter, der skal udføres af den udviklende organisation. For eksempel kunne proceskrav specificere de metoder, der skal følges, og begrænsninger, som organisationen skal overholde.

Produkt- og proceskrav er tæt forbundet; et produktkrav kan siges at angive den automatisering, der kræves for at understøtte et proceskrav, mens et proceskrav kan siges at specificere de aktiviteter, der kræves for at understøtte et produktkrav. For eksempel kan et krav til maksimale udviklingsomkostninger (et proceskrav) pålægges for at hjælpe med at opnå et krav til maksimal salgspris (et produktkrav); et krav om, at produktet skal kunne vedligeholdes (et produktkrav), løses ofte ved at stille krav om at følge bestemte udviklingsparadigmer (fx objektorienteret programmering), stilmanualer eller en gennemgangs-/inspiceringsproces (proceskrav).

Typer af krav

Krav er typisk klassificeret i typer produceret på forskellige stadier i en udviklingsproces, hvor taksonomien afhænger af den overordnede model, der anvendes. For eksempel blev følgende skema udtænkt af International Institute of Business Analysis i deres Business Analysis Body of Knowledge (se også FURPS og typer af krav).

Arkitekturkrav

Arkitekturkrav beskriver, hvad der skal gøres ved at identificere den nødvendige integration af systemstruktur og systemadfærd, dvs. et systems systemarkitektur. I softwareudvikling kaldes de arkitektonisk signifikante krav, som defineres som de krav, der har en målbar indflydelse på et softwaresystems arkitektur.

Forretningskrav

Beskrivelser på højt niveau af en organisations mål eller behov. De beskriver normalt muligheder, som en organisation ønsker at realisere eller problemer, som de ønsker at løse. Ofte angivet i en business case.

Brugerkrav (interessentkrav)

Beskrivelser på mellemniveau af behovene hos en bestemt interessent eller gruppe af interessenter. De beskriver normalt, hvordan nogen ønsker at interagere med den påtænkte løsning. Fungerer ofte som en mellemting mellem de overordnede forretningskrav og mere detaljerede løsningskrav.

Funktionelle krav (løsningskrav)

Som regeldetaljerede beskrivelser af evner, adfærd og information, som løsningen har brug for. Eksempler omfatter formatering af tekst, beregning af et tal, modulering af et signal. De er også nogle gange kendt som kapabiliteter.

Ikke-funktionelle krav (kvalitetskrav)

Som regel detaljerede beskrivelser af de forhold, hvorunder løsningen skal forblive effektiv, kvaliteter, som løsningen skal have, eller begrænsninger, inden for hvilke den skal fungere. Eksempler omfatter: pålidelighed, testbarhed, vedligeholdelsesdygtighed, tilgængelighed. De er også kendt som karakteristika, begrænsninger eller ilities.

Implementeringskrav (overgangskrav)

Som regel detaljerede erklæringer om evner eller adfærd, der kun kræves for at muliggøre overgangen fra virksomhedens nuværende tilstand til den ønskede fremtidige tilstand, men som derefter ikke længere vil være påkrævet. Eksempler omfatter rekruttering, rolleændringer, uddannelse, migrering af data fra et system til et andet.

Lovkrav

Krav defineret af retskilder (føderale, statslige, kommunale eller regionale), kontrakter (vilkår og betingelser) eller politikker (virksomheds-, afdelings- eller projektniveau).

Egenskaber ved gode krav

Egenskaber ved gode krav er forskelligt angivet af forskellige forfattere, hvor hver forfatter generelt lægger vægt på de egenskaber, der er mest passende for deres generelle diskussion eller det specifikke teknologidomæne, de behandler. Imidlertid er følgende egenskaber bredt anerkendt:

Egenskab	Forklaring
Enhed (sammenhæng)	Kravet omhandler én og kun én ting.
Fuldstændighed	Kravet er fuldt ud angivet ét sted uden manglende oplysninger.
Konsistens	Kravet er ikke i modstrid med andre krav og er fuldt ud i overensstemmelse med al autoritativ ekstern dokumentation.
Atomicitet (disjunktion)	Kravet er atomisk, dvs. det indeholder ikke konjunktioner. F.eks. skal "Postnummerfeltet skal validere amerikanske og canadiske postnumre" skrives som to separate krav: (1) "Postnummerfeltet skal validere amerikanske postnumre" og (2) "Postnummerfeltet skal validere canadiske postnumre".
Sporbarhed	Kravet opfylder hele eller en del af et forretningsbehov som angivet af interessenter og autoritativt dokumenteret.
Aktualitet	Kravet er ikke blevet forældet med tiden.
Entydighed (utvetydighed)	Kravet er beskrevet kortfattet uden brug af teknisk jargon, akronymer (medmindre de er defineret andetsteds i kravdokumentet) eller anden esoterisk sprogbrug. Det udtrykker objektive fakta, ikke subjektive meninger. Det er underlagt én og kun én fortolkning. Vage emner, adjektiver, præpositioner, verber og subjektive vendinger undgås. Negative udsagn og sammensatte udsagn undgås.
Prioritering	Mange krav repræsenterer en interessentdefineret egenskab, hvis fravær vil resultere i en større eller endda afgørende mangel. Andre repræsenterer funktioner, der kan implementeres, hvis tid og budget tillader det. Kravet skal angive et niveau af betydning eller en priotering af kravet efter en kendt metode fx MoSCoW.
Verificerbarhed	Implementeringen af kravet kan bestemmes gennem grundlæggende mulige metoder: inspicering, demonstration, test (instrumenteret) eller analyse (for at inkludere valideret modellering og simulering).

Der er mange flere egenskaber at overveje, som bidrager til kvaliteten af kravene. Hvis krav er underlagt regler om fx dataintegritet, så er nøjagtighed/korrekthed og gyldighed/autorisation også værdige egenskaber. Sporbarhed bekræfter, at det stillede krav opfylder behovet (ikke mere - og ikke mindre end det krævede).

Til ovenstående tilføjer nogle egenskaben "eksternt observerbar", der vil sige, at kravet specificerer en egenskab ved produktet, som kan observeres af eksterne eller opleves af brugeren. Sådanne fortalere hævder, at krav, der specificerer intern arkitektur, design, implementering eller testbeslutninger, sandsynligvis er begrænsninger og bør være klart formuleret i afsnittet om begrænsninger i kravdokumentet. Den modstridende opfattelse er, at dette perspektiv fejler på to punkter. For det første anerkender perspektivet ikke, at brugeroplevelsen kan være understøttet af krav, som ikke kan opfattes af brugeren. For eksempel kan et krav om at præsentere geokodet information til brugeren understøttes af et krav om en grænseflade med en ekstern tredjepart. Grænsefladen vil være umærkelig for brugeren, selvom præsentationen af information præsenteret gennem grænsefladen bestemt ikke ville. For det andet begrænser en begrænsning designalternativer, hvorimod et krav specificerer designegenskaber. For at fortsætte eksemplet er et krav om valg af en webservicegrænseflade forskellig fra en begrænsning, der begrænser designalternativer til metoder, der er kompatible med en single sign-on-arkitektur.

Verificering

Alle krav skal kunne verificeres. Den mest almindelige metode er ved test. Hvis dette ikke er tilfældet, bør der i stedet anvendes en anden verificeringsmetode (fx analyse, demonstration, inspicering eller gennemgang af design).

Visse krav er på grund af deres struktur ikke verificerbare. Disse omfatter krav, der siger, at systemet aldrig eller altid skal udvise en bestemt egenskab. Korrekt test af disse krav ville kræve en uendelig testcyklus. Sådanne krav skal omskrives for at kunne verificeres. Som nævnt ovenfor skal alle krav være verificerbare.

Ikke-funktionelle krav, som ikke kan verificeres på softwareniveau, skal stadig opbevares som dokumentation for kundens hensigt. De kan dog spores til proceskrav, der vurderes at være en praktisk måde at opfylde dem på. For eksempel kan et ikke-funktionelt krav om at være fri for bagdøre opfyldes ved at erstatte det med et proceskrav om at bruge parprogrammering. Andre ikke-funktionelle krav kan spores til andre systemkomponenter og verificeres på det niveau. For eksempel verificeres systemets pålidelighed ofte ved analyse på systemniveau. Flysoftware med dets komplicerede sikkerhedskrav skal følge DO-178B-udviklingsprocessen.

Aktiviteter, der fører til afledning af system- eller softwarekrav kaldes kravudvikling: det kan involvere en forundersøgelse eller en konceptuel analysefase af projektet, kravindsamling (indsamling, forståelse, gennemgang og artikulering af interessenternes behov) og kravanalyse, analyse (kontrol af sammenhæng og fuldstændighed), specificering (dokumentation af kravene) og validering (sørg for, at de specificerede krav er korrekte).

Krav er sårbare over for problemer med tvetydighed, ufuldstændighed og inkonsistens. Teknikker såsom streng inspicering har vist sig at hjælpe med at håndtere disse problemer. Uklarheder, ufuldstændigheder og uoverensstemmelser, der kan løses i kravfasen, koster typisk størrelsesordener mindre at rette op på, end når de samme problemer findes i senere stadier af produktudviklingen. Kravanalyse søger at løse disse problemer.

Der er en ingeniørmæssig afvejning at overveje mellem krav, der er for vage, og dem, der er så detaljerede, at de

• tager lang tid at producere - nogle gange til det punkt, at de er forældede, når de er færdige
• begrænser de tilgængelige implementeringsmuligheder
• er dyre at producere

Agile tilgange udviklede sig som en måde at overvinde disse problemer på, ved at basere krav på et højt niveau og uddybe detaljer på en just-in-time- eller sidste ansvarlige tidspunkt-basis.

Dokumentation af krav

Krav er som regel skrevet som et middel til kommunikation mellem de forskellige interessenter. Det betyder, at kravene skal være lette at forstå både for normale brugere og for udviklere. En almindelig måde at dokumentere et krav på er at angive, hvad systemet skal gøre. Eksempel: "Entreprenøren skal levere produktet senest xyz dato." Andre metoder omfatter use cases og user stories.

Ændringer af krav

Krav ændrer sig generelt med tiden. Når de er defineret og godkendt, bør kravene falde under ændringskontrol. For mange projekter ændres kravene, før systemet er færdigt. Dette skyldes til dels kompleksiteten af computersoftware og det faktum, at brugerne ikke ved, hvad de vil have, før de ser det. Denne egenskab har medført undersøgelser af og praksisser for kravstyring.

Se også

• Kravudvikling
• Kravanalyse
• Kravindsamling
• Kravstyring
• Kravspecifikation
• MoSCoW-metoden - prioriteringsteknik
• User story
• Use case

Eksterne henvisninger

• Discovering System Requirements