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.

Funktionelle krav i softwareudvikling

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

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".

Opsummer dette indlรฆg med: