Ikke-funksjonelle krav

Ikke-funksjonelle krav 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.[1]

I vid forstand definerer funksjonelle krav definere hva et system som er ment å gjøre, og ikke-funksjonelle krav definere 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 innputt-prosess-utputt-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 vilkår for ikke-funksjonelle krav er «kvaliteter», «kvalitetsmål», «quality of service-krav» (QoS), «begrensninger» og «ikke-atferdsmessige behov».[2] 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:

  1. Kvaliteter ved utførelsen, som for eksempel sikkerhet og brukbarhet, og som er observerbare i kjøretid.
  2. Kvaliteter ved utviklingen, slik som testbarhet, vedlikehold, utvidelsesmuligheter og skalerbarhet, som er bygd inn i den statiske strukturen til programvaren.[3][4]

Eksempler rediger

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å rediger

Referanser rediger

  1. ^ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). «Characterizing Architecturally Significant Requirements». IEEE Software (2 utg.). 30: 38–45. doi:10.1109/MS.2012.174. 
  2. ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management. O'Reilly Media. s. 113. ISBN 978-0-596-00948-9. Arkivert fra originalen 9. februar 2015. 
  3. ^ Wiegers, Karl; Beatty, Joy (2013). Software Requirements, Third Edition. Microsoft Press. ISBN 978-0-7356-7966-5. 
  4. ^ Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4. 

Litteratur rediger

Eksterne lenker rediger