Tiivistetty vaatimusmäärittely
- [SIJOITA TOIMEKSIANNON NIMI TÄHÄN]
- Projektimäärittely/vaatimusmäärittelyn tiivistetty versio v 0.3 4.1.2021 (NarsuMan)
Ohjeita ennen aloitusta :)
Olet editoimassa tiivistettyä vaatimusmäärittelyä, joka on normaalia OPF:n laajempaa vaatimusmäärittelyä rajatumpi. Kannattaa tutustua ehdottomasti laajempaan vaatimusmäärittelyyn, koska se sisältää ohjeistuksen lisäksi videomateriaalia.
Johdanto
Kuvaa tavoiteltua kokonaisuutta, hieman taustaa ja aiheeseen olennaisesti liittyviä asioita? Jos kyseessä harjoitustehtävä, niin tarkista voitko käytää olemassa olevia tilaajien oikeita nimiä! Muussa tapauksessa vaihdetaan kaikki nimet itse keksittyihin :)
Pengwin media on yksi neljästä WIMMA Labin virtuaalisesta yrityksestä. Ryhmän vastuualueisiin kuuluu visuaalisen ulkoasun suunnittelu ja toteutus. Tämän vuoden ryhmän tehtäviin kuului WIMMA Labin brändiuudistus ja siihen liittyvä verkkosivujen uudistaminen. Toimeksianto toteutetaan vuoden 2021 kesän aikana. Pengwin mediassa on laajasti erilaista osaamista visuaalisesta suunniittelusta ja toteutuksetsa, ohjelmistotekniikasta sekä kyberturvallisuudesta.
Tavoitteet
Mitä ratkaisun avulla voidaan tehdä? Mihin pyritään? Tämä osuus voidaan käsitellä myös projektisuunnitelmassa, mutta vaatimusmäärittelyssä voidaan avata tarkemmin tavoiteltua ratkaisua.
Ryhmän pääasialliset vastuutehtävät liittyvät visuaaliseeen puolen suunnitteluun ja toteutukseen. Ryhmän yksi tehtävistä on brändiuudistuksen suunnittelu ja toteutus. Tämän pohjalta ryhmä kirjoittaa uuden brändbookin, johon tehdyt ulkoasun muutokset ovat koottu. Ryhmä myös suunnittelee ja toteuttaa uudet verkkosivut WIMMA Labille sekä virtuaaliyrityksille. Tavoitteet voidaan jakaa kahteen osaan: ennen avoimia ovia olevat tavoitteet ja avoimien ovien jälkeen olevat tavoiteet.
Ennen avoimia ovia
Ennen avoimia ovia ryhmä suunnitteli Verkkosivut hyödyntäen aikaisempaa verkkosivua. Uuden verkkosivun värimaailmaa kevennettiin ja sisältöä muokattiin ajantasaisemmaksi. WIMMA Lab.org -sivusto luotiin avointen ovien -verrkosivun perusteella, minkä jälkeen sisältö muutettiin sopivaksi ja päivitettiin ajantasaisemmaksi. Ryhmä suunnittelee ja toteuttaa grafiikkaa muille virtuaalisille yrityksille tarpeen mukaan.
Avointen ovien jälkeen
Ryhmän tehtäviin kuuluu WIMMA Labin brändiuudistus, jonka suunnittelua ja toteutusta jatketaan avointen ovien jälkeen.Ryhmä alkaa suunnitlemaan ja koodaan uusia verkkosivuja. Etusivu rakannetta muutetaan selkeämmäksi ja tiedot päivitetään. Verkkosivut toteutaan next:js hyödyntäen.
Tehtävät verkkosivut * WIMMALab.org -verkkosivu * Virtuaalisten yritysten verkkosivut
Kohderyhmä
Millaisia ovat sen käyttäjät? Mikä tuotoksen tavoite on eri sidosryhmien kannalta? Kannattaa nostaa esiin lyhyesti mahdolliset loppukäyttäjä ja oleellisiin palvelusta hyötyviin sidosryhmät WIMMA Labin kohderyhmä voidaan jakaa pääasiassa opiskelijoihin ja mahdollisiin toimeksiantajiin/työpaikan työntekijöihin.
Opiskiljat ovat yksi WIMMA Labin kohderyhmistä. Opiskelijat voidaan jakaaa kahteen osaan, joita ovat kiinnostuneet ja osallistuvat opiskelijat. Opiskelijat-osiosta WIMMA Labista kiinnostuneet opiskelijat löytävät helposti tietoa siitä, mikä WIMMA Lab on, mitä siellä tehdään ja miten siihen voi hakea. WIMMA Labissa mukana olevat opiskelijat löytävät sivun kautta helposti tietoa muiden ryhmien toiminnasta sekä WIMMA Labiin liittyviä oppaita.
Toinen kohderyhmä on IT-alan yritykset. Osion tarkoituksena on koota tietoa siitä, miten yritykset voivat osallistua WIMMA Labin toimintaa. Tällöin yritysten kynnys osallistua WIMMA Labin toimintaan on matalampi, sillä tarvittavat tiedot löytyvät osiosta.
JAMK pystyy markkinoimaan WIMMA Labia ja sen toimintaa opiskelijoiden keskuudessa. Tällöin mukaan voisi saada laajasti opiskelijoita eri osaamisalueilta esim. tietojenkäsittelyn koulutusohjelma.
Sidosryhmäkartta
Mietitään tarkemmin millaisia käyttäjä/sidosryhmiä liittyy suunniteltuun ratkaisuun/ohjelmistoon/palvelukokonaisuuteen? Näitä selkeyttääksemme kirjataan kaikki sidosryhmät sidosryhmäkartan muotoon. Nostetaan samalla esiin mikä on ko. sidosryhmän/edustajan palveluun liittyvä motivaatio. Kuvauksen voi laatia esim. piirtämällä, MindMap-muodossa tai soveltaen sopivaa UML-notaatiota.
Voit tutustu nyt aiemmin mainittuun PlantUML-työkaluun ja kokeilla luoda sidosryhmäkartta käyttäen (http://plantuml.com/) Huomaa! PlantUML-lohkon määrittelyssä käytetään Gitlab-ympäristössä eri avainsanoja @startuml/@enduml- rivien sijaan
WIMMA Labin verkkosivujen todennäköisimmät sidosryhmät ovat opiskelijat sekä eri yritysten työntekijät / mahdolliset toimeksiantajat.
tämä vanhasta, pitäisikö tehdä vastaava myös itse?
Tarkennettut sidosryhmäprofiilit
Kuvataan tarkemmin sidosryhmäkartasssa esiteltyhä sidosryhmiä/profiileja. Tarvittaessa kuvataan tarkemmin valitut sidosryhmät ja tarkennetaan niitä, jos toimeksianto sitä edellyttää. Tähän sovelletaan alisivuja, joita tarpeen mukaan kopioidaan "pohjat"-kansiosta Katso esim. Asiakas B
| ID | Tyyppi | Nimi | Piirteet | Motivaatio |
|---|---|---|---|---|
| SR-001 | Sidosryhmä/Profiili | Opiskelija | "aikuinen" | Selkeä tarve palvelulle, löytää tartvitsemansa tiedon helposti yhdestä paikasta |
| SR-002 | Sidosryhmä/Profiili | Toimeksiantaja Asiakas B - Profiili 1 | "Aikuinen" 22-45V | Tarve satunnainen, mutta yksi yleisimmistä asiakasryhmistä |
| SR-003 | Sidosryhmä/Profiili | JAMK | Toimeksiantaja | Haluaa uudistaa WIMMA Labin brändin ja sille uudet verkkosivut |
| SR-004 | Sidosryhmä/Profiili | häirikkö | sidosryhmä, joka pyrkii teoillaan aiheuttamaan vahinkoa palvelulle | Vahingonteko |
| SR-005 | Sidosryhmä/Profiili | Pengwin-media | Verkkosivuston toteuttaja | Sidosryhmä, joka on tekemisissä palvelun kanssa usein. Haluaa kehittää sen valmiiksi |
Valitut asiakastarinat
Haastattele tai "kuvittele" haastattelevasi palvelun kannalta olleellisia profiili/sidosryhmän edustajia ja pyydä heitä kuvaamaan palvelun käyttöön liittyviä oleellisia tilanteita. Miten henkilö/sidosryhmä hyötyy/käyttää palvelua. Kirjoita tämä tarinan muotoon. Kerro mitä palvelun käyttö käytännössä tarkoittaa asiakkaan, pääkäyttäjän etc. näkökulmasta! Alla olevassa videossa näet millaisia tarinoita ei ole tarkoitus kirjata tähän osioon :)
Olli opiskelija
Olli Opiskelija opiskelee JAMKilla tieto- ja viestintätekniikkaa. Opintoja on kertynyt jo jonkin verran ja mahdollisen harjoittelupaikan etsiminen alkaa olla ajankohtaista. Olli on kuullut JAMKin järjestämästä projektipohjaisesta opintojaksosta nimeltä WIMMA Lab. Olli avaa kännykällä selaimen ja siirtyy katsomaan WIMMA Labin kotisivuja. Etusivulta hän lukee yleistä tietoa ja siirtyy sen jälkeen opiskelijoille tarkoitettuun osioon. Sieltä hän lukee perustiedot siitä, mitä siellä tehdään sekä miten pystyy hakemaan mukaan. Olli täyttää lomakkeen osallistumista varten ja jää odottelemaan tietoa haastattelujen ajankohdasta.
### Topi toimeksiantaja Topi selailee tauollaan LinkedIniä ja huomaa postauksen WIMMA Labista. Topi ei ole koskaan kuullutkaan moisesta, mutta kiinnostuu asiasta. Hän siirtyy sivustolle tutkimaan, mikä juttu on oikeastaan kyseessä. Hän lukee etusivulta perustietoa WIMMA Labista ja kiinnostuu sen toiminnasta enemmän. Topi ei tiedä miten heidän yritys voisi olla mukana WIMMA Labin toiminnassa. Hän siirtyy katsomaan tietoa yritksille tarkoitetusta osiosta, josta hän löytää tarvitsemansa tiedot. Topi laittaa sähköpostia, jossa kertoo mahdollisesta toimeksiannosta sekä kiinnostuksesta tulla kertomaan heidän yrityksensä käyttämästä teknologiasta.
Veera Virtuaaliyrityksen työntekijä
Veera on osallistunut WIMMA Labiin ja projektin on päässyt kunnolla alkuun. Heidän ryhmänsä tekee palvelua, mutta he tarvitsevat sille verkkosivut. Veera laittaa viestiä Pengwin medialle ja kysyy sivuston toteuttamisesta. Veera kertoo Pengwin medialle millaista sivustoa he tarvitsevat ja millaisia ominaisuuksia sillä pitää olla. Veeraa jää odottelemaan Pengwin median yhteydenottoa siitä, kun sivusto on valmis.
Palveluun liittyviä asiakaspolkuja
Mieti toimeksiantoa ja pohdi onko siitä tunnistettavissa ns. palvelupolkuja? Asiaspolkukuvauksen avulla kuvataan tapahtuma sarjaa joka käydään jossain valitussa tilanteessa läpi palvelun käytön aikana. Asiakas kohtaisia palvelupolkuja voi olla useita, mutta tärkeintä on tunnistaa alkuvaiheessa oleellisimmat. Palvelupolkua kuvattaessa voi hyödyntää esim. Swim lane/BluePrint/tilakone-kuvausta tai muuta sopivaksi katsottua kuvausta. Tärkeää on kuitenkin kuvata polku ja käyttää sitä tarvittaessa selkeyttämään ymmärrystä tavoitellusta palvelusta. Käy läpi tekemäsi kuvausta jonkun toisen henkilön kanssa yhdessä? Käy läpi polku ja kerro mitä sen aikana tapahtuu..
asiakaspolku PlantUML-esimerkki tilakoneena
Kokeillaan luonnostella asiakaspolkua PlantUML-työkalun avulla. Kannattaa kokeilla ehdottomasti myös muita tapoja! Sovella esim. PlantUML SDL/Swimlane kuvausta?
tämä oli vanha esimerkki. sen voisi poistaa kun ei tarvitse enää
Opiskelija
Toimeksiantaja
Käyttöliittymänäkymä/mockup
Jos projektin tuloksena tuo sähköinen ratkaisu, on sen konkretisoimiseksi hyvä hyödyntää esimerkiksi MockUp-kuvaa. Tähän kannattaa liittää tarvittaessa kuvausta kuvan/mockup-näkymän muodossa. Se helpottaa ymmärtämään tarvittaessa oleellisesti tavoiteltua ratkaisua.
Ryhmä hyödyntää Mockupin suunnittelussa Figma-työkalua. Sen avulla alustavan version sisältö ja visuaalinen ulkonäkö suunnitellaan.
Ennen avoimia ovia
Ennen avoimia ovia ryhmä suunnitteli Verkkosivut hyödyntäen aikaisempaa verkkosivua. Uuden verkkosivun värimaailmaa kevennettiin ja sisältöä muokattiin ajantasaisemmaksi. WIMMA Lab.org -sivusto luotiin avointen ovien -verrkosivun perusteella, minkä jälkeen sisältö muutettiin sopivaksi ja päivitettiin ajantasaisemmaksi.
tähän voisi laittaa kuvauksia
Avointen ovien jälkeen
Avointen ovien jälkeen ryhmä alkaa suunnitlemaan ja koodaan uusia verkkosivuja. Verkkosivut toteutaan next:js hyödyntäen. Ryhmä koodaa WIMMALab.org-verkkosivun sekä jokaiselella virtuaaliselle yrityksellä omansa.
tähän voisi myös laittaa kuvia
Tärkeimmät toiminnallisuudet/ominaisuudet
Hahmotellaan tähän kohtaan ominaisuudet pelkästään ranskalaisilla viivoilla ja MindMap-kuvauksen avulla. Eli mitä tavoitellulla ratkaisulla/palvelulla mielestäsi on mahdollista tehdä? Mieti tilannetta, kun joku kysyy sinulta mitä palvelulla voi tehdä? Saat aikaa vastata 15 sekuntia. Mitä vastaat ja mitkä toiminnot nostatat esiin ehdottomasti valtteina verrattuna muihin vastaaviin ratkaisuihin/palveluihin? Tässä kohtaa kannattaa tarkistaa mitä olivat asiakkaan esittämät toiveet palvelusta? Niistä voisi löytyä ehkä joitain tässä vaiheessa?
- Oleelliset toiminnot (Esimerkkejä)
- Käyttäjä pystyy tutkimaan etusivulta
- käyttäjä pääsee siirtymään opiskelijoille/toimeksiantajalle tarkoitettuun osioon
- Verkkosivun lokalisaatio toimii suomeksi ja englanniksi
onko muita toimintoja? Tuosta voisi tehdä kaavion?
tämä on vanha versio, voisiko sitä hyödyntää uuden kanssa ehkä?
Alustavat käyttäjätarinat
näitä olen vähän miettinyt, mutta voisi olla enemmän
Ketterän kehityksen myötä on yleistynyt tapa kuvata asiakkaan tarpeita ns. käyttötarinoiden (User Story) muodossa. Kirjataan tähän ennalta tunnistetut käyttötarinat.
| ID | Tyyppi | Kuvaus | Linkki |
|---|---|---|---|
| US-001 | Käyttäjätarina | Käyttäjänä haluan helposti löytää tarvittavan tiedon, sillä en halua käyttää aikaa etsimiseen useista eri lähteistä. | #1 |
| US-002 | Käyttäjätarina | Opiskelijana haluan saada tietoa WIMMA Labista, sillä haluan hakea siihen. | #2 |
| US-003 | Käyttäjätarina | Haluan verkostoitua opiskelijoiden kanssa, sillä yritykseni etsii uusia päteviä työntekijöitä. | #3 |
Yleiset tekniset vaatimukset
en ole tähän vielä mitään kirjoittanut
Teknisiä ratkaisuja määriteltäessa on hyvä tunnistaa tarvittavat teknologiat, laitteistot tai muut tarvittavat fyysiset ratkaisut. Ohjelmiostoratkaisuja määriteltäessä kannattaa erottaa puhtaasti tekniset/tuotannolliset vaatimukset ja kirjata ne vaatimusmäärittelyyn esimerkiksi teknisinä vaatimuksina.
| ID | Tyyppi | Kuvaus |
|---|---|---|
| HWREQ-0002 | Tekniset vaatimukset | Palvelun tärkeimpien palvelujen on oltava vähintään kahdennettu N+1 |
| HWREQ-0003 | Tekniset vaatimukset | Palvelimen muistikapasiteeti >32GB |
| HWREQ-0005 | Tekniset vaatimukset | Palvelimen fyysinen sijainti on oltava EU-aluella |
| HWREQ-0005 | ... | ... |
Toiminnalliset vaatimukset (Functional Requirements)
en ole tähän vielä mitään kirjoittanut
Mitä toimintoja palveluun liittyy? Nämä kannattaa kirjata ensi ns. toiminnallisina vaatimuksina? Toiminnallisilla vaatimuksilla kuvataan ohjelmistolta/järjestelmältä vaadittuja toimintoja. Toiminnalliset vaatimukset ovat helpoimmin tunnistettavia. Vältä useamman vaatimuksen kirjaamista samaan lauseeseen! Jokainen vaatimus erikseen.
| ID | Tyyppi | Kuvaus | Toiminnallisuus johon vaatimus vaikuttaa |
|---|---|---|---|
| FUNCREQ-C0001 | Toiminnallinen vaatimus | Krjautumiseen voi käyttää Facebook-tunnuksia | Toiminnallisuus X |
| FUNCREQ-C0002 | Toiminnallinen vaatimus | Käyttöliittymää voidaan ohjata äänikomennoilla | Toiminnallisuus Y |
| FUNCREQ-C0003 | Toiminnallinen vaatimus | ... | ... |
Laadulliset eli ei-toiminnalliset vaatimukset
Mitä olivat ei-toiminnalliset vaatimukset? Voit esittää eri vaatimuksia erillisessä taulukossa tai viitata tässä yhteen laajempaan taulukkoon. Ei-toiminnalliset vaatimukset sisältää laajan joukko eri näkökulmia sähköiseen palveluun liittyen. Tärkeimmät kirjoittajan näkökulmasta ovat seuraavat: Suorituskyky, tietoturva ja saavutettavuus
- Suorituskyky
- Tietoturva
- Saavutettavuus
Suorituskykyyn liittyvät vaatimukset
Tätä olisi varmaan hyvä miettiä. Tässä on vain valmiita asioita, mitä pohjassa oli.
Millaisia vaatimuksia palveluun kohdistuu suorituskyvyn näkökulmasta?
| ID | Tyyppi | Kuvaus |
|---|---|---|
| PERFREQ-0000 | Suorituskyky | Kirjautuminen on mahdollista yhtäaikaa 100 käyttäjällä (100 request/s) |
| PERFREQ-0001 | Suorituskyky | Palvelun maksimi käyttäjä määrä on ? |
| PERFREQ-0002 | Suorituskyky | ... |
Tietoturvan vaatimukset
Tästä en ole vielä kirjoittanut yhtään mitään. Jäin miettimään miten meidän sivustolla näkyy tietoturvaan liittyvät asiat. Sivustolla ei ole kirjautumista eikä se kerää tietoa käyttäjistä. Onko käyttölogiin höydyllistä tai edes tarpeellista kirjata mitään tapahtumia?
Millaisia vaatimuksia palveluun kohdistuu tietoturvan näkökulmasta?
| ID | Tyyppi | Kuvaus | Miten testataan? |
|---|---|---|---|
| SECURITY-REQ-0001 | Salasanassa on käytettävä vähintään MD5-tason salausta, koska CONSTRAIN-000 sitä edellyttää | Testitapaus X | |
| SECURITY-REQ-0002 | Jokainen tapahtuma palvelussa on kirjattava käyttölogiin, että niitä voidaan tarkastella myöhemmin | Testitapaus Y | |
| SECURITY-REQ-0003 | ... | ... |
Saavutettavuuden vaatimukset
Mitä tarkoitetaan saavutettavuudella? Millaisia asioita/ohjeistuksia on otettava huomioon palvelua toteutettaessa? Tutustu saavutettavuusdirektiiviin ja kirjaa
Verkkosivun saavutettavuus on yksi asioista, jotka olisi hyvä huomioida verkkosivua suunniteltaessa. Olsi tärkeää että sivusto olisi selkeä ja mahdollisimman monen saavutettavissa. Sivuston saavutettavuutta kehitetään erilaisten ohjeiden ja suositusten mukaisesti. Saavutettavuutta testataan manuaalisesti sekä erilaisten työkalujen ja lisäosien avulla.
| ID | Luokka | Kuvaus | Miten testataan? |
|---|---|---|---|
| AVAILREQ-0000 | Saavutettavuus | Nimetään verkkosivun kannalta tärkeät kuvat, jotta lukulaite voi välittää tiedon niistä näkövammaiselle käyttäjälle | Testit |
| AVAILREQ-0001 | Saavutettavuus | Huomoidaan sivuston värimääailma, jotta sen kontrasti olisi riittävän hyvä | Testit |
| AVAILREQ-0002 | Saavutettavuus | Huomioidaan puna-vihersokeat ja muut sivustoa suunniteltaessa, jotta sivusto olisi kaikkien saavutettavissa | ... |
| AVAILEREQ-0003 | Saavutettavuus | Varmistetaan jokaisella sivulla olevan yksilöllinen ja kuvaava title-otsikko | [testi] |
| AVAILEREQ | Saavutettavuus | Tarkoituksenmukainen HTML-elementtien merkitykselllinen käyttö esim. H1 | [testi] |
| AVAILEREQ | Saavutettavuus | Tarkistestaan sivuilla olevien linkkien toimivuus | [Testi] |
Toimeksiannon kannalta tärkeät oleelliset rajaukset
Näitä en ole vielä miettinyt ollenkaan. Kaikki pohjan mukana tulleita
Eri ohjelmistojena/palvelujen toteutusta ja käyttöä ohjaavat usein lait ja säädökset. Näiden edellyttämät vaatimukset voidaan kirjataan tarvittaessa vaatimusmäärittelyyn. Rajausten vaikutus koskee usein palvelun jonkin osa-kokonaisuuden toteuttamista. Tästä syystä eri rajoitteet on tunnistettava ajoissa, koska vaikutus saataa olla varsin ratkaiseva pitemmällä tähtäimella. Esimerkkinä tästä on viime vuonna voimaan tullut EU GDPR-säädös. Kannattaa tutkia esimerkiksi https://www.sfs.fi/aihealueet/terveydenhuolto/laakinnalliset_laitteet tai http://docs.jhs-suositukset.fi/jhs-suositukset/JHS190/JHS190.html
| ID | Tyyppi | kategoria | Vastuullinen |
|---|---|---|---|
| CONSTRAIN-000 | Rajaus | Palvelun kirjautumisprosessin on noudatettava JUHTA-hyväksyttyjä käytänteitä | Kirjautuminen ft1 |
| CONSTRAIN-001 | Rajaus | On huomioitava Standardi ZZZ osana palvelun tapahtuma login talletusta | Log-palvelin |
| CONSTRAIN-002 | Rajaus | ... | ... |
Palvelun tuotantoympäristö
Vaatimusmäärittelyn tukena sovelletaan erilaisia kuvauksia, joista esimerkkinä UML-kuvauskieleen liittyvä sijoittelu näkymä, eli "Deployment Diagram", kuvauksen avulla voi esittää miten palvelu on tarkoitus toteuttaa käytännössä. Missä sijaitsevat eri osat palvelusta ja miten eri osat on kytketty toisiinsa.
Tähän voisi lisäillä jotain jos keksii
Pengwin media tekee yhteistyö Mysticons-virtuaaliyrityksen kanssa. Mysticons luo alustan verkkosivujen julkaisemista varten. Verkkosivu pyörii docker-kontin sisällä.
Palveluun liittyvät muut järjestelmät
Nämä kaikki olivat valmiina pohjassa
Alla olevat kuvaukset ovat esimerkkejä UML-kuvauksen mahdollisuuksista, kannattaa tutustua tarkemmin laajempaan vaatimusmäärittely pohjaan, koska siitä löytyy esimerkkejä.
Järjestelmien välisiä yhteyksiä voidaan kuvata tarvittaessa esim. UML-kuvauksiin liittyvän sekvenssikaavion muodossa (Sequence Diagram).
Standardit ja lähteet
Vaatimusmäärittelyyn kannattaa liittää mukaan kaikki tärkeät lähteet, joista on hyötyä tai merkitystä kokonaisuuden kannalta. Standardit ja ennalta jaetut ohjeistukset ovat hyödyllisiä lähteitä ja tarvittaessa tukevat esitettyjä vaatimuksia.
nämä olivat valmiina
| ID | Nimi | Linkki | Kuvaus |
|---|---|---|---|
| REF1 | JHS 165 ICT | JHS Suositukset - vaatimusmäärittelylle | Vaatimusmäärittelyn suositus |
| REF2 | ISO 9241-11 | Käytettävyys | Usability |
| REF3 | EN 301 549 | Saavutettavuus | Availability |
| REF4 | GDPR | GDPR Asetus | General_Data_Protection_Regulation |