Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega

lisa 3 - isikuandmete töötlemise nõuded volitatud töötlejale.pdf

Lisa 3 RMK ja OIXIO Digital AS vahelise lepingu nr 1-18/2026/25 juurde

ISIKUANDMETE TÖÖTLEMISE NÕUDED VOLITATUD TÖÖTLEJALE

(hiliseima digitaalallkirja kuupäev)

1. Üldine 1.1. Riigimetsa Majandamise Keskus (RMK) (edaspidi vastutav töötleja) edastab

OIXIO Digital AS (edaspidi volitatud töötleja) punktis 2.1 nimetatud andmed ja volitab volitatud töötlejat neid andmeid töötlema ainult juhul, kui andmete töötlemine on lepingust tulenevalt vajalik.

1.2. Käesoleva lisa eesmärk on kokku leppida volitatud töötleja õigustes ja kohustuses lepingu täitmise käigus saadud isikuandmete töötlemisel, millest pooled juhinduvad lepingu täitmisel.

1.3. Vastuolude korral lepingu ja käesoleva lisa sätete vahel tuleb juhinduda käesoleva lisa sätetest.

2. Isikuandmete töötlemise eesmärk ja kirjeldus 2.1. Vastutav töötleja kirjeldab ära isikuandmete töötlustoimingud tabelis 1, milles

sätestatakse: 2.1.1. andmete töötlemise eesmärgi/eesmärgid, milleks isikuandmeid vastutava

töötleja nimel töödeldakse; 2.1.2. andmesubjektide kategooriad, kelle isikuandmeid töödeldakse; 2.1.3. töödeldavate isikuandmete koosseisu; 2.1.4. töötlemise alused; 2.1.5. andmete säilitustähtajad.

Töötlemise eesmärk 

Andmete kategooriad 

Andmete koosseis  Töötlemise alused  Säilitustähtajad 

Töösuhte haldamine, palgaarvestus, palkade välja maksmine ja maksude deklareerimine 

Töölepingulised töötajad

Näiteks: ees- ja perekonnanimi, isikukood, ametikoht, tööle asumise kuupäev, töölepingu lõpetamise kuupäev, IBAN, brutopalk, maksuvaba tulu määr, töötasude ja maksude arvestus, toetuste ja hüvitiste või muu väljamaksed

GDPR art 6(1)(b), (c); Töölepinguseadus, Tulumaksuseadus, Raamatupidamise seadus, Keskmise töötasu määrus 

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele  ning vastavalt töölepinguseadusele 10 või 50 aastat

Leingute haldamine, tasude väljamaksmisne ja maksude deklareerimine

RMK töötajaskond (va töölepingulised töötajad)

Näiteks: ees- ja perekonnanimi, isikukood, lepingu ese, lepingu alguskuupäev, lepingu lõpetamise kuupäev, IBAN, väljamakstava tasu liik, väljamakstav summa, maksuvaba

GDPR art 6(1)(b), (c); Töölepinguseadus, Tulumaksuseadus, Raamatupidamise seadus

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele 

tulu määr, tasu ja maksude arvestus

Kontaktandmete haldamine 

RMK töötajaskond 

Näiteks: e-post, telefoninumber, elukoha aadress 

    GDPR art 6(1)(b), (f); Töölepinguseadus   

Kuni 1 aasta pärast töösuhte lõppu 

    Puhkuste ja tööaja arvestus   

Töölepingulised töötajad, juhatuse liikmed 

Näiteks: tööajaarvestuse info, puhkuste liigid ja kestus, tasu maksmise eelistus, puhkuse liigi kasutamise õigust tõendav info 

GDPR art 6(1)(b); Töölepinguseadus, Keskmise töötasu määrus, Riigieelarvest hüvitamise kord 

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele 

Töövõimetuse ja hoolduslehtede haldamine 

Töölepingulised töötajad

    Näiteks: arstitõendid, töövõimetuse algus- ja lõppkuupäevad, tööõnnetuse toimumine   

GDPR art 9(2)(b); Töölepinguseadus, Ravikindlustuse seadus, Riigieelarvest hüvitatava puhkusetasu kord 

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele 

Hariduse, kvalifikatsiooni ja koolituste arvestus 

RMK töötajaskond 

Näiteks: haridust või selle omandmaist tõendavad dokumendid, koolituste info, kutsetunnistused 

GDPR art 6(1)(f); Täiskasvanute koolituse seadus, Töölepingu seadus 

Kuni 1 aasta pärast töösuhte lõppu 

Muud andmed, mille kogumiseks ja töötlemiseks on tööandjal õigustatud huvi 

RMK töötajaskond 

Näiteks: lähedased isikud, foto, tervisekontrolli andmed

GDPR art 9(2)(b); Töölepinguseadus, 

Reeglina kuni 1 aasta pärast töösuhte lõppu 

Töölähetuste ja kuluhüvitiste arvestus 

Töölepingulised töötajad, juhatuse liikmed 

Näiteks: lähetuse sihtkoht ja kestus, sõidukulud, majutuskulud, päevaraha, kuluarved 

GDPR art 6(1)(b), (c); Töölähetuse kulude määrus, Raamatupidamise seadus, Liiklusseadus 

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele 

Töötajate esindajate ja kollektiivsete suhete haldamine 

Usaldusisikud  Näiteks: usaldusisiku nimi, kontaktandmed, tasu 

GDPR art 6(1)(c); Töötajate usaldusisiku seadus, Kollektiivlepingu seadus 

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele 

Kutsehaiguste menetlemine

Töölepingulised töötajad, endine töötaja

Näiteks: nimi, IBAN, ametikoht, maksude arvestus vms

GDPR art 9(2)(b); Töölepinguseadus. Töötervishoiu ja tööohutuse seadus

7 aastat pärast viimast väljamakset vastavalt raamatupidamise seadusele 

Tabel 1. Isikuandmete töötlustoimingute tabel 3. Isikuandmete töötlemise kestus ja säilitamise nõuded 3.1. Volitatud töötleja töötleb isikuandmeid üksnes minimaalses vajalikus mahus ja lepingus

kindlaksmääratud aja jooksul, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva seaduse alusel.

3.2. Käesoleva lisa raames tuleb andmeid säilitada vastavalt tabelis 1 sätestatud ajale. Selle aja möödudes tuleb andmed volitatud töötleja süsteemidest kustutada.

3.3. Peale teenuslepingu lõppemist tuleb vastutava töötleja teave volitatud töötleja hallatavatest süsteemidest turvaliselt kustutada, küsides enne selleks vastutavalt töötlejalt kirjaliku kinnituse. Kinnituse küsimisel tuleb kirjeldada plaanitav turvalise kustutuse meetod.

4. Nõuded volitatud töötlejale 4.1. Volitatud töötleja on kohustatud kasutama ja töötlema tabelis 1 olevaid andmeid üksnes

lepingu täitmiseks ja vastutava töötleja dokumenteeritud juhiste alusel, välja arvatud juhul, kui volitatud töötleja on kohustatud teavet töötlema volitatud töötleja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab volitatud töötleja vastutavat töötlejat vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei ole olulise avaliku huvi tõttu volitatud töötleja suhtes kohalduva õigusega keelatud.

4.2. Volitatud töötleja peab täitma kõiki kehtivaid andmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning andmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja muid eeskirju.

4.3. Volitatud töötleja on kohustatud aitama vastutavat töötlejat järgmiste nõuete täitmise tagamisel, võttes arvesse andmetöötluse laadi ja volitatud töötlejale kättesaadavat teavet: 4.3.1. kohustus hinnata kavandatavate töötlemistoimingute mõju isikuandmete kaitsele

(edaspidi „andmekaitsealane mõjuhinnang“), kui teatava töötlemisviisiga kaasneb tõenäoliselt suur oht füüsiliste isikute õigustele ja vabadustele;

4.3.2. kohustus tagada isikuandmete õigsus ja ajakohasus, teavitades vastutavat töötlejat viivitamata, kui volitatud töötleja saab teada, et tema töödeldavad isikuandmed on ebaõiged või aegunud;

4.3.3. kohustus teavitada vastutavat töötlejat kohe, kui vastutava töötleja nõuded ja juhised lähevad volitatud töötleja arvates vastuollu isikuandmete kaitse üldmäärusega või kohaldatavate liidu või liikmesriigi andmekaitsealaste sätetega.

5. Alamtöötleja kaasamine 5.1. Volitatud töötleja ei telli käesolevate nõuete kohaselt vastutava töötleja nimel tehtavate

töötlemistoimingute tegemist alamtöötlejalt ilma vastutava töötleja eelneva kirjaliku eriloata. Volitatud töötleja esitab eriloa taotluse vähemalt 14 kalendripäeva enne kõnealuse alamtöötleja kaasamist koos teabega, mis on vajalik, et vastutav töötleja saaks loa kohta otsuse teha. Luba registreeritakse lepingu külge lisana.

5.2. Kui volitatud töötleja kaasab konkreetsete töötlemistoimingute tegemiseks (vastutava töötleja nimel) alamtöötleja, teeb ta seda lepinguga, millega kehtestatakse alamtöötlejale sisuliselt samad andmekaitsealased nõuded, mis on volitatud töötlejal käesolevate nõuete kohaselt.

5.3. Volitatud töötleja tagab, et alamtöötleja täidab volitatud töötleja suhtes käesolevaid nõudeid.

5.4. Volitatud töötleja jääb vastutava töötleja ees täielikult vastutavaks alamtöötleja nõuete täitmise eest vastavalt volitatud töötlejaga sõlmitud lepingule. Volitatud töötleja teavitab vastutavat töötlejat, kui alamtöötleja ei täida oma lepingulisi nõudeid.

6. Tehnilised ja korralduslikud meetmed, sealhulgas tehnilised ja korralduslikud

meetmed andmete turvalisuse tagamiseks 6.1. Volitatud töötleja kohustub tarvitusele võtma asjakohased tehnilised ja korralduslikud

meetmed lepingu alusel toimuva andmete töötlemise loata või ebaseadusliku töötlemise, juhusliku kaotamise või hävitamise või kahjustumise vältimiseks.

6.2. Volitatud töötleja tagab organisatsioonisisese metoodilise ja süstemaatilise infoturbe haldamise, eelistatult laialdaselt tunnustatud turvasmetoodika põhjal (nt ISO/IEC 27001, SOC2, CIS Security Controls, Eesti riiklik infoturbe standard E-ITS vms), sh rakendades: 6.2.1. infoturbe riskihalduse; 6.2.2. varahalduse, sh arvestades RMK varadega; 6.2.3. infoturbe rollide ja vastutuse kindlaksmääramine; 6.2.4. pääsuõiguste halduse; 6.2.5. turvaintsidentide halduse; 6.2.6. jätkuvuse halduse, sh oma tarneahela ulatuses; 6.2.7. tööjaamade ja teiste IT-seadmete ja tarkvarade tugevdamise ja

konfiguratsioonihalduse; 6.2.8. kahjurvara tõrje; 6.2.9. krüptograafiliste meetmete halduse; 6.2.10. auditilogi ja turvaseire olemasolu; 6.2.11. nõrkuse ja paigahalduse; 6.2.12. füüsiliste turvameetmete halduse; 6.2.13. turvameetmete perioodilise läbivaatuse (vähemalt kord aastas).

6.3. Kõik need infoturbe protsessid peavad tagama RMK varade konfidentsiaalsuse, tervikluse, käideldavuse ja organisatsiooni kohanemisvõime muutuvas küberohtude keskkonnas.

7. Andmete turvalisus edastamisel ja talletamisel 7.1. Volitatud töötleja on kohustatud hoidma lepingu täitmise käigus teatavaks saanud

andmeid rangelt konfidentsiaalsena ning mitte kasutama ega avaldama andmeid, mis tahes muul kui käesolevas lepingus sätestatud eesmärgil.

7.2. Konfidentsiaalse teabe edastamisel arvutivõrgu kaudu peab teave olema krüpteeritud turvalise krüptomeetme abil vastavalt kokkulepitud andmeedastuse viisile, kas: 7.2.1. rakenduste vahelisel suhtlusel üle API kasutades turvalist šifrikomplektiga TLS

(HTTPS) veebiseanssi; 7.2.2. inimkasutajale andmete jagamisel üle veebiliidese kasutades turvalist

šifrikomplektiga TLS (HTTPS) veebiseanssi; 7.2.3. kaugpääsuga andmete jagamisel kasutades VPN ühendust turvalise

konfiguratsiooniga; 7.2.4. e-kirjaga andmete edastamisel kasutades krüpteeritud manuseid (.cdoc).

7.3. Konfidentsiaalse teabe talletamisel (andmed jõudeolekus) peab rakendama turvalisi krüptomeetmeid. Näiteks kogu ketta krüpteerimine, mälupulga krüpteerimine, krüpteeritud andmebaas või andmebaasi kirjed.

7.4. Turvaline krüptomeede on lahendus, mis rakendab turvalist krüptoalgoritmi, võtmepikkust, krüptovõtme käsitlust, tarkvara jms. Valikul peab lähtuma uusimast RIA avaldatud krüptograafiliste algoritmide elutsükli uuringust (https://www.ria.ee/amet- uudised-ja-kontakt/uudised-pressikontakt/uuringud-ja- analuusid?view_instance=2&current_page=1&sort_property=1&sort_direction=desc# kruptouuringud).

7.5. Volitatud töötlejal pole lubatud edastada andmeid väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma vastutava töötleja sellekohase selgesõnalise kirjaliku nõusolekuta.

8. Pääsuhalduse meetmed 8.1. Volitatud töötleja on kohustatud oma töötajatele andma töödeldavatele isikuandmetele

juurdepääsu üksnes ulatuses, mis on vajalik lepingu täitmiseks, haldamiseks ja selle täitmise üle tehtavaks järelevalveks. Volitatud töötleja tagab, et isikuandmeid töötlema hakkavad volitatud isikud on kohustatud järgima isikuandmete töötlemise nõudeid või nende suhtes kehtivaid asjakohaseid seadusjärgseid konfidentsiaalsuskohustusi.

8.2. Juurdepääs RMK varadele, sh teabele on lubatud, vastavalt: 8.2.1. veebiliidese kaudu RMK rakenduses Microsoft Dynamics 365 Business Central;

8.3. Vastutava töötleja konfidentsiaalse teabega dokumentatsioon peab olema vastavalt märgistatud, kui vastav märgistus on juba seotud alusdokumentatsioonil või kui need juhised on vastutava töötleja poolt antud. Dokumentatsioonil saab kasutada märgistust: asutusesiseks kasutamiseks ning vastav viide õigusaktile või “RMK siseseks kasutamiseks”.

8.4. Vastutava töötleja süsteemides talletatud ja üksnes seal töötlemiseks mõeldud teavet ei tohi kopeerida volitatud töötleja süsteemidesse, kui ei ole kirjalikult kokku lepitud teisiti.

8.5. Vastutava töötleja konfidentsiaalsele teabele juurdepääsu jagamisel tuleb arvestada konkreetsete töötajate teadmisvajadusega ning rakendada minimaalõiguste printsiipi.

8.6. Juurdepääsu võimaldavat teavet (nt paroolid, PIN-koodid, salajased või privaatvõtmed, tookenid jne) tohib talletada ainult krüpteeritud kujul (nt tarkvaraline paroolihoidla, vault) või füüsiliselt kaitstud hoidlas (nt seifis).

8.7. Juurdepääsul peab kõikidele kasutajatele jõustama mitmetasemelised autentimisviisid ja keelama üksnes ühetasemelised autentimisviisid.

8.8. Vastutava töötleja süsteemides loodud kasutajakontosid võib kasutada ainult volitatud töötleja töötaja, kellele nimeline konto on loodud ja kellele on pääsuõigused üle antud. Konto jagamine on keelatud.

8.9. Volitatud töötleja peab vastutavat töötlejat viivitamata teavitama kasutajakonto sulgemisese vajadusest, kui mõni volitatud töötleja töötajatest on töölt lahkunud, ei ole enam seotud lepingu täitmisega või pääsuandmed on sattunud ohtu (nt lekkinud).

9. Töötluskoha füüsilise turbe meetmed 9.1. Vastutava töötleja konfidentsiaalset teavet tohib töödelda ainult nendes ruumides, kus

on tagatud piisav kaitse füüsiliste turvaohtude eest, näiteks seadme vargus või volitamata juurdepääs, ekraani või klaviatuuri jälgimine jms.

10. Andmete kvaliteedi tagamise meetmed 10.1. Volitatud töötleja peab vastutava töötleja konfidentsiaalset teavet töötlema viisil, et

andmete õigsus, täielikkus ja ajakohasus oleks tagatud. Võimalusel peab rakendama sisendandmete valideerimist, töödeldud andmete testimist ja kindlustama volitatud töötleja poolt kasutatava tarkvara korrektne toimimine.

11. Sündmuste logimine ja seire 11.1. Volitatud töötleja tagab konfidentsiaalse teabe töötlemisega seotud revisjonlogi (audit

logi) olemasolu ja pideva turvaseire. 11.2. Logisid peab säilitama 2 aastat. 12. Jätkuvuse ja muudatuse meetmed 12.1. Volitatud töötleja teavitab vastutavat töötlejat kirjalikult kõigist muudatustest, mis

võivad mõjutada volitatud töötleja võimet või väljavaateid pidada kinni käesolevast

lisast ja vastutava töötleja kirjalikest juhistest. Pooled lepivad kõigis käesolevat lisa puudutavates täiendustes ja muudatustes kokku kirjalikult.

12.2. Volitatud töötleja tagab oma teenuste kättesaadavuse, arvestades võimalike probleemidega enda tarneahelas.

12.3. Vastutava töötleja poolsel pärimisel annab volitatud töötleja teavet oma toodetes kasutatavatest süsteemi-komponentidest ja turvafunktsioonidest.

12.4. Teenuseid mõjutavatest muudatustest ja võimalikest plaanilistest katkestustest antakse vastutavale töötlejale teada enne muudatust või katkestust.

13. Turvameetmete teavitus ja kontroll 13.1. Vastutav- ja volitatud töötleja peavad suutma tõendada käesolevate nõuete täitmist. 13.2. Volitatud töötleja peab võimaldama vastutaval töötlejal või tema poolt volitatud

audiitoril teha auditeid ja kontrolle ning panustama nendesse. 13.3. Vastutav- ja volitatud töötleja teevad auditi käigus saadud teabe ja auditite tulemused

taotluse korral kättesaadavaks pädevale järelevalveasutusele. 13.4. Volitatud töötleja tagab oma töötajate teavitamise käesolevatest turvameetmetest. 13.5. Volitatud töötleja tagab iseseisvalt enda ja alltöövõtjate organisatsioonis pideva

turvameetmete rakendatuse kontrolli. 13.6. Volitatud töötleja organisatsioonisisest infoturbehaldust peab auditeerima sõltumatu

osapool vähemalt üks kord aastas. Selle korraldab volitatud töötleja. 13.7. Tunnustatud turvasertifikaadi (nt ISO/IEC 27001, SOC2) või auditiaruande (E-ITS

auditi aruanne) korral ei pea eraldiseisvat sõltumatud auditit lisaks läbi viima, kui sertifikaat või auditi aruanne: 13.7.1. on kehtiv; 13.7.2. käsitlusala katab ära RMK varadega seotud teenused või tooted; 13.7.3. tehakse vastutavale töötlejale kättesaadavaks.

13.8. Võimalikud erandid ja kõrvalekalded nimetatud meetmetest tuleb kirjalikult kooskõlastada vastutava töötlejaga enne erandi rakendamist.

13.9. RMK võib igal ajahetkel kontrollida ja auditeerida nimetatud turvameetmete rakendatust ja volitatud töötleja peab seda toetama.

14. Andmetega seotud rikkumisest teavitamine 14.1. Volitatud töötleja teavitab vastutavat töötlejat andmetega seotud rikkumistest või kui on

alust kahtlustada, et selline rikkumine on aset leidnud, ilma põhjendamatu viivituseta alates hetkest, kui volitatud töötleja või tema poolt kasutatav alamtöötleja saab teada andmetega seotud rikkumisest või on alust kahelda, et selline rikkumine on aset leidnud, kuid mitte hiljem kui kakskümmend (20) tundi pärast sellest teada saamist.

14.2. Volitatud töötleja teeb vastutava töötlejaga igakülgset koostööd turvaintsidentide käsitlemisel, sh analüüsimisel, isoleerimisel ja normaalse olukorra taastamisel.

14.3. Volitatud töötleja peab oma sisemised lahendused ja protsessid korraldama selliselt, et intsidendi korral vastutava töötlejaga seotud äriprotsessid ja -teenused toimiksid võimalikult vähese häiringuga.

14.4. Vastutava töötleja nõudmisel peab volitatud töötleja ilma põhjendamatu viivituseta edastama vastutavale töötlejale kogu andmetega seotud rikkumist puudutava asjakohase informatsiooni.

14.5. Teates tuleb kirjeldada vähemalt järgmist: 14.5.1. toimunud andmetega seotud rikkumise laad, andmesubjekti kategooriad ja

ligikaudne arv ning isikuandmete liigid ja ligikaudne arv; 14.5.2. eeldatav kuupäev ja kellaaeg; 14.5.3. isikuandmetega seotud rikkumise tõenäolised tagajärjed;

14.5.4. volitatud töötleja asjakohase kontaktisiku nimi ja kontaktandmed, kellelt saab täiendavat informatsiooni;

14.5.5. meetmeid, mida volitatud töötleja rikkumise lahendamiseks on tarvitusele võtnud või võtab, et vältida andmetega seotud rikkumisi tulevikus, ja vajaduse korral ka meetmeid, mille abil leevendada rikkumise võimalikke negatiivseid mõjusid;

14.5.6. esitama muud teavet, mis on mõistlikult nõutav, et vastutav töötleja saaks täita kohaldatavaid andmekaitsealaseid nõudeid, sealhulgas riigiasutustega seotud teavitamise ja avaldamise kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks;

14.5.7. Juhul kui kogu teavet ei ole võimalik esitada korraga, peab esialgne teade sisaldama sel ajal kättesaadavat teavet ning täiendav teave esitatakse viivituseta pärast selle saamist.

14.6. Teavet andmetega seotud rikkumistest ja turvaintsidentide kohta loetakse konfidentsiaalseks ja see tuleb edastada krüpteeritult.

14.7. Teavitus tuleb edastada: 14.7.1. E-posti aadress: [email protected]; 14.7.2. telefon: +372 676 7000.

14.8. Vastutav töötleja teavitab vajadusel kolmandaid osapooli, avalikkust ja järelevalveasutusi, sh Andmekaitse Inspektsiooni, Riigi Infosüsteemi Ametit ja Politsei- ja Piirivalveametit. Volitatud töötleja ei teosta avalikku suhtlust osas, mis võimaldab tuvastada vastutavat töötlejat ja tema kliente.

15. Lõppsätted 15.1. Kui volitatud töötleja ei täida käesolevatest nõuetest tulenevaid kohustusi, võib vastutav

töötleja anda volitatud töötlejale korralduse peatada isikuandmete töötlemine seniks, kuni volitatud töötleja järgib käesolevaid nõudeid või leping lõpetatakse. Volitatud töötleja teavitab vastutavat töötlejat viivitamata, kui ta ei suuda käesolevaid nõudeid mis tahes põhjusel täita.

15.2. Vastutaval töötlejal on õigus lõpetada leping , kui: 15.2.1. vastutav töötleja on volitatud töötleja poolse isikuandmete töötlemise punkti

15.1 kohaselt peatanud ja kui käesolevaid nõudeid ei hakata järgima mõistliku aja jooksul või hiljemalt ühe kuu jooksul pärast peatamist;

15.2.2. volitatud töötleja rikub oluliselt või jätkuvalt käesolevaid nõudeid või isikuandmete kaitse üldmäärusest tulenevaid nõudeid.

15.3. Volitatud töötlejal on õigus lõpetada leping isikuandmete töötlemise osas pärast seda, kui ta on vastutavat töötlejat punkti 4.3.3 kohaselt teavitatud, et tema juhised lähevad vastuollu kohaldatavate õigusnõuetega, kuid vastutav töötleja nõuab nende juhiste järgimist.

15.4. Pärast lepingu lõpetamist kustutab volitatud töötleja vastutava töötleja valikul kõik vastutava töötleja nimel töödeldud isikuandmed ja kinnitab vastutavale töötlejale, et ta on seda teinud, või tagastab kõik isikuandmed vastutavale töötlejale ja kustutab olemasolevad koopiad, välja arvatud juhul, kui seaduses kohaselt nõutakse isikuandmete säilitamist. Volitatud töötleja jätkab nendele nõuetele vastavuse tagamist seni, kuni andmed kustutatakse või tagastatakse.

raamleping_oixio digital as.asice

Digiallkirjad

Allkirjade kehtivust ei ole kontrollitud.

KAIRI KALLAS PNOEE-47901204910 2026-02-11 13:51:24

LIIE STRENZE PNOEE-47704160259 2026-02-12 14:27:17

lisa 1 - tehniline kirjeldus.pdf

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

1

LISA 1 – TEHNILINE KIRJELDUS 1. Hanke eesmärk ja üldised tingimused 1.1. Käesoleva hanke eesmärgiks on sõlmida raamleping ühe pakkujaga, kes hakkab juurutama RMK

(Hankija) personali- ja palgaarvestuse ja iseteeninduse lahendust (lisaks võimalikud lisaarendused). Hankega on hõlmatud lisaks koolitused ning tugi- ja hooldusteenus ning pakkuja lahenduse spetsiifilised litsentsid.

1.2. Eesmärgiks on võtta kasutusele ühtne MS Business Central HRM4Baltics personali- ja palgaarvestuse ja iseteeninduse tarkvara lähtuvalt HD Lisast 1 ja 2.

2. Tehnoloogilised nõuded 2.1. Tarkvara peab olema liidestatav hankija poolt kasutusel olevate ning tulevikus kasutusele

võetavate infosüsteemidega. Hanke väljakuulutamise hetkeks olevad infosüsteemid on kirjeldatud HD Lisas 2 (funktsionaalsusnõuded) ning Lisas 2.1.

2.2. Arendus- ja testkeskkondades kasutatakse ainult testandmeid. Andmetöötluse vajaduse ilmnedes LIVE (siin ja edaspidi tähenduses: töökeskkond, kus lahendus on hankijale kättesaadavaks tehtud) keskkonnast antakse töödeldavad andmed reeglina hägustatud või muul viisil anonümiseeritud kujul (v.a. juurutusperioodil).

3. Üldised nõuded tarkvarale Lahenduse funktsionaalsed nõuded on detailselt kirjeldatud HD Lisas 2 (funktsionaalsusnõuded). 3.1. Funktsionaalsuse ulatus ja kvaliteet:

3.1.1. Tarkvara peab katma kõik hanke alusdokumentides nõutud funktsionaalsused või pakkuma vähemalt samaväärset funktsionaalsuse taset.

3.1.2. Infosüsteem peab sisaldama mooduleid töötajate iseteeninduseks, personalihalduseks, palgaarvestuseks ja tööjõu planeerimiseks.

3.2. Äriprotsesside automatiseerimine: 3.2.1. Tarkvara peab sisaldama tööriistu äriprotsesside automatiseerimiseks, personali- ja

palgaarvestuse protsessis. 3.2.2. Peab võimaldama töövoogude loomist ja kohandamist, mis toetavad ettevõtte konkreetseid

äriprotsesse. 3.2.3. Moodulid peavad olema omavahel seotud (st standardlahenduses järgitakse läbivalt ühe

kliki põhimõtet eesmärgiga maksimeerida automatiseerimine ning tekitada protsessides efektiivsus). Andmesisestus peab olema läbivalt üle tarkvara ühekordne, st andmed on kasutatavad/kuvatavad teises moodulis (nt iseteeninduses või personalimoodulis sisestatud andmetest vajalikud väljad on nähtavad tööaja- ja palgaarvestuse moodulites).

3.3. Skaleeritavus ja paindlikkus: 3.3.1. Süsteem peab olema skaleeritav vastavalt hankija kasvavatele või kahanevatele

vajadustele ning toetama kohandusi ja konfiguratsiooni muudatusi vastavalt hankija spetsiifilistele nõuetele.

3.4. Pilvepõhisus ja turvalisus: 3.4.1. Tarkvara peab olema pilvepõhine lahendus, mis tagab kõrge turvalisuse ja andmete

kättesaadavuse. 3.4.2. Peab olema saadaval ülemaailmselt ja vastama EL-i isikuandmete kaitse üldmäärusele

(GDPR). 3.4.3. Juurutatav tarkvara lokalisatsioon ja tema komponendid peavad olema paigaldatud Hankija

haldusalas olevasse pilveruumi. 3.5. Kasutusmugavus ja kasutajaliides:

3.5.1. Tarkvara peab olema kasutajasõbralik ja intuitiivne, et tagada tõhus kasutamine organisatsiooni eri tasanditel.

3.5.2. Kõikidele funktsioonidele peab olema võimaldatud juurdepääs töölaua kaudu. 3.5.3. Palgaarvestuse moodul peab arvestama, et lisaks töötajatele teostatakse palgaarvestuse

süsteemi kaudu igakuiselt väljamakseid.

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

2

4. Andmete korrastus ja andmete migratsioon 4.1. Pakutav tarkvaraline lahendus peab võimaldama andmete migratsiooni Hankija olemasolevatest

süsteemidest ja Hankija poolt välja töötatud reeglite alusel kus: 4.1.1. Defineeritakse andmete koosseis ja formaat; 4.1.2. Migreeritavate andmete maht; 4.1.3. Migreeritavate andmete eluiga.

4.2. Pakkuja peab pakkuma migratsiooni jaoks vajalikud tehnilised lahendused, milleks võivad olla: 4.2.1. Exceli kokkulepitud vormid; 4.2.2. Pakkuja võib pakkuda teistsugust lahendust, mis on aja- ja kuluefektiivsuse poolest sama

või parem. 4.3. Pakkuja peab pakkumist tegemisel arvestama, et andmed võivad migreerimisel vajada töötlust

ning nende kvaliteet testimist.

5. Litsentsid 5.1. Pakkuja peab tagama toote kasutamiseks vajalikud litsentsid Hankija poolt määratud ulatuses. 5.2. Pakkuja võib tarkvara loomisel kasutada järgnevaid komponente ja litsentse:

5.2.1. Üleantav tarkvara (või tarkvara üleantavad komponendid) – täitja loovutab kõik varalised autoriõigused tarkvarale tervikuna (või selle teatavatele osadele) tellijale.

5.2.2. Jagatav tarkvara (või komponendid) – täitja annab kõik varalised autoriõigused (või osa neist) tellijale ja jätab samad õigused ka endale. Jagatavate õiguste sisu ja maht tuleb pakkumuses selgelt määratleda.

5.2.3. Litsentseeritav tarkvara (või komponendid) – täitja annab tellijale enda loodud tarkvara suhtes litsentsi ning mis tuleb kirjeldada vastavalt punktile 5.6.

5.3. Hankija soetab Microsofti litsentsid personali- ja palgaarvestuse töötajatele ning iseteeninduse kasutajatele, mis on minimaalselt vajalikud MS Business Central lahenduses personali- ja palgaarvestuse protsesside haldamiseks ning iseteeninduse kasutamiseks, ning nende litsentside maksumust ei arvestata olelusringi kulude hulka.

5.4. Pakkuja pakkumus võib sisaldada lisaks punktis 5.2 nimetatud litsentsidele veel teisi Microsoft litsentse, mis peab olema lahti kirjeldatud litsentsikirjelduses (vt p 5.6).

5.5. Pakkuja võib rakendada eraldi litsentsitasusid pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete osas. Nimetatud litsentsid peavad olema lahti kirjeldatud litsentsikirjelduses (vt p 5.6) ning võtma arvesse, et:

5.5.1. litsentside kogus on eeldatav lähtuvalt kasutajate arvust, kuid kasutajate arv võib muutuda raamlepingu täitmise ajal ning hankija ei ole kohustatud soetama litsentse käesolevas dokumendis märgitud kogustes;

5.5.2. litsentside maksumuse määramisel arvestatakse, et kõik kasutajad hakkavad LIVE keskkonda kasutama pärast I etapi LIVE;

5.5.3. arvesse võetakse kasutajate profiilid, mis võivad ühe isiku puhul kattuda, ning kasutajate kogused. Näiteks palgaarvestaja võib olla samuti ka tavakasutaja ehk lähtuma peaks loogikast, et kõrgema järgu litsents katab ära vastava isiku rollist tulenevad kõik tarkvara funktsionaalsused, mida tal on vaja kasutada.

Kasutajate profiil Arv ettevõttes Peakasutaja 1

Personalitöötaja 4 Tööaja märkija 8

Masin-masin liides 1 Iseteeninduse kasutaja 700

5.6. Pakkuja esitab vastavustingimustes litsentsikirjelduse, mis sisaldab: 5.6.1. kõikide pakkumusega seotud litsentside nimetust, kogust kasutajagruppide lõikes jm

oluline info; 5.6.2. pakkuja olemasolevate funktsionaalsuste, moodulite vm toodete pakutavate litsentside

osas lisaks kirjeldust ja maksumust, nn masin-masin litsentsid; 5.6.3. samaväärse platvormi litsentside jm seotud litsentside kirjeldust ja maksumust vastavalt

arenduse etappidele.

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

3

5.7. Maksumusena märgitakse HD Lisas 3 ühikuhinnad kuu- ja/või aastapõhise hinnastamisega. Kasutajate arvu määramisel lähtutakse punktis 5.3.4 esitatud tabelist või HD Lisas 3 toodud kogusest, mis on eelduslikud.

5.8. Punktis 5.5.2 ja 5.5.3 nimetatud maksumused arvestatakse hanke maksumuse hulka vastavalt hindamiskriteeriumites toodule.

5.9. Microsofti litsentse Hankija käesoleva hanke raames edukalt pakkujalt ei osta, vaid ostab need eraldi. Samaväärsed litsentsid, mis on vajalikud lahenduse toimimiseks ja mis peavad olema pakkumuses välja toodud, ostab hankija edukalt pakkujalt käesoleva hanke raames otse vastavalt esitatud pakkumusele.

5.10. Hankija hindab vastavusena sh litsentside vajaduse realistlikkust (sh kas pakkuja poolt pakutud litsentside sisu ja kogusega on võimalik kasutada tarkvara hanke alusdokumentides märgitud funktsionaalsuses ja kasutajate arvuga).

5.11. Pakkuja võib pakkumusse lisada omapoolsed litsentsilepingu tingimused, mis ei tohi olla vastuolus hanke alusdokumentides sätestatuga ega esitada hankijale kitsendavaid või piiravamaid tingimusi hanke alusdokumentides sätestatust.

6. Juurutustööd ja lisaarendustööd 6.1. Juurutustööde aluseks on Pakkuja poolt pakkumusega esitatud Lisa 2, milles on esitatud iga

nõude eeldatav töötundide maht. Täpsem töötundide maht täpsustub peale analüüsifaasi koostatud projektiplaanis, kus on välja toodud töömahud tundide kaupa. Kui tegelik töömaht osutub projektiplaanis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.

6.2. Lisaarendustööde maht esitatakse arendusdokumendis töötundide kaupa. Kui tegelik töömaht osutub arendusdokumendis toodud tundidest rohkem kui 5% suuremaks, on Täitja kohustatud sellest Tellijat kirjalikult teavitama ning ootama ära Tellija kirjaliku kinnituse töödega jätkamiseks. Ilma Tellija eelneva kirjaliku kooskõlastuseta ületatud töötunnid ei kuulu Tellija poolt tasumisele.

6.3. Lisaarendustööd tähendavad nii uute süsteemide liidestamist tarkvaraga kui ka uute funktsionaalsuste lisamist.

6.4. Lisaarendustööd seisnevad tarkvara täiendava funktsionaalsuse eesmärgipärase funktsioneerimise tagamiseks teostatavatest töödest, mis ei ole käsitletavad tugiteenusena ja ei tulene seadusandluse muudatustest. Lisaarendustööd võivad olla ka täiendavad juurutamistööd raamlepingu kestvusel pärast esialgse juurutusperioodi lõppu. Hankijal on õigus, kuid mitte kohustus tellida täiendavaid lisaarendustöid.

6.5. Lisaarendus peab ühilduma tarkavaga selliselt, et see ei häiri tarkvara muud funktsionaalsust. Üleantud lisaarendus loetakse tarkvara osaks ning sellele laieneb ka tugiteenus olemasolevas mahus.

7. Arendustööde nõuded 7.1. Tarnida RMK jaoks arendatud Business Central laiendused koos lähtekoodiga. 7.2. Tarnida RMK jaoks arendatud Business Central laiendused koos tehnilise ja kasutaja

dokumentatsiooniga. 7.3. Kui tarnitav lahendus või selle osa ei ole Business Centrali platvormi komponent, siis sellistel

lahendustel peab olema eraldi turva / vastavuse sertifikaat. 7.4. Business Central äppide arendamisel peab tarnija jälgima Microsofti poolt kehtestatud nõuded ja

parimat praktikat, näiteks https://learn.microsoft.com/en-us/dynamics365/business-central/dev- itpro/compliance/apptest-bestpracticesforalcode.

7.5. Jälgima RMK tarkvara arenduse põhimõtted ja praktikat (vt HD Lisa 3). 7.6. Tarnija peab olema valmis kasutama RMK poolt ette antud IT haldusvahendid – JIRA, Confluence,

Azure DevOps jne. 7.7. Juhul, kui RMK-le tarnitakse kohandatud Business Centrali laiendus, mis põhineb sama tarnija

teise baasäppi peal ja laiendab selle funktsionaalsuse, peab tarnija hoidma ka põhirakenduste koodi up-to-date.

8. Koolitused 8.1. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise eestikeelse üldjuhendi koostamine

ja hankijale kättesaadavaks tegemine hiljemalt arendusetapi lõpuks. Lisaks peab olema tagatud

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

4

kogu tarkvara kasutamise ajal ajakohastatud kasutusjuhendite kättesaadavus, sh lisaarenduste kirjeldused.

8.2. Riigihanke arendustööde mahtu kuulub tarkvara kasutamise koolitus kasutajatele rollist lähtuvates gruppides. Koolitus peab toimuma eesti keeles. Koolituse toimumisvorm (veebis või kohapeal) ja täpsed koolitusajad kokkuleppel hankijaga. Koolitus tuleb salvestada ning salvestus edastada hankijale. Koolitusel peavad olema käsitletud tarkvara funktsionaalsused. Täpsemad koolituste sihtgrupid ja arvud on funktsionaalsuste tabelis.

9. Tugiteenus ja hooldusteenus 9.1. Tugiteenus peab sisaldama pakutava lahenduse toimimisega seotud kasutajatuge (tugiisik kõigi

lokalisatsioonide jaoks) ja tarkvarauuendusi (sh versiooniuuendused) kogu raamlepingu kehtivusperioodil vastavalt hanke alusdokumentidele.

9.2. Seadusemuudatustest tulenevad versiooniuuendused peavad olema Tellijale kättesaadavad ilma täiendava tasuta.

9.3. Hankija nõuded tugiteenusele on järgmised: 9.3.1. raamlepingu täitmise ajal tagab pakkuja tarkvara kasutusteenuse nõuetekohase toimise,

sh intsidentide tekkimise korral reageerima ja probleemi lahendama vastavalt teenustasemetele;

9.3.2. parandama turvanõrkuseid ja uuendama tarkvara vastavalt lepingus sätestatule; 9.3.3. hoidma tarkvara kohalikule seadusandlusele vastavana; 9.3.4. hoidma tehnilist ja lõppkasutaja dokumentatsiooni ajakohasena; 9.3.5. nõustama hankijat süsteemis muudatuste tegemisel ja kasutamisel.

9.4. Tugi- ja hooldusteenust tellitakse vastavalt vajadusele ning arveldatakse tunnitasupõhiselt. 9.5. Tugiteenus peab olema tagatud tööpäevadel kella 08.00 kuni 17.00. Tööpäevadeks loetakse kõiki

nädalapäevi, välja arvatud laupäev, pühapäev ja riigipühad. 9.6. Teenusetasemed:

Raskusaste Probleemi definitsioon Reageerimisaeg Lahendamise

aeg

Tase 1 Kriitiline viga

Kogu rakendus pole saadaval või Kriitiline funktsionaalsus ei toimi. Kriitiline funktsionaalsus - tegevused, mis on seotud õigeaegse rahalise väljamaksega ja mille mitte toimimisest tekib hankijale rahaline kahju. Tegevused, mis tulenevalt mingist olukorrast on muutunud aegkriitiliseks.

1 töötund Kuni 4 tundi

Tase 2 Kõrge

tasemega viga

Osa kriitilisest funktsionaalsusest ei toimi, tagatud on workaround väljamakse tegemiseks.

1 töötund Kuni 24 tundi

Kriitiline funktsionaalsus toimib piiratud viisil; süsteemi või teenuse halvenemine, mis mõjutab lõppkasutajat või kahjustab oluliselt äriprotsesside kontrolli või tegevuse tõhusust (vaja on täiendavat tööaega).

Tase 3 Keskmise

tasemega viga

Viga mitte kriitilises funktsionaalsuses ja kõik muud probleemid

1 tööpäev kokkuleppel

Tase 4 Madala

tasemega viga

Kõik muud toenõuded, millega ei kaasne probleeme. 3 tööpäeva kokkuleppel

9.7. Kriitiliste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt kaks (2)

tööpäeva, planeerimata katkestuste kogukestvus kuus ei tohi ületada 16 tundi ning aastas 192

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

5

tundi. Kriitiliste funktsionaalsuste varundamine peab toimuma igapäevaselt, varukoopiaid tuleb LIVE keskkonnal säilitada 365 päeva, testkeskkonnal 185 päeva.

9.7.1. Iga kuu 1.-5. tööpäeval ei tohi Tellija teostada planeeritud katkestusi. 9.8. Keskmiste funktsionaalsuste planeeritud katkestustest tuleb ette teatada vähemalt kaks (2)

tööpäeva, planeerimata katkestuste kogukestvus kuus ei tohi ületada 96 tundi ning aastas 1152 tundi. Keskmiste funktsionaalsuste varundamine peab toimuma igapäevaselt, varukoopiaid tuleb nii LIVE kui ka testkeskkonnal säilitada 35 päeva.

9.8.1. Iga kuu 1.-5. tööpäeval ei tohi Tellija teostada planeeritud katkestusi. 9.9. Tase 1 viga tuleb lahendada maksimaalselt 4 tunni jooksul, isegi kui lahendamise aeg väljub

punktis 9.5 nimetaud ajalisest piirist. 9.10. Reageerimisaeg on aeg, mille jooksul pakkuja annab hankijale esialgset tagasisidet probleemide

uurimise kohta. 9.11. Lahendusaeg on probleemi lahendamise maksimaalne aeg või Tellijale vastuvõetava alternatiivse

lahenduse rakendamine ja lõpliku lahenduse tähtaja kokkuleppimine Tellijaga ilma lisakuludeta hankijale.

9.12. Funktsioonide kasutamist häirivate plaaniliste hooldustööde kestus ei tohi ületada 12 tundi (kumulatiivselt) kuus.

9.13. Pakkuja esitab eelmise kvartali lõpus järgmisse kvartalisse tooteomaniku, kui tootja, poolt planeeritud tarkvarauuenduste info e-kirja teel lepingus kokku lepitud kontaktisikutele.

9.14. Pakkuja peab teostama tugiteenuse käigus ka korrapäraseid hooldustöid, mis tagavad pakutava tarkvara kasutusteenuse terviku (kaasa arvatud selle juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse, turvalisuse jms).

9.15. Pakkuja peab tagama tarkvara käideldavuse ja lahendama pöördumisi vastavalt raamlepingus sätestatud tähtaegadele.

9.16. Teenustaseme puhul loetakse oluliseks lepingu rikkumiseks mh, kui on rohkem kui 1 (üks) "Tase 1" või "Tase 2" viga kvartalis või 2 (kaks) "Tase 3" viga kvartalis eraldi või koos, mis ei ole punktis 9.5 etteantud ajal jooksul parandatud.

9.17. Järgmisi asjaolusid ei loeta rikkumisteks: 9.17.1. kokkulepitud plaanilised hoolduspausid; 9.17.2. rike, mis on põhjustatud võrguühendusest väljaspool taristu teenuse (IaaS)

teenusepakkuja võrku; 9.17.3. seisak, mille on põhjustanud vääramatu jõud.

9.18. Teenustasemete reageerimisaja rikkumiste korral kasutab Hankija tööaja kompenseerimise mudelit ehk tasuta tööaja pakkumist järgnevalt:

9.18.1. Tase 1 rikkumise korral on Hankijal õigus saada kuni 8 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.

9.18.2. Tase 2 rikkumise korral kuni 4 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.

9.18.3. Tase 3 ja tase 4 rikkumise korral kuni 2 tundi tasuta hooldustööd, mida võib kasutada järgmise 30 kalendripäeva jooksul.

9.19. Hankijal on õigus punkti 9.18. kompenseerimise mudel asendada leppetrahviga raamlepingu punktis 6.6 sätestatud määradega.

10. Raamhanke struktuur ja eeldatav ajakava 10.1. Raamleping kehtib 48 kalendrikuud või maksimaalse maksumuse täitumiseni (kohaldub esimene

täituv tingimus). 10.2. Tarkvara arenduse struktuur:

10.2.1. Arendusetapid võivad käivituda samaaegselt; 10.2.2. Funktsionaalsusnõuetes (HD Lisa 2) on kõik arendusnõuded defineeritud kui

„kohustuslikud“. 10.3. Lisaarenduse protsess kohaldub vaid nendele võimekustele, mida kohustuslikes funktsionaalsetes

nõuetes ei ole loetletud. 10.4. Ajakava:

10.4.1. LIVE kuupäev on eelduslikult 01.10.2026. 10.5. Pärast iga alametapi LIVE-i pakub pakkuja kaks kalendrinädalat nö hüperhooldust ehk

suurendatud järelevalvet LIVE-s tuvastatud esmaste vaegtööde lahenduseks, mille käigus keskendutakse tarkvara stabiilsuse tagamisele, varajaste vigade ja probleemide kiirele lahendamisele ning kasutajate tagasiside integreerimisele süsteemi täiustamiseks.

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

6

10.6. Pärast alametapi hüperhoolduse perioodi lõppu hakkab kehtima antud alametapi osas ühe kalendriaastane garantii periood.

10.7. Juhul kui pakkumus sisaldas pakkuja poolt pakutavaid tarkvara litsentse, peab pakkuja võimaldama litsentsiga kaetud tarkvarale ligipääsu alates LIVEst. Vastav leping sõlmitakse enne LIVE ja hakkab kehtima LIVE kuupäevast.

11. Testimine 11.1. Enne töö üleandmist viib Täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid. 11.2. Kui töö või mistahes selle osa ei läbi teste, viiakse viivitamatult pärast seda, kui Täitja on teinud

vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel. Tellija nõudmisel viib kordustestid läbi Täitja.

12. Dokumentatsioon 12.1. Arenduste teostamisel peab Täitja koostama dokumendi(d), millede eesmärgiks on anda selge ja

konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest. 12.2. Eraldiseisvaid dokumente üle ei anta vaid Tellija keskkonda kirjutatakse analüüsi jooksvalt projekti

käigus. 12.3. Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust. 12.4. Üle antavad dokumendid peavad sisaldama:

12.4.1. Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused jms;

12.4.2. Vormide (ekraanivormide) kirjeldused; 12.4.3. Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused.

12.5. Infosüsteemi teenuste kirjeldused. 12.6. Juurutuse faasis ja lõpus peab Täitja esitama arhitektuuri kirjeldus dokumendi, mille eesmärgiks

on kirjeldada loodava ja/või juurutatava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise.

12.7. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest.

12.8. Täitja sisemiste koosolekute eest, mille töötunde esitatakse Tellijale tasumiseks, peab Täitja koostama ja esitama ülevaatliku memo, mis peab sisaldama vähemalt järgmist infot:

12.8.1. Koosolekul osalenud isikute nimekiri; 12.8.2. Koosoleku eesmärk ja arutatavad teemad; 12.8.3. Koosolekust projektile tekkiv väärus või mõju; 12.8.4. Põhiotsused ja järgmised sammud (kui rakendub); 12.8.5. Koosoleku kuupäev ja kestus.

Memo eesmärk on tagada tööde läbipaistvus ning võimalus hinnata koosoleku asjakohasust projekti täitmise seisukohast. Ilma nõuetekohase memota ei ole Täitjal õigust esitada Tellijale arvet nende töötundide eest.

13. Garantiitingimused 13.1. Täitja garanteerib tööde vastavuse lepingule ja seadusega sätestatud töövõtu tingimustele,

tarkvara kirjeldusele ning tellija põhitegevuse tavapärastele ja mõistlikele nõuetele kokkulepitud aja jooksul pärast tööde vastuvõtmist tellija poolt.

13.2. Täitja tagab garantii perioodiks 12 (kaksteist) kuud, mis algab tööde kogumina vastuvõtmisest. 13.3. Garantii korras vea parandamine hõlmab kõigi tarkvara osade, sealhulgas abistava

dokumentatsiooni parandamist või muutmist.

14. Nõuded projektiplaanile 14.1. Pakkumuse osana esitatakse tarkvara arenduse projektiplaan, mis sisaldab ajakava (tegevuste

ajalist kestvust) kõikide funktsionaalsuste loomiseks ja vajalike tööde läbiviimiseks. 14.2. Projektiplaanis peab olema selgelt eristatavad tööde etapid ning vajadusel jätku ja/või muud

tegevused. Tegevused peavad olema välja toodud nädala täpsusega. Projektiplaan peab olema koostatud arvestusega, et kõik hanke alusdokumentides nimetatud arendusega seotud tegevused oleks teostatud ja kogu lahendus kasutatav eelduslikult 01.10.2026.

14.3. Pakkumuses esitatav projektiplaan peab vastama järgmistele tingimustele:

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

7

14.3.1. projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus;

14.3.2. iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus töötundides või tööpäevades ja tähtaeg vastavalt tööde mahule;

14.3.3. projektiplaanis peavad kajastuma töö tegemiseks vajalikud eeldused/lähteandmed ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tööde ajalist kestvust.

14.3.4. kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud; 14.3.5. projektiplaan peab sisaldama varuaega (puhvrit) arvestades riiklike pühade,

puhkepäevade, projektimeeskonna puhkustega/vahetustega ja muu taolisega; 14.3.6. Projekti ajakohastamine toimub vaid poolte kirjalikul kokkuleppel.

14.4. Pakkuja peab kirjeldama, kuidas ta kavatseb maandada tarkvara arenduse projekti realiseerimise riske (HD Lisa 3).

14.5. Projektiplaan ja riskide maandamise plaan esitatakse Exceli kujul. Pakkuja võib lisaks pakkumusse lisada projektiplaani Microsoft Project formaadis.

15. Nõuded meeskonnale 15.1. Juhul, kui Täitja ei ole tooteomanik, kui tootja, peab Täitja kaasama läbiviidavatesse analüüsi

töötubadesse ka tooteomaniku, kui tootja esindaja, et tagada: 15.1.1. nõuetele vastavus ja toote funktsionaalne terviklikkus; 15.1.2. funktsionaalsuste ja tehniliste piirangute korrektne tõlgendamine; 15.1.3. süsteemi arhitektuuri ja konfiguratsioonipõhimõtete kinnitamine; 15.1.4. analüüsi tulemuste vastavus tarkvara tegelikele võimalustele; 15.1.5. hilisemate arenduste ja seadistuste valideerimine tootja pädevuse alusel.

15.2. Pakkuja peab raamlepingu täitmiseks komplekteerima piisava suurusega meeskonna, et oleks tagatud vajalik ning asjakohane inimressurss kogu arenduse ja juurutusperioodiks, kuid ka tugi- ja hooldusteenuse osutamiseks ja lisaarenduste tellimiseks.

15.3. Kõik meeskonnaliikmed peavad olema kättesaadavad projekti jooksul. 15.4. Kõik meeskonna rollid peavad olema lepingu kestel kaetud ja kättesaadavad vastavalt lepingus

kokkulepitud ulatusele. Kui mõne rolli täitja vahetub, peab Täitja teavitama Tellijat rollis oleva liikme asendamisest kirjalikult vähemalt 5 tööpäeva ette. Rolli ajutine või püsiv katmata jätmine on lubatud üksnes juhul, kui Tellija on selleks andnud eelneva kirjaliku nõusoleku.

15.5. Pakkuja asendab töid teostava isiku viivitamatult Lepingu eseme täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning hankijale vastuvõetava isikuga, kui nimetatud töid teostav isik osutub Tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine pidevalt kahjustab raamlepingu korrektset ja õigeaegset täitmist.

15.6. Tellija ei ole kohustatud tasuma Täitja töötajate väljaõppe, sisseelamise ega koolitamisega seotud töötundide eest. Juhul kui Täitja vahetab projekti rollis oleva isiku, peab uus töötaja omandama vajalikud teadmised ja projektiga seonduva info Täitja enda kulul. Tellija ei tasu töötundide eest, mis on seotud:

15.6.1. uue töötaja koolitamise või väljaõppega; 15.6.2. projekti teemadega tutvumisega (sh dokumentatsiooni läbilugemine); 15.6.3. Täitja sisese duubeldamise või varjutamisega koosolekutel (nt olukord, kus uus või noorem

konsultant osaleb koosolekul ilma Tellijale lisaväärtust loomata). Sellised tunnid ei kuulu arveldamisele ja neid ei või Tellijale esitada sõltumata sellest, kas Täitja märgib need sisemiselt projekti tööajaks või mitte.

15.7. Arendusmeeskonna liikmetel peab olema varasem kogemus pakutava lahenduse juurutamisel (alates lahenduse analüüsist kuni juurutatava tarkvara kasutuselevõtuni). Meeskonna tööd koordineerib projektijuht, kelle suhtluskeel on eesti keel, sh peavad eesti keelt valdama B2 tasemel spetsialistid, kes on Tellijaga otsesuhtluses.

15.8. Pakkuja kannab kõik nimetatud asendusest tulenevad või sellega kaasnevad kulud. 15.9. Pakkuja meeskonna poolt täidetavad rollid on esitatud alljärgnevalt, kusjuures üks spetsialist ei

tohi katta mitte rohkem kui kahte rolli. 15.10. Projektijuht, kes korraldab suhtlust arendusmeeskonna ja hankija kontaktide vahel ning

vastutab lepingu igapäevase täitmise eest, sealhulgas: 15.10.1. koostöös tellijaga koostab ja jälgib arenduste teekaarti (sh ajakava, riskid); 15.10.2. korraldab ja juhib arenduste planeerimise ja retroperspektiivi koosolekuid; 15.10.3. korraldab ja juhib projektimeeskonna teisi korralisi koosolekuid;

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

8

15.10.4. juhib ja korraldab arendusmeeskonna igapäevatööd; 15.10.5. küsib tellija poolset tagasisidet ja lahendab sealt ülesse kerkinud probleeme; 15.10.6. korraldab tarkvara hooldamise ja toe pakkumise protsesse; 15.10.7. korraldab intsidentide ja probleemide lahendamise vastavalt lepingutingimustele; 15.10.8. korraldab tööde üleandmise ja arveldamise, planeerib tööde üleandmise tellijale

ning veendub enne üleandmist nende vastavuses tellija soovidele; 15.10.9. koostab ja esitab tellijale projekti aruandluse ning korraldab infovahetuse tellijaga. 15.10.10. Projektijuhil peab olema vähemalt 3-aastane kogemus tarkvaraprojektide juhtimisel

avalikus sektoris või samas mahuklassis erasektoris. 15.11. Arhitekt, kes kooskõlastab kõik suuremad arendustööd ja seisab selle eest, et

tarkvara arendatakse vastavalt baastoote loogikale ja arendussuunistele, sealhulgas: 15.11.1. töötab välja koostöös tellijaga tarkvara arhitektuuri (komponendid, andmestruktuurid,

algoritmid) ning suhtlusprotokollid teiste süsteemide ja kasutajatega; 15.11.2. vaatab üle suuremad muudatused teenustes ning uut tüüpi teenusesoovid ning liidesed; 15.11.3. vaatab üle muudatused andmemudelis; 15.11.4. otsustab ja kooskõlastab tellijaga kasutusele võetavad tehnoloogiad; 15.11.5. teeb ettepanekuid paremateks lahendusteks tarkvaras; 15.11.6. kirjutab tarkvara koodi ja andmelaadimise tingimused; 15.11.7. teostab koodi ülevaatust.

15.12. Analüütik/konsultant, kes kirjeldab kasutajate vajadused, seadistab süsteemi ja loob vajadusel lähteülesande arendusteks, sealhulgas:

15.12.1. analüüsib, millised on ärilised vajadused töö käigus väljatöötatavate lahenduste taga ning millised on lahenduste toimimiseks vajalikud ärilised protsessid;

15.12.2. analüüsib tellija soove ja vajadusi seoses tarkvaralahendusega ja formuleerib vajadused ning nõuded süsteemile;

15.12.3. töötab välja vajadustele vastavad lahenduste kavandid või täiendamisvajadused olemasolevas tarkvaras;

15.12.4. loob ärilistele vajadustele vastavad prototüübid; 15.12.5. tunneb tarkvara funktsionaalsust ning konsulteerib vajadusel peakasutajaid; 15.12.6. kaardistab ja dokumenteerib süsteemide ja süsteemi osade vahelised liidesed; 15.12.7. koostab lähteülesandeid arendusteks ja tehnilise dokumentatsiooni. 15.12.8. Analüütik peab omama varasemat kogemust palga- ja personali (HRM) valdkonna

lahenduste analüüsimisel ja seadistamisel. 15.12.9. Konsultandil peab olema vähemalt 2-aastane kogemus Microsoft Business Centrali või

samaväärse ERP-süsteemi personalimooduli kasutuselevõtul ning ta peab omama HRM4 Baltics toote ametlikku sertifikaati.

15.13. Arendaja, kes teostab vastavalt lähteülesandele ja MS Dynamicsi arendussuunistele kliendispetsiifilised eriarendused, sealhulgas:

15.13.1. hoolitseb selle eest, et tarkvara andmebaas, komponendid ja liidestused erinevate infosüsteemide vahel kõik omavahel hästi töötaksid;

15.13.2. konsulteerib konsultante/analüütikuid vajadustele vastavate lahenduste variantide osas; 15.13.3. kirjutab tarkvara koodi; 15.13.4. kirjutab automaattestid; 15.13.5. teostab koodi ülevaatust. 15.13.6. Arendajal peab olema vähemalt 2-aastane kogemus Business Centrali (AL-keele) arenduses

ning ta peab omama HRM4 Baltics toote ametlikku sertifikaati, mis kinnitab pädevust konkreetse toote laienduste ja integratsioonide loomisel.

15.14. Testija/dokumenteerija, kes dokumenteerib nõuetekohaselt teostatud arendused ja testib nende toimimist, sealhulgas:

15.14.1. loob testjuhtumid valminud lahenduste testimiseks; 15.14.2. genereerib vajadusel testandmed loodud lahenduste testimiseks; 15.14.3. testib tarkvara; 15.14.4. loob ja täiendab testlugusid; 15.14.5. loob kasutusjuhendeid; 15.14.6. teostab kasutajate konsulteerimist ja koolitamist; 15.14.7. võib kirjutada kasutajaliidese automaat-teste. 15.14.8. Testijal peab olema kogemus ERP-lahenduste testimise metoodikate ja

kvaliteediprotsesside rakendamisel.

Avatud hankemenetlus „Personali- ja palgaarvestuse tarkvara soetamine ja hooldus koos iseteenindusega“

Viitenumber: 302765 Lisa 1 – Tehniline kirjeldus

9

15.15. Hankija meeskonda kuuluvad arendusprojekti projektijuht, peakasutajad, IT tooteomanikud, analüütikud, arhitektid, tehnilised konsultandid.

15.16. Juhul, kui Täitja ei ole tooteomanik, kui tootja, siis on Hankijal õigus kaasata tooteomaniku, kui tootja, esindaja olulisemaid projekti etappe ja mahte sõltumatu osapoolne valideerima.

lisa 2 - rmk arendusnõuded.pdf

Arendusnõuded Avalikustamine: RMK sisene teave

Teavet ei ole lubatud jagada kolmandate osapooltega, v.a juhul, kui selleks on õiguslik alus ja/või see on vajalik tööprotsesside toimimiseks.

Avalikustamise lisainfo: “Arendusnõuded (MFN)” lisatakse tarkvara arendamise, hankimise ja juurutamise hangete korral hankedokumen de juurde, v.a dokumendi punk s 2.1 viidatud “RMK Töö- ja koodihaldus” ja punk s 5 viidatud “Logimise spetsifikatsioon”, mis väljastatakse hanelepingu sõlmimise järel ning punk s 2.3 viidatud “Eelistatud tehnoloogiate nimekiri”, mis väljastatakse konfidentsiaalsusleppe (NDA) või hankelepingu sõlmimise järel. Riigihangete portaali hankedokumen de juurde koos “Arendusnõuded (MFN)” dokumendiga neid vaikimisi ei lisata.

Sisukord Arendusnõuded ...................................................................................................................................... 1

1. Ülevaade ja skoop ........................................................................................................................... 2

2. Üldnõuded ...................................................................................................................................... 2

2.1 Töö- ja koodihaldus ................................................................................................................... 2

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release ............................................................ 2

2.3 Platvorm .................................................................................................................................... 3

2.4 Koodi kvaliteet ja arendusprotsess ........................................................................................... 3

2.5 Dokumenteerimine ................................................................................................................... 4

2.6 Haldus ....................................................................................................................................... 4

2.7 Välised sõltuvused .................................................................................................................... 5

2.8 Muud üldised nõuded ............................................................................................................... 5

3. Frontend nõuded (UX/UI) ............................................................................................................... 5

3.1 Tehnilised .................................................................................................................................. 5

3.2 Kasutuskogemus ....................................................................................................................... 6

4. Backend nõuded (API/teenused) .................................................................................................... 7

4.1 Konfiguratsioon ja deploy ......................................................................................................... 7

4.2 API disain ja dokumentatsioon ................................................................................................. 7

4.3 Töökindlus ja monitooring ........................................................................................................ 7

4.4 Koodistruktuur ja arendus ........................................................................................................ 8

4.5 Integratsioon ............................................................................................................................. 8

5. Logimine .......................................................................................................................................... 8

6. Andmebaasi ja andmetöötluse nõuded .......................................................................................... 9

6.1 Üldpõhimõ ed .......................................................................................................................... 9

6.2 Iden fikaatorid ja audit ............................................................................................................. 9

6.3 Platvorm ja tööriistad................................................................................................................ 9

6.4 Turvalisus ja juurdepääs ............................................................................................................ 9

7. Turvanõuded ................................................................................................................................. 10

7.1 Üldised põhimõ ed ................................................................................................................ 10

7.2 Sessioonid ............................................................................................................................... 10

7.3 Lähtekood ja arendusvahendid ............................................................................................... 10

9. Hooldatavus ja toetatavus ............................................................................................................ 11

1. Ülevaade ja skoop Käesolev dokument kirjeldab kuidas RMK-s arendatakse, hangitakse ja juurutatakse tarkvara. See hõlmab nii tarkvara arendust kui ka karbitoodete ja SaaS (So ware as a Service) teenuste kasutusele võ u. Nõuded ei kirjelda ärifunktsionaalsust.

Dokumendis viidatakse ka teistele välistele dokumen dele, mis moodustavad käesoleva dokumendiga ühtse terviku.

2. Üldnõuded

2.1 Töö- ja koodihaldus  Kõik tööd peavad olema kirjeldatud pile na RMK JIRA-s. Täpsemad JIRA ja versioonihalduse

kasutamise nõuded on kirjeldatud dokumendis „RMK Töö- ja koodihaldus“(välisele arenduspartnerile väljastatakse dokument peale hankelepingu sõlmimist).

 Git repod: RMK kood asub Azure DevOps repodes.

2.2. Operatsioonid, lokaalne käivitamine, CI/CD ja release  Lokaalne käivitus: Rakendused peavad olema lokaalselt käivitatavad ilma väliste

sõltuvusteta. Vajalikud sõltuvused peaksid olema lokaalselt käivitatavad Docker Compose-i konteineriga. Välised sõltuvused(API-d) võivad olla mockitud. Rakenduse käivitamiseks ja tes miseks vajalikud andmed peavad olema rakenduses seadistatud. Peale käivitamist peab olema rakendus kasutatav. Rakenduse Vajalikud käsud ja sammud rakenduse lokaalseks käivitamiseks peavad olema välja toodud koodi repos README.md failis.

 Koodi formaadi kontroll: koodi formaadi kontroll peab olema build protsessi osa. Kood peab vastama RMK-s kokku lepitud formaadile.

 Staa line analüüs: staa line analüüs(nt Sonar) peab olema build protsessi osa selliselt, et kui kvaliteedi lävendit ei ületata, siis build ei õnnestu. Uus kood ei tohi tekitada juurde Sonari vigu. Lokaalselt seda sammu ei ole(võimalusel kasutada Sonarit IDE pluginana, või minna eraldi Sonari liidesesse ja kontrollida vigasid).

 Tes mise üldnõuded: vt peatükk 9.

 Release strateegiad: kasutusel võivad olla erinevad väljalaskmise mustrid (nt blue-green, canary). Täh s on, et uue versiooni kasutuselevõ oleks kontrollitud ja võimaldaks vajadusel kiiret tagasipööramist.

 Produc on ressursivajadus: arendusmeeskonna ülesanne on tes da rakenduse jõudlust ja selle põhjal teha e epanek rakenduse ressursivajaduse kohta produc on keskkonnas, mis on sisendiks haldusosakonnale.

2.3 Platvorm  Versioon: Ükskõik mis programmeerimiskeelte, raamis ke või teekidega infosüsteeme

realiseeritakse, keh b sama põhimõte: ala kasutatakse kas viimast LTS(Long Term Support) versiooni, või selle puudumisel viimast stabiilset versiooni. Kui arendustöö käigus tuleb uus LTS versioon välja, siis see uuendatakse kohe ära, kui ei esine seda takistavaid asjaolusid.

 Eelistatud tehnoloogiate nimekiri: Nimekiri programmeerimiskeeltest, raamis kest, teekidest ja nende versioonidest, mida võib ilma täiendava kooskõlastamiseta kasutada on kirjeldatud dokumendis „Eelistatud tehnoloogiate nimekiri“(välisele arenduspartnerile väljastatakse dokument riigihanke käigus NDA alusel või peale hankelepingu sõlmimist). Juhul kui on soov kasutada midagi muud, siis tuleb see valik kooskõlastada RMK tarkvaraarhitek ga.

 Keskkond: backend, frontend ja andmebaasid töötavad Azure pilvekeskkonnas.

 CI/CD: kasutatakse Azure CI/CD. Build protsessi osana käivitatakse koodi formaadi kontroll, staa line analüüs, tes d.

 Sõltuvused: kasutatakse ainult toetatud ja turvauuendusi saavaid teeke.

 Skaleeruvus: rakenduste arendamisel peab arvestama võimalusega, et need jooksevad mitme õla peal.

 Docker: rakendus peab olema tarnitav Dockeri konteineritena.

2.4 Koodi kvaliteet ja arendusprotsess  Põhiharu kvaliteet: main haru peab ala olema tes tud ja valmis produc on keskkonda

paigaldamiseks.

 Sisendi valideerimine: kõik kasutajalt või teistest süsteemidest tulevad sisendid valideeritakse. Kui rakendusel on nii kliendi- kui serveripool, toimub valideerimine mõlemas komponendis. Samu rakendatakse valideerimist teistes integratsioonipunk des(andmebaas, välised liidesed).

 Väljundandmete kontroll: Rakenduse poolt kasutajale või teisele süsteemile väljastatavad andmed peavad olema õiges vormindatud, äriliselt korrektsed ja turvalised.

o Formaadi kontroll: kõik väljastatavad väärtused vastavad kokkulepitud skeemile või standardile. Näiteks kuupäevad esitatakse ISO 8601 formaadis (2025-09-

02T12:00:00Z), rahasummad kahe komakohaga, ning API vastus vastab OpenAPI kirjeldatud struktuurile.

o Äriline korrektsus: väljastatav info järgib ärireegleid ja loogikat. Näiteks ei väljastata nega ivset saldo väärtust, kui süsteemi reeglid seda ei luba; ID viitab ala reaalselt olemasolevale kirjetele; staatuse väljad sisaldavad ainult eeldefineeritud väärtusi.

o Turvalisus: väljund ei tohi sisaldada tundlikke või sisemisi andmeid, mida kasutaja või partner ei pea nägema (nt paroole, võtmeid, sisemisi tehnilisi tunnuseid). Teks d peavad olema korrektselt escape’itud, et väl da XSS või sarnaseid ründeid. Logidesse ei tohi sa uda täielikud isikuandmed ega salajased iden fikaatorid.

 Staa line koodianalüüs: kasutatakse staa list koodianalüüsi(Sonar); kõrge prioriteediga turvavead tuleb lahendada enne live keskkonda paigaldamist. Kõik Sonari vead vaadatakse enne arenduse üleandmist üle, vead mida ei peeta otstarbekaks parandada kooskõlastatakse RMK tarkvaraarhitek ga.

 Kompilaatori hoiatused: build-i hoiatused ja staa lise analüüsi tulemused vaadatakse üle ja arvestatakse.

 Kiirlahenduste väl mine: ei kasutata tes mata lahendusi, mis eiravad häid prak kaid või RMK nõudeid.

 Tes mise põhimõ ed: vt peatükk 9.

2.5 Dokumenteerimine  Dokumentatsiooni põhielemendid:

o süsteemi funktsionaalne ja tehniline kirjeldus,

o kasutatavad liidesed (API-d, integratsioonid),

o perioodilised tööd (schedulerid, batch-protsessid),

o arenduskeskkonna seadistamine

o andmebaasi struktuuri kirjeldus (tabelid, seosed, migratsioonid),

o keskkonnad ja paigaldus

o peamised hooldustegevused (nt logide ülevaatus, varunduse kontroll, sõltuvuste uuendamise tsükkel)

 Dokumentatsiooni asukoht: RMK Confluence keskkond

 Diagrammid: süsteemi arhitektuuri ja komponente visualiseeritakse eelistatult PlantUML või Mermaid formaadis.

 Arhitektuur: iga süsteemi kohta peab olema arhitektuuriülevaade, sealhulgas API spetsifikatsioonid (nt OpenAPI).

2.6 Haldus  Tehniline võlg: arenduse käigus tuleb dokumenteerida teadaolevad piirangud ja tehniline

võlg (nt TODO-d, aju sed lahendused) ning soovitused nende likvideerimiseks.

 Sõltuvuste ja platvormi uuendused: arenduse käigus tuleb kirjeldada süsteemi kaasaegsena hoidmise strateegiat (nt milliseid raamis kke ja teeke tuleb regulaarselt uuendada, millal tuleb planeerida üleminek LTS-versioonidele).

 Monitooringu vajadused: tarnija peab kirjeldama arendatava süsteemi monitooringu aspek d (nt vealogid, jõudlusmõõdikud, integratsioonide toimivus, job scheduler-i töö).

 Teavitused: tarnija peab defineerima soovitatud häirete künnised (nt kui API annab vea, kui mingi protsess ei lõpeta näiteks 15 minu ga).

 Elutsükli planeerimine: tarnija peab andma hinnangu, millised tehnoloogiad või komponendid võivad lähiaastatel vajada moderniseerimist või väljavahetamist.

 Andmete säilitustähtajad: kui süsteemis talletatakse andmeid, millel on määratud säilitustähtaja (vastavalt teabe liigitusskeemile Jira Asse s), tuleb see dokumenteerida. Dokumentatsioonis peab olema kirjeldatud, millised andmed kustutatakse automaatselt, millal ja kuidas.

2.7 Välised sõltuvused  Teekide kasutamine: kasutada ainult laialdaselt toetatud ja turvauuendusi saavaid teeke.

 Sõltuvuste miinimum: sõltuvusi hoitakse minimaalsena, et vähendada turvariske ja halduskoormust.

 Litsentsid: sõltuvuste litsentsi ngimusi, turvalisust ja ajalugu hinnatakse; eelistatakse vabavaralisi komponente.

 Jätkusuutlikkus: hinnatakse teekide jätkuarenduse ja toe kä esaadavust. Vajadusel analüüsitakse mõju RMK protsessidele, kui komponendi arendus lõpeb.

 Ühilduvus: analüüsitakse kasutatavate komponen de ühilduvust teiste süsteemidega.

2.8 Muud üldised nõuded  Kodeering ja locale: kogu süsteemis (lähtekoodis, andmebaasis, jne) kasutatakse UTF-8

kodeeringut; vaikekeel on et-EE (laiendatav i18n); ajatsoon on UTC (UI-s kohalik aeg).

3. Frontend nõuded (UX/UI)

3.1 Tehnilised  Tehnoloogia: kui rakenduse nõuded võimaldavad siis eelistame serveris renderdatud HTML-i

(Thymeleaf, HTMX).

 Raamis kud: kui kasutatakse mingit raamis kku, siis eelistame laialdaselt toetatud raamis kku (nt React, Angular või Vue).

 Raamis ku versioon: projek s kasutatavad raamis kud peavad olema toetatud ja saama turvauuendusi.

 Build: sõltuvused hallatakse pake halduriga, arvestades kasutatavat tehnilist lahendust:

o SPA: npm / yarn / pnpm (lock fail versioonihalduses; build deterministlik).

o Java SSR (Server-Side Rendering nt Thymeleaf): Gradle (või Maven) hoiab nii backendi kui frontendi build-i .

o PHP SSR: Composer.

o Python SSR: pip. Build peab olema deterministlik ja versioonitav (lock failid, build-config git-s).

 Keskkonnaspetsiifilised seaded: hoitakse välises konfiguratsioonis (nt .env).

 API kasutus: kõik API-päringud käivad läbi konfiguratsiooni alusel määratud lõpp-punk de; otselinke koodis ei kasutata.

 Turvalisus: tundlikke andmeid ei salvestata brauseri püsivasse vahemällu (LocalStorage, SessionStorage) ilma krüpteerimiseta.

 Jõudlus: rakendus peab laadima mõistliku aja jooksul – esmase laadimise vaikimisi nõue on 2s. Täpsem kontekst (nt mõõdik, tüüpiline seade ja võrguolud) lepitakse projek alguses kokku ja fikseeritakse rakenduse/projek dokumentatsioonis. Pildid, skrip d ja s ilid peavad olema op meeritud (lazy load, cache, minify).

 Telemeetria: krii lised kliendipoolsed vead (JavaScript errorid, katkised API päringud) peavad jõudma tsentraalsesse monitooringusse.

3.2 Kasutuskogemus  Reageeriv(responsive) disain: rakendus peab olema kasutatav erineva ekraanisuurusega

seadmetel (desktop, mobiil, tahvel).

 Navigatsioon: menüüd ja liikumisloogika on rakenduse eri vaadetes ühtsed. Sama funktsionaalsus on ala leitav samast kohast.

 Nuppude paigutus ja järjestus: sama tüüpi tegevused (nt “Salvesta”, “Tühista”) paiknevad ala samas järjekorras ja paigutusega.

 Veateated: esitatakse ühtses formaadis (struktuur, sõnastus, värvilahendus). Teated on arusaadavad ja ei sisalda tehnilist müra. Veateated ei sulgu automaatselt, et kasutajal oleks võimalik neid adekvaatselt edastada toe saamiseks.

 Kinnitused ja dialoogid: riskantsete tegevuste (nt kustutamine, lõplik kinnitamine) puhul küsitakse ala kinnitust. Dialoogid järgivad sama s ili ja loogikat.

 Abiteks d ja juhendid: tool pid, sisestusväljade placeholderid ja abiteks d on s ililt ja positsioonilt ühtsed. Kõik väljad ja tegevused on varustatud abiteks ga, mis aitab kasutajal mõista, mis juhtub enne kui ta midagi teeb.

 Laadimise tagasiside: pikemate tegevuste puhul (nt päring serverisse, faili üleslaadimine) peab kasutaja nägema visuaalset indikaatorit (spinner, progress bar).

 E eaimatavus: süsteemi käitumine peab olema selge ja ootuspärane – väldime olukorda kus kasutaja peab mõtlema „mis siis juhtub, kui ma siia vajutan“. Tegevuste tagajärjed on nähtavad või selgitatud enne sooritamist.

 Ikonograafia ja sümbolid: sama tegevuse tähistamiseks kasutatakse ala sama ikooni ja tähendust.

 S il ja kujundus: värvipale , kirjatüübid ja komponen de kujundus vastavad ühtsele disainisüsteemile või s ilijuhendile.

 Klahvikombinatsioonid ja kiirtoimingud (kui rakendatud): töötavad järjepidevalt kõigis vaadetes.

 Terminoloogia: teks d ja nimetused (nt “kasutaja”, “konto”, “fail”) on järjepidevalt samad kogu rakenduses.

 Andmete sisestuse valideerimine: sisestusväljade puhul kasutatakse valideerimist enne serverisse saatmist, et ilmseid vigu kasutajale kiiremini esile tuua.

4. Backend nõuded (API/teenused)

4.1 Konfiguratsioon ja deploy  Seadistused: keskkonnaspetsiifilised väärtused hoitakse rakendusest väljas (Azure Key

Vault, keskkonnamuutujad), aga konfiguratsioon ise on koodi juures vastavates failides.

 Konfiguratsioon: konfiguratsioon on versioneeritav ja muudatused jälgitavad.

 Ehitamine: Java projek de ehitamisel eelistatakse Gradle-t.

4.2 API disain ja dokumentatsioon  Versioonimine: REST/HTTP liidesed on versioonitud (nt /v1).  Dokumentatsioon: kõik REST/HTTP liidesed peavad olema dokumenteeritud nii, et

partneritel ja RMK-l on võimalik neid kasutada ja tes da. Dokumentatsiooni võib teha erineval viisil (nt kirjalik juhend, Postman collec on, README näidised). Soovitatavalt kasutatakse masinloetavat standardit OpenAPI ja sellest genereeritud Swagger liidest.

 Asukoht: kui kasutatakse OpenAPI/AsyncAPI dokumentatsiooni, peab vastav fail asuma samas Git repo-s koos lähtekoodiga, et see oleks ala koodiga kooskõlas.

 Koormuse juh mine: kasutatakse mehhanisme ülekoormuse väl miseks (nt rate limi ng, thro ling).

 Veakäsitlus: veateated on standardiseeritud, inimloetavad ja ei sisalda tundlikku sisemist infot.

 Sisend, väljund: API sisend ja väljund peab jälgima REST põhimõ eid (h ps://res ulapi.net/).

 Protokoll, formaat: kasutatakse HTTP protokolli ja API väljund on JSON, välja arvatud binaarfailide puhul.

4.3 Töökindlus ja monitooring  Health-checkid: rakendus peab pakkuma health-check ja readiness liideseid(Spring Boot

Actuator).

 Observability: rakendused edastavad minimaalselt request count, response me, error rate mõõdikuid Azure Monitori(Micrometer)

 API töökindlus: API peab olema kasutatav (vastab päringutele) ja enamus päringuid peab lõppema mõistliku aja jooksul ning ilma veata. Täpsemad jõudluse või töökindluse eesmärgid määratakse projek põhiselt.

 Tes mine: Integratsiooniteste ja end-to-end teste võib kirjutada. Nende puudumisel tuleb enne release-i teha regressioonites mist käsitsi.

4.4 Koodistruktuur ja arendus  Struktuur: Java projek des kasutatakse kihipõhist package struktuuri, kus komponendid on

jaotatud package-tesse tehnilise rolli järgi (nt controllers, services, repositories).  Perioodilised tööd: kõik schedulerid, batchid ja stored procedures dokumenteeritakse

README-s. Perioodiliste tööde käivitamine eraldi klassis äriloogikast.  Automaatne andmete kustutamine: kui süsteemis on andmeid, millel on määratud

säilitustähtaja (vastavalt teabe liigitusskeemile), tuleb rakendada automaatne kustutamise funktsionaalsus. Automaatne kustutamine toimub perioodilise tööna (scheduler, batch), mis kontrollib andmete vanust ja kustutab andmeid, mis on ületanud säilitustähtaja. Kustutamise protsess peab olema logitud.

 Teenusklassid: äriloogika peab olema realiseeritud Service kihis, mille sisendiks ja väljundiks on domeeniobjek d. Teenuseklassi tes deks on unit tes d.

 Kontrollerid: Kontrollerite tes d tuleb kirjutada kasutades MockMvc raamis kku, kus teenuste kihi vastused on mockitud.

 Presentatsioonikiht: presentatsioonikiht ei tohi kasutada sisendiks ja väljundiks domeeniobjekte, vaid eraldi Request ja Response ressursse.

 Autoriseerimine: päringute autoriseerimine peab toimuma kontrollerite kihis.  Tes mine: koodi unit tes de haru-ka uvus(branch coverage) peab olema 80%. Unit tes d

tuleb jooksutada CI/CD süsteemis iga buildiga uues . Build peab katki minema, kui tes d pole edukad. Repository (ja messaging) kihi tes d tuleb kirjutada integratsioonites dena vastu mockitud (nt rest apid) või konteineris jooksva päris välise süsteemi vastu (näiteks rakenduse Postgres baas TestContainers abil). Iga test hoolitseb ise oma testandmete loomise ja esialgse seisu taastamise eest. Erinevates tes des samade andmete kasutamine ei ole lubatud.

 Koodistandard: vaikimisi kasutatakse Google Java koodistandardit, mille kontrollimine on osa buildist.

4.5 Integratsioon  Andmebaasid, välised liidesed: andmebaasi ja teiste väliste andmete küsimine peab olema

lahendatud eraldi repository kihis, mis väljastab äriloogika kihile ainult domeeniobjekte.

 Sõnumid, even d: even de saatmine ja vastuvõtmine peab olema realiseeritud äriloogikast eraldi consumerites ja producerites.

5. Logimine Logimisnõuded on kirjeldatud dokumendis „Logimise spetsifikatsioon“.

 NB! Välisele arenduspartnerile väljastatakse “Logimise spetsifikatsioon” dokument peale hankelepingu sõlmimist.

6. Andmebaasi ja andmetöötluse nõuded

6.1 Üldpõhimõ ed  Andmete terviklikkus: kõik andmebaasi struktuurid (tabelid, seosed, indeksid) peavad

tagama andmete terviklikkuse ja väl ma duplikaate või orvuks jäänud kirjeid.

 Normaliseeritus: andmemudel peab olema vähemalt 3. normaalkujus või põhjendatult denormaliseeritud (näiteks jõudluse kaalutlustel).

 Järjepidevus: andmete formaat ja tähistus (nt kuupäevad, valuutad, staatuse väljad) peab olema ühtne kogu süsteemis.

 Äriloogika: relatsioonilisse baasi tuleb suhtuda kui andmete hoidlasse, äriloogika peab olema implementeeritud rakenduskihis. Stored procedure kasutamine ei ole lubatud.

6.2 Iden fikaatorid ja audit  Primaarvõtmed: numbrilised ID-d on eelistatud, mi e UUID, välja arvatud kui on tehniline

vajadus globaalseks unikaalsuseks.

 Auditväljad: igas tabelis, kus toimub andmete muutmine, peavad olema väljad created_by, created_at, modified_by, modified_at. Ajatemplid (created_at, modified_at) on vajalikud ka andmete automaatseks kustutamiseks vanuse järgi.

 Kustutuse logimine: kõik andmete kustutamise operatsioonid (nii automaatsed kui käsitsi) peavad olema logitud koos kustutatud andmete tüübi, kustutamise ajaga, põhjuseks ja tegijaga (süsteem või kasutaja).

 Auditlogi või event sourcing: kasutatakse sõltuvalt süsteemi iseloomust ja ärivajadusest.

6.3 Platvorm ja tööriistad  Andmebaasi tarkvara: RMK eelistatud andmebaas on PostgreSQL. Arenduse ja tes mise

eesmärgil võib kasutada ka mäluandmebaase (nt H2, SQLite3).

 Migratsioonid: kõik struktuurimuudatused hallatakse migratsioonitööriistadega ja versioonihalduses (soovitatavalt Flyway). Käsitsi tehtud muudatused ei ole lubatud, välja arvatud erandkorras ja RMK-ga eelnevalt kooskõlastatult. Kõik sellised muudatused tuleb dokumenteerida ja kanda tagasi migratsiooniskrip desse, et tagada keskkondade ühtsus.

6.4 Turvalisus ja juurdepääs  Paroolid ja auten misandmed: salvestatakse ainult soolatud räsi kujul (nt Argon2, bcrypt,

scrypt). Lih eks na talletamine on keelatud.

 Õiguste haldus: andmebaasis kasutatakse eraldi kontosid rakenduse ja haldustööde jaoks (väikseima privileegi põhimõte).

7. Turvanõuded

7.1 Üldised põhimõ ed  Auten mine ja iden teet: rakendused ja kasutajad tuvastavad end RMK auten misnõuete

alusel (Entra ID, TARA väliskasutajatele).

 Autoriseerimine: juurdepääs rakendustes toimub rollipõhiselt. Rollide nimetusvorming: APP- {env}-{teenus}-{roll}.

 Andmete liigitus: rakenduse planeerimisel määratakse andmete tüüp ja liigitus, dokumenteeritakse nende käsitlemise alused. Säilitustähtajad määratakse vastavalt teabe liigitusskeemile Jira Asse s ja andmesäilituse teemapolii kale.

 Turvaline arendus: rakenduse arendamisel järgitakse RMK dokumente Arenduse elutsükkel ja Turvaline arhitektuur.

 Andmekaitse: mi eavalikud andmed kaitstakse vastavalt teabe liigitusskeemile ja andmekaitse nõuetele. Töötlemisel järgitakse keh vaid andmekaitse õigusakte, sh GDPR.

 Andmevahetus: kogu andmevahetus on krüpteeritud (TLS 1.2+); kasutatakse RMK krüptograafia juhendis määratud protokolle ja vorminguid.

 Auditväljad ja -logi: rakendustes logitakse, millal ja kes kirje lõi ning viima muu s (audit trail).

 Saladuste haldus: kõik võtmed ja paroolid hoitakse Azure Key Vault-s, mi e lähtekoodis või konfiguratsioonifailides.

 Keskkondade eraldatus: live keskkond peab olema rangelt eraldatud arendus- ja testkeskkondadest. Toodanguandmeid ei tohi kasutada arendus- ega testkeskkondades.

 Vajaduspõhine ligipääs: kõik ligipääsud lähtuvad vajaduspõhimõ est (default deny).

 Vähima privileegi põhimõte: kõik protsessid töötavad vähimate vajalike õigustega.

 Auten mise integreerimine: kasutajate õiguseid arvestatakse läbivalt igal tasemel (UI, äriloogika, andmebaas, integratsioonid).

7.2 Sessioonid  Timeout: serveripoolne sessiooni idle meout ≤ 30 minu t, absoluutne meout ≤ 12 tundi.

 Sessiooni turvalisus: sessiooni ID logitakse vajadusel maskitult või räsitult.

 Sessiooni lõpetamine: sessioon suletakse automaatselt, kui kasutaja logib välja või jõuab meout.

7.3 Lähtekood ja arendusvahendid  Ligipääs: lähtekood asub RMK Azure DevOps keskkonnas, kus ligipääsu hallatakse projek

põhiselt.

o RMK arendajatele antakse ligipääs vajaduspõhiselt töölepingu keh vuse ajal.

o RMK töötajatele antakse ligipääs ainult vajaduse korral ja vaikimisi lugemisõigus.

o Välistele arendajatele antakse projek põhine ligipääs, mis eemaldatakse projek lõppedes.

 Lähtekoodi turvalisus: tuleb väl da lubamatute funktsioonide lisamist ja tagada, et lähtekood, arendusvahendid ja teegid on kaitstud tahtmatute või pahatahtlike muudatuste eest.

 Koodi kvaliteet: turvavigade automaatne analüüs (nt Sonar).

8. Hooldatavus ja toetatavus  Koodistandardid: rakenduse kood peab olema ühtses s ilis, loetav ja järgitav, et ka uus

arendaja saaks töö kiires üle võ a.

 Juhendite prak lisus: dokumentatsioon peab olema piisavalt selge, et uuel arendajal või administraatoril oleks võimalik süsteem kiires üle võ a.

 Tes d: rakenduse põhitöövood peavad olema kaetud automaatsete tes dega. See võimaldab veenduda, et süsteemi põhifunktsioonid töötavad ka pärast muudatusi. Täpsemalt vt peatükk 9.

 Runbook-d (käitamis- ja taastamisjuhendid): krii liste töövoogude ja häireolukordade jaoks peab olema lühike samm-sammuline juhend, mis kirjeldab, kuidas probleem lahendada või süsteem taastada.

 Tugi ja eskaleerimine: peab olema selge, kes ja kuidas reageerib süsteemi tõrgetele ning millised on reageerimisajad erineva tõsidusega olukordades.

9. Tes mine  CI/CD ja build: unit- ja integratsioonites d peavad jooksma igal ehitusel. Build peab

ebaõnnestuma, kui tes d ei ole edukad.

 Peaharu: main haru peab ala olema tes tud ja valmis produc on keskkonda paigaldamiseks.

 Tes de ka uvus: unit tes de haru-ka uvus (branch coverage) peab vaikimisi olema 80%. Projek - või hankepõhisel kokkuleppel võib tase olla madalam ning erand tuleb fikseerida kirjalikult.

 Tes de liigid ja kasutus:

o Unit tes d: puhta loogika tes miseks, kus on konkeete sisend ja väljund. Unit tes d ei sobi tes deks, mille osaks on I/O, võrguga seotud funktsionaalsus või aeg.

o Integratsioonites d: katavad liideseid ja sõltuvusi(andmebaas, failisüsteem, MQ, REST liidesed jne)

o End-to-end tes d: katavad kasutaja töövooge (nt Playwright); vaikimisi katame E2E tes dega ainult põhitöövood.

 Testandmed: iga test loob ise testandmed ja vajadusel taastab esialgse seisu; erinevates tes des samu testandmeid kasutada ei tohi.

 Integreerimis- ja E2E tes d: kui neid ei ole, tuleb enne release'i teha regressioonites mine käsitsi.

 Testkeskkonnad ja -andmed: tes mise käigus ei tohi kasutada toodanguandmeid arendus- ega testkeskkondades (vt 7.1).

 Turva- ja jõudlustes d: tehakse projek ja vajaduspõhiselt.