Vi har tidligere diskuteret de fire vigtigste aktiviteter i kravteknik.

Kravteknik er en proces, hvor man indsamler og definerer, hvilke tjenester systemet skal levere.

Det fokuserer på at vurdere, om systemet er nyttigt for virksomheden (feasibility study), at finde frem til kravene (elicitation og analyse), at konvertere disse krav til et eller andet standardformat (specifikation) og at kontrollere, at kravene definerer det system, som kunden ønsker (validering).

I praksis er requirements engineering ikke en sekventiel proces, det er en iterativ proces, hvor aktiviteterne er indlejret i hinanden.

For eksempel itererererer man først på brugerkravene; elicitation, specifikation og validering, og gentager de samme trin for systemkravene.

Tidligt i processen vil den største indsats blive brugt på at forstå forretnings- og brugerkrav på højt niveau. Senere i processen vil der blive brugt flere kræfter på at få fremkaldt og forstå detaljerede systemkrav.

Nogle anser requirements engineering for at være processen med at anvende en struktureret analysemetode, såsom objektorienteret analyse. Dette indebærer analyse af systemet og udvikling af et sæt grafiske systemmodeller som f.eks. brugssagsmodeller, som derefter tjener som systemspecifikation.

Selv om strukturerede metoder spiller en rolle i processen for kravteknik, er der meget mere i kravteknikken end det, der er dækket af disse metoder.

Objektorienteret analyse og design vil blive behandlet i en anden serie af tutorials.

Bruger- og systemkrav

Typisk præsenteres krav i to detaljeringsniveauer; bruger- og systemkrav, hvor brugeren har brug for en højniveau-angivelse af kravene, mens systemudviklere har brug for en mere detaljeret systemspecifikation. Så bruger- og systemkrav henviser blot til forskellige detaljeringsniveauer.

Det er nyttigt at have forskellige detaljeringsniveauer, fordi det kommunikerer oplysninger om det system, der udvikles, til forskellige typer læsere.

Så slutbrugere vil ikke være optaget af detaljerne, de har brug for et generisk, abstrakt skrevet krav.

Mens de mennesker, der er involveret i udviklingen, de har brug for, hvad præcis de systemet skal gøre.

Du vil sandsynligvis vil ende med en masse problemer og misforståelser, hvis du ikke havde en klar adskillelse mellem de forskellige detaljeringsniveauer.

Brugerspecifikke krav

Det beskriver de tjenester, som systemet skal levere, og de begrænsninger, som det skal fungere under. Vi forventer ikke at se noget detaljeringsniveau, eller hvad systemet præcist skal gøre, Det er mere af generiske krav.

Det er normalt skrevet i et naturligt sprog og leveres ved hjælp af diagrammer.

Vi vil diskutere forskellige måder at specificere kravene på senere i denne serie.

Systemkrav

Systemkravene betyder en mere detaljeret beskrivelse af systemtjenesterne og de operationelle begrænsninger som f.eks. hvordan systemet skal bruges, og udviklingsbegrænsninger som f.eks. programmeringssprog.

Denne detaljeringsgrad er nødvendig for dem, der er involveret i systemudviklingen, som f.eks. ingeniører, systemarkitekter, testere osv.

Funktionelle & Ikke-funktionelle krav

Software-kravene inddeles i funktionelle krav og ikke-funktionelle krav.

Funktionelle krav

Det dækker de vigtigste funktioner, der skal leveres af systemet. Når de udtrykkes som brugerkrav, beskrives de normalt på en abstrakt måde.

Men mere specifikke funktionelle systemkrav beskriver systemets funktioner, dets input, behandling; hvordan det vil reagere på et bestemt input, og hvad der er det forventede output.

Non-funktionelle krav

Dette er begrænsningerne på de funktioner, der leveres af systemet.

Begrænsningerne, f.eks. hvor mange processer systemet kan håndtere (ydeevne), hvilke (sikkerheds)problemer systemet skal tage sig af, f.eks. SQL-injektioner …

Fejlfrekvensen (pålidelighed), hvilke sprog og værktøjer der skal bruges (udvikling), hvilke regler du skal følge for at sikre, at systemet fungerer inden for organisationens love (lovgivning).

Non-funktionelle krav er ofte kritiske end de enkelte funktionelle krav. Brugerne kan normalt finde måder at arbejde uden om en systemfunktion, der ikke rigtig opfylder deres behov. Men hvis et ikke-funktionelt krav ikke opfyldes, kan det betyde, at hele systemet er ubrugeligt.

Til eksempel, hvis et fly ikke opfylder sine pålidelighedskrav, vil det ikke være sikkert i drift, eller hvis et indlejret kontrolsystem ikke opfylder sine præstationskrav, vil kontrolfunktionerne ikke fungere korrekt.

Ikke-funktionelle krav bør være målbare

Når det er muligt, bør vi skrive ikke-funktionelle krav kvantitativt, så de kan testes. Man kan måle dem, når systemet testes for at kontrollere, om systemet opfylder de ikke-funktionelle krav.

I praksis er det ofte svært for kunderne til et system at omsætte deres mål til målbare krav. De forstår ikke, hvad nogle tal, der definerer den krævede hastighed eller pålidelighed. For nogle mål, som f.eks. vedligeholdbarhed, er der ingen målinger, der kan bruges.

Udgifterne til at verificere målbare ikke-funktionelle krav kan være meget høje, og kunderne mener måske ikke, at disse omkostninger er berettigede.

Non-funktionelle og funktionelle krav er afhængige

Non-funktionelle krav er ofte i konflikt med, interagerer med eller genererer endda andre funktionelle eller ikke-funktionelle krav.

Et brugerkrav, der vedrører sikkerhed, f.eks. begrænsning af adgangen til autoriserede brugere, kan generere andre krav, der er funktionelle, f.eks. behovet for at inkludere brugergodkendelsesfaciliteter i systemet.

Skelnen mellem funktionelle og ikke-funktionelle krav

I praksis er det vanskeligt at adskille funktionelle og ikke-funktionelle krav. Sondringen er ikke så klar, som deres definitioner antyder.

Sondringen mellem funktionelle og ikke-funktionelle krav

Hvis de ikke-funktionelle krav er angivet separat fra de funktionelle krav, kan forholdet mellem dem være svært at forstå.

Derimod bør vi eksplicit fremhæve krav, der klart er relateret til emergente systemegenskaber som f.eks. ydeevne eller pålidelighed.

Emergente egenskaber er egenskaber ved systemet som helhed snarere end egenskaber, der kan udledes af egenskaberne ved de enkelte systemkomponenter.