Hvad er et funktionelt krav i softwareteknologi?

⚡ Smart opsummering

Funktionelle krav beskriver alle de tjenester, et softwaresystem skal tilbyde, og registrerer input, adfærd og output, så udviklere, testere og forretningsinteressenter deler en enkelt, verificerbar definition af, hvad produktet rent faktisk skal gøre.

📘 Definition: Et funktionelt krav, også kaldet en funktionel specifikation, angiver, hvad systemet skal gøre – input, adfærd og output, beskrevet fra brugerens eller forretningsperspektiv.
📄 Dokumentomfang: Et funktionelt kravdokument dækker skærmoperationer, datahåndteringslogik, rapporter, arbejdsgange, tilladelser og overholdelse af lovgivningen.
🗂️ Almindelige typer: Transaktionshåndtering, forretningsregler, rapportering, administrative funktioner, autorisationsniveauer, revision trackonge, eksterne grænseflader og juridiske krav.
💡 eksempler: Loginvalidering, salgsregistrering, rollebaseret omsætningsvisning, integration med bank-API og overholdelse af tilgængelighedskrav er alle inkluderet i funktionelle krav.
🆚 Ikke-funktionel kontrast: Funktionelle krav beskriver, hvad et system gør; ikke-funktionelle krav beskriver, hvor godt det gør det - ydeevne, sikkerhed og brugervenlighed.
✅ Bedste praksis: Hold kravene detaljerede, testbare og kortlagt til et forretningsmål, og fremskynd dem gennem interviews og workshops.

Læs mere

Hvad er et funktionskrav?

A Funktionskrav (FR) er en beskrivelse af den service, som softwaren skal tilbyde. Det beskriver et softwaresystem eller dets komponent. En funktion er defineret af input, adfærd og output. Det kan være en beregning, datamanipulation, forretningsproces eller brugerinteraktion, der definerer, hvad systemet skal gøre. Funktionelle krav i softwareudvikling kaldes også Funktionel specifikation.

Et funktionelt krav spænder fra et interessentbehov på højt niveau til en detaljeret matematisk specifikation. Funktionel software Kravene indfanger systemets tilsigtede adfærd.

Hvad skal inkluderes i et funktionelt kravdokument

Her er hvad et funktionelt kravdokument bør dække:

Eksempel på funktionskrav

Et funktionelt kravdokument indeholder typisk:

Detaljer om udførte operationer på hver skærm
Datahåndteringslogik, som systemet skal anvende
Descriptioner af systemrapporter og andre output
Fuld information om de arbejdsgange, som systemet udfører
Hvem har tilladelse til at oprette, ændre eller slette data i systemet
Hvordan systemet opfylder gældende lovgivningsmæssige og overholdelseskrav

Fordele ved funktionelle krav

De vigtigste fordele ved et velskrevet funktionelt kravdokument er:

Bekræfter, at applikationen leverer alle de specificerede funktioner
Definerer systemets og dets undersystemers funktionalitet på ét sted
Kombineret med kravanalyse hjælper funktionelle krav med at identificere manglende behov og tydeliggøre forventet systemadfærd
Fejl, der opdages i kravfasen, er de billigste at rette
Understøtter brugernes mål, opgaver og aktiviteter

Typer af funktionelle krav

Almindelige kategorier af funktionelle krav omfatter:

Transaktionshåndtering
Forretningsregler
Certificeringskrav
Rapporteringskrav
Administrative funktioner
Autorisationsniveauer
Revision Tracking
Eksterne grænseflader
Historisk datahåndtering
Lovmæssige og regulatoriske krav

Eksempler på funktionelle krav

Nedenfor er praktiske eksempler på funktionelle krav:

Softwaren skal automatisk validere kunder i forhold til ABC Contact Management System.
Salgssystemet skal give brugerne mulighed for at registrere kunders salg.
Baggrundsfarven for alle vinduer i applikationen skal være blå med en hexadecimal RGB-værdi på 0x0000FF.
Kun medarbejdere på ledelsesniveau har ret til at se omsætningsdata.
Softwaresystemet skal integreres med bankens API.
Softwaresystemet skal opfylde Sektion 508 tilgængelighedskrav.

Funktionelle vs. ikke-funktionelle krav

Her er de vigtigste forskelle mellem funktionelle og ikke-funktionelle krav i Software Engineering:

Driftsparametre	Funktionskrav	Ikke-funktionelle krav
Hvad er det	Udsagnsord	Attributter
Krav	Det er obligatorisk	Det er ikke obligatorisk
Optagelsestype	Det er fanget i use case.	Det er fanget som en kvalitetsegenskab.
Slutresultat	Produktegenskab	Produktegenskaber
Optagelse	Let at fange	Svært at fange
Objektiv	Hjælper dig med at verificere softwarens funktionalitet.	Hjælper dig med at verificere softwarens ydeevne.
Fokusområde	Fokus på brugerkrav	Koncentrerer sig om brugerens forventning.
Dokumentation	Beskriv, hvad produktet gør	Beskriver hvordan produktet virker
Type af test	Funktionel test som system, integration, ende til ende, API-testOsv	Ikke-funktionel test som ydeevne, stress, brugervenlighed, SikkerhedsprøvningOsv
Testeksekvering	Testudførelse udføres før ikke-funktionel testning.	Efter den funktionelle test
Produkt Info	produktegenskaber	Produktegenskaber

Bedste praksis for at skrive funktionelle krav

De vigtigste bedste fremgangsmåder til at skrive et funktionelt kravdokument er:

Kombiner ikke to krav til ét; hold hvert krav detaljeret.
Gør alle krav så fuldstændige og præcise som muligt.
Udarbejd alle tekniske krav i dokumentet.
Kortlæg alle krav til de mål og principper, der driver succesfuld softwarelevering.
Afdæk behovene gennem interviews, workshops og uformelle samtaler.
Dokumenter alle kendte, verificerede begrænsninger, der væsentligt påvirker et krav.
Registrer alle antagelser i dokumentet.

Almindelige fejl ved skrivning af funktionelle krav

Almindelige fejl, der begås ved udarbejdelse af et funktionelt kravdokument, omfatter:

Tilføjelse af uberettigede ekstra oplysninger, der forvirrer udviklere
Uden de detaljer, som udviklerne skal bruge for at bygge funktionen.
Blandingsregler, eksempler, scoping udsagn eller målsætninger i selve kravet.
Udeladelse af oplysninger, der er afgørende for at angive kravet fuldt ud og præcist.
At forsvare et eksisterende krav, når en ændringsanmodning modtages, i stedet for at finde det korrekte svar.
Skrivekrav, der ikke er knyttet til noget mål eller princip.

Ofte Stillede Spørgsmål

AI-værktøjer grupperer interviewnotater, genererer udkast til brugerhistorier, markerer tvetydigt sprog og registrerer dubletter på tværs af store kravsæt. Forretningsanalytikere validerer stadig ethvert forslag i forhold til reelle interessenters behov, før det når den godkendte baseline.

Copilot og GPT producerer udkast til brugerhistorier, acceptkriterier og skal-udsagn ud fra korte prompts. En forretningsanalytiker redigerer hvert output for testbarhed og bekræfter overensstemmelse med forretningsmål før formel gennemgang.

Et forretningskrav angiver, hvorfor et projekt eksisterer, såsom omsætningsvækst eller compliance. Et funktionelt krav angiver, hvad systemet skal gøre for at levere dette resultat, såsom at validere en betaling eller generere en rapport.

Brug et tydeligt subjekt, ordet "skal" og én testbar handling pr. sætning. Undgå tvetydige ord som "hurtigt", og dæk én adfærd, så kravet kan testes med en enkelt bestået eller ikke-bestået kontrol.

EARS, Easy Approach to Requirements Syntax, tilbyder fem skabeloner: allestedsnærværende, event-drevet, tilstandsdrevet, valgfri funktion og uønsket adfærd. Hver skabelon gennemtvinger en testbar struktur, såsom "Når TRIGGER" (Udløser), skal systemet REAGERE.

En softwarekravspecifikation er det overordnede dokument, der beskriver, hvad et system skal kunne. Funktionelle krav udgør den største del sammen med grænseflader, ikke-funktionelle krav, use cases og begrænsninger.

Funktionelle krav driver testcases i system-, integrations-, end-to-end-, API- og brugeraccepttest. Hvert krav knyttes til mindst én testcase, og kravene TracEability Matrix bekræfter dækningen før frigivelse.

Agile teams udtrykker funktionelle krav som brugerhistorier ved hjælp af formatet: Som en rolle ønsker jeg en evne, så værdien... Acceptkriterier knyttet til historien forvandler kravet til en testbar definition af "udført".