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