Hvad er ikke-funktionelle krav i softwareteknologi?

Af: Charles Moore Charles Moore
Hours Opdateret

⚡ Smart opsummering

Ikke-funktionelle krav specificerer kvalitetsegenskaber såsom ydeevne, sikkerhed, brugervenlighed, pålidelighed, skalerbarhed og portabilitet. De definerer, hvor godt et softwaresystem skal opføre sig, og omdanner vage forventninger til målbare, testbare og håndhævelige tekniske mål i hele leveringscyklussen.

  • 📘 Definition: Et ikke-funktionelt krav, eller NFR, beskriver, hvor godt et system præsterer med hensyn til ydeevne, sikkerhed, brugervenlighed, pålidelighed og bærbarhed.
  • 🗂️ Almindelige typer: Brugervenlighed, sikkerhed, pålidelighed, skalerbarhed, kapacitet, tilgængelighed, vedligeholdelse og overholdelse af regler er kategorierne for teams. track oftest.
  • 📊 FURPS+ Model: FURPS+ grupperer NFR'er i funktionalitet, brugervenlighed, pålidelighed, ydeevne, supportbarhed og design- eller grænsefladebegrænsninger.
  • 🎯 Testbare udsagn: Erstat "hurtig" eller "sikker" med numeriske tærskler og verifikationsmetoder, så NFR kan testes og accepteres.
  • 🆚 Funktionel kontrast: Funktionelle krav angiver, hvad systemet gør, mens ikke-funktionelle krav angiver, hvor godt det gør det under faktiske forhold.
  • ✅ Forretningspåvirkning: Manglende NFR'er er den hyppigste årsag til produktionshændelser, lovgivningsmæssige fund og dyre omarbejdelser af arkitekturen i de sene faser.
Læs mere

Ikke-funktionelle krav i softwareudvikling

Hvad er et ikke-funktionelt krav?

A Ikke-funktionelle krav (NFR) specificerer en kvalitetsegenskab ved et softwaresystem. NFR'er bedømmer systemet ud fra responsivitet, brugervenlighed, sikkerhed, portabilitet og andre kvalitetsegenskaber, der er afgørende for succes. Et almindeligt eksempel på ikke-funktionelle krav er, "hvor hurtigt indlæses hjemmesiden?" Manglende opfyldelse af ikke-funktionelle krav skaber systemer, der frustrerer brugerne.

Ikke-funktionelle krav i softwareudvikling sætter begrænsninger på systemets design på tværs af den agile backlog. For eksempel skal webstedet indlæses på tre sekunder, når antallet af samtidige brugere overstiger 10,000. At beskrive ikke-funktionelle krav er lige så vigtigt som at registrere funktionelle krav.

Typer af ikke-funktionelle krav

Hovedkategorierne af ikke-funktionelle krav er:

Typer af ikke-funktionelle krav

Typer af ikke-funktionelle krav

  • Usability
  • servicevenlighed
  • Administration
  • Genoprettelighed
  • Sikkerhed
  • Data Integrity
  • Kapacitet
  • tilgængelighed
  • Skalerbarhed
  • Interoperabilitet
  • Pålidelighed
  • Maintainability
  • Regulatory Compliance
  • Miljømæssige begrænsninger

Eksempler på ikke-funktionelle krav

Her er praktiske eksempler på ikke-funktionelle krav:

  1. Brugere skal ændre den oprindelige adgangskode efter den første vellykkede login, og den oprindelige adgangskode må aldrig genbruges.
  2. Medarbejdere må ikke opdatere deres egne lønoplysninger, og ethvert sådant forsøg skal rapporteres til sikkerhedsadministratoren.
  3. Ethvert mislykket forsøg fra en bruger på at få adgang til et dataelement skal registreres i et revisionsspor.
  4. Hjemmesiden skal understøtte 20 millioner samtidige brugere uden at forringe svartiderne.
  5. Softwaren skal være bærbar, så det ikke skaber problemer at skifte fra ét operativsystem til et andet.
  6. Informationsfortrolighed, eksport af begrænsede teknologier og intellektuelle ejendomsrettigheder skal kunne revideres.

Funktionelle vs. ikke-funktionelle krav

De væsentligste forskelle mellem funktionelle og ikke-funktionelle krav er:

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 Funktionstest som system-, integrations-, end-to-end-testning, API-testning osv. Ikke-funktionel test som ydeevne, stress, brugervenlighed, sikkerhedstest osv.
Testeksekvering Test udføres før ikke-funktionel test. Efter den funktionelle test
Produkt Info produktegenskaber Produktegenskaber

RELATEREDE ARTIKLER

Fordele ved ikke-funktionelle krav

De vigtigste fordele ved Ikke-funktionel test er:

  • Ikke-funktionelle krav sikrer, at systemet følger juridiske regler og compliance-regler.
  • De beskytter systemets pålidelighed, tilgængelighed og ydeevne.
  • De leverer en god brugeroplevelse og nem betjening.
  • De former softwarens sikkerhedspolitik.

Ulemper ved ikke-funktionelle krav

Almindelige ulemper ved ikke-funktionelle krav er:

  • Ikke-funktionelle krav kan påvirke flere softwareundersystemer på højt niveau.
  • De kræver særlige overvejelser under arkitektur og design på overordnet niveau, hvilket øger omkostningerne.
  • Implementering knyttes sjældent til et enkelt softwareundersystem.
  • De er svære at ændre, når arkitekturfasen er færdig.

FURPS+ Model til Klassificering af Ikke-funktionelle Krav

FURPS+ er den mest anvendte taksonomi for ikke-funktionelle krav. Den blev oprindeligt udviklet hos Hewlett-Packard og grupperer kvalitetsattributter i fem hovedkategorier plus yderligere begrænsninger markeret med "+". Modellen hjælper forretningsanalytikere med at undgå at overse en hel klasse af krav.

  • Funktionalitet: Funktioner, sikkerhed og genbrugelighed, der går ud over den grundlæggende funktionsliste.
  • Anvendelighed: Menneskelige faktorer, æstetik, konsistens, dokumentation og brugeroplevelsens responsivitet.
  • Pålidelighed: Tilgængelighed, gennemsnitlig tid mellem fejl, genoprettelsesevne, forudsigelighed og nøjagtighed.
  • Ydelse: Hastighed, gennemløb, kapacitet, skalerbarhed og ressourceforbrug under belastning.
  • Understøttelse: Testbarhed, fleksibilitet, installerbarhed, lokaliseringsbarhed og vedligeholdelsesvenlighed af det leverede system.
  • Plus (+): Design, implementering, grænseflade og fysiske begrænsninger såsom nødvendige platforme, standarder eller hardware.

Teams, der knytter alle ikke-funktionelle krav til en FURPS+ kategori, er mindre tilbøjelige til at levere et system, der opfylder funktionerne, men fejler på ydeevne, sikkerhed eller vedligeholdelse.

Sådan skriver du testbare ikke-funktionelle krav

Et velskrevet ikke-funktionelt krav er målbart, verificerbart og tidsbestemt. Vage udsagn som "systemet skal være hurtigt" eller "appen skal være sikker" er ambitioner, ikke krav. Følg nedenstående trin for at konvertere en intention til en testbar NFR.

  1. Identificér kvalitetsegenskaben. Knyt bekymringen til en FURPS+ kategori, så teamet ved, om det er et krav til ydeevne, brugervenlighed, sikkerhed eller pålidelighed.
  2. Vælg en metrik. Hver NFR har brug for en enhed — millisekunder, anmodninger pr. sekund, samtidige brugere, procentvis oppetid eller en overholdelsesstandard som ISO 27001.
  3. Indstil en numerisk tærskel. Erstat "hurtig" med "under 400 millisekunder ved 95. percentil". Erstat "meget tilgængelig" med "99.9 procent månedlig oppetid".
  4. Beskriv tilstanden. Angiv den belastning, det miljø eller det brugersegment, som tærsklen gælder for, f.eks. "under spidsbelastningssalg med 10,000 samtidige brugere".
  5. Definer verifikationsmetoden. Bemærk testtypen — belastningstest, penetrationstest, kaoseksperiment, tilgængelighedsrevision — og det værktøj, der bekræfter tærsklen.
  6. Anvend SMART-tjekket. Bekræft, at kravet er specifikt, målbart, opnåeligt, relevant og tidsbestemt, før det indgår i efterspurgten.

Eksempel på omskrivning: "Systemet skal være hurtigt" bliver til "Kassesiden skal reagere på under 500 millisekunder ved den 95. percentil med 5,000 samtidige brugere, verificeret af en JMeter "indlæs test hver udgivelse." Den reviderede erklæring lader udviklere designe til den, testere verificere den, og produktejere acceptere den uden argumenter.

Ofte Stillede Spørgsmål

AI-drevne belastnings- og ydeevneværktøjer genererer realistisk trafik, registrerer uregelmæssigheder i svartidsfordelinger og forudsiger skaleringsgrænser før produktion. AI inspicerer også logfiler og adgangsmønstre for at markere sikkerhedshændelser, som traditionelle regelbaserede værktøjer overser.

Copilot og GPT konverterer vage kvalitetserklæringer til målbare NFR'er med metrikker, tærskler, betingelser og verifikationsmetode. Forretningsanalytikere gennemgår hvert udkast i forhold til FURPS+ kategorier og SMART-rammeværket, før de accepterer det i backloggen.

Funktionel testning kontrollerer, om funktioner, såsom login eller søgning, fungerer korrekt. Ikke-funktionel testning måler, hvor godt systemet præsterer under belastning, stress og brug, og dækker mål for ydeevne, sikkerhed, brugervenlighed, kompatibilitet og pålidelighed.

Skalerbarhed, tilgængelighed, latenstid, elasticitet og omkostningseffektivitet dominerer cloud-NFR'er. Teams også track-observabilitet, mål for nødberedskab såsom RPO og RTO og overholdelse af regler i flere regioner, fordi de driver de fleste beslutninger om cloudarkitektur.

Vælg en metrik med en enhed, angiv en numerisk tærskel, beskriv den betingelse, den gælder under, og navngiv verifikationsmetoden. For eksempel en svartid under 400 millisekunder ved den 95. percentil med 5,000 brugere, verificeret af JMeter.

Kryptering af data i hvile og under transit, godkendelsesstyrke, rollebaseret godkendelse, revisionslogning, sessionstimeout og overholdelse af standarder som ISO 27001, PCI DSS og GDPR er de sikkerheds-NFR'er, som de fleste teams dokumenterer.

Brug af vage adjektiver, udeladelse af metrikken eller betingelsen, kun at liste NFR'er i slutningen af ​​et projekt og at kopiere og indsætte standardtekster, som ingen test kan verificere, er de mest almindelige fejl, der fører til omarbejdning af arkitekturen i den sene fase.

NFR'er findes i softwarekravspecifikationen, arkitekturbeslutningsregistreringer, serviceniveauaftaler og tjeklister for færdiggørelse. Agile teams knytter ofte målbare NFR'er til episke opgaver og til definitionen af ​​"ready for each user story".

Opsummer dette indlæg med: