Funktionelle vs ikke-funktionelle krav

Nøgleforskel mellem funktionelle og ikke-funktionelle krav

  • Et funktionelt krav definerer et system eller dets komponent, hvorimod et ikke-funktionelt krav definerer ydeevneattributten for et softwaresystem.
  • Funktionelle krav hjælper sammen med kravanalyse med at identificere manglende krav, mens fordelen ved ikke-funktionelle krav er, at det hjælper dig med at sikre en god brugeroplevelse og nem operating af softwaren.
  • Funktionelt krav er et verbum, mens ikke-funktionelt krav er en egenskab
  • Typer af ikke-funktionelle krav er skalerbarhed, kapacitet, tilgængelighed, pålidelighed, gendannelse, dataintegritet osv., hvorimod transaktionskorrektioner, justeringer og annulleringer, forretningsregler, certificeringskrav, rapporteringskrav, administrative funktioner, autorisationsniveauer, revisionssporing, ekstern Grænseflader, håndtering af historiske data, juridiske eller regulatoriske krav er forskellige typer funktionskrav.
Funktionelle vs ikke-funktionelle krav
Forskellen mellem funktionelle og ikke-funktionelle krav

Hvad er et funktionskrav?

I softwareteknik, a funktionskrav definerer et system eller dets komponent. Den beskriver de funktioner en software skal udføre. En funktion er intet andet end input, dens adfærd og output. Det kan være en beregning, datamanipulation, forretningsproces, brugerinteraktion eller enhver anden specifik funktionalitet, som definerer, hvilken funktion et system sandsynligvis vil udføre.

Funktionelle krav i software engineering hjælpe dig med at fange systemets tilsigtede adfærd. Denne adfærd kan udtrykkes som funktioner, tjenester eller opgaver, eller hvilket system er forpligtet til at udføre.

Hvad er ikke-funktionelle krav?

A ikke-funktionelle krav definerer kvalitetsegenskaben for et softwaresystem. De repræsenterer et sæt standarder, der bruges til at bedømme det specifikke operation af et system. Eksempel, hvor hurtigt indlæses hjemmesiden?

Et ikke-funktionelt krav er væsentligt for at sikre anvendeligheden og effektiviteten af ​​hele softwaresystemet. Manglende opfyldelse af ikke-funktionelle krav kan resultere i systemer, der ikke opfylder brugernes behov.

Ikke-funktionelle krav giver dig mulighed for at pålægge begrænsninger eller begrænsninger på designet af systemet på tværs af de forskellige agile efterslæb. Eksempel, webstedet skal indlæses på 3 sekunder, når antallet af simultaneoos brugere er > 10000. Beskrivelse af ikke-funktionelle krav er lige så kritisk som et funktionskrav.

Eksempel på funktionelle krav

Her er nogle eksempler på funktionelle krav i software engineering:

  • Softwaren validerer automatisk kunder mod ABC Contact Management System
  • Salgssystemet skal give brugerne mulighed for at registrere kundernes salg
  • Baggrundsfarven for alle windows i applikationen vil være blå og have en hexadecimal RGB-farveværdi på 0x0000FF.
  • Kun medarbejdere på lederniveau har ret til at se indtægtsdata.
  • Softwaresystemet skal være integreret med bank-API
  • Softwaresystemet skulle bestå Sektion 508 tilgængelighedskrav.

Eksempler på ikke-funktionelle krav

Her er nogle eksempler på ikke-funktionelle krav i softwareudvikling:

  1. Brugere skal ændre den oprindeligt tildelte login-adgangskode umiddelbart efter det første succesfulde login. Desuden bør initialen aldrig genbruges.
  2. Medarbejdere må aldrig opdatere deres lønoplysninger. Et sådant forsøg skal rapporteres til sikkerhedsadministratoren.
  3. Ethvert mislykket forsøg fra en brugers side på at få adgang til et dataelement skal registreres på et revisionsspor.
  4. Et websted skal være i stand til at håndtere 20 millioner brugere med at påvirke dets ydeevne
  5. Softwaren skal være bærbar. Så det skaber ikke noget problem at flytte fra et OS til et andet OS.
  6. Beskyttelse af oplysninger, eksport af teknologier, der begrænses, intellektuelle ejendomsrettigheder osv. bør revideres.

Forskellen mellem funktionelle og ikke-funktionelle krav

Nedenfor er hovedforskellen mellem funktionelle og ikke-funktionelle krav i software engineering:

parametre 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 Test udføres før ikke-funktionel test. Efter den funktionelle test
Produkt Info produktegenskaber Produktegenskaber

Fordele ved funktionelle krav

Her er fordele/fordele ved at oprette et typisk funktionelt kravdokument-

  • Hjælper dig med at kontrollere, om applikationen leverer alle de funktioner, der blev nævnt i funktionskravet for den applikation
  • Et funktionskravdokument hjælper dig med at definere funktionaliteten af ​​et system eller et af dets undersystemer.
  • Funktionelle krav sammen med kravanalyse hjælper med at identificere manglende krav. De hjælper tydeligt med at definere den forventede systemservice og adfærd.
  • Fejl fanget i indsamlingsfasen for funktionelle krav er de billigste at rette.
  • Støt brugermål, opgaver eller aktiviteter for nem projektstyring
  • Funktionelle krav kan udtrykkes i Use Case-form eller brugerhistorie, da de udviser eksternt synlig funktionel adfærd.

Fordele ved ikke-funktionelle krav

Fordele/fordele ved ikke-funktionel test i software Engineering er:

  • De ikke-funktionelle krav sikrer, at softwaresystemet følger lov- og overholdelsesregler.
  • De sikrer pålideligheden, tilgængeligheden og ydeevnen af ​​softwaresystemet
  • De sikrer en god brugeroplevelse og brugervenlighed operating af softwaren.
  • De hjælper med at formulere sikkerhedspolitik for softwaresystemet.