Ikke-funksjonelle krav

Ikke-funksjonelle krav (IFK) eller ikke-funksjonelle primitiver er krav som angir kriterier for kvaliteter ved en komponent, programvare eller systems bruk og drift, snarere enn spesifikke atferd. Motsatt av dette er funksjonelle krav, som definerer bestemt atferd eller funksjoner. Plan for implementering av funksjonelle krav er beskrevet i systemdesign. Plan for implementering av ikke-funksjonelle krav er beskrevet i systemarkitektur, fordi de er betydelige arkitektoniske krav.

I vid forstand definerer funksjonelle krav hva et system er ment å gjøre, og ikke-funksjonelle krav definerer hvordan et system er ment å være. 

Funksjonelle krav er vanligvis i form av «systemet må gjøre <krav>», en individuell handling, en del av systemet, kanskje ved å implementere en matematisk funksjon, en "black box" beskrivelse av inndata og utdata, med tilhørende prosessering og kontroll som en funksjonell modell eller input-process-output-modell (IPO-modell). 

Motsatt er ikke-funksjonelle krav i form av «systemet skal være <krav>», en samlet kvalitativ egenskap ved hele systemet eller for en begrenset aspekt, men ikke en bestemt funksjon. Systemets er generelle kvalitative egenskaper vil være en indikator på om utviklingsprosjektet har lyktes eller mislyktes.

Ikke-funksjonelle krav blir ofte kalt «kvalitetsegenskaper» for et system. Andre begrep tilknyttet ikke-funksjonelle krav er «kvaliteter», «kvalitetsmål», «quality of service-krav» (QoS-krav), «begrensninger» og «ikke-atferdsmessige behov». Uformelt blir disse noen ganger kalt «ilities», fra egenskaper som stabilitet og mobilitet. 

Kvaliteter—som er ikke-funksjonelle krav—kan deles inn i to hovedkategorier:
 Kvaliteter ved utførelsen, dvs. til systemet, som for eksempel sikkerhet og  Brukskvalitet , som er observerbare i kjøretid.
 Kvaliteter ved utviklingen, slik som testbarhet, vedlikehold, utvidelsesmuligheter og skalerbarhet, som er bygd inn i den statiske strukturen til programvaren.

 Eksempler 
I et system kan det være nødvendig for brukeren å se et antall poster i en database. Dette er et funksjonelt krav. Hvor oppdatert nummeret må være er et ikke-funksjonelt krav. Hvis nummeret må oppdateres i sanntid så må systemarkitektene påse at systemet er i stand til å vise et oppdatert antall poster innen en akseptabelt kort tidsintervall mens antall poster er i endring.

Tilstrekkelig båndbredde på nettverket kan være en ikke-funksjonelle krav til systemet. Andre eksempler inkluderer (bruk engelske uttrykk til det er klart hva som er gyldige norske uttrykk):

 Avhengighet (dependency), på tredjepart
Brukskvalitet (usability) hos målgruppen
Utrulling (deployment)
Deponeringsavtale (escrow)
Dokumentasjon (documentation)
Driftsdyktighet (operability)
Effektivitet (effectiveness), resulterende ytelse ved en gitt last
Effisiens (efficiency), ressursbruk ved en gitt last
Emosjonelle faktorer (emotional factors), som at systemet er morsomt å bruke eller lære, eller har høy «Vov!» -faktor
Elastisitet (elasticity), for løsninger i nettskyen
Feilhåndtering (failure management)
Feiltoleranse (fault tolerance), f.eks. overvåking av operasjonelle systemer, måling og styring
Fleksibilitet (flexibility), f.eks. evnen til å håndtere fremtidige krav
Gjenbrukbarhet (reusability)
Gjennomløp (throughput)
Gjenoppretting etter katastrofe (disaster recovery)
Gjenopprettingsevne (recoverability), f.eks. gjennomsnittlig tid til gjenoppretting (mean time to recovery, MTTR)
Holdbarhet (durability)
Integrerbarhet (integrability), f.eks. muligheten til å integrere komponenter
Internasjonalisering og lokalisering (internationalization and localization), f.eks. språk og ikoner
Interoperabilitet (interoperability)
Juridiske og lisensieringsspørsmål eller unngåelse av patentkrenkelser, se EULA
Kapasitet (system capacity), både nåværende og fremtidig
Kompatibilitet (compatibility), for programvare, verktøy, standarder, etc.
Konfigurasjonsstyring (configuration management)
Kostnad (cost), både initielt og gjennom livsløpet
Kvalitet (quality), f.eks. påviste feil, leveransenfeil, feilrettingens effekt
Ledelse (management)
Lesbarhet av kode (readability of source code)
Miljøvern (environmental protection)
Modifiserbarhet (modifiability)
Nettverkstopologi (network topology)
Optimering, f.eks. av minne (memory optimization)
Plattformkompatibilitet (platform compatibility)
Personvern (privacy), f.eks. i samsvar med GDPR
Portabilitet (portability)
Pålitelighet eller reliabilitet (reliability), f.eks. gjennomsnittlig tid mellom feil (mean time between/to failures, MTBF/MTTF)
Rapportering (reporting)
Redusert fotavtrykk (footprint reduction), f.eks. redusere størrelsen på .exe-filer
Resliens (resilience), (må ikke forveksles med robusthet)
Responstid (response time)
Ressursbegrensninger (resource constraints), f.eks. prosessorhastighet, minne, diskplass, nettverksbåndbredde, osv.
Revisjon og kontroll / ettergåelse (audit and control)
Robusthet (robustness), (må ikke forveksles med resiliens)
 Samsvar og etterlevelse (compliance)
Sertifisering (certification)
Sikkerhetskopi (backup)
Trygghet (safety), for liv og helse eller kontinuerlig drift
Sikkerhet (security), både fysisk og digital sikring av eiendeler
Skalerbarhet (scalability), horisontalt og vertikalt
Stabilitet (stability)
Støttbarhet (supportability)
Testbarhet (testability)
Tilgang (accessibility)
Tilgjengelighet (availability), se tjenestenivåavtale (service level agreement)
Utnyttbarhet (exploitability)
Utvidbarhet (extensibility), legge til egenskaper (features), og videreføring av tilpasninger ved neste større versjonsoppgradering
Utviklingsmiljø (development environment)
 Vedlikeholdbarhet (maintainability)
Volumtesting (volume testing)
 Ytelse eller responstid (performance or response time), se ytelsesteknikk (performance engineering)
Åpen kildekode (open source)
Åpenhet (transparency)

 Se også 
 Kravspesifikasjon
 Brukskvalitet

 Referanser 

 Litteratur 


 Eksterne lenker 



  (


Kategori:Informatikk
Kategori:Programvarekrav