developer.e-ehitus.ee

Mittefunktsionaalsed nõuded

Käesolev dokument kirjeldab e-ehituse platvormi rakenduste mittefunktsionaalseid nõudeid koos viidetega vastavatele allikatele või täiendavale infole.

Nõude kirjeldusKategooria
1. Rakenduse arhitektuur peab lähtuma EHR arhitektuuridokumendist. arhitektuur
2. Rakenduse kasutajaliides peab olema juurdepääsetav ning vastama vähemalt Web Content Accessibility Guidelines (WCAG) 2.1 tasemele AA.kasutajaliides
3.Rakenduse kasutajaliides peab olema kasutatav järgmiste veebibrauseritega: Chrome, Safari, Firefox, Edge, AndroidChrome ja IOS lehitsejad.kasutajaliides
4. Rakenduse kasutajaliides peab ühilduma täielikult HTML5, CSS3 ja Javascript kehtivate standarditega ning kõikide nõutud veebilehitsejate viimaste versioonidega.kasutajaliides
5. Rakenduse kasutajaliides peab kohanduma erinevate ekraanivaadetega (arvuti, tahvel ja mobiiltelefon).kasutajaliides
6. Rakenduse kasutajaliidese disainiotsused tuleb tellijaga kooskõlastada.kasutajaliides
7. Rakenduse kasutajaliides peab olema tehtud lähtudes värskeimatest UX trendidest.kasutajaliides
8. Rakenduse kasutajaliidese kujunduses tuleb lähtuda e-ehituse stiiliraamatust.kasutajaliides
9. Rakenduse kasutajaliidese aluskomponentideks on MTA komponendid.kasutajaliides
10.Kasutajaliidese komponendid peavad olema dokumenteeritud.kasutajaliides
11.Kasutajaliidese komponendi Git projekti readme.md failis peab olema (vt näidisfail Ehitise kehtivate andmete teenus ja Swagger):
  • • Komponendi eesmärgi tutvustus
  • • Juhend, kuidas komponenti saab teistes projektides kasutada
  • • Viide dokumentatsiooni asukohale – dokumentatsioon peab sisaldama näiteid, kuidas komponenti võõrast koodist välja kutsuda
  • • Juhend edasiarendamiseks
  • • Juhend versioneerimiseks ja publitseerimiseks.
kasutajaliides
12.Rakendus peab töötama veebibrauseritega, mis toetavad ID-kaarditarkvara 2 viimast versiooni.eID
13.Rakendus peab kasutama kasutaja tuvastamiseks keskset TARA autentimisteenust. eID
14.Arendusprojekti juhtimiseks ja projekti läbiviimiseks kasutatakse MKM projektijuhtimistarkvara Jira. (Selgitus: Arendustööde tellimused ja tarkvaravigade haldamine.) organisatsioon
15.Arendusprojekti käigus loodav lähtekood esitatakse dokumenteerituna läbi koodihalduskeskkonna: https://git.mkm.ee/projekti_nimi. organisatsioon
16.Arendusprojekti käigus loodavate rakenduste versioone tähistatakse vastavalt Semver 2.0 standardile „versioon-x.x.x”. Versiooni numbrid peavad kajastuma koodihoidla Git Tag’ ides. organisatsioon
17.Statistilisi parameetreid mõõdetakse Google Analytics keskkonna kaudu. (Selgitus: Tellija annab omalt poolt vastava Google Analytics konto andmed.) analüütika
18.Jõudluse parameetrid:
  1. • Üldjuhul peavad API päringud tagastama tulemuse brauserisse alla 1s.
    1. • Mõõdetakse brauseri põhiselt.
    2. • API erijuhud lepitakse Tellijaga eraldi kokku.
  2. • Kasutajaliidese HTML peab koos stiilide ja Javascriptiga laaduma < 1s.
kvaliteet
19.API rakenduse endpoint-id peavad olema vastavuses juhendiga EHR API teenuste nimetused ja teenuste kirjeldamine.kvaliteet
20.API rakenduse kõik „route“-d peavad olema varustatud Katalon testiga, mis testib sisend/väljundit ja kiirust. kvaliteet
21.Rakendus peab tagama isikuandmete töötlemise vastavalt isikuandmete kaitse üldmäärusele ja isikuandmete kaitse seadusele: Euroopa Parlamendi ja nõukogu määrus (EL) 2016/679, 27. aprill 2016. infoturve
22.Rakenduse ja andmebaasi turvalisuse tagamiseks tuleb järgida OWASP-i parimaid praktikaid: OWASP Cheat Sheet. infoturve
23.Rakendus peab salvestama kõik paroolid ainult krüpteeritud kujul. infoturve
24.Rakendus ei tohi lubada ühe kasutajaga mitut samaaegset sessiooni. infoturve
25.Rakenduse ja kasutaja vaheline infovahetus tohib käia ainult üle HTTPS protokolli.infoturve
26.Rakendus peab olema kirjutatud arvestades töödeldavatele andmetele määratud ISKE turvaklassi nõudeid. (Selgitus: ISKE turvaklassi täpsustab Tellija. Täpsem info RIA infoturbe lehel.) infoturve
27.Krüptograafiliste algoritmide valimisel lähtuda RIA krüptograafiliste algoritmide elutsükli uuringutest. infoturve
28.API rakendus peab olema turvatud Denial-Of-Service (DOS), Cross-Site-Scripting (XSS), Brute Force ja SQL/NoSQL Injection rünnakute vastu. infoturve
29.API peab sisaldama: …/version route‘i, mis tagastab API kehtiva versiooni ja k8s liveness probe, mille abil K8s kontrollib API rakenduse „elus“ olekut. infoturve
30.Loodav infosüsteem majutatakse riigipilve keskkonda ning sellega tuleb arvestada arhitektuuri planeerimisel. infra
31.Eelistatud on vabavaraliste andmebaaside platvormide kasutamine, nt PostgreSQL. infra
32.Rakendusserverite ja andmebaasi teenuste jooksutamise tuleb kasutada plokksalvestuskeskkonda. infra
33.Faililao loomisel eelistatakse objektsalvestuskeskkonna kasutamist S3 REST API-ga. infra
34.Rakenduse logimine peab vastama isikuandmete kaitse seaduses §36 kehtestatule. andmekaitse
35.Automaatseks rakenduse ehitamiseks ja paigaldamiseks kasutame Gitlab CI/CD töövooge koos Docker‘iga. DevOps
36.Rakendused käitatakse Docker konteinerites Kubernetese klastrites. Kubernetes haldamiseks kasutame Rancher’it. DevOps
37.Kubernetesesse paigalduseks tuleb rakendusele lisada Helm chart, mis arvestab, et rakendust paigaldatakse erinevatesse Rancher projektidesse.DevOps
38.Helm chart peab sisaldama paigalduse juhendit koos rakenduse tööks vajalike secretite ja configmap muutujate kirjeldusega failis app-readme.md ning paigalduseks vajalike muutujate kirjeldusi failis questions.yml. kvaliteet
39.Rakenduse kasutajaliidese kood peab olema silutud ning linter “Eslint“ Airbnb reeglitele vastav väljund ei tohi sisaldada vea ning hoiatusteateid. kvaliteet
40.Rakenduse testimiseks peavad olema koostatud testilood ning igale testiloole peab olema koostatud sellele vastav Katalon automaattest. Automaattestid peavad töötama ilma vigadeta. kvaliteet
41.Rakendusele html kujul kasutusjuhendit tuleb täiendada ja viia see vastavusse rakenduses tehtud muudatustega. kvaliteet
42.Kasutajajuhendi stiil lähtub e-ehituse stiiliraamatust . kvaliteet
43.Kasutusjuhend peab olema kasutusloo põhine, ehk juhendama kasutajat samm sammult iga konkreetse kasutusloo läbiviimisel. kvaliteet
44.Kasutusjuhendi kirjutamisel tuleb lähtuda nendest juhistest. kvaliteet
45.Kasutajajuhend peab olema kontekstipõhiselt lingitud kasutajaliidese elementidega. kvaliteet
46.Rakendusele peab olema koostatud paigaldusjuhend ja taasteplaan. turve
47.Rakenduses peab saama MKM-i Peakasutaja hallata väljade, nuppude, pealkirjad nimetusi, info (i) tekste, abitekste, veateateid. kasutajaliides
48.Rakenduse loomisel tuleb arvestada võimalusega muuta see mitmekeelseks (nt inglise, eesti, vene). kasutajaliides

Changelog

VersioonKuupäevAutorKommentaar
v1.213.01.2020Ülo Puskar, Kristjan KaiklemAlgversioon