Non-funktionelle krav

De non-funktionelle krav til en ny/ændret løsning skal identificeres og gøres synlige lige så vel som de funktionelle krav skal det i kravspecifikationen, så der kan tages hånd om disse krav helt fra start i arbejdet med løsningen. Såfremt systemejer ikke har helt specifikke og aftalte krav på et eller flere af disse områder, vil det dels være AU IT's gældende principper på disse områder, der implementeres (hvor de findes), alternativt vil indholdet af disse krav blive defineret i et tæt samarbejde med en ressourceperson fra det område, der forvalter pågældende ansvarsområde i AU IT (eller andre steder i AU).

De non-funktionelle krav omhandler følgende 5 typer:

Krav til arkitektur

• Arkitekturprincipperne (evt link til)
  • Informationsarkitektur
  • Applikationsarkitektur
  • Teknisk arkitektur
• Komponenter i arkitekturløsningen
• Miljøer i arkitekturløsningen

Krav til sikkerhed

• Fortrolighed
• Tilgængelighed
• Integritet

Krav til brugergrænseflader

• Se https://arkitektur.digst.dk/rammearkitektur/faelles-krav-til-gode-brugeroplevelser

Krav til systemgrænseflader

• Kommunikation til/fra systemet, dataudveksling

Krav til kvalitetskarakteristika

(se https://iso25000.com/index.php/en/iso-25000-standards/iso-25010)

• Performance (Oppetid, hastighed, svartid, mængde samtidige brugere)
• Kapacitet (Nuværende kapacitet/forventet vækst, data)
• Pålidelighed (Backup, nøjagtighed, adgangskontrol)
• Drift og vedligehold (Oppetid, genstartstid, udvidelsesmulighed, flytbarhed, kompatibilitet, installation, internationalisering (sprog), vedligeholdelsesvenlighed (herunder dokumentation), gennemsigtighed og supportvenlighed)
• Fleksibilitet (Flytbarhed, kompatibilitet på tværs af platforme, programmeringssprog, internationalisering (sprog), brug af open source)
• Brugerorientering (Indlæringstid, forståelighed, hurtigt at anvende, hjælpefaciliteter, uddannelse)

'Eksempel' på synliggørelsen af et non-funktionelt krav

Særligt for SaaS-løsninger

Når der er tale om SaaS-systemer, er der i tillæg til ovennævnte non-funktionelle krav en række andre non-funktionelle områder, som bør påkalde sig fokus i forbindelse med kravsætning og test heraf. Nedenstående listede områder er uddraget fra Digitaliseringsstyrelsens "Vejledning i anvendelse af cloudservices" fra 2019. 

Skalering

• Skalering pr. komponent (og komponentinddelte containers) eller pr. system?
• Skaleringsparat systemdesign - fra server- til cloudløsning eller nyt cloudsystem?
• Udelukkende cloudservices eller skalering til cloudservices ved spidsbelastninger?
• Skaleringsparat design
• Omkostningseffektivitet

Leverandørafhængighed

• Bindinger på enkelte komponenter eller kompleks system med mange integrerede komponenter?
• Mulighed for påvirkning af leverandørens valg af teknologier og ny funktionaliet?
• Klar exit-strategi nødvendig (systemskiftevil ofte være lig leverandørskifte)

Arkitekturmæssig understøttelse

• Datakryptering (ved opbevaring og transport af data)
• Budgetusikkerhed -  nye  processer i organisationen til at analysere og  godkende faktureringen samt håndtere budgetusikkerheden
• Udbudslovens tærkselværdier gælder, selvom der afregnes pr. forbrug - er løsningen arkitekturmæssigt forberedt til at kunne migreres fra en leverendørs IaaS/PaaS til en andens?

Juridiske overvejelser

• Fysisk kontrol af leverandørens overholdelse af juridiske krav sjældent muligt. Vurderes i stedet på baggrund af foreliggende dokumentation, herunder certificeringer og revisionserklæringe for overholdelsen af juridiske krav og krav stillet på baggrund af konkret risikovurdering?
• Hvilke typer personoplysninger behandles (om nogen) i systemet?
• Kan systemet og leverandøren imødekomme rettigheder i databeskyttelsesforordningen (den registreredes ret til indsigt, berigtigelse, sletning og indsigelse i data om pågældende)?
• Kan AU (dataansvarlig) gennemføre tekniske og organisatoriske foranstaltninger, der sikrer en effektiv implementering af de grundlæggende databeskyttelsesprincipper, opfyldelse af kravene i Databeskyttelsesforordningens artikel 25 og beskyttelse af registreredes rettigheder?

• Anvendes leverandører (eller underleverandører) fra tredjeland (sikker eller usikkert?)

• Sker der ved hver enkelt cloudservice overførsel til et sikkert eller usikkert tredjeland (uanset i hvilket led af leverandørkæden dette måtte forekomme)? 
• Sikring af klar exit-strategi for overholdelse af databeskyttelsesforordningen - for flytning af applikation samt data og sletning af data fra backups hos afgivende leverandør.
• Håndtering af tvungne opdateringer og validering

Sikkerhed

• Kontrol af sikkerhedsmæssige foranstaltninger på baggrund af dokumentation fra leverandøren
  • Certificeringer
  • Revisionsrapporter
  • Sikkerhedslogs
  • Evt. dokumentation fra uafhængig tredjepart
• Hvilke dokumenter udgør sammenlagt tilfredsstillende grundlag for den sikkerhedsmæssige kontrol?
• Svartider på support hos leverandøren?
• Hvor hurtigt udrulles sikkerhedsopdateringer?
• Hvad er leverandørens processer og regler for oprettelse og sletning af brugere eller gendannelse af backupdata?
• Supporteres de anvendte operativsystemer stadig med relevante sikkerhedsopdateringer (eller har leverandøren truffet andre foranstaltninger til at forhindre sikkerhedshændelser)?
• Er der etableret et beredskab hos AU, som er ansvarlig for at sikre:
  • at der foretages vurdering af, om en opdatering udgør en potentiel  risiko?
  • at AU får testet sine  systemer for sådanne opdateringer i god tid, inden de implementeres? 
  • at AU kan håndtere opdateringer, der gennemføres med meget kort eller intet varsel?
  • at der foretages vurdering af, om der er afledte effekter i andre systemer som følge af en opdatering?