Skip to main content

Mittefunktsionaalsed nõuded arendustele

Parima kasutajakogemuse saamiseks palume kasutada allolevaid PDF faile

Mittefunktsionaalsed nõuded arendustele

SKAISi MFN

Versioon: 2.0

Sotsiaalministeeriumi haldusala

riist- ja tarkvara ning e-teenuste üldine haldamise ja arendamise infotehnoloogiline standard

Üldsätted

  1. Infotehnoloogilise standardi (edaspidi IT profiili) eesmärgid on:
    1. kirjeldada Tervise ja Heaolu Infosüsteemide Keskuse poolt hallatava riist- ja tarkvara tüüpkonfiguratsioone ja nende miinimumparameetreid.
    2. haldus-, hooldus- ja koolituskulude vähendamine olemasolevale infosüsteemile;
    3. tekkida võivate probleemide ja kulude minimeerimine läbi erinevate infosüsteemi osade integreerimise;
    4. jätkuva arengu garanteerimine kõigile kasutatavatele infotehnoloogilistele (edaspidi IT) lahendustele Sotsiaalministeeriumi haldusalas;
    5. kasutatava tarkvara ja riistvara ühtsuse saavutamine, mille abil on tsentraliseeritud hangete kaudu võimalik märkimisväärselt kokku hoida;
    6. süsteemidele mõjuvate turvariskide minimeerimine;
    7. tekitada süsteemide kasutajatele efektiivne, turvaline ja mugav töökeskkond.
  2. IT profiili korrigeeritakse vastavalt vajadusele kuid mitte harvemini kui üks kord aastas (või arendusprojektide sisendi tulemusel vastavalt vajadusele). Muudetud IT profiil kinnitatakse TEHIK arhitektuurinõukogu poolt.

Tehnilised nõuded e-teenustele, lähtudes TEHIK'u hallatavatest infosüsteemidest ja infrastruktuurist

  1. IT toodete ja komponentide valiku põhimõtted
    1. sama funktsionaalsusega, kuid erinevate tootjate komponentide arv peab olema viidud miinimumini. Standard riistvara soetamisel eelistada soovitavalt ühe tootja seadmeid, mis tagab kogu IT infrastruktuuri parema toimivuse ja seadmete ühilduvuse;
    2. kõik valitud tooted peavad de facto vastama kehtivatele tööstusstandarditele, kusjuures tuleb eelistada avatud standardeid;
    3. testistaadiumis (beta, release candidate jne) tarkvara võib kasutada ainult testimise eesmärgil;
    4. komponendid ja tooted peavad vastama asutuse poolt määratud turvareeglitele;
    5. komponentide ja toodete, mis ei ole antud dokumendis kajastatud, kasutusele võtmine vajab eelnevat arhitektuurinõukogu heakskiitu.

Kehtib nii olemasolevate süsteemide uuendamise kui ka uute süsteemide loomise kohta (Applies to building brand new systems and also to refactoring existing systems)

Nõude nrNõude sisuSeletusedKoostamise eest vastutajaTestimise läbi viib või kinnitab
  1. Vastavus üldistele standarditele
1.1Lahenduse X-tee teenused peavad vastama RIA nõuetelehttps://www.ria.ee/et/ametist/juhendid.htmlArendajaTestija
1.2Lahendus peab vastama Sotsiaalministeeriumi IT-profiilile
ArendajaProjektijuht
Arhitekt
Administraator
Testija
Turvatestija
Infoturbe spetsialist
Standardija
1.3Rakendus peab olema kirjutatud arvestades selle rakenduse poolt töödeldavatele andmetele määratud ISKE turvaklassi nõudeid

https://www.ria.ee/et/kuberturvalisus/infosusteemide-turvameetmete-susteem-iske.html

ArendajaTurvatestija
1.4Veebirakenduse kasutajaliides peab vastama vähemalt WCAG 2.0 tasemele AAhttp://www.w3.org/TR/WCAG20/ArendajaTestija
1.5Veebipõhine kasutajaliides peab ühilduma täielikult standarditega HTML 5 ja CSS 3. Kokkuleppel TEHIK arhitektiga on lubatud erandid.Valideerimiseks kasutatakse vastavaid validaatoreid: http://validator.w3.org/ Kui on tegu olemasoleva süsteemi edasiarendusega, siis tuleb järgida olemasolevat HTML ja CSS versiooni.ArendajaTestija
1.6ID-kaardiga allkirjastamisel on eelistatud veebipõhine digidoc-teenuste kasutamine ja failide asemel failiräside saatmine teenusesse.Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud digidoc-teekide versioonid ja kasutuskohad.ArendajaTestija
1.7Veebirakendus peab probleemiteta läbima OWASP ASVS baasil põhineva testiKui pole arenduse eraldi kokku lepitud teisiti, siis on OWASP ASVS tasemeks 2 (https://www.owasp.org/index.php/Category:
OWASP_Application_Security_Verification_Standard_Project
).
Kinnise lähtekoodiga kommertstoote kasutamisel ei eeldata ligipääsu kinnisele lähtekoodile.Tellija poolset turvatestimist teostab kolmas sõltumatu pool.Selline esmane kolmanda poole turvatestimine tellitakse tellija finantseeringul. Ilmnenud vigade korral ja peale nende parandamist peab järeltestimise rahaliselt kompenseerima arendaja, kui tellija vastava nõudmise esitab.
ArendajaTurvatestija
1.8Krüptoalgoritmite ja räsifunktsioonide kasutamisel tuleb järgida uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut, st lahendustes ei tohi kasutada uuringus väljatoodud ebaturvalisi algoritme ja võtmepikkuseidArendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) tuleb välja tuua kasutatavad krüpto- ja räsialgoritmid, nende võtmepikkused, kasutuskohad, sh SSL sertifikaatide kasutuskohad. Värskeima uuringu leiab aadressilt https://www.ria.ee/et/ametist/uuringud-analuusid-ulevaated.htmlArendaja

Arhitekt

Administraator

Turvatestija

1.9Andmete edastus peab olema kaitstud kasutades turvalisi ja üldteada andmeedastusprotokolle. Kokkuleppel TEHIK arhitektiga on lubatud erandid.
ArendajaTurvatestija
1.10Infosüsteem peab kasutama serveri kellaaega ja ajatsooni.
ArendajaAdministraator
1.11Süsteemi edasiarendamisel/loomisel peab arvestama selle võimaliku laiendamisega nii andmemahtude, kui ka kasutajate arvu osas. Konkreetsed nõuded annab ette TEHIK arhitekt.
Arendaja

Arhitekt

Testija

1.12Rakendus peab olema tehniliselt tükeldatud vastavalt loogilisele jaotusele. Saadud osised peavad olema eraldi versioneeritavad ja paigaldatavadNäiteks, kui rakendus on eraldi turvakontekstidega liidesed ametnikule ja kodanikule, peab rakendus olema jagatav kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiksArendajaArhitekt
1.13Avalike e-teenuste loomisel peab arvestama valitsusasutusele kehtestatud visuaalse identiteedi stiilijuhisedhttps://www.valitsus.ee/et/eesmargid-tegevused/valitsusasutuste-visuaalse-identiteedi-stiilijuhisArendajaTestija
1.14Avalike e-teenuste loomisel peab arvestama valitsusasutustele kehtestatud iseteeninduskeskkonna raamistikuga

https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistik_08.07.2015.pdf

https://www.mkm.ee/sites/default/files/iseteeninduskeskkondade_raamistiku_kasutatavuse_nouded_dets.pdf

ArendajaTestija
1.15Avalike e-teenuste koomisel peab arvestama TEHIKu stiiliraamatu nõuetega<Siia tuleb link TEHIKu gitlabi>ArendajaArhitekt

2. Nõuded rakenduse arhitektuurile

2.1Rakenduse, andmebaasi ja kolmanda osapoole komponentid peavad olema sellised, mille eluea lõpp (EOL) pole teadaolevalt vähem kui 2 aasta pärast.Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema välja toodud kasutatavate komponentide nimetused ja versioonid. Versiooni eluea lõppu ei loeta võrdseks terve komponendi eluea lõpuks, st versiooni tugi võib aeguda, kui uus versioon on välja lastud.ArendajaArhitekt
2.2Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, kolmanda osapoole komponendid) ja topoloogia peab olema enne reaalse arenduse algust infosüsteemide halduse osakonna juhiga kooskõlastatud.Süsteemi jõudlus peab vastama kokkulepitud topoloogial eelanalüüsi ja lähteülesande käigus välja toodud jõudlusnäitajatele.ArendajaArhitekt
2.3Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril.
ArendajaAdministraator
2.4Rakendusserver peab olema vajadusel klasterdatav aktiivklastris (kasutajasessioon ei tohi olla klastri node põhine).
ArendajaAdministraator
2.5Rakendust peab saama ilma ümberprogrammeerimata liigutada erinevate domeenide ja domeeni saitide vahelLahendus ei tohi olla sisse kompileeritud absoluutseid URI-sidArendajaAdministraator
2.6Rakenduse konfiguratsiooniparameetrid tuleb ühte kohta kokku tuua nii, et nende muutmisel ei peaks rakendust uuesti kokku kompileerima (nt ühte tekstipõhisesse konfiguratsioonifaili, andmebaasi tabelisse).Rakendus peab neid sealt ka kasutama (mitte kopeerima parameetreid käivitamisel kolmandatesse kohtadesse), logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näit Log4net). Samuti on väga soovitatav eraldi konfiguratsioonifailis hoida arendaja ja administraatori vastutusala parameetrid. Infosüsteem peab olema seadistatav konfiguratsiooniparameetrite(de) abil. Konfiguratsioonifailiks ei saa lugeda faili, kus hoitakse lisaks konfiguratsioonile ka muud programmikoodi.ArendajaAdministraator
Testija
2.7Rakenduse taaskäivitus, konfiguratsiooni muutmine vms peab toimuma mõistliku aja jooksul.Maksimaalne aeg on 5 minutit. Kui rakendus vajab indekseeritud sisu ja see pole kättesaadav, siis peab rakendus väljastama selle kohta selge teate.ArendajaTestija
2.8

Kui rakendusel või mõnel selle komponendil on tihti kasutatav teenus ning sellel teenusel on aeglaselt laetav konfiguratsioon, siis tuleb:

a)       laadida konfiguratsioon ühekordselt ja korduvkasutada seda;

b)      konfiguratsiooni automaatselt ja regulaarselt värskendada; regulaarsuse tarbeks peab saama määrata intervalli, millise aja järel või täpsed kellaajad, millal konfiguratsiooni värskendatakse;

c)       luua võimalus värskendada konfiugratsiooni käsitsi.

Näiteks digidoc4j teegi korral laetakse TSL nimekiri välisvõrgust, mis on aeglane.

Arendaja

Arhitekt

Testija

Administraator

2.9Rakendus peab kasutama 64-bitist arvutiarhitektuuri kui ei ole kokku lepitud teisiti.
Arendaja

Administraator

Arhitekt

2.10Kõik andmed, andmebaasid, SQL skriptid ja rakendus peavad kasutama UTF-8 kodeeringut. Kokkuleppel TEHIK arhitektiga on lubatud erandid.
ArendajaAdministraator
Testija
2.11Failisüsteemi salvestamisel ei tohi ühte kausta tekkida üle 10000 faili.Failid peab katalogiseerima kokkulepitud tunnuste alusel (nt aasta, kuu, kuupäev).ArendajaAdministraator
2.12Ühest andmetabelist teise viitamisel tuleb kasutada väliseid võtmeid (Foreign key).
ArendajaArhitekt
2.13Kõik välised võtmed (Foreign Key) peavad olema indekseeritud.Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded rakenduse jõudlusele oleksid täidetud ka tulevikus. (1, 3, 5 või 10 aasta pärast – vastavalt planeeritud kasutusajale).ArendajaArhitekt
2.14Tuleb kasutada päringumuutujaid (Parameter Binding)SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation)ArendajaArhitekt
2.15Kõigis andmebaasi tabelites peab olema defineeritud üks primaarvõti. Andmebaasi objektide nimetused peavad olema sisulised ja andma aimu nende otstarbest.Kasutada vastava andmebaasisüsteemi nimetamise parimaid praktikaid.ArendajaArhitekt
2.16

Andmebaasis defineeritakse üldjuhul kaks või enam kasutajat:

  • Rakenduse peakasutaja, kellena luuakse objektid ja skeemid.
  • Rakenduse piiratud õigustega kasutaja, kellena pöördub rakendusserver/rakendus.

Objektide loomiseks vajalikud õigused ja ressursid on loetletud rakenduse dokumentatsioonis.

Need õigused, mis on vajalikud ainult rakenduse baasi loomiseks, on eraldi välja toodud ja tuleb peale installi ära võtta. Karbitoodete puhul tuleb erisused läbi arutada TEHIK arhitektiga.ArendajaAdministraator
2.17Failide hoidmise asukoht lepitakse igakord kokku. Kuid failid ja failide indeks peavad olema replikeeritavad teise serveriruumi.Failide hoidmine klassikalises andmebaasis on kulukas ja seab kõrgendatud nõudmised ja piirangud andmebaasiserveritele. Lahenduse dokumentatsioonis tuleb ära tuua failide hoidmise asukoht.ArendajaArhitekt
2.18Peab olema minimiseeritud vajadus, et haldur teeb haldustoiminguid otse baasis. St rakendusel peab olema haldusliides, mille kaudu rakenduse haldur saab teha tavapäraseid haldustoiminguid.Halduri haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus.ArendajaTestija
2.19Rakendus peab olema võimeline kasutama keskkonnamuutujaid (serverinimi, kuu, päev jne).Näiteks logifailides.ArendajaTestija
2.20Andmebaas peab toetama nii külm- kui ka kuumvaru (peegeldamist) teise serviruumi.Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "MSSQL filestream").ArendajaArhitekt
2.21Sorteerimisreeglistik peab olema Eesti tähestikule vastav. Tõusutundlikkus peab olema välja lülitatud. Accent peab olema sisse lülitatud.Näiteks PostgreSQL puhul et_EE.ArendajaTestija
2.22Kui infosüsteemid saadavad e-kirju,  peavad nad kasutama välist e-mailiserverit. Kirja saatmisel peab rakendus veenduma, et e-mailiserver võttis meili vastu. E-kirjade vormindamine peab järgima interneti standardeid (RFC 5322).Saatja ja adressaadid, pealkiri ja sisu ei tohi olla rakendusse kodeeritud, vaid on muudetavad konfiguratsioonifaili kaudu. Genereeritud kirjade puhul peab tagama kirjade jälitatavuse (näiteks lisada X-päise kodeeritud kirje, milles on kirjeldatud, mis protsess/skriptifail/kasutaja kirja genereeris jms abistav info).ArendajaAdministraator
2.23Konfiguratsiooniparameetrite nimed peavad olema sisulised. Kui see ei ole võimalik, siis peab kõrval olema seletus.

Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne

ArendajaAdministraator
Testija
2.24Infosüsteemides on eessüsteemid (front end; presentatsiooni kiht) ja tagasüsteemid (back end; äriloogika kiht) arhitektuuriliselt selgelt lahutatud ja eraldi paigaldatavad.Koostöövõime raamistik 2011. Punkt 3.1. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste pakkumine. Tagasüsteemid ei tegele lõppkasutaja autentimise ja autoriseerimisega. Lõppkasutaja autoriseerimise tagavad eessüsteemid. Välise süsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Välise süsteemi taastumisel peab süsteem olema suuteline oma tööd jatkama taaskäivitamata.ArendajaArhitekt
2.25Konfiguratsioonifailid peavad olema vastavalt rakendusserveri tüübile vaikimisi kaitstud failidNäiteks IIS: *.config , *.resources Apache: *.conf, .htaccess.  Arendaja peab välja tooma konfifailide listi, kui neid on mitu.ArendajaAdministraator
2.26Rakenduse failid, mida kasutaja näha ei tohi, peavad olema vaikimisi kaitstud kaustades ja ei tohi olla veebi juurkaustas.Näiteks: IIS: Bin,App_Code, App_Data, App_Browsers, App_GlobalResources, App_LocalResources, App_Themes, App_WebReferencesArendajaAdministraator
2.27Konfiguratsiooniparameetrite taaskasutus. Erinevaid sama sisuga parameetreid ei tohi konfiguratsioonis eksisteerida.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid korra, mitte nii, et igas lõigus kirjeldatakse samu asju uuesti.

ArendajaAdministraator
Testija
2.28Kõik rakenduse liidesed peavad olema võimelised töötama  kõrgkäideldavalt.Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav lahendus on selline, mida saab samaaegselt käitada erinevates masinates.ArendajaAdministraator
2.29Klientrakendus ei tohi pöörduda otse andmebaasi poole.Tuleb kasutada rakendusservereid.ArendajaAdministraator
2.30Keskkonnapõhised muutujad peavad olema konfiguratsioonifailist seadistatavad.Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele.ArendajaAdministraator
Testija
2.31Eelistada tuleb tsentraalseid autentimislahendusi (nt TARA, AAM). Kui rakendus realiseerib ise autentimist, siis peab olema võimalik piirata ebaõnnestunud logimisi ajaühiku kohta (mobiil-ID, paroolid) ühelt IP-aadressilt.Eelistama peaks IP-aadressipõhist blokeeringut. Erandina tellijaga kokkuleppel võib kasutada captchat või konto lukustamist. Blokeeringute ajavahemikku ja logimiskatsete arvu peab saama konfiguratsioonifailist muuta.Arendaja

Arhitekt

Testija

2.32Rakenduse äriloogika tuleb realiseerida andmebaasist eraldi sõltumatus rakenduskihis.Andmebaas ei tohi sisaldada äriloogikat, mis muudab andmetabelites olevaid/sinna kirjutatavaid andmeid, va trigerid, mis tekitavad logi.ArendajaArhitekt
2.33Andmebaasis võib kasutada vaid ISO/IEC 9075 standardiga kaetud funktsionaalsusi. Lisaks ei tohi kasutada ka sama standardi osas 13 kirjeldatud funktsionaalsusi.

*Ei ole soovitav kasutada mingit platvormispetsiifilist lahendust, mille üleviimine mõnele muule andmebaasiplatvormile ei ole võimalik.
*ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis.

ArendajaArhitekt
2.34Kui rakendus eeldab eraldi kasutajate, rollide ja õiguste registri pidamist, siis peab rakendus kasutama Tellija tsentraalseid autoriseerimislahendusi.
Arendaja

Arhitekt

Testija

2.35Uniform resource identifier (URI) pikkus ei tohi ületada ühegi IS poolt toetatava brauseri maksimaalset lubatud väärtust.Harilikult on piiriks 2000 tähemärki, kuid iga IS puhul tuleb seda eraldi järele uurida sõltuvalt IS komponentidest. Asjakohased viited: RFC 3986 ja RFC 7239.Arendaja

Administraator

Testija

2.36Veebiteenuseid (REST, SOAP) pakkuv rakendus peab olema üles ehitatud nii, et see toetaks teenuste versioneerimist URL-i ja/või schema tasemel.

Näiteks WSDL puhul: Alajaotis definitions/types/schema:

* complexType defineerimisel tuleb sellele lisada any element.

ArendajaArhitekt
2.37Rakendus peab olema võimeline töötama koormusjaoturitega varustatud taristul.SSL offloadArendajaAdministraator
2.38Sidusinfosüsteemide mitte kättesaadavus ei tohi segada rakenduse töötamist. Sidusinfosüsteemidega andmevahetamisel tekkinud vead logitakse ja kasutajat hoiatatakse.

Sidussüsteemi tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Sidussüsteemi taastumisel peab süsteem olema suuteline oma tööd jatkama taaskäivitamata.

Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid väljastama mõistliku (võimalikult lühikese) aja jooksul ajakohase veateate. Võimalusel tuleb kasutada asünkroonseid liideseid.

Arendaja

Administraator

Testija

2.39Automaatselt käivituvaid taustatöid peab saama käsitsi (taas)käivitada.Vajalik juhuks, kui automaatsel käivitumisel on tekkinud viga ja/või taustatöö on pooleli jäänud. Pärast vea põhjuse korrigeerimist peab saama taustatöö uuesti käivitada.ArendajaTestija
2.40Kui ajastatult käivitatav taustatöö, ei ole mõeldud käima paralleelselt, peab selles olema realiseeritud kontrollmehhanism, mis tagab, et sama taustatööd ei ole võimalik käivitada uuesti enne, kui eelmisena käivitatud instants on oma töö lõpetanud.
Arendaja

Administraator

Testija

2.41Ühe tarkvarakomponendi raames ei tohi sama parameetri seadistamine toimuda rohkem kui ühes kohas.Näiteks kui rakenduse komponent pöördub andmebaasi või veebiteenuse poole, siis selle pöördumise parameetrid peavad olema muudetavad vaid ühes kohas.ArendajaAdministraator
2.42Uue toote arenduse ja olemasolevate infosüsteemide versiooniuuendustel kasutusele võetavate tehnoloogiate ja standardite valik tuleb kooskõlastada Tellija poolse arhitektiga
ArendajaArhitekt
2.43Rakenduse ühenduste (s.h. andmebaasi ja sidusinfosüsteemide ühendused) realiseerimisel tuleb kasutada ühenduste puulimist (connection pooling).Implementeeritud peab olema vähemalt maksimaalsete ühenduste arvu piirang ja päringu aegumise aeg (request timeout). Rakenduse ühenduste tõrge tohib mõjutada ainult sellest otseselt sõltuvate kasutuslugude toimimist. Ühenduste taastumisel peab rakendus olema suuteline oma tööd jatkama taaskäivitamata. Tekkinud vead logitakse ja kasutajat hoiatatakse.ArendajaArhitekt
2.44Rakenduse uuendustega kaasnevad andmebaasi muudatused tuleb automatiseerida.Näiteks Liquibase või Flyway.ArendajaAdministraator
3. Turvalisuse tagamisega seotud nõuded
3.1Asutuse siseseks kasutamiseks mõeldud rakenduse kasutajate autentimist peab saama teha Active Directory põhiselt.

Erandina tellija kooskõlastusel võib sellest loobuda ja kasutada vaid ID-kaardi ja mobiil-ID põhist autentimist. ID-kaardi puhul peab isiku sertifikaatide kehtivust saama kontrollida vastu OCSP ja CRL-i (vastavalt vajadusele).

ArendajaTurvatestija
3.2Kliendi ja serveri vahel peab autenditud kasutajasessioonide korral olema sessioon krüpteeritud HTTPS-protokolli kasutades.
ArendajaTurvatestija
3.3SSL veebiserver peab kasutama turvalisi ja SSL/TLS versioone ja šifrikomplekte

Protokolli krüpto tugevust saab kontrollida lehel https://www.ssllabs.com/ssltest/

AdministraatorTurvatestija
3.4Rakendus tohib kasutada vaid sessiooni küpsiseid (cookies). Muude küpsiste kasutamine on keelatud.
ArendajaTurvatestija
3.5Kui andmebaasis olevate andmete ISKE tervikluse turvaosaklass on 3 (kõrge), siis tuleb kõik andmebaasi kirjed/tabelid versioneerida.

St kõik andmemuudatused peavad baasis säilima. Andmete muutmisel  andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana muudetakse kehtetuks. Iga uus kirje peab sisaldama järgmist informatsiooni:

*viide kirjele, mille ta kehtetuks muutis (kui on)

*kasutaja, kes kirje lõi

*kirje loomise aeg

*sessiooni-ID (kui on olemas). Iga kehtetuks tunnistatud kirje peab omama järgmist informatsiooni:

*kasutaja, kes kirje kehtetuks tunnistas 

*kirje kehtetuks tunnistamise aeg.

Arendaja

Turvatestija

Arhitekt

3.6Rakendusega peab kaasas olema lahendus, mis suudab toota toodangu andmetest testandmed, mis ei sisalda konfidentsiaalset informatsiooni.Testandmed peavad säilitama kõik toodangu andmete omadused (pikkuse, tüübi) ja omavahelised suhted. Täpsem vajadus ja tegevusplaan tuleb koostada TEHIKu arhitekti ja tooteomanikuga.ArendajaArhitekt
3.7Andmebaasis olevate rakenduse kontod peavad omama ainult minimaalselt rakenduse tööks vajalikke õiguseid.Ei resource, dba, ANY ega muud sellist. Nõude täitmiseks vajalikud vahendid (skriptid) peavad kuuluma rakenduse juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse installijuhendis.

Arendaja

Administraator

Turvatestija
3.8Rakendusse ja andmetele tohib olla ligipääs vaid dokumenteeritud ja tellimuses kirjeldatud teid mööda ning dokumenteeritud autentimisprotseduure kasutades.St rakendustes ega andmebaasides ei tohi olla ligipääsemiseks teisi võimalusi.ArendajaTurvatestija
3.9Kõik paroolid ja salaküsimuste vastused peab rakendus salvestama vaid räsitud+soolatud. Kui räsimise asemel valitakse krüpteerimine, siis tuleb kirjeldada krüptovõtme turvalise hoidmise protseduur.Hetkel kehtivad nõuded saab TEHIKu arhitektilt. Arendaja loodud lahenduse dokumentatsioonis (nt detailanalüüs vms) peab olema ära toodud kasutatavad räsi ja krüptoalgoritmid, võtmepikkused ja nende kasutuskohad (vt nõue p 1.10)ArendajaTurvatestija
3.10Rakendused, kuhu saavad ligi välised kasutajad, peavad võimaldama sisselogimist ID-kaardi ja mobiil-ID-ga. Paroolipõhist autentimist ei tohi kasutada.Kui on vajalik ka parooliga logimine, peavad  välised kasutajad autentima ennast AD pihta. Vajadus tuleb kooskõlastada TEHIKu arhitektiga.ArendajaTurvatestija
3.11Mobiil-ID autenimise korral tuleb lisaks kasutaja telefoninumbrile küsida ka kasutaja isikukoodi.Veebilehel kuvatav kontrollkood peab olema selgelt nähtav, sh ka nutitelefonidel ilma ekraanipilti kerimata.ArendajaTurvatestija
3.12Rakendus ei tohi teostada X-tee päringut otse kasutajaarvutist.Kasutajaarvutitest otse x-tee päringute tegemine on arvutivõrgu tasemel kinni.ArendajaTurvatestija
3.13Veebipõhised välise veebilehega rakendused peavad kasutama vahendeid kaitsmaks rakendust lubamatute päringute eest.IIS puhul peab  kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Lubamatud päringud on kõik päringud, mis ei ole detailanalüüsi käigus vastavalt kasutusjuhtudele ette nähtud. Kasutama peab whitelisting põhimõtet, mitte blacklisting.

Arendaja

Administraator

Turvatestija
3.14Rakendus peab sisenemisel näitama pärast õnnestunud sisselogimist eelmise õnnestunud sisselogimise aega. Kui on toimunud ebaõnnestunud sisselogimise katseid, siis peab kuvama ka, millal need toimusid, mitu neid oli ja mis IP-aadressilt pöörduti.Kasutaja peab saama soovi korral veenduda, kas keegi pole tema nime all vahepeal sisse loginud. Ebaõnnestunud logimiste katsete kuvamise nõue kehtib juhul, kui autentimine ja autoriseerimine lahendatakse rakenduses lokaalselt.ArendajaTurvatestija
3.15Kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega.ArendajaTurvatestija
3.16Krüpteerimise ja/või räside arvutamise korral tuleb kasutada tugevaid algoritme.Järgida tuleb uusimat RIA kodulehel avaldatud krüptograafiliste algoritmide kasutusvaldkondade ja elutsükli uuringut. Lahenduse dokumentatsioonis tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad.ArendajaTurvatestija
3.17Autenditud sessiooni tunnust ei tohi ainult lihtsa küpsisega lahendada (tunnus peab olema krüpteeritud).Sessiooni ei tohi olla võimalik üle võtta sessioonitunnuse kopeerimisega ühest arvutist teise.ArendajaTurvatestija
3.18LDAP lahenduse (nt AD) kasutamisel peab rakendus kasutama kontoga kaasnevaid piiranguparameetreid.Näiteks: konto on lukus, parool aegunud, konto aegunud, paroolipoliitika jne.ArendajaTurvatestija
3.19Tagada tuleb rakenduse rollide lahusus.Peakasutajal ja tavakasutajal on erinevad tööülesanded. Rollide/õiguste kirjeldus peab lähtuma detailanalüüsist ja kasutusjuhtudest.ArendajaTurvatestija
3.20ID-kaardiga autentimisel, peab rakendus suutma vastu võtta ID-kaardi sertifikaati ka päises.Proxy tugiArendajaTurvatestija
3.21Kui kasutajaid hallatakse ka rakenduses ja autenditakse AD või  AAM-i vahendusel, tuleb sisselogimisel kõigepealt kontrollida kasutaja olemasolu rakenduses ja alles siis pöörduda AD või AAM-i poole.Eesmärk vähendada AD ja AAM-i koormust.ArendajaTurvatestija
3.22Arendus peab olema orienteeritud toodangukeskkonnas toimimiseks.Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis toodangu keskkonnas on ebavajalikud või segavad (näiteks kasutuseta funktsionaalsus ja komponendid, mõeldud testimiseks testkeskkonnas, arendusabiks arenduskeskkonnas jne).ArendajaTurvatestija
3.23Rakendus ei tohi lubada ühe kasutajaga mitut samaaegset sessiooni.Juhul kui lähteülesanne spetsiaalselt ei ütle teisiti.ArendajaTurvatestija
3.24Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema kas ajatembeldatud, digiallkirjastatud või digitembeldatud.Milline lahendus valitakse tuleb kokku leppida tellijaga. Täpsustuseks vt ISKE nõue HT.34. Vt ka nõuet 3.28.ArendajaTurvatestija
3.25Kui lahendus peaks kasutama ajatempli teenust, siis tuleks eelistada Guardtime lahendust.Ajatempli kasutamise vajadus lepitakse eraldi kokku Tellija IT juhiga ja infoturbejuhiga. See sõltub Tellija keskse ajatempli kasutamise võimalustest.ArendajaTurvatestija
3.26Kui rakenduse tervikluse turvaosaklass on T3, peavad tõestusväärtust omavad andmed olema krüptoaheldatud, et tagada et tõestusväärtusega andmeid ei saaks märkamatult kustutada.Täpsustuseks vt ISKE nõue HT.10. Krüptoahela kasutamise vajadus lepitakse eraldi kokku Tellija infrastrktuuri juhiga ja infoturbejuhiga. See sõltub Tellija keskse krüptoahela kasutamise võimalustest.ArendajaTurvatestija
3.27Kui rakenduses on S3 salastuse astmega andmeid, peavad need olema nii transpordi ajal ja ka salvestatult alati krüpteeritult.Täpsustuseks vt ISKE nõue HT.37.ArendajaTurvatestija
3.28

Veebirakendus ei tohi jätta sulgemisel kasutaja tööjaama maha ajutisi faile.
Paksu kliendi korral ei tohi rakendus kasutaja tööjaama jätta maha krüpteerimata kujul ajutisi faile, mis sisaldavad või võivad sisaldada konfidentsiaalse või kõrget terviklust nõudvat informatsiooni.

Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline  kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. Nõude eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks, sh pääsuandmeid, isikuandmeid, andmekogu sisulisi andmeid jmsArendajaTurvatestija
3.29Rakendus ja selle komponendid peavad võimaldama kasutada keskkondade lahusustArendaja arendab arenduskeskkonnas ja annab tarne üle tellijale paigalduspakkidena. Tellija paigaldab selle testkeskkonda ja testib ning seejärel paigaldab tarne toodangu keskkonda. Reaalseid andmekogu andmeid tohib töödelda üksnes toodangu keskkonnas.ArendajaTurvatestija
3.30Rakendus peab võimaldama hõlpsalt välja vahetada aegunud ja ebaturvalise krüptoalgoritmi.Krüptograafiat kasutav rakenduskood ei tohi nimeliselt välja kutsuda krüptograafilisi algoritme, vaid peaksid seda tegema vahendavate vaheteekide kaudu üldiste funktsioonide järgi (nt krüpteerimine, dekrüpteerimine, signeerimine, signatuuri verifitseerimine jne). Dokumentatsioon peab kajastama üldist kirjeldust, kuidas vajadusel ebaturvaline krüptoalgoritm välja vahetada.ArendajaTurvatestija
3.31Rakenduse andmebaasi krüpteerimisega seotud andmeväljad peavad olema muudetava pikkusega.Andmebaasides kasutatavad krüpteerimisfunktsioonidest tingitud lisaväljad peaksid olema muudetava pikkusega, et formaati muutmata saaks kasutada teistsuguste parameetritega krüpteerimisalgoritme.ArendajaTurvatestija
4. Logimine, debuggimine, testimine
4.1Rakendusel peab olema masinloetav testleht (health check) nt JSON või XML formaadis.Testlehe kättesaadavus erinevatest arvutivõrkudest peab olema konfigureeritav. Testleht peab uuendama ennast lehe pärimisel. Testleht peab sisaldama custom built rakenduse versiooni numbrit, standardsed komponendid (veebiserver, andmebaas, CMS'id jms) ei tohi oma versioone reeta.   Samuti peab testlehel olema infot rakenduse (vajadusel tema erinevate osade) ja tema kõigi väliste liideste staatuse kohta (töötab, ei tööta).  Rakenduse, andmebaasi ja liideste töökorda kontrollitakse testpäringute teel, mis tuleb tellijaga kokku leppida eelanalüüsi käigus. Testleht peab oma konfiguratsiooni võtma rakenduse üldisest konfiguratsioonist (baasistring, välised ühendused).Arendaja

Arhitekt

Administraator

4.2

Rakendus peab pakkuma monitooringu lehte, kus leidub informatsioon rakenduse funktsionaalsuse toimimise kohta.


Näiteks Prometheuse formaadis monitooringu leht, kus näeb infot päringu kestuste kohta, veakoodide ja nende hulka. Rakenduse mälu kasutamist jne.Arendaja

Arhitekt

Administraator

4.3Rakenduse kõik üleantavad versioonid peavad enne tellijale üle andmist olema testitudTestitulemused tuleb edastada tellijale koos rakenduse üleandmisega. Vaata lisaks nõuet 4.21 ja 4.22.ArendajaTestija
4.4Rakendus peab logima kasutaja edukat ja ebaedukat autentimist ja sessiooni lõpetamist, kasutaja IP ja autentimismeetodit (ID-kaart, mobiil-ID vms), eduka autendi puhul tuleks logida ka kasutaja isikukood ja mobiil-ID ning Smart-ID puhul telefoninumberLogima peab ka autentimise ebaõnnestumise koos põhjusega (vale parool, aegunud konto jne). Logida tuleks IP-aadress, meetod ja kui võimalik kasutajatunnus (mobiil-ID puhul telefoni number, ID-kaardi puhul isikukood). Kui rakendus kasutab kasutajate autentimiseks AAM-i või TARA, siis leppida projektijuhiga eraldi kokku autentimise detailsus ehk mis kajastatakse AAM-is või TARA-s ja mis rakenduses.ArendajaTestija
4.5Erinevate logifailide kirjeid peab olema võimalik seotud komponentide logidega loogiliselt kokku viia.Tegevuste sidumiseks peab olema võimalik logikirjeid siduda ühise välja abil. Selleks ei sobi kellaaeg ega IP. Sobib näiteks unikaalne ID, mis ei tohi olla sessiooni ID, sest seda saaks logist välja lugeda ja rünnakuks ära kasutada. Võib olla sessiooni ID räsi koos transaktsiooni ID'ga. Konkreetne lahendus tuleb valideerida TEHIKu arhitektiga.Arendaja

Arhitekt

Testija

4.6Rakendus peab suutma logida kõiki X-tee teenuste kaudu liikuvaid andmeid. Peab olema võimalus logimist sisse-välja lülitada.Vajalik eelkõige silumiseks ja toodangu keskkonna probleemide lahendamiseks.ArendajaAdministraator
Testija
4.7Logimiseks tuleb kasutada standardseid komponente kogu logiahela ulatuses.Näiteks java-s log4j/logback ... , transpordiks syslog, logi formaadiks JSON või CSV või tabeldus-eraldus. Failid peavad olema loetavad tekstilisel kujul. Logid peavad olema kujul, et neid saaks töödelda masinloetavalt ja inimloetavalt.ArendajaAdministrator
Arhitekt
4.8Andmete loomise/vaatamise/muutmise/kustutamise tegevused peavad olema kajastatud logides.Logikirjes peab sisalduma piisavalt informatsiooni, et vastata küsimustele kes, mida, kus, kust, millal, kuidas ja tulemus.Arendaja

Testija

Turvatestija

Infoturbespetsialist

4.9Logid peavad olema jaotatud loogiliselt.

Seansilogi - info sisselogimiste, väljalogimiste ja seansi aegumiste kohta. Vigased sisselogimise katsed. Info õiguste suurendamise kohta. Peab olema logitud ka tühja või puuduvate parameetritega logimise katsed.
Tegevuslogi - kogu informatsioon kasutajate tegevuste kohta koos tegevuse tüübi, seansi parameetrite (korreleerimaks seansi- ja tegevuslogi) ja kasutaja poolt esitatud sisendparameetritega (sh. väliste ressursside kasutamise kohta). Logida tuleb nii õnnestunud kui ka ebaõnnestunud tegevusi.
Tehniline logi - rakendusserveri poolt loodud logi
Vealogi - erinevate veaolukordade info
Silumislogi - arendajate jaoks vajalik debug info

ArendajaAdministraator
Testija
4.10Administraatorite ja haldurite poolt tehtavaid andmete vaatamised, muutmised sh kustutamised (ka otse baasis) tuleb logida.Lahendus peab tagama, et administraatorid/haldurid ei saa andmete vaatamise, muutmise logimist ise (ka tavakasutajate logimist) deaktiveerida või logisid kustutada/muuta.ArendajaInfoturbespetsialist
Testija
4.11Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega.Näiteks NULLArendajaTestija
4.12Logis tuleb kõik mitte kuvatavad (non-printable) sümbolid kodeerida.Näiteks reavahetused -> \n, non-printable sümbolid - 0x00..0x1f, 0x7f..0xff.ArendajaTestija
4.13Logides peab olema maksimaalselt üks sündmus ühel real.Mitme realiste sündmuste puhul kasutada kodeerimist või JSON formaati. Mitme realiste sündmused võivad olla tehnilises-, vea- või silumislogis kui rakendusserver ei oska seda kodeerida.ArendajaTestija
4.14Ühe ja sama sündmuse väljad peavad olema erinevatel logikirjetel samas järjekorras
ArendajaTestija
4.15Logida tuleb ka päringud, mille vastus on puhverdatud.
ArendajaAdministraator
Testija
4.16Logimine peab olema optimeeritud.Informatsiooni dubleerimist logides tuleb vältida, kui ei ole nõutud teisiti.ArendajaTestija
4.17Rakendusega peab olema kaasas skript jõudlustestide tegemiseks.Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud tarkvaralised vahendid kokkulepitud jõudlustestide läbiviimiseks. Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist.ArendajaArhitekt
Administraator
Testija
4.18Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.Logi sisaldab minimaalselt vea tekkimise aega, veakoodi, veakirjeldust (stack trace, traceback vms), võimalusel kasutaja andmeid, HTTP-, GET- ja POST-parameetrid ja nende väärtusi. Logimise detailsusrežiimi (info, warning, errog, debug) peab saama muuta.ArendajaAdministraator
Testija
4.19Rakenduse funktsionaalsuse kirjeldusega tuleb luua ka logimise dokumentatsioon ja loginäidised. Koos funktsionaalsuse arendamisega tuleb luua ka loodava funktsionaalsuse logimine ja selle dokumentatsioon.Mida logitakse, kuidas sündmused on logifailidesse jagatud, logiridade näited.ArendajaArhitekt
Administraator
4.20Logimisparameetreid peab saama muuta rakendust taaskäivitamata.Näiteks log4j konfiguratsiooni failis "monitoring-interval".ArendajaAdministraator
Testija
4.21Lahendus peab olema minimaalselt 75% ulatuses kaetud automaatsete komponenditestidega (unit test).  Käivitatakse tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse lähtekoodi analüsaatoris (nt SonarQube).ArendajaArhitekt
Testija
4.22Lahendus peab olema minimaalselt 50% ulatuses kaetud automaatsete vastuvõtutestidega.Käivitatakse tellija pideva integreerimise (CI) keskkonnas (nt Gitlab) ja kaetust raporteeritakse lähtekoodi analüsaatoris (nt SonarQube).ArendajaArhitekt
Testija
5. Nõuded rakenduse lähtekoodile
5.1Lähtekoodi kommentaarid peavad kõigis lahenduse kihtides (rakenduse enda kood, andmebaas jne) olema kirjutatud inglise keeles.NB! Nõuet ei arvestata arendustarkvara poolt automaatselt genereeritavate koodilõikude puhul – neid ei ole vaja tõlkida. Samuti ei rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile – nt igasugu erinevad lahtise koodiga koodilõigud jms. Kui on tegu olemasoleva süsteemi edasiarendusega, siis peaks kommentaarides kasutama eelnevalt kasutatud keelt.ArendajaArhitekt
5.2Lähtekoodi kommentaarid peavad olema selged, arusaadavad ja sisuliselt kirjeldama vastavat koodi, mille juures nad on ning moodustama vähemalt 20% koodi mahust.Rakenduse kood peab olema piisavalt hästi kommenteeritud, et erialast haridust omav tarkvaraarendaja on võimeline süsteemile jätkuarendusi teostama.ArendajaArhitekt
5.3Muutujate, tüüpide ja funktsioonide nimed peavad olema sisulised ja andma aimu nende otstarbest.Parim praktikaArendajaArhitekt
5.4Koodis kasutatavad konstandid ja lühendid tuleb kirjutada suurte tähtedega, lähtudes kasutatava programmeerimiskeele parimast praktikast.Nt Javas identifikaator --> IDArendajaArhitekt
5.5Koodis kasutatavaid konstante ei tohi selle kasutamise kohta väärtusena hardcodeda – need tuleb defineerida muutujatena ja kasutada läbi nende.
ArendajaArhitekt
5.6Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses (st igasugu collectionid, arrayd, jms).N:Isik; Menetlus; jne. Andmebaaside struktuurikirjeldustes/andmemudelis ei tohi kasutada täpitähti.ArendajaArhitekt
5.7Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.Kasutada tuleb konkreetse andmebaasisüsteemi nimetamise parimaid praktikaid. Nt kui on tegu tabelitega ’Isikud’ ja ’Autod’, siis seos ’isiku autod’ oleks: Isikud.ID=Autod.Isik_IDArendajaArhitekt
5.8Andmebaasi väljade pikkused tuleb kirjeldada sümbolites, mitte baitides.Selle asemel, et eraldada väljale x baiti, tuleb eraldada x tähemärki. (Instead of allocating x bytes of storage for the field, x chars of storage must be allocated).ArendajaArhitekt
5.9Kui kokku pole lepitud teisiti, siis JAVA rakenduse kood peab olema kirjutatud vastavalt  "Oracle Java Code convention" dokumendile.Checkstyle (http://checkstyle.sourceforge.net/) ei tohi käivitamisel järgmise konfiguratsioonifailiga väljastada ühtegi viga.ArendajaArhitekt
5.10Kui kokku pole lepitud teisiti, siis Python rakenduse kood peab olema kirjutatud vastavalt  "Style Guide for Python Code " dokumendilehttp://www.python.org/dev/peps/pep-0008/ArendajaArhitekt
5.11Kui kokku pole lepitud teisiti, siis .NET rakenduse kood peab olema kirjutatud vastavalt "NET Framework Developer's Guide - Design Guidelines for Developing Class Libraries".http://msdn.microsoft.com/en-us/library/ms229042.aspx Valideerimiseks kasutatakse 'StyleCop' vaikimisi konfiguratsiooniArendajaArhitekt
5.12Koodi valideerimiseks kasutatakse minimaalselt TEHIK-u Sonarqube teenust.ArendajaArhitekt
5.13Kasutuses mitteolev kood tuleb rakenduse lähtekoodist kõrvaldada.
ArendajaArhitekt
5.14Arendamisel kasutatakse DRY ja SOLID printsiipe

http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

ArendajaArhitekt
5.15Üleantavas koodis ei tohi olla paroole, mida on kasutatud arenduse käigusKehtib ka siis, kui need on välja kommenteeritud. Kõik sellised paroolid tuleb asendada fraasiga “<password>“.ArendajaArhitekt
5.16Rakenduste lähtekoodi tasemel ei tohi olla ühtegi sisse kodeeritud parameetrit, veateadet.Eelpoolmainitu haldamine toimub failis või andmebaasis.ArendajaArhitekt
6. Andmekvaliteet ja standardid
6.1Aadressiandmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Valitsuse määrusest "Aadressiandmete süsteem".

Liidestatakse maaameti X-tee teenusega.

https://www.riigiteataja.ee/akt/103102017005?leiaKehtiv

ArendajaStandardija
Testija
6.2Rakendus peab võimalikult palju informatsiooni eeltäitma automaatselt (kirje sisestamise kuupäev, kasutaja nimi jne).Välja arvatud logimisvormi lahtrid autentimiselArendajaTestija
6.3Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda  Vabariigi Valitsuse 10. Jaanuari 2008. a määrusest nr 11 "Klassifikaatorite süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit.
ArendajaStandardija
Testija
6.4Tervishoiuteenuste osutajate andmete kasutamisel peab kontrollima nende andmeid, sh tegevuslubade kehtivust Terviseameti Tegevuslubade registristLiidestatakse Terviseameti x-tee teenusegaArendajaTestija
6.5Tervishoiutöötajate andmete kasutamisel peab kontrollima nende andmeid Terviseameti tervishoiutöötajate registristLiidestatakse Terviseameti x-tee teenusegaArendajaTestija
6.6Meditsiiniandmete vahetamiseks tuleb kasutada meditsiiniandmete andmevahetuse standardit HL7

www.hl7.org   Vajadusel on lubatud ka teiste standardite kasutamine, kuid see tuleb tellijaga eraldi kokku leppida

ArendajaStandardija
Testija
6.7Tervise valdkonna klassifikaatorid peavad olema kooskõlas Tellija OID-ide ja publitseerimiskeskusegaVõimalusel tuleb kasutada olemasolevaid OID-e ja klassifikaatoreid, mida vajadusel täiendatakse või luuakse uued ning publitseeritakse samuti publitseerimiskeskuses http://pub.e-tervis.eeArendajaStandardija
Tellija
7. Kasutajaliides
7.1Kasutajaliidese kõik disainiotsused  peavad olema kooskõlastatud tellijaga enne nende realiseerimist
ArendajaProjektijuht
7.2Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega, sh nutiseadmetel (Android, IOS)Minimaalselt Internet Explorer, Mozilla Firefox, Chrome ja Safari arenduse testimise hetkel tootja poolt toetatud versioonid. Täpsemad nõuded dokumendis "Front-end arendusreeglid"ArendajaTestija
7.3Rakenduse värviskeem ja logo kasutamine peab vastama Tellija ametlikule visuaalsele identiteedile (CVI) ja disainijuhistele (UIG).Kui tegemist on struktuurfondide projektiga on lisaks nõutud ka vastav SF sümboolika. Tellija ametlikud CVI esitluspõhjad, logo kasutusjuhend ja kõik logod (ka jpg-na) küsida tellijalt.ArendajaTestija
7.4Kasutajaliidese kõik osad ja teated peavad olema eestikeelsed.Kui soovitakse juurde eraldi ka muid keeli, siis see on spetsifitseeritud hankedokumentidesArendajaTestija
7.5Avalikuks kasutamiseks tehtav rakendus peab olema graafiliselt skaleeruv ja mugavalt  kasutatav kõigi enamlevinud arvutite monitoride resolutsioonidega.Toetatud peavad olema vähemalt resolutsioonid: 1920x1200, 1920x1080, 1680x1050, 1600x1200, 1440x900, 1360x768, 1280x1024, 1280x960, 1280x800, 1280x768, 1152x864, 1024x768,  1024x600. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba.ArendajaTestija
7.6Sisemiseks kasutamiseks  tehtav rakendus peab olema graafiliselt skaleeruv ja mugavalt  kasutatav TEHIKu töökohasprofiilis loetletud resolutsioonides.

Toetatud peavad olema töökohaprofiilis loetletud resolutsioonid. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba.

ArendajaTestija
7.7Hüpikaknaid (pop-up) ei tohi kasutada.Silmas on peetud uusi veebilehtiseja aknaid avavaid hüpikaknaidArendajaTestija
7.8Kasutajaliideses toiminguni (põhi- ehk enamkasutatavad tegevused) navigeerimiseks peab kehtima 3 kliki printsiip, väljalogimiseks 1 kliki printsiip.Kõik rakenduse kasutajaliidesest tehtavad toimingud tohivad üksteisest olla maksimaalselt 3 hiirekliki kaugusel. Toimingut ei pea nende 3 klikiga tehtud saama. Väljalogimise nupp/link peab olema ühe kliki kaugusel ja arusaadavas/intuitiivses kohas.ArendajaTestija
7.9Kasutajaliides peab alati küsima kinnituse andmete kustutamise  ja massmuutmiste kohta kui pole kokku lepitud teisiti.
ArendajaTestija
7.10Rakenduse kasutamisel tekkinud veale peab kasutajaliides vastama kasutajale eestikeelse kasutajasõbraliku veateatega, mis sisaldab soovituslikult ka vea koodi. Veateated peavad olema hallatavad.Veateated peavad olema sellised, mis võimaldavad IT-abil võimalikult lihtsalt tuvastada vea olemuse ja asukoha.ArendajaTestija
7.11Kasutajaliides peab olema ilma rakenduse koodi muutmata tõlgitav teise keelde, v.a kui ei ole kokkulepitud teisiti.Uue keele lisamine peab olema teostatav konfiguratsiooni failist või administreerimisliidesest.ArendajaTestija
7.12Rakenduse tausta, menüüde ja teksti värvid peavad olema ilma rakenduse koodi muutmata  vahetatavad.
ArendajaTestija
7.13Rakenduse kasutajaliides peab teavitama kasutajat ette sessioon aegumisest.Ette teavitamise aeg peab olema konfigureeritav.Arendaja

Administraator

Testija

7.14Kui vormile sisestatakse mahukaid andmevälju peab kasutajaliides kokku lepitud ajavahemike järel salvetama välja sisu, et sessiooni aegumisel või võrgu katkestuse korral juba sisestatud andmed ei kaoks.Kui vorm koosneb paljudest väiksest andmeväljadest (nt taotlus), siis jagatakse vorm etappideks ning salvestatakse vastava etapi lõpus.ArendajaTestija
7.15Sisestusvormidel andmete sisestamisel peab saama väljade vahel vastavalt äriloogikale liikuda klaviatuuri abil tabulaatoriga.
ArendajaTestija
7.16Interaktiivsete vormide puhul (näiteks faili üleslaadimine), ei tohiks lehe värskendamisega tegevust korrata (faili taas üles laadida, andmeid saata, avaldust esitada).
ArendajaTestija
7.17Kui päring võtab aega kauem kui 3 sekundit, peab kasutaja saama visuaalse teate, et süsteem tegeleb päringu läbiviimisega.Ikoon peab muutuma liivakellaks ja/või kuvatakse teade: päringut sooritatakse või muu tellijaga kokkulepitud indikaator.ArendajaTestija
7.18Esilehel (sisselogimata) ja ka pärast kasutaja sisselogimist peab olema lihtne võimalus teavitada kasutajat muudatustest või probleemidest. Teavitus peab olema halduri poolt lihtsalt lisatav ja olema kasutajale märgatav.Näiteks võimalikud teavituses: mingi süsteemi osa on vigane, tuli mingi uus funktsionaalsus, vahetage oma parool, uuendage isikuandmeid jne.ArendajaTestija
7.19Nutiseadmetele tuleb luua eraldi kohaldatud kasutajaliides.See vajadus spetsifitseeritakse arenduse tellimisel.ArendajaTestija
7.20Päringu vastusena kuvatud tabeli veerge on võimalik andmete/teksti tähestikulises järjekorras sorteerida.
ArendajaTestija
7.21Andmeväljade kohustuslikkus peab olema infosüsteemi väljadel märgitud tärniga (*).
ArendajaTestija
7.22Rakenduse andmeväljade mõisted peavad olema üheselt identifitseeritavad, korrektses eesti keeles (ilma kirjavigadeta) ja vajadusel sisaldama selgitavat teksti. Abiinfo (kasutusjuhendid) peab olema kättesaadav rakenduse toimimise erinevatel etappidel.
ArendajaTestija
7.23Kasutajaliides peab vastama ka dokumendis "Front-end arendusreeglid" kirjeldatud reegliteleFront-end arendusreeglid
Testija
8. Dokumentatsioon
8.1


Lõppkasutajatele ja avalikkusele suunatud rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.



Erandiks võivad olla kolmanda osapoole komponentide (mis pole kirjutatud tellija jaoks) dokumentatsioon. Samuti võib erandiks olla välispooltega seotud projektid. Erandid tuleb kooskõlastada tellijaga enne dokumentatsiooni koostamist



Arendaja


Projektijuht
Arhitekt
Administraator
Testija
Infoturbe spetsialist
8.2

Lahendus kirjeldatakse RIHA määruse nõuete kohaselt.


https://www.riigiteataja.ee/akt/12933746?leiaKehtiv#para6


ArendajaProjektijuht


ProjektijuhtRIHA haldur
Tellija RIHA haldur
8.3



Rakenduse dokumentatsioon peab vastama ka dokumendis "Nõuded infosüsteemi dokumentatsioonile" kirjeldatud nõuetele




Dokumentatsioon peab olema versioneeritud, muutmiskuupäevadega, autori nimedega, korrektse keelekasutusega, selge struktuuriga. Dokumentatsiooni detailsus peab olema piisav, et sõltumatu kolmas tehnliste IT baasteadmistega isik suudaks dokumendist vajalikke järeldusi teha (st dokument peab olema arusaadav sellele isikule, kuid näiteks paigaldusjuhise järgi toimetades ei pea ta ebaõnnestunud tarnele teostama veaanalüüsi).


Nõuded infosüsteemi dokumentatsioonile



Arendaja



Projektijuht
Arhitekt
Administraator
Testija
Infoturbe spetsialist
8.4Rakenduse dokumentatsioon  peab sisaldama tabelite-andmete-logide mahu kasvu arvestuslikku hinnangut rakenduse sihipärase kasutamise korral ettenähtud arvu kasutajate poolt. (MB/GB kuus/aastas).

Esialgne kirjete mahu hinnang peab tulema lähteülesandest, ning täpsustuma eel- ja detailanalüüsi käigus. Mahuhinnang peab sisaldama ka logide säilitamise, arhiveerimise tähtaegu.

ArendajaProjektijuht
Arhitekt
Administraator
Infoturbe spetsialist
8.5Iga uue versiooniga peab alati välja tooma versiooni muudatuse kirjeldused (release notes).Release notes peab kajastama kõiki muudatusi eelmise ja uue versiooni vahel.ArendajaProjektijuht
9. Versioonihaldus
9.1Kogu rakenduse testimiseks, koolituseks või implementeerimiseks üle antav lähtekood ja tarkvarapaketid peavad olema versioneeritud. Kasutama peab Tellija versioonihalduse ja tehiste (artifaktide) repositooriumi.Arendajale antakse selleks õigused Tellija versioonihalduse repositooriumi, kus ta peab hoidma oma erinevaid versioone. Versioonihalduse repositooriumi juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.ArendajaArhitekt
Administraator
9.2Arendaja peab veenduma, et teeb muudatusi aktuaalsesse koodi.

Hea tava on, et paralleelse arendamise puhul  võetakse igal hommikul versioonihalduse repositooriumist viimane seis koodist.

ArendajaArhitekt
Administraator
9.3Nii arendamisel kui ka hoolduslepingute korral kasutatakse Tellija tööde ja veahalduse keskkonda.Arendajale antakse selleks õigused Tellija tööde ja veahalduse keskkonda. Juurdepääsutaotlus esitatakse Tellija kasutajatoele läbi projektijuhi.ArendajaProjektijuht
10. Paigalduspaketi kooste
10.1Juhul kui versioonihalduse keskkond ei paku paigalduspaketile kontrollsumma (checksum) automaatset koostamist, siis koostatakse kontrollsumma arendaja poolt ja pannakse eraldi .sum failina tarnele kaasa.Räsialgoritmiks tuleb kasutada SHA256. Linuxi käsurealt kontrollkoodi koostamiseks: $ sha256sum filename [filename2] ... > kontrollkood.sum.ArendajaAdministraator
10.2Tarnitava lahenduse koosseisus üle antava lähtekoodiga peavad kaasas olema kirjeldused sellest paigalduspaketi koosteks.

Näiteks võib lahenduse paigalduspaketi koosteprotsess ette näha, et käivitada tuleb rida shell-käske või võivad lahenduse koosseisus olla valmis (ant, ..) koosteskriptid või mis iganes muu moodus paigalduspaketi tekitamiseks.

Eelistatud on kasutada Dockerfile ja Gitlab töövooge.

ArendajaProjektijuht
Administraator
10.3Kooste kirjelduste alusel valmiv paigalduspakett tohib sisaldada ainult minimaalse rakenduse käitamiseks vajamineva failikomplekti.

Näiteks: kompileeritavate keelte puhul ei tohi sisaldada lähtekoodi, kui see pole vajalik rakenduse käitamiseks.

ArendajaArhitekt
Administraator
10.4Kooste kirjelduste alusel valmivat paigalduspaketti peab olema võimalik liigutada erinevate masinate vahel.Näiteks ei tohi tekitada olukorda, kus rakenduse jooksutamiseks uues serveris tuleb see tingimata just sealsamas kokku kompileerida.ArendajaAdministraator
10.5Rakenduse kõik sõltuvused peavad olema kompileerimisel saadavad Tellija tehiste repositooriumist (repo.tehik.ee).
ArendajaArhitekt
10.6Andmebaasi paigalduse skriptid ei tohi olla kompileeritud.Administraator tahab veenduda skripti sisus.ArendajaAdministraator
10.7Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse keskkonnast sõltumatult (konteinerlahenduses) kokku kompileerimiseks.Tellijal peab olema võimalik suuri pingutusi tegemata ja keskkonna erinevusi vältides teha rakendusest paigaldatav pakk.ArendajaArhitekt
10.8Rakenduse lähtekoodi juures peab leiduma skriptid rakenduse lokaalselt mõnes konteinerlahenduses (Docker) käivitamiseks.Vajadusel peab konteinerlahendus käivitama ka rakenduse muud sõltuvused (näiteks andmebaas). See on Täitjale uue meeskonnaliikme liitumise lihtsustamiseks ja Tellijale võimalus suuri pingutusi tegemata süsteemi testimiseks.ArendajaArhitekt
10.9Paigalduspakett koostatakse Tellija pideva integratsiooni (continuous integration - CI) keskkonnas.

Erandid lepitakse kokku tellija arhitektiga.ArendajaArhitekt