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:

Kvaliteter ved utførelsen, som for eksempel sikkerhet og brukbarhet, og 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.^[3]^[4]

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å

Referanser

^ 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.
^ 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.
^ Wiegers, Karl; Beatty, Joy (2013). Software Requirements, Third Edition. Microsoft Press. ISBN 978-0-7356-7966-5.
^ Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4.

Litteratur

Eide, Petter L. H. (2005). Quantification and Traceability of Requirements (PDF). Faculty of Information Technology, Mathematics and Electrical Engineering Department of Computer and Information Science. Arkivert fra originalen (PDF) 26. august 2016. Besøkt 12. juni 2016.

Eksterne lenker

«Non-functional Requirements». Besøkt 13. juni 2016. Maler og eksempler
Wada, Hiroshi; Suzuki, Junichi; Oba, Katsuya. «Modeling Non-Functional Aspects in Service Oriented Architecture» (PDF). Modellering av ikke-funksjonelle egenskaper i SOA
«Non-Functional Requirements: Do User Stories Really Help?». www.methodsandtools.com. Besøkt 12. juni 2016. Smidig ikke-funksjonelle krav
«Non-Functional Requirements Be Here | CISQ - Consortium for IT Software Quality». it-cisq.org. Arkivert fra originalen 5. juni 2016. Besøkt 12. juni 2016. Strukturelle krav (
Jansen, Arne. «Kravdefinisjon og kravspesifikasjon». ndla.no. Arkivert fra originalen 30. juni 2016. Besøkt 21. juni 2016.

[ASR_Chen-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.

[Wiegers13-3] Wiegers, Karl; Beatty, Joy (2013). Software Requirements, Third Edition. Microsoft Press. ISBN 978-0-7356-7966-5.

[Young01-4] Young, Ralph R. (2001). Effective Requirements Practices. Addison-Wesley. ISBN 978-0-201-70912-4.

[1]

[2]

[3]

[4]