Ikke-funksjonelle krav

Fra Wikipedia, den frie encyklopedi
Hopp til: navigasjon, søk

Ikke-funksjonelle krav (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 system arkitektur, 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 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 | rediger kilde]

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):

  • Tilgjengelighet (Accessibility)
  • Audit and control
  • Availability (se «service level agreement»)
  • Sikkerhetskopi (Backup)
  • Capacity, nåværende og fremtidig
  • Sertifisering (Certification)
  • Compliance
  • Konfigurasjonsstyring (Configuration management)
  • Dependency på tredjepart
  • Deployment
  • Documentation
  • Disaster recovery
  • Efficiency (ressursbruk ved en gitt last)
  • Effectiveness (resulterende ytelse ved en gitt last)
  • Emotional factors (som at systemet er morsomt å bruke eller lære, eller har høy «Vov!» -faktor)
  • Miljøvern (Environmental protection)
  • Escrow
  • Exploitability
  • Extensibility (legge til «features», og «carry-forward of customizations at next major version upgrade»)
  • Failure management
  • Fault tolerance (e.g. Operational System Monitoring, Measuring, and Management)
  • Legal and licensing issues or patent-infringement-avoidability
  • Interoperability
  • Maintainability
  • Modifiability
  • Nettverkstopologi (Network topology)
  • Open source
  • Operability
  • Performance / response time (performance engineering)
  • Platform compatibility
  • Pris (økonomi) (Price)
  • Personvern (Privacy)
  • Portability
  • Kvalitet (Quality) (e.g. påviste feil, leveransens feil, feilrettingens effektivitet)
  • Recovery / recoverability (e.g. mean time to recovery - MTTR)
  • Reliability (e.g. mean time between failures - MTBF, or availability)
  • Reporting
  • Resilience
  • Resource constraints (processor speed, memory, disk space, network bandwidth, etc.)
  • Response time
  • Reusability
  • Robustness
  • Safety or Factor of safety
  • Skalerbarhet (Scalability) (horisontalt, vertikalt)
  • Security
  • Software, verktøy, standarder etc. Bakoverkompatibilitet (Compatibility)
  • Stability
  • Supportability
  • Testability
  • Brukskvalitet (Usability) av målgruppen

Se også[rediger | rediger kilde]

Referanser[rediger | rediger kilde]

  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 2015-02-09. 
  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 | rediger kilde]

Eksterne lenker[rediger | rediger kilde]