Hva er ikke-funksjonelle krav i programvareteknikk?

by: Charles Moore Charles Moore
Hours oppdatert

⚡ Smart oppsummering

Ikke-funksjonelle krav spesifiserer kvalitetsegenskaper som ytelse, sikkerhet, brukervennlighet, pålitelighet, skalerbarhet og portabilitet, og definerer hvor godt et programvaresystem må oppføre seg og gjør vage forventninger om til målbare, testbare og håndhevbare tekniske mål gjennom hele leveransesyklusen.

  • 📘 Definisjon: Et ikke-funksjonelt krav, eller NFR, beskriver hvor godt et system yter når det gjelder ytelse, sikkerhet, brukervennlighet, pålitelighet og portabilitet.
  • 🗂️ Vanlige typer: Brukervennlighet, sikkerhet, pålitelighet, skalerbarhet, kapasitet, tilgjengelighet, vedlikeholdbarhet og samsvar med forskrifter er kategoriene teamene bruker. track oftest.
  • 📊 FURPS+ Modell: FURPS+ grupperer NFR-er etter funksjonalitet, brukervennlighet, pålitelighet, ytelse, støtteevne og design- eller grensesnittbegrensninger.
  • 🎯 Testbare utsagn: Erstatt «rask» eller «sikker» med numeriske terskler og verifiseringsmetoder, slik at NFR kan testes og aksepteres.
  • 🆚 Funksjonell kontrast: Funksjonelle krav angir hva systemet gjør, mens ikke-funksjonelle krav angir hvor godt det gjør det under reelle forhold.
  • ✅ Forretningsmessig påvirkning: Manglende NFR-er er den viktigste årsaken til produksjonshendelser, regulatoriske funn og kostbare omarbeidinger av arkitekturen i senfasen.
Les mer

Ikke-funksjonelle krav i programvareteknikk

Hva er et ikke-funksjonelt krav?

A Ikke-funksjonelle krav (NFR) spesifiserer en kvalitetsattributt for et programvaresystem. NFR-er bedømmer systemet ut fra responsivitet, brukervennlighet, sikkerhet, portabilitet og andre kvalitetsattributter som er kritiske for suksess. Et vanlig eksempel på ikke-funksjonelle krav er, "hvor raskt laster nettstedet?" Å ikke oppfylle ikke-funksjonelle krav fører til systemer som frustrerte brukere.

Ikke-funksjonelle krav i programvareutvikling setter begrensninger på systemets design på tvers av den smidige etterslepet. For eksempel bør nettstedet laste inn på tre sekunder når antallet samtidige brukere overstiger 10 000. Å beskrive ikke-funksjonelle krav er like viktig som å fange opp funksjonelle krav.

Typer ikke-funksjonelle krav

Hovedkategoriene av ikke-funksjonelle krav er:

Typer ikke-funksjonelle krav

Typer ikke-funksjonelle krav

  • Usability
  • service~~POS=TRUNC
  • administrasjon
  • Gjenvinnbarhet
  • Trygghet
  • Data Integrity
  • Kapasitet
  • Tilgjengelighet
  • skalerbarhet
  • Interoperabilitet
  • Pålitelighet
  • vedlikeholdbarhet
  • Overholdelse av regelverk
  • Miljømessige begrensninger

Eksempler på ikke-funksjonelle krav

Her er praktiske eksempler på ikke-funksjonelle krav:

  1. Brukere må endre det opprinnelige passordet etter første vellykkede pålogging, og det opprinnelige passordet må aldri brukes på nytt.
  2. Ansatte skal ikke ha lov til å oppdatere sin egen lønnsinformasjon, og ethvert slikt forsøk skal rapporteres til sikkerhetsadministratoren.
  3. Alle mislykkede forsøk fra en bruker på å få tilgang til et dataelement skal registreres i et revisjonsspor.
  4. Nettstedet skal støtte 20 millioner samtidige brukere uten at responstiden går forringet.
  5. Programvaren skal være portabel slik at det ikke skaper problemer å bytte fra ett operativsystem til et annet.
  6. Informasjonspersonvern, eksport av begrenset teknologi og immaterielle rettigheter skal kunne revideres.

Funksjonelle vs. ikke-funksjonelle krav

De viktigste forskjellene mellom funksjonelle og ikke-funksjonelle krav er:

Parametre Funksjonskrav Ikke-funksjonelle krav
Hva er det? Verb attributter
Krav Det er obligatorisk Det er ikke obligatorisk
Fangetype Det fanges opp i brukstilfelle. Det fanges opp som et kvalitetsattributt.
Sluttresultat Produktfunksjon Produktegenskaper
fange Lett å fange Vanskelig å fange
Målet Hjelper deg å verifisere funksjonaliteten til programvaren. Hjelper deg med å verifisere ytelsen til programvaren.
Fokusområde Fokus på brukerkrav Konsentrerer seg om brukerens forventning.
Teknisk dokumentasjon Beskriv hva produktet gjør Beskriver hvordan produktet fungerer
Type testing Funksjonell testing som system-, integrasjons-, ende-til-ende-testing, API-testing osv. Ikke-funksjonell testing som ytelse, stress, brukervennlighet, sikkerhetstesting, etc.
Testutførelse Testutførelse gjøres før ikke-funksjonell testing. Etter funksjonstestingen
produkt info Produktegenskaper Produktegenskaper

RELATERTE ARTIKLER

Fordeler med ikke-funksjonelle krav

De viktigste fordelene med Ikke-funksjonell testing er:

  • Ikke-funksjonelle krav sikrer at systemet følger juridiske regler og samsvarsregler.
  • De beskytter systemets pålitelighet, tilgjengelighet og ytelse.
  • De leverer en god brukeropplevelse og enkel betjening.
  • De former programvarens sikkerhetspolicy.

Ulemper med ikke-funksjonelle krav

Vanlige ulemper med ikke-funksjonelle krav er:

  • Ikke-funksjonelle krav kan påvirke flere programvareundersystemer på høyt nivå.
  • De krever spesielle hensyn under arkitektur og design på overordnet nivå, noe som øker kostnadene.
  • Implementering er sjelden knyttet til et enkelt programvareundersystem.
  • De er vanskelige å endre når arkitekturfasen er fullført.

FURPS+ modell for klassifisering av ikke-funksjonelle krav

FURPS+ er den mest brukte taksonomien for ikke-funksjonelle krav. Den ble opprinnelig utviklet hos Hewlett-Packard, og grupperer kvalitetsattributter i fem hovedkategorier pluss ytterligere begrensninger markert med «+». Modellen hjelper forretningsanalytikere med å unngå å gå glipp av en hel klasse med krav.

  • Funksjonalitet: Funksjoner, sikkerhet og gjenbrukbarhet som går utover den grunnleggende funksjonslisten.
  • brukervennlighet: Menneskelige faktorer, estetikk, konsistens, dokumentasjon og responsivitet i brukeropplevelsen.
  • Pålitelighet: Tilgjengelighet, gjennomsnittlig tid mellom feil, gjenopprettingsevne, forutsigbarhet og nøyaktighet.
  • Ytelse: Hastighet, gjennomstrømning, kapasitet, skalerbarhet og ressursforbruk under belastning.
  • Støtteevne: Testbarhet, fleksibilitet, installerbarhet, lokaliseringsbarhet og vedlikeholdbarhet for det leverte systemet.
  • Pluss (+): Design, implementering, grensesnitt og fysiske begrensninger som nødvendige plattformer, standarder eller maskinvare.

Team som tilordner alle ikke-funksjonelle krav til en FURPS+-kategori, har mindre sannsynlighet for å levere et system som oppfyller funksjoner, men som svikter på ytelse, sikkerhet eller vedlikeholdbarhet.

Hvordan skrive testbare ikke-funksjonelle krav

Et velskrevet ikke-funksjonelt krav er målbart, verifiserbart og tidsbundet. Vage utsagn som «systemet må være raskt» eller «appen bør være sikker» er ambisjoner, ikke krav. Følg trinnene nedenfor for å konvertere en intensjon til en testbar NFR.

  1. Identifiser kvalitetsegenskapen. Kartlegg bekymringen til en FURPS+-kategori, slik at teamet vet om det er et krav til ytelse, brukervennlighet, sikkerhet eller pålitelighet.
  2. Velg en beregning. Hver NFR trenger en enhet – millisekunder, forespørsler per sekund, samtidige brukere, prosentvis oppetid eller en samsvarsstandard som ISO 27001.
  3. Angi en numerisk terskel. Erstatt «rask» med «under 400 millisekunder ved 95. persentil». Erstatt «svært tilgjengelig» med «99.9 prosent månedlig oppetid».
  4. Beskriv tilstanden. Angi belastningen, miljøet eller brukersegmentet som terskelen gjelder for, for eksempel «under toppsalg med 10 000 samtidige brukere».
  5. Definer verifiseringsmetoden. Merk testtypen – belastningstest, penetrasjonstest, kaoseksperiment, tilgjengelighetsrevisjon – og verktøyet som vil bekrefte terskelen.
  6. Bruk SMART-sjekken. Bekreft at kravet er spesifikt, målbart, oppnåelig, relevant og tidsbestemt før det havner i etterslepet.

Eksempel på omskrivning: «Systemet skal være raskt» blir til «Kassesiden skal svare på under 500 millisekunder ved 95. persentil med 5,000 samtidige brukere, bekreftet av en JMeter lasttest hver utgivelse.» Den reviderte uttalelsen lar utviklere designe for den, testere verifisere den, og produkteiere godta den uten argumenter.

Spørsmål og svar

AI-drevne belastnings- og ytelsesverktøy genererer realistisk trafikk, oppdager avvik i responstidsfordelinger og forutsier skaleringsgrenser før produksjon. AI inspiserer også logger og tilgangsmønstre for å flagge sikkerhetshendelser som tradisjonelle regelbaserte verktøy overser.

Copilot og GPT konverterer vage kvalitetsutsagn til målbare NFR-er med metrikk, terskel, tilstand og verifiseringsmetode. Forretningsanalytikere gjennomgår hvert utkast mot FURPS+-kategorier og SMART-rammeverket før de aksepterer det i ordrebeholdningen.

Funksjonstesting sjekker om funksjoner oppfører seg som de skal, for eksempel pålogging eller søk. Ikke-funksjonell testing måler hvor godt systemet yter under belastning, stress og bruk, og dekker ytelse, sikkerhet, brukervennlighet, kompatibilitet og pålitelighetsmål.

Skalerbarhet, tilgjengelighet, latens, elastisitet og kostnadseffektivitet dominerer skybaserte NFR-er. Teamene også track-observabilitet, mål for gjenoppretting etter katastrofe som RPO og RTO, og samsvar med flere regioner fordi de styrer de fleste beslutninger om skyarkitektur.

Velg en beregning med en enhet, angi en numerisk terskel, beskriv betingelsen den gjelder under, og navngi bekreftelsesmetoden. For eksempel responstid under 400 millisekunder ved 95. persentil med 5,000 brukere, bekreftet av JMeter.

Kryptering av data i ro og under overføring, autentiseringsstyrke, rollebasert autorisasjon, revisjonslogging, tidsavbrudd for økter og samsvar med standarder som ISO 27001, PCI DSS og GDPR er sikkerhets-NFR-ene de fleste team dokumenterer.

Å bruke vage adjektiver, utelate metrikken eller betingelsen, liste opp NFR-er bare på slutten av et prosjekt, og kopiere og lime inn standardtekst som ingen test kan verifisere er de vanligste feilene som fører til omarbeiding av arkitekturen i sent stadium.

NFR-er finnes i programvarekravspesifikasjonen, arkitekturbeslutningsrapporter, tjenestenivåavtaler og sjekklister for ferdige resultater. Agile team knytter ofte målbare NFR-er til episke hendelser og til definisjonen av «klar for hver brukerhistorie».

Oppsummer dette innlegget med: