Üldkäskkiri

KÄSKKIRI

Tallinn 18.03.2025 nr 3-1/58

Avatud hankemenetlusega riigihanke ,,Rahvastikuregistri menetlustarkvara baaslahenduse

arendus, I etapp (287849) alusdokumentide muutmine

Siseministeeriumi infotehnoloogia- ja arenduskeskuse riigihangete korra punkti 6.4 alusel:

1. Muudan peadirektori 20.02.2025 nr 3-1/50 käskkirjaga kinnitatud riigihanke alusdokumente

järgmiselt:

1.1. „Tehniline kirjeldus“ punkti 10 (muudetud dokument lisatud).

1.2. ,,Vastavustingimused’’ punkti 6 lisatakse juurde sõnastus (dokument lisatud):

,,Loetletud on hankija vaates olulised rollid. Pakkuja otsustada jääb, kui mitu isikut konkreetsesse rolli

hankelepingu täitmise eesmärgil pakutakse. Juhul, kui pakkuja peab oluliseks suurendada meeskonda,

siis see on lubatud, kuid iga uus liige peab vastama hankes esitatud nõuetele.

Juhul kui hankes ei ole kirjeldatud rolli, mida pakkuja peab vajalikuks meeskonda kaasata, eeldab

hankija, et pakutaval isikul on vähemalt IT-alane kutseharidus keskhariduse baasil (sh on aktsepteeritud

ka IT-alane kutsekeskharidus) ja tal on oma rollis vähemalt 5-aastane töökogemus või IT-alane

kõrgharidus ja tal on oma rollis vähemalt 3-aastane töökogemus. Nõuetele vastavuse tõendamiseks

tuleb esitada CV.’’

(allkirjastatud digitaalselt)

Mart Nielsen

peadirektor

TEHNILINE KIRJELDUS

Sisukord

1. SISSEJUHATUS ......................................................................................................................... 3

2. HANKE ESE JA TULEM ............................................................................................................. 3

2.1. Hanke ese ........................................................................................................................ 3

3. RAHVASTIKUREGISTRI INFOSÜSTEEM. KASUTATAVAD TEHNOLOOGIAD. ............................. 4

3.1. Rahvastikuregister (RR) ................................................................................................... 4

3.2. Rahvastikuregistri menetlustarkvara .............................................................................. 5

3.3. Rahvastikuregistri iseteenindusportaal ehk e-rahvastikuregister .................................. 6

3.4. Rahvastikuregistri broneerimissüsteem ......................................................................... 7

3.5. Rahvastikuregistri teavitussüsteem ................................................................................ 7

3.6. Rahvastikuregistri andmeladu ja -analüütika ................................................................. 7

3.7. X-tee ................................................................................................................................ 8

3.8. Rahvastikuregistri haldusandmed .................................................................................. 8

4. UUE RAHVASTIKUREGISTRI MENETLUSTARKVARA LOOMINE ................................................ 8

4.1. Visioon............................................................................................................................. 8

5. DETAILANALÜÜS ................................................................................................................... 10

5.1. Nõuded detailanalüüsile ............................................................................................... 11

6. OTSINGUD ............................................................................................................................. 12

6.1. Üldised nõuded otsingutele .......................................................................................... 12

6.2. Üldised nõuded otsitulemustele ................................................................................... 14

6.3. Isikuotsing ..................................................................................................................... 14

6.3.1. Nõuded isikuotsingule .............................................................................................. 16

6.3.1.1. Menetlustarkvara kasutaja ................................................................................... 16

6.3.1.2. Menetlustarkvara arendaja .................................................................................. 17

6.3.1.3. X-tee teenused ...................................................................................................... 17

6.4. Dokumendiotsing .......................................................................................................... 18

6.4.1. Nõuded dokumendiotsingule ................................................................................... 19

6.4.1.1. Menetlustarkvara kasutaja ................................................................................... 19

6.4.1.2. Menetlustarkvara arendaja .................................................................................. 20

6.4.1.3. X-tee teenused ...................................................................................................... 20

7. MENETLUSTARKVARA KASUTAJALIIDES ............................................................................... 20

7.1. Üldised nõuded kasutajaliidesele ................................................................................. 21

8. KASUTAJATE HALDUS ............................................................................................................ 21

8.1. Üldised nõuded kasutajate haldusele ........................................................................... 21

9. ANDMESIIRE .......................................................................................................................... 22

10. MENETLUSTE INFOSÜSTEEMI PLATVORM ........................................................................ 22

10.1. Nõuded lahendusele ................................................................................................. 23

10.2. Nõuded andmebaasile .............................................................................................. 24

10.3. Nõuded X-tee teenustele .......................................................................................... 24

10.4. Nõuded logimisele .................................................................................................... 25

10.5. Nõuded liidestustele ................................................................................................. 25

10.5.1. Rahvastikuregistri haldussüsteemi rakendused ....................................................... 25

10.5.2. Liidestused kolmandate osapooltega ....................................................................... 25

10.6. Nõuded sõnumiruumile ............................................................................................ 26

10.7. Monitooring .............................................................................................................. 26

10.8. Infosüsteemi mittefunktsionaalsed nõuded ............................................................. 26

11. ÜLEANTAV TULEM ............................................................................................................ 27

12. NÕUDED TESTIDELE JA TESTIMISELE ................................................................................ 28

13. NÕUDED ARENDUSELE JA DOKUMENTEERIMISELE ......................................................... 29

13.1. Nõuded arendusele .......................................................................................................... 29

13.2. Nõuded dokumenteerimisele ................................................................................... 31

1. SISSEJUHATUS

Käesolev hange on esimene osa tervikprojektist, mille lõpuks soovitakse välja arendada uus

rahvastikuregistri menetlustarkvara ning võtta see tänase vana rahvastikuregistri menetlustarkvara

asemel kasutusele.

Uus menetlustarkvara peab toetama ja lihtsustama ametnike tööprotsesse, võimaldama menetluste

automatiseerimist, toetama e-teenuste pakkumist ning olema lihtsasti täiendatav ja uuendatav. See

peab igas mõttes vastama kaasaegsetele nõudmistele ning tagama maksimaalse kasutusmugavuse ja

efektiivsuse, aitama kasutajatel töötada kiiremini ja tõhusalt ning teha tööprotsesside läbiviimisel vähem

vigu.

Käesoleva hankega loome eelduse tervikprojektiga edasi liikumiseks.

2. HANKE ESE JA TULEM

2.1. Hanke ese

Hanke ja hankemenetluse tulemusel sõlmitava lepingu esemeks on järgnev:

2.1.1. Detailanalüüs

2.1.2. Loodud on uus menetluste infosüsteemi platvorm (infosüsteemi arhitektuur, tehnoloogilised

komponendid):

2.1.2.1. süsteemi komponendid: klientrakendus, serverrakendus, andmebaasid

2.1.2.2. logimine: süsteemi toimimine, kasutaja tegevused, teenuste saatmise ja vastuvõtmise

logid

2.1.2.3. liidestused kolmandate osapoolte teenustega (nt x-tee, kinnistusraamat jmt)

2.1.3. Loodud on järgmised funktsionaalsused:

2.1.3.1. kasutaja töölaud

2.1.3.2. liidestused RRi teiste rakendustega

2.1.3.3. sisselogimine ja kasutajate haldus

2.1.3.4. kaks otsingut koos otsitulemuste kuvadega:

2.1.3.4.1. isikuotsing

2.1.3.4.2. dokumendiotsing

2.1.3.5. isikuandmete detailvaade

2.1.3.6. dokumendi detailvaade

2.1.4. Loodud on otsinguteks vajalikud teenused rahvastikuregistris x-tee teenusrakenduses:

2.1.4.1. isikuotsing

2.1.4.2. dokumendiotsing

2.1.5. Andmesiire

Hanke tulemusel on loodud tarkvara platvorm, mis võimaldab järgmistes etappides arendada välja

kohalike omavalitsuste poolt kasutatavaid menetlusi.

Hankelepingu täitmisel tuleb lähtuda relevantsetest õigusaktidest jm regulatsioonidest, valdkondlikest

strateegiatest ja arengukavadest:

 Sidusa Eesti arengukava;

 rahvastikuregistri seadus;

 perekonnaseisutoimingute seadus;

 nimeseadus;

 haldusmenetluse seadus;

 andmekaitse seadus;

 ja muud seonduvad õigusaktid.

3. RAHVASTIKUREGISTRI INFOSÜSTEEM. KASUTATAVAD TEHNOLOOGIAD.

Rahvastikuregister on andmekogu, mis koondab Eesti kodanike, Eestis elukoha registreerinud Euroopa

Liidu, Euroopa Majanduspiirkonna liikmesriigi ja Šveitsi Konföderatsiooni kodanike ja Eestis elamisloa või

elamisõiguse saanud välismaalaste ning teiste rahvastikuregistrisse kantud isikute peamisi isikuandmeid

ja isikuandmetega seotud andmeid, rahvastikuregistri pidamist abistavaid andmeid, rahvastikuregistri

objekti staatust ettevalmistavaid andmeid ja rahvastikuregistri arhiivis säilitatavaid andmeid.

Rahvastikuregistri vastutav töötleja on Siseministeerium ja rahvastikuregistri volitatud töötleja on

Siseministeeriumi infotehnoloogia- ja arenduskeskus (SMIT).

Järgnevalt on kirjeldatud rakendused, millest rahvastikuregistri andmekogu koosneb.

3.1. Rahvastikuregister (RR)

RR on andmekogu tuumrakendus. Rahvastikuregistrisse tehti 2023. aastal ~200 miljonit päringut.

Rohkem kui 70% operatiivandmebaasist sisaldab X-tee teenuste päringute logisid. Rahvastikuregistrisse

teevad päringuid enamus riigiasutusi, kohalikud omavalitsused ja ka erasektori ettevõtted (suurimad on

pangad ja laenukontorid). See rakendus ei ole käesoleva hanke skoobis.

Rahvastikuregistri rakendus pakub X-tee teenuseid nii andmekogu alamsüsteemidele kui ka avalikule ja

erasektorile. Tegemist on tarkvaraga, mis võeti kasutusele 2010. aastal, kuid arhitektuur ja tehnilised

valikud on tehtud ca 15 aasta tagasi.

RRi keskmeks on andmekogu andmeid hoidev andmebaas Progress OpenEdge platvormil. Teenused on

realiseeritud keeles OpenEdge Advanced Business Language (ABL) ning neid käitatakse OpenEdge

WebSpeed keskkonnas.

Rahvastikuregistri haldamiseks on loodud rakendus RR Admin, kus saab teha erinevaid toiminguid.

Näiteks: RR kodifikaatorite, asutuste, häälestuste loomine ja muutmine, aadressandmete haldamine,

ligipääsude haldamine, andmete muutmine, järelevalve jne. RR Admin on loodud Progress WebClient

tehnoloogiat kasutades.

SMIT on välja töötanud rahvastikuregistri uue arhitektuurivisiooni, mis näeb ette mikroteenustel ja

konteinerarhitektuuril põhinevaid lahendusi.

3.2. Rahvastikuregistri menetlustarkvara

RR menetlustarkvara näol on tegemist ametnikele suunatud rakendusega, mis võimaldab teostada

toiminguid rahvastikuregistri andmekogus olevate andmetega. Vastavalt pädevusele ja õigustele on

kasutajal võimalik teha järgmist:

 päringuid isikuandmete, dokumentide, kannete ja toimikute kohta;

 menetlustoiminguid ja kandeid;

 tõendite ja väljavõtete väljatrükke;

 andmete ja kannete parandamist;

 aruandlust ja statistika päringuid;

 aadressmuudatuste ja valimisteatiste edastamist ja vastuvõtmist;

 kasutajate, rollide ja õiguste haldamist;

 järelevalvetoiminguid.

Menetlustarkvaras tehakse ligikaudu 70 menetlustoimingut. Rakendatud on 45 erinevat rolli, kusjuures

ühel isikul võib olla tulenevalt tööülesannetest üks kuni mitu rolli samaaegselt. Rollile vastab üks kuni

mitu õigust, mida kasutaja saab menetlustarkavaras vaadata/teostada. Isikukoodi andmise menetluse

õigustega on hetkel suurusjärgus 580 kasutajat. Elukoha menetluse õigustega on suurusjärgus 340

kasutajat. Ametnikke, kes menetlustarkvara kasutavad on ligikaudu 1700.

Menetlustarkvara kasutajad jaotuvad laias laastus kaheks:

 asutused kellel on andmete sisestamise ja muutmise õigused (nt linnavalitsused, vallavalitsused,

notarid, välisesindused jne)

 üksnes vaataja õigustega asutused (nt Rahvusarhiiv).

Menetlustarkvaral ei ole avalikku kasutajaliidest, on vaid piiratud kasutajaskonnale mõeldud tarkvara

kasutajaliides. Rakendus ei ole kasutajasõbralik ega intuitiivne. Menetlused on ajamahukad, ebaloogilise

ülesehitusega ning vajavad olulist ajakohastamist sh automatiseeritud kontrolle.

Menetlustarkvara arenduskeeleks on C# ja alusraamistikuks .Net Framework. Andmebaasihaldus-

süsteemina on kasutusel Microsoft SQL Server ning suhtlusel andmebaasiga kasutatakse lisaraamistikku

Entity Framework (EF). Klientrakenduseks on töölauarakendus, mille loomisel on kasutatud

lisaraamistikku Windows Form (WinForms). Klient- ja serverrakenduse vahelises suhtluses kasutatakse

lisaraamistikku Windows Communication Foundation (WCF). Menetlustarkvara pakub SOAP põhiseid X-

tee teenuseid, mis vastavad x-tee sõnumiprotokollile v4 (Xtee v6).

Aastatel 2022-2023 viidi läbi menetlustarkvara eel- ja ärianalüüs Finestmedia AS-i poolt (Lisa 9).

3.3. Rahvastikuregistri iseteenindusportaal ehk e-rahvastikuregister

Iseteenindusportaalis on võimalik inimesel vaadata ja muuta enda, oma alaealiste laste ja

eestkostetavate rahvastikuregistris olevaid andmeid ning piirata oma andmetele juurdepääsu. Lisaks on

võimalik esitada elektroonilisi avaldusi (näiteks elukoha ja sünni registreerimiseks), tellida

perekonnasündmuste tõendeid, teha nime sobivuse ja sugulussuhete päringuid ning kasutada muid

rahvastikuregistri teenuseid.

E-rahvastikuregistri andmebaasiks on PostgreSQL ja Redis. Arenduskeelteks on Java ning TypeScript.

Alusraamistikeks on Spring Framework ja Angular. Server rakenduste puhul kasutatud lisa raamistikku

Spring Boot. Veebipõhine klient ning server rakendused suhtluses kasutatakse REST põhist lahendust

(JSON sõnumid).

Automatiseeritud testide loomiseks kasutatakse Selenium raamistikku, lisaks veel ka TestNG ja JUnit

raamistikku koos PageFactory mustriga.

3.4. Rahvastikuregistri broneerimissüsteem

Mikroteenus, mis võimaldab kohaliku omavalitsuse perekonnaseisuametnikul:

 seadistada kalendrisse perekonnaseisutoiminguteks kasutatavaid ruume ja nende parameetreid;

 määrata perekonnaseisutoimingute teostamise aegu;

 lisada kalendrisse muid sündmuseid (nt puhkused), mil perekonnaseisutoiminguid ei teostata;

 reserveerida kalendris perekonnaseisutoimingute läbiviimiseks aeg, sh puhveraeg sündmuse

ettevalmistamiseks;

 muuta kalendris aegu.

Kodanikul on võimalik läbi iseteenindusportaali vaadata, valida ja märkida perekonnaseisutoiminguks (nt

abielu registreerimine või abielulahutus) sobilik aeg.

Rahvastikuregistri broneerimissüsteemi andmebaasiks on PostgreSQL ja arenduskeeleks on PL/pgSQL.

Teenusrakenduse arendusplatvormiks on ASP.NET Core ja arenduskeeleks on C#.

3.5. Rahvastikuregistri teavitussüsteem

Mikroteenus, mis edastab automaatteavitusi inimesele tema esitatud avalduste ja registriandmetega

toimunud muudatustest. Avalduse esitajale saadetakse teavitus e-posti aadressile ja rahvastikuregistri

iseteenindusportaali, kui esitatud avaldusega seoses on toimunud muudatus. Lisaks saab ruumi omanik

automaatsel teavituse isikute kohta, kes registreerivad oma elukoha tema ruumi aadressile või kelle

aadress lõpetatakse.

Rahvastikuregistri teavitussüsteemi andmebaasiks on PostgreSQL ja arenduskeeleks on PL/pgSQL.

Tuumrakenduse arendusplatvormiks on ASP.NET Core ja arenduskeeleks on C#. Adapterrakenduse

arenduskeeleks on Java.

3.6. Rahvastikuregistri andmeladu ja -analüütika

Veebirakendus rahvastikuregistri ja menetlustarkvara statistika vaatamiseks ja töötlemiseks. Andmelao

kasutajateks on Siseministeeriumi töötajad, sh järelevalveametnikud, SMIT registripidajad, menetlejad

(KOV ametnikud, jm menetlejad), kellele on vastav ligipääs ja aruandlus loodud. Vastavalt pädevustele ja

õigustele saab andmelaos luua uusi ja vaadata juba loodud aruandeid. Andmelattu on tänasest

menetlustarkvarast üle viidud aruandlus ja statistikapäringud.

Rahvastikuregistri andmelao ja -analüütika andmebaasiks on PostgreSQL ja arenduskeeleks on

PL/pgSQL. Veebirakenduse arendusplatvormiks on Tableau Desktop ja arenduskeeleks on VizQL.

3.7. X-tee

Eesti riigi põhilisi andmebaase ühendav turvaline ja tõestusväärtust tagav keskkond, mis korraldab

internetipõhist andmevahetust riigiasutuste vahel ja erasektoriga. RRis on kokku kasutusel enam kui 250

x-tee teenust.

3.8. Rahvastikuregistri haldusandmed

Mikroteenused rahvastikuregistri kodifikaatorite/klassifikaatorite, häälestuse parameetrite, asutuste ja

aadresskomponentide haldamiseks ning propageerimiseks vajalikesse rakendustesse ning nende

keskkondadesse. Rahvastikuregistri rakendused kasutavad haldusandmeid nii vajaduspõhiselt kui endale

dubleerimiseks. Samuti on realiseeritud teenused andmete esitamiseks kolmandatele osapooltele X-tee

vahendusel. Kasutatakse järgmiseid tehnoloogiaid: Arenduskeeleks on C#, andmebaasiks PostgreSQL,

liidestamiseks REST X-tee teenuseid ja RabbitMQ sõnumiservereid. SMIT UAA kasutajate autentimise ja

autoriseerimise lahendus, mis on integreeritud RIA TARA-ga, kasutajad ja kasutajagrupid on kirjeldatud

Active Directory-s.

4. UUE RAHVASTIKUREGISTRI MENETLUSTARKVARA LOOMINE

Uue rahvastikuregistri menetlustarkvara projekti eesmärk on luua menetluste läbiviimise lahendus, mille

protsessid ja vaated vastaksid tänastele protsessidele ning toetaksid kasutajaid nende läbiviimisel.

Lahenduse struktuur peab olema piisavalt paindlik, et toetada muudatuste sisse viimist, mis võivad

tekkida protsesside ja vajaduste muutumisel.

4.1. Visioon

Uue rahvastikuregistri menetlustarkvara puhul on planeeritud luua süsteem, mis rakendab

mikroteenuste arhitektuuri põhimõtteid. Mikroteenused luuakse nii, et need koondavad äriliselt kokku

kuuluvaid vajadusi ehk moodustuvad ärifunktsionaalsed grupid. Iga ärilise funktsionaalse grupi jaoks on

loodud vajalikud kasutajaliidese vaated, mis võimaldavad teenusrakenduste funktsionaalsuste tarbimist

kasutajale. Erinevate äriliste funktsionaalsete gruppide vaated on koondatud kokku ühtsesse

veebirakendusse, mis lõppkasutaja jaoks moodustab ühtse ja tervikliku rahvastikuregistri

menetlustarkvara. Veebirakenduse kasutajateks on erinevate valdkondade ametnikud nii Eestis kui ka

välismaal.

Koos menetlustarkvara uuendamisega toimuvad muudatused ka rahvastikuregistri iseteenindusportaali

e-avalduste esitamise vaadetes, kus ühtlustuvad kuvad ning taustaloogika, mida e-avaldustega seotud

protsessides kasutatakse. Suhtlus rahvastikuregistri ning teiste andmekogudega toimub x-

tee andmevahetusplatvormi vahendusel. Eelnevat illustreerib allolev joonis.

Joonis 1. Rahvastikuregistri menetlustarkvara visiooni visand

Uue lahendusega vaadatakse üle ning rakendatakse mitmeid erinevaid nõudeid, mis puudutavad

näiteks:

 järelevalvet kasutajate tegevuste ja andmete kasutamise üle ;

 nõudeid dokumentatsiooni haldusele;

 kasutajate ligipääsude ning privileegide haldust;

 andmete arhiveerimist ning kustutamist.

Loetelu ei ole lõplik, vajadused täpsustatakse hankija poolt tervikprojekti käigus läbiviidavate erinevate

projektide käigus. Lisaks ärivajadustest tulenevatest vajadustest tuleb realiseerida erinevad kaasnevad

nõuded, milleks võivad olla rakenduste monitooring, logimine ja administreerimise funktsionaalsused.

5. DETAILANALÜÜS

Detailanalüüsi eesmärk on selgitada välja vajadused uuele menetlustarkvarale ja pakkuda välja

lahendused. Detailanalüüsi läbiviimine sisaldab endas kõigi nõuete spetsifitseerimist ja kogu tehnilise

dokumentatsiooni läbivaatamist koos hankijaga, et leida hanke eesmärgi saavutamiseks parim lahendus.

Detailanalüüsi tulemusel lepivad hankija ja pakkuja kokku, mida pakkuja realiseerib ning hankija hangib.

Detailanalüüs peab andma vastused küsimusele: mida, millal, kuidas, mis tulemiga ja kes peab saama

erinevaid protsesse/töövooge tarkvaras läbi viia.

Detailanalüüsis tuleb käsitleda vähemalt järgmisi teemasid:

1. Rakenduse kasutajaliides hõlmab vähemalt järgmisi vaateid ja protsesse:

a. sisse- ja väljalogimine

b. veebirakendus

c. kasutajate haldus

d. isikuotsing (mh liidestused x-tee teenustega)

e. dokumendiotsing (mh liidestused x-tee teenustega)

f. kande otsingud

g. toimiku otsingud

h. aadresside otsingud

2. Tehniline lahendus, sh vähemalt:

a. arhitektuur, sh vähemalt

i. Komponendid

ii. Liidestused

iii. paigaldus

b. üldised tarkvara mehhanismid

c. tehnoloogilised valikud

d. perifeeriaseadmete (printer, skänner jms) integreerimine veebirakendusse

e. logimine ja monitoorimine

3. Andmesiire

4. Kasutajate rollid, privileegid ja tegevused (nt juurdepääsupiirangud, andmete vaatamine ja/või

muutmine, menetluste ja otsingute teostamine)

Pakkuja meeskonnalt eeldatakse hankija võimalusi ja soove arvesse võtvat suhtlust ja koostööd hankija

esindajate ja meeskonnaga kogu analüüsi perioodi vältel.

Detailanalüüsi läbiviimisel tuleb arvestada riigihanke (282703) tulemitega. Nõuete realiseerimise ulatus

lepitakse kokku kas pärast kogu detailanalüüsi või selle üksikute osade valmimist.

5.1. Nõuded detailanalüüsile

5.1.1. Olemasoleva dokumentatsiooni ja süsteemianalüüsi tulemina koostab pakkuja ja esitab

hankijale detailanalüüsi dokumentatsiooni (täpsustatud spetsifikatsiooni süsteemi osade kohta,

sh nõuded serveri spetsifikatsioonile).

5.1.2. Detailanalüüsi läbiviimise tegevuskava, formaat ja oodatud tulem lepitakse enne tööga

alustamist kokku hankija ja pakkuja vahel.

5.1.3. Detailanalüüs koostatakse eesti keeles ja esitatakse koos analüüsi käigus tekkinud

dokumentidega (sh analüüsitulemused, intervjuude ja koosolekute memod, protokollid jm

asjasse puutuv).

5.1.4. Detailanalüüs koostatakse detailsusega, mis on sobiv arendajale lähteülesandeks ja testijale

testlugude koostamiseks. Erandiks võib olla hankijaga kokkuleppel tehniline ja kolmanda

osapoole komponentide (mis pole kirjutatud hankija jaoks) dokumentatsioon.

5.1.5. Kõik hanke alusdokumentides lõplikult kirjeldamata või ebaselged kohad (nõuded) räägib

pakkuja hankijaga täiendavalt läbi ning lõplik otsus realiseerimisele kuuluvate nõuete osas

fikseeritakse kirjaliku protokollina.

5.1.6. Kui pakkuja jätab lõplikult kirjeldamata osa detailanalüüsist või ebaselged kohad läbi rääkimata,

siis lähtutakse vaidluse tekkimisel hankija tõlgendusest.

6. OTSINGUD

Käesoleva hanke raames loodavad otsingud tuleb realiseerida rahvastikuregistri x-tee teenusrakenduses

eesmärgiga võimaldada menetlustarkvara kaudu ligipääsu rahvastikuregistri andmetele.

Otsingute lahendus peab toetama ja lihtsustama menetlustarkvara kasutajate (ametnike) tööd ning

lühendama menetluse aega (vähem nupuvajutusi, kiirelt vajamineva leidmine jne).

Tänases menetlustarkvaras on võimalik teha erinevaid otsinguid:

 toimikud - kõik toimikud, mis on RR menetlustarkvaras loodud;

 tellimused - PPA tellimused, mida edastatakse RR menetlustarkvarase automaatteenuse kaudu

isikukoodi tellimiseks, dokumendi kandmiseks rahvastikuregistrisse jms;

 käskkirjad - nimemuutmisega seotud käskkirjad/otsused;

 isikud - võimaldab otsida kõiki isikuid, kes on kantud rahvastikuregistrisse kas ID või isikukoodi

alusel ja nendega seotud andmeid;

 dokumendid - võimaldab otsida dokumente, mis on kantud rahvastikuregistrisse (aga mitte

numbri järgi);

 kanded - võimaldab otsida RR kandeid, mille alusel vastavad muudatused andmetes on kantud

rahvastikuregistrisse;

 kartoteek - võimaldab otsida arhiivseid dokumente;

 DIGIS - võimaldab otsida perekonnaakte ja -kirju digitaliseeritud (pildi) kujul.

Uued otsingud, mis tänases menetlustarkvaras puuduvad:

 Tõendite ja väljavõtete otsing

 Aadresside otsing

 Asutuste otsing

Kõik ülal loetletud otsingud tuleb tervikprojekti lõpuks uude menetlustarkvarasse luua. Käesoleva hanke

skoobis on kaks otsingut:

1. isikuotsing

2. dokumendiotsing

Otsingute lahendus tuleb valideerida hankija meeskonnaga.

6.1. Üldised nõuded otsingutele

Käesolevas peatükis loetletud nõuded on esialgsed ning need tuleb detailanalüüsi käigus läbi töötada ja

vajadusel täiendada. Detailanalüüsi läbiviimisel tuleb arvestada riigihanke (282703) tulemitega. Nõuete

realiseerimise ulatus lepitakse kokku pärast detailanalüüsi otsingute osa valmimist.

6.1.1. Otsingute lahendus peab arvestama kasutajate piirangutega. Kui mingid andmed on piiratud

ligipääsuga, siis kuvatakse kasutajale vastav teavitus.

6.1.2. Kasutaja peab kõigi otsingute tegemisel märkima päringu aluse ja sisestama selgituse. Ilma

nendeta süsteem otsingut teha ei luba ja kuvab kasutajale hoiatus teate selgitusega. Kui

varasema päringu parameetreid avada, siis kuvatakse ka selle päringu alus ja selgitus. Saab

taaskäivitada sama päringut sama aluse ja selgitusega.

6.1.3. Kasutaja peab saama otsingut käivitada läbivalt ühte moodi.

6.1.4. Hoiatuste tekstid peavad läbivalt selgitama kasutajale, mis on probleem ja mida kasutaja peaks

tegema.

6.1.5. Kasutaja peab saama otsingu peatada (nt võtab liiga kaua aega; selgub, et otsingu aluseid on

vaja muuta või täpsustada vm põhjusel).

6.1.6. Otsingu parameetrite välju peab saama kiirelt ühe vajutusega tühjendada.

6.1.7. Kui otsingus kasutatakse kuupäevi, siis on lahenduses alati võimalik sisestada kuupäevade

vahemikku (alates-kuni).

6.1.7.1. Kuupäeva vahemiku loogilised kontrollid tuleb iga parameetri puhul läbi mõelda

detailanalüüsi käigus.

6.1.8. Otsingu parameetrite juures on abistavad selgitustekstid.

6.1.9. Kõik otsingud logitakse ja salvestatakse (RRS § 8 lg 1 ja § 25 p 3).

6.1.10. Süsteem peab otsinguid logima ja neid kuvama kasutajale nii, et kasutaja saab:

6.1.10.1. Näha enda tehtud viimaseid otsinguid (parameetreid, otsingu alus, selgitus, mis

kuupäeval, kellaajal otsing teostatud).

6.1.10.2. Oma logide seast peab saama kuupäeva ja kellaaja järgi otsingut teha.

6.1.10.3. Logide otsimist ja vaatamist tuleb samuti logida.

6.1.11. Otsingu järel peavad otsingu aluseks olnud parameetrid jääma avatuks või ligipääsetavaks nii, et

kasutajal oleks võimalik samal ajal kasutada tarkvara teisi funktsionaalsusi ning ta saab mugavalt

naasta viimati tehtud otsingu ja selle tulemuste juurde.

6.1.12. Otsinguväljad ei ole tõstutundlikud.

6.1.13. Otsingut peab saama teostada ka terviklikku parameetri väärtust teadmata (nt nimes võib olla

mõni tähemärk varasemalt dokumendilt teisel kujul). Süsteem peab tegema taustal kontrolli ja

pakkuma ametnikule võimalikke vasteid.

6.1.14. Otsinguväljadel peab võimalusel olema kasutusel automaatne täitmine ehk otsisõna

ennustamise funktsioon, mille puhul rakendus ennustab ülejäänud sõna, mida kasutaja sisestab.

6.2. Üldised nõuded otsitulemustele

6.2.1. Otsitulemused tuleb kuvada kokkuvõtva numbrina.

6.2.2. Otsitulemused tuleb kuvada tabelis tervikloeteluna, millest peab saama liikuda edasi iga

konkreetse otsitulemi detailvaatesse.

6.2.3. Otsitulemuste tervikloetelus peab olema eristatavad need vasted, mida on juba avatud nendest,

mis on avamata.

6.2.4. Otsitulemuste juures tuleb kuvada erinevaid teateid.

6.2.5. Otsitulemuse detailvaate avamine ei tohi piirata menetlustarkvara teiste funktsioonide tööd.

6.2.6. Otsitulemuste juures peab olema kuvatud päringu andmeid täpsustav info.

6.2.7. Otsingu tulemuste tabeli veerge peab saama liigutada kasutajale sobivasse järjekorda.

6.2.8. Otsitulemuste tabelis on tulemused kuvatud vaikimisi igas tulbas järgnevalt:

6.2.8.1. Dokumendi (tulevikus ka kanne, toimik, tellimus, kartoteek) otsitulemused on

järjestatud vastava kuupäeva järgi varasemast hilisemani.

6.2.8.2. Asutuste ja aadresside otsitulemused on järjestatud tähestikulises järjekorras A-Z.

6.2.8.3. Isiku otsingu tulemused on vaikimisi järjestatud isikukoodi järgi.

6.2.8.4. Kui on aktiveeritud ka ajalised parameetrid, siis on lisaks järjekord ajalise arvestusega.

6.2.9. Otsitulemusi peab saama tabelis sorteerida.

6.2.10. Otsitulemusi peab saama filtreerida iga tabeli veeru lõikes.

6.2.11. Otsitulemuste kuvamisel tuleb lähtuda kasutaja õigustest.

6.2.12. Kõik otsitulemusi puudutavad nõuded täpsustatakse detailanalüüsis.

6.3. Isikuotsing

Isiku otsingut tehakse peamisel kahel põhjusel:

1. menetluse alustamisel, menetluse sees või konkreetse isiku kohta teatud info leidmiseks – eeldus,

et inimene on RR-is olemas.

2. isikule isikukoodi loomisel topelt isiku tegemise välistamise kontroll – eeldus, et isiku andmed

võivad olla RR-is , aga näiteks nime kuju, sugu või sünniaeg võib olla hetkel esitatust erinev.

Alljärgnevalt on välja toodud isikuotsingu parameetrid:

1. Eesti isikukood

2. Välisriigi isikukood

3. Eesnimi

4. Perenimi

5. Isanimi

6. Otsing muude nimede hulgast

7. Kodakondsus

8. Muu kodakondsus

9. Sugu

10. Sünniaeg

11. Isiku olek

12. Kirje olek

13. Kirjel oleku põhjus

14. Surma kuupäev

15. Elukoht

16. Sünnikoht

17. Viibimiskoht

18. Lisa-aadress

19. Paralleel-aadress

20. Arhiivi kandmise alus

Loetletud parameetrid on esialgsed ning need tuleb detailanalüüsi käigus läbi töötada ja täpsustada.

Detailanalüüsi läbiviimisel tuleb arvestada riigihanke (282703) tulemitega. Nõuete realiseerimise ulatus

lepitakse kokku pärast detailanalüüsi otsingute osa valmimist.

6.3.1. Nõuded isikuotsingule

Järgnevalt on toodud miinimumnõuded isikuotsingule, mis peavad täpsustuma ja täienema

detailanalüüsi käigus. Otsingud realiseeritakse rahvastikuregistri andmete alusel.

6.3.1.1. Menetlustarkvara kasutaja

6.3.1.1.1. Kasutajaliidese kaudu peab saama otsida isikut erinevate parameetrite järgi, et valida

edasisteks menetlusteks õige isik.

6.3.1.1.2. Kasutajaliidese kaudu peab saama valida otsingu tulemustest mõne isiku tema detailandmete

vaatamiseks, et kontrollida isiku andmete õigsust. Hanke koostamise hetkel teadaolevad

andmete liigid on:

6.3.1.1.2.1. Isiku põhiandmed;

6.3.1.1.2.2. Isiku dokumendid;

6.3.1.1.2.3. Isiku suhted;

6.3.1.1.2.4. Isikuga seotud hooldusõigused;

6.3.1.1.2.5. Isiku aadressid;

6.3.1.1.2.6. Isiku kontaktid;

6.3.1.1.2.7. Isikuga toimunud muudatused

6.3.1.1.2.8. Isiku viibimiskoht

6.3.1.1.2.9. Lisa-aadress

6.3.1.1.2.10. Arhiivi kandmise alus

6.3.1.1.2.11. Endine isikukood

6.3.1.1.3. Andmete liigid võivad detailanalüüsi käigus täieneda ja täpsustuda.

6.3.1.1.4. Loodav otsingulahendus peab olema (taas)kasutatav nii eraldi menüüpunkti kui ka nt

"modaali" alt ehk vahel on tarvis otsida isikut ka mõne muu protsessi sees.

6.3.1.1.5. Kasutajaliidese kaudu peab saama teha topelt isiku tegemise välistamise kontrolli otsingut (vt

punkt 6.3). Probleem on, et kui isiku nimekuju võib olla varasemates kannetes teine (nt a

asemel o või u; x asemel ks; i asemel ii või vastupidi jne), samuti võib olla nimi või sugu

muutunud jne. Sellise otsingu puhul võib olla vajalik kontrollida isiku sünnikohta, sünniaega,

isa nime või muid parameetreid.

6.3.1.1.6. Andmekaitse ja haldusõiguse vaatest tohib ametnik küsida ja talle kuvatakse vaid neid

andmeid, mida menetluse eesmärgi täitmiseks vajatakse ning rohkem mitte. Seega otsingu

tulemuste kuvamisel pakkuda lahendus, mis välistab andmete liiasusega töötlemise.

6.3.1.1.7. Esmane kuvatav info on üldine, kuid avada peab saama isiku detailandmete vaate, kui

menetlejal on vastavad õigused.

6.3.1.1.8. Kasutaja peab saama tulemuste tabelist valida isikut, kelle detailandmeid ta vaadata soovib

või alustada selle isikuga menetlust.

6.3.1.1.9. Isiku detailandmete vaates suhete alamjaotises saaks vaadata ja avada suhte teise osapoole

andmeid. Ei vajaks eraldi suhte osapoole isiku päringu tegemist.

6.3.1.1.10. Kasutaja peab saama isiku rea aktiveerimisel teostada täiendotsingu selle isikuga samal

aadressil elavate isikute kohta.

6.3.1.2. Menetlustarkvara arendaja

6.3.1.2.1. Tulevaste funktsionaalsuste arendajana soovin, et loodav otsingu lahendus oleks

(taas)kasutatav nii eraldi menüüpunkti kui ka nt "modaali" alt ehk vahel on tarvis otsida isikut

ka mõne muu protsessi sees.

6.3.1.2.2. Tulevaste funktsionaalsuste arendajana soovin, et loodav isiku detailandmete kuvamise

lahendus oleks (taas)kasutatav nii eraldi menüüpunkti, kui ka näiteks "modaali" alt ehk vahel

on tarvis otsida isikut ka mõne muu protsessi sees.

6.3.1.3. X-tee teenused

6.3.1.3.1. Otsingu teostajana soovin anda teenuse sisendparameetriks punktis 6.3 loetletud

otsinguparameetrid.

6.3.1.3.2. Otsingu teostajana soovin saada teenuse väljundisse loetelu isikutest, kes vastavad punktis

6.3. loetletud sisendparameetritele.

6.3.1.3.3. Otsingu teostajana soovin saada teenuse väljundisse iga isiku kohta punktis 6.3. loetletud

andmeväljad.

6.3.1.3.4. Otsingu teostajana soovin pärida teenusega punktis 6.3. loetletud vajalikke isiku

detailandmeid.

6.4. Dokumendiotsing

Dokumendiotsingu teemaplokis on koos kõik erinevat tüüpi isikuga seotud dokumendid, sh tõendid,

väljavõtted ja isikule RR-is edastatud dokumendid (pass, ID-kaart jne).

Alljärgnevalt on välja toodud dokumendiotsingu parameetrid:

Dokumendi liik

Dokumendi alamliik

Riik

Asutus

Asutuse nimetus

Koostamise kuupäev

Sündmuse/jõustumise kuupäev

Dokumendi number

Eesti isikukood

Välisriigi isikukood

Kodakondsus

Muu kodakondsus

Eesnimi

Perekonnanimi

Isanimi

Otsing muude nimede hulgas

Sugu

Sünniaeg

Taastatud

Dokumendi olek

Automaatotsus

Loetletud parameetrid on esialgsed ning need tuleb detailanalüüsi käigus läbi töötada ja täpsustada.

Detailanalüüsi läbiviimisel tuleb arvestada riigihanke (282703) tulemitega. Nõuete realiseerimise ulatus

lepitakse kokku pärast detailanalüüsi otsingute osa valmimist.

6.4.1. Nõuded dokumendiotsingule

Järgnevalt on toodud miinimumnõuded dokumendiotsingule, mis peavad täpsustuma ja täienema

detailanalüüsi käigus. Otsingud realiseeritakse rahvastikuregistri andmete alusel.

6.4.1.1. Menetlustarkvara kasutaja

6.4.1.1.1. Soovin kasutajaliidese kaudu otsida dokumenti erinevate parameetrite (nt dokumendi liik,

kuupäev jne) järgi, et valida edasisteks menetlusteks õige dokument.

6.4.1.1.2. Soovin kasutajaliidese kaudu otsida erinevate asutuste poolt välja antud tõendeid, tunnistusi

ja väljavõtteid.

6.4.1.1.3. Dokumendi liikide alla peab lisanduma DIGISes olevate dokumentide otsing nimetusega

„DIGIS dokument“.

6.4.1.1.4. Soovin valida kasutajaliidese kaudu otsingu tulemustest mõne dokumendi selle

detailandmete vaatamiseks, et kontrollida dokumendi andmete õigsust.

6.4.1.1.5. Soovin, et kasutajaliides kuvaks dokumentide otsingu tulemused loendina, vastavalt otsingu

kriteeriumitele.

6.4.1.1.6. Soovin, et kasutajaliides kuvaks dokumendi detailandmed dokumendi numbri järgi.

6.4.1.1.7. Aktiveerides tulemuste tabelis konkreetse dokumendi rea tuleb samas vaates kuvada

järgmine info: millises toimikus asub, mis asutuse antud, kellele (kui on mitu dokumendiga

seotud isikut või asutust, siis tuleb kuvada kõik).

6.4.1.1.8. Dokumendiga seotud isikute nimekirjast peab olema võimalik minna otse isiku

detailandmetesse, kui kasutajal on selleks vastavad õigused.

6.4.1.1.9. Dokumendi juurest peab saama edasi liikuda sellega seotud toimikusse ja kandesse (kui neid

on) ja kasutajal on selleks vastavad õigused.

6.4.1.1.10. Kasutaja peab saama dokumenti avada ja alustada selle parandamist, kui reeglid seda

lubavad.

6.4.1.2. Menetlustarkvara arendaja

6.4.1.2.1. Tulevaste funktsionaalsusete arendajana soovin, et loodav otsingu lahendus oleks

(taas)kasutatav nii eraldi menüüpunkti kui ka nt "modaali" alt ehk vahel on tarvis otsida

dokumenti ka mõne muu protsessi sees.

6.4.1.2.2. Tulevaste funktsionaalsuste arendajana soovin, et loodav dokumendi detailandmete

lahendus oleks (taas)kasutatav nii eraldi menüüpunkti, kui ka näiteks "modaali" alt ehk vahel

on tarvis otsida dokumenti ka mõne muu protsessi sees.

6.4.1.3. X-tee teenused

6.4.1.3.1. Otsingu teostajana soovin anda teenuse sisendparameetriks punktis 6.4. loetletud

otsinguparameetrid.

6.4.1.3.2. Otsingu teostajana soovin saada teenuse väljundisse loetelu dokumentidest, kes vastavad

punktis 6.4. loetletud sisendparameetritele.

6.4.1.3.3. Otsingu teostajana soovin saada teenuse väljundisse iga dokumendi kohta punktis 6.4.

loetletud andmeväljad.

6.4.1.3.4. Otsingu teostajana soovin pärida teenusega punktis 6.4. loetletud vajalikke dokumendi

detailandmeid.

Dokumendiotsingu üksikasjad selgitatakse välja detailanalüüsi käigus.

7. MENETLUSTARKVARA KASUTAJALIIDES

Veebirakenduse prototüüp valmib käesolevat hanget ettevalmistava riigihanke (282703) tulemina.

Kasutajaliidese realiseerimisel tuleb lähtuda nimetatud hanke tulemustest. Hanke tulemid on

eeldatavasti valmis 2025. aasta suvel. Juhul kui nimetatud hanke tulemid ei ole mõistliku aja jooksul

valminud ning neid ei ole võimalik aluseks võtta, tuleb pakkujal endal luua kasutajaliidese prototüüp, see

hankija meeskonnaga testida, viia testi tulemusel laekunud parandused sisse ning see realiseerida.

Hankija eeldab, et tarkvara kasutajaliides (ja vajadusel selle prototüüp) luuakse tihedas koostöös hankija

meeskonnaga.

7.1. Üldised nõuded kasutajaliidesele

7.1.1. Kasutajaliides on lahus arendatav, pakendatav, versioneeritav ja paigaldatav.

7.1.2. Kasutajaliides võib korraga suhelda mitme loogikakomponendiga.

7.1.3. Kasutajaliidese olekut hoitakse kliendi poolel.

7.1.4. Kasutajaliides vahetab äriloogika komponendiga ainult andmeid.

7.1.5. Menetlustarkvara kasutajaliidese loomisel tuleb arvestada, et kasutajaliides peab olema

laiendatav ka tulevikus lisanduvatele ärifunktsionaalsetele vaadetele.

7.1.6. Lähtub micro frontend arhitekuurist.

7.1.7. Veebirakendusena tuleb kasutada Typescript (Angular 19 + Angular Material).

8. KASUTAJATE HALDUS

Menetlustarkvara kasutajate õigused lähtuvad sellest, kas ja mis ulatuses tohivad kasutajad

rahvastikuregistris olevaid andmeid näha ja muuta oma asutuse ligipääsude ulatuses ning milliseid

toimingud tohib kasutaja oma õiguste ulatuses teha. Rollidel on privileegid menetluste tegemiseks

(andmete sisestamiseks ja muutmiseks) ja andmete nägemiseks.

Käesoleva hanke raames koostatakse menetlustarkvara kasutajate rollide ja õiguste põhjalik analüüs.

Analüüsitulemused esitatakse CRUD maatriksina ning sellele on lisatud kirjeldused ja täpsustavad

selgitused.

Hankija eeldab, et kasutajate rollide ja õiguste analüüs viiakse läbi tihedas koostöös hankija

meeskonnaga.

8.1. Üldised nõuded kasutajate haldusele

Järgnevalt loetletud nõuded ei ole lõplikud ning need võivad täieneda detailanalüüsi käigus.

8.1.1. Peab saama gruppe luua, kustutada, kirjeldada ja muuta.

8.1.2. Peab saama kasutajaid luua, kustutada, kirjeldada ja muuta.

8.1.3. Peab saama tegevuste privileege luua, kustutada, kirjeldada ja muuta.

8.1.4. Peab saama rolle luua, kustutada, kirjeldada ja muuta.

8.1.5. Kõik kasutajate grupid peavad olema profileeritud: määratletud peab olema, mis menetlusi

tohib/peab kasutaja tegema, nägema ning mis andmeid tohib/peab nägema.

8.1.6. Kasutajate gruppide järgi tuleb luua rollid vastavate privileegidega.

8.1.7. Kasutaja tuvastamiseks peab saama kasutada vähemalt ID-kaarti.

9. ANDMESIIRE

Detailanalüüsi käigus uuritakse vajadust teostada andmesiiret hanke eseme ulatuses. Juhul, kui analüüsi

käigus tuvastatakse vajadus viia läbi andmesiire, tuleb see analüüsidokumendis põhjalikult kirjeldada,

misjärel lepitakse hankijaga kokku selle realiseerimise ulatus.

10. MENETLUSTE INFOSÜSTEEMI PLATVORM

Käesoleva hanke eesmärk on disainida ja luua infosüsteemi platvorm, mis võimaldab järgmistes

arendusetappides järk-järgult välja arendada terviklik menetlustarkvara, mille hulka kuulub ca 70

menetlust.

Detailanalüüsi käigus koostatakse ärifunktsionaalsed grupid ning pakutakse välja mikroteenustel

põhinev tehniline lahendus.

Paika peavad saama järgmised komponendid:

1. veebirakendus;

2. funktsionaalsuste mikrokuva selles;

3. juurdepääsu privileegide ja rollide rakendamine;

4. kasutaja tuvastamine;

5. rakenduslüüside kasutamine;

6. süsteemi teavituste administreerimine;

7. serverrakendused ja nende loomine;

8. kolmandate osapoolte x-tee teenuste kasutamine;

9. perifeeriaseadmete (printer, skänner jms) integreerimine veebirakendusse.

Loetelu ei ole lõplik ning täieneb vastavalt detailanalüüsis püstitatule.

Infosüsteemi platvormi ehitamisel tuleb arvestada riigihanke (282703) tulemitega. Nõuete realiseerimise

ulatus lepitakse kokku kas pärast kogu detailanalüüsi või vastavate osade valmimist.

Hankija eeldab, et uue infosüsteemi lahendus luuakse tihedas koostöös.

10.1. Nõuded lahendusele

Pakutav tehnoloogiline lahendus:

10.1.1. Peab olema pilvesõbralik ehk sobima SMITi pilvekeskkonda (Kubernetes) ja Riigipilvega.

10.1.2. Arvestab SMITis infosüsteemide arendamisele kehtestatud nõuetega, sealhulgas turva- ning

logimisnõuetega.

10.1.3. Arvestab SMITis juba loodud või loodavate sarnaste lahendustega (sh arhitektuuri ümarlaua

suunised) komponentide taaskasutatavuse kontekstis.

10.1.4. Andmesiirdel ja uuele tehnoloogilisele lahendusele ümberlülitumisel on

täidetud rahvastikuregistri menetlustarkvara SLA.

10.1.5. Lahenduse etappidena teostamisel peab olema täidetud rahvastikuregistri menetlustarkvara

SLA.

10.1.6. Lahendus peab olema vähemalt 80% ulatuses kaetud ühik- või integratsioonitestidega.

10.1.7. Lahendus peab kasutajate autentimisel ja autoriseerimisel kasutama OpenID Connect (OIDC)

protokolli.

10.1.7.1. Võimalusel on võimalik kasutada SMIT-i keskset kasutajate autentimise ja

autoriseerimise lahendust UAA (The User Account and Authentication Service (UAA))

10.1.8. Rakenduse tehnilised komponendid kaitsevad iseennast ja valideerivad nende poole

pöördunud kasutaja või tehnilise teenuse õiguseid.

10.1.9. Peab kasutama kasutajaliidesena Typescript (Angular 19 + Angular Material või teist tööde

alguses kehtivat uusimat versiooni).

10.1.10. Uue menetlustarkvara arendamiseks peab kasutama serverkomponentidena Java 21 (Spring

Boot 3 + JOOQ või teist tööde alguses kehtivat uusimat versiooni).

10.1.11. Rahvastikuregistri x-tee teenuste arendamiseks peab kasutama .NET 8 või teist tööde alguses

kehtivat uusimat .NET LTS versiooni. ja C# programmeerimiskeelt.

10.1.12. Komponentide vaheliseks suhtluseks kasutatakse SSL/TSL kanalit.

10.1.13. Tehniliste komponentide API'del eksisteerib automaatselt genereeritud dokumentatsioon

(näiteks Swagger).

10.1.14. Kasutajaliidese olekut (state) hoitakse kliendi liidese poolel ja teenused on ise olekuta.

10.1.15. Kasutaja sessiooni hoidmiseks ei kasutata mälus olevat sessiooni, vaid iga päringuga

valideeritakse päringu teostaja "tokeni" kehtivust.

10.1.16. Kliendil või teenuse haldajal peab olema võimalus kesksest hoidlast tokeniga seotud info

kustutada (nö välja logimine).

10.1.17. Juhul, kui on tarvis liidestuda Rahvastikuregistri Haldusandmetega, tuleb kasutada

sõnumivahetust (RabbitMQ).

10.1.18. Kasutaja arvutisse paigaldatavad rakendused peavad olema digitaalselt allkirjastatud vastava

sertifikaadiga.

10.1.19. Rakenduse lähtekoodi analüüs, paki (artifact) koostamine ja tarnimine toimub Atlassian

Bamboo plaanidega. Plaanide loomisel peab kasutama Bamboo YAML spetsifikatsioone.

10.1.20. Turvameetmete rakendamisel peab süsteem vastama ISO27001 nõuetele.

10.2. Nõuded andmebaasile

10.2.1. Kasutama peab PostgreSQL andmebaasi.

10.2.2. Andmed peavad olema talletatud vähemalt UTF-8 enkoodingus.

10.2.3. Andmete kustutamine ei tohi kustutada tegelikke kirjeid andmebaasist, välja arvatud, kui kirjed

pole mittefunktsionaalsed, ehk ei oma ärilist seost.

10.2.4. Andmebaasi komponentide integratsioonivahendina ei tohi kasutada.

10.2.5. Andmebaasi pöördutakse ainult rakenduse jaoks eraldatud süsteemsete kasutajatega.

10.2.6. Rakendusse tuleb luua võimekus leida vajadusel mitme andmebaasi instantsi seast peamine,

kuhu on võimalik kirjutamispäringuid saata. Vaike seadistuses kasutab SMIT PgBouncer-it.

10.3. Nõuded X-tee teenustele

10.3.1. Loodavad X-tee teenused peavad kasutama x-tee REST-i põhist sõnumiprotokolli:

10.3.1.1. X-Road: Message Protocol for REST

10.3.2. Teenuste tarbimine ja pakkumine peab toimuma x-tee turvaserveri vahendusel.

10.3.3. Loodavad X-tee teenused peavad päringud logima, kas rahvastikuregistrisse või

rahvastikuregistri päringute logide lahendusse, kui see on valmis.

10.3.4. Teenustel peavad olema kõik kohustuslikud ja valikulised päise elemendid.

10.3.5. Lisaks X-tee dokumentatsioonis määratud päistele tuleb lisada järgmised päised:

10.3.5.1. RR-Request-Reason - Päringu alus, kokkulepitud väärtuste kogum. Võimaldab eristada,

kas tegu on õigustatud huvi alusel tehtud päringuga; avaliku ülesande täitmiseks

tehtud päringuga; seadustes sätestatud alustel päringule juurdepääsu piiramist vajava

päringuga.

10.3.5.2. RR-Request-Group-Id - Unikaalne identifikaator sama menetluse/toimingu raames

sooritatud mitme X-tee päringu koondamiseks üheks kirjeks andmejälgijas.

10.4. Nõuded logimisele

Täpsemad nõuded logimisele on toodud lisas 7.1 "Logimise nõuded".

10.5. Nõuded liidestustele

Täiendavad nõuded liidestustele on toodud peatükis Infosüsteemi mittefunktsionaalsed nõuded.

10.5.1. Rahvastikuregistri haldussüsteemi rakendused

10.5.1.1. Liidestuma peab järgmiste rahvastikuregistri rakendustega:

10.5.1.1.1. kodifikaatorite haldussüsteem

10.5.1.1.2. häälestuste haldussüsteem

10.5.1.1.3. asutuste haldussüsteem

10.5.1.1.4. aadresside haldussüsteem

10.5.1.2. Liidestumisel peab kasutama RabbitMQ-l baseeruvat sõnumivahetust.

10.5.1.3. Liidestumisel peab lähtuma replikeerimise põhimõttel ehk andmed talletatakse rakenduse

enda andmebaasi ja muudatuste korral uuendatakse.

10.5.2. Liidestused kolmandate osapooltega

Tuleb luua tarkvara teek suhtluseks ühe kinnistusraamatu teenusega.

10.6. Nõuded sõnumiruumile

10.6.1. Kasutama peab RabbitMQ-l baseeruvat sõnumivahetust.

10.6.2. Veakindlus, kui sõnumiruumi info saatmine ebaõnnestub, tuleb süsteemil info talletada ning

pakkuda automaatset ning manuaalselt uuesti edastamise võimalust.

10.7. Monitooring

10.7.1. Komponentide poolt publitseeritavad teenuste monitoorimiseks vajalik info on kättesaadav

JSON formaadis, soovitatav kasutada REST lähenemist.

10.7.1.1. Monitooringu keskkonnaks kasutatakse SMIT-is vabavaralist tarkvara Zabbix.

10.7.2. Realiseeritud peab olema /health endpoint, mis annab infot, kas rakendus on korras või mitte.

10.7.3. Realiseeritud peab olema rakenduse mõõdikute väljastamine, mis rakenduse instantsi põhiselt

esitab rakenduse toimimise andmeid.

10.7.4. Mõõdikute väljastamise juures tuleb lähtuda OpenTelemetry teekide võimalustest valitud

platvormil.

10.8. Infosüsteemi mittefunktsionaalsed nõuded

Arenduse käigus tuleb Pakkujal lähtuda Hankija juhistest ja hanke alusdokumentides toodud nõuetest.

10.8.1. Digiriigi tulevikuarhitektuuri suunad (offline koopia manuses: Digiriigi tulevikuarhitektuuri

suunad.pdf)

10.8.2. Tehnoloogiakaart

10.8.3. Tehnilised nõuded tarkvaralahendustele (Lisa 7.5)

10.8.4. Nõuded karbitoodetele

10.8.5. Rakendustevahelised integratsioonipõhimõtted (Lisa 7.4)

10.8.6. Lähtekoodi halduse ja ehitamise nõuded arendajale (Lisa 7.2)

10.8.7. Logimise nõuded (Lisa 7.1)

10.8.8. REST teenuste disainimisel ning ehitamisel tuleb järgida OpenApi standardit

10.8.9. Nõuded infosüsteemi dokumentatsioonile (Lisa 7.3)

10.8.10. Hankijal on õigus viia hanke tulemi osas läbi turvatestid. Pakkujal on kohustus turvatestide

tulemusel leitud puudused lahendada.

11. ÜLEANTAV TULEM

Hankelepingu täitmise käigus Pakkuja poolt loodav ja Hankijale üle antav tulem vastab hanke

alusdokumentides toodud nõuetele ja sisaldab järgmist:

11.1. Töötav rahvastikuregistri menetlustarkvara infosüsteemi platvorm, millele on edaspidi võimalik

arendada juurde ca 70 menetlust, täiendavaid otsinguid, uusi funktsionaalsusi jne vastavalt

hanke alusdokumentides toodud nõuetele ja detailanalüüsis püstitatule.

11.2. Loodud on veebirakenduse kasutajaliides.

11.3. Realiseeritud on vähemalt kaks otsingut koos otsitulemuste kuva ja detailandmete kuvaga

vastavalt hanke alusdokumentides toodud nõuetele ja detailanalüüsis püstitatule:

11.3.1. isikuotsing

11.3.2. dokumendiotsing

11.4. Teostatud on kasutajate tegevuste, õiguste rollide põhjalik analüüs.

11.5. Teostatud on detailanalüüs hanke alusdokumentides kirjeldatud ulatuses.

11.6. Realiseeritud on kasutajate autentimine ja haldus vastavalt hanke alusdokumentides toodud

nõuetele ja detailanalüüsis püstitatule.

11.7. Loodud on sõnumiruum kodifikaatorite edastamiseks.

11.8. Analüüsitud on andmesiirdega seotud üksikasjad.

11.9. Süsteemi arhitektuuri dokumentatsioon:

11.9.1. Ülevaade süsteemi üldisest arhitektuurist, sealhulgas komponentide, moodulite ja

nendevaheliste ühenduste kirjeldus.

11.9.2. Kõigi peamiste funktsionaalsuste ja nende toimimise kirjeldus.

11.9.3. Arhitektuurimustrid ja disainiprintsiibid, mida süsteemis on kasutatud.

11.10. Koodibaasi ja versioonihalduse dokumentatsioon:

11.10.1. Koodistruktuuri ja failide organiseerimise põhimõtted.

11.10.2. Koodinõuded, standardid ja parimad praktikad, mida projekti jooksul järgiti.

11.10.3. Versioonihalduse töövood, sealhulgas harude haldamine, versioonide numereerimise

skeem ja väljalaskeprotsessid.

11.11. Arenduskeskkonna ja tööriistade kirjeldus:

11.11.1. Arenduskeskkonna seadistamise juhend, sealhulgas vajalikud tarkvara ja tööriistad

(IDE-d, ehitustööriistad, käitamisserverid, andmebaasiserverid jne).

11.11.2. Tööriistade ja tehnoloogiate loetelu, mida kasutati arenduse, testimise ja juurutamise

käigus (nt. koodi kvaliteedikontrolli tööriistad, CI/CD tööriistad, testimisraamistikud).

11.11.3. Keskkondade kirjeldus (arendus-, testimis-, lavastus- ja produktsioonikeskkonnad),

nende seadistamine ja eripärad.

11.12. Tarkvara dokumentatsioon:

11.12.1. on täiendatud iga töö raames ja vastab hetkolukorrale;

11.12.2. dokumentatsioon on sellisel tasemel, et kolmas osapool on suuteline jätkama

arendustöid;

11.12.3. rakenduse kompileerimiseks vajalikud sõltuvused ja rakenduse kompileerimise juhis;

11.12.4. rakenduse komponentide levitamise juhis.

11.13. Tarkvara kasutusjuhend lõppkasutajale.

12. NÕUDED TESTIDELE JA TESTIMISELE

12.1. Ühik- või integratsioonitestid peavad katma nii uue tarnitava, kui ka varem tarnitud

funktsionaalsuse.

12.2. Teostama peab jõudlustestid kontrollimaks mittefunktsionaalsetes nõuetes (Lisa 7.5 Tehnilised

nõuded tarkvaralahendusele) kirjeldatud nõudeid. Jõudlustestid koos raportitega tuleb üle anda

Hankijale.

12.3. Automaattestide läbiviimisel on arendaja/automaattestija ülesanded järgmised:

12.3.1. iga sprindiga peab automaattestija üle andma testilood ja testi tulemusteraportid

teostatud töö kohta;

12.3.2. iga sprindiga peab automaattestija üle andma teadaolevate vigade vearaportid SMIT

Jirasse, mida planeeritakse parandada järgnevate tarnetega;

12.3.3. arendaja/automaattestija on kohustatud looma töölaua rakendusele automaateste, mis

peab katma nii uue tarnitava funktsionaalsuse kui ka varem tarnitud funktsionaalsuse

regressioonitestid;

12.3.4. arendaja on kohustatud teostama jõudlustestid kontrollimaks mittefunktsionaalsetes

nõuetes kirjeldatud nõudeid. Jõudlustestid koos raportitega tuleb üle anda Hankijale;

12.3.5. arendaja/automaattestija on kohustatud siduma automatiseeritud testide lahenduse

pideva integratsiooni (Continious Integration/CI) vahendiga.

13. NÕUDED ARENDUSELE JA DOKUMENTEERIMISELE

13.1. Nõuded arendusele

13.1.1. Pakkuja on kohustatud järgima SMITis kehtivaid arendusnõudeid, sh nõudeid lähtekoodile.

Kehtivad arendusnõuded lisatakse igale hankele.

13.1.2. Lähtekoodi kvaliteedist ja tehnoloogilisest võlast ülevaate saamiseks kasutatakse platvormi

SonarQube ja Pakkujal on kohustus SonarQube-i poolt leitud lähtekoodi vead ja halvad lõhnad

(code smells) enne tulemi/commiti üleandmist parandada. Kui selgub, et tulemi üleandmisel

olid lähtekoodis vead ja halvad lõhnad parandamata, on Hankijal õigus tulemit/commiti mitte

vastu võtta.

13.1.3. Lähtekood peab olema Täitja poolt piisavalt kommenteeritud, et hiljem oleks võimalik teha

edasiarendusi või parandusi.

13.1.4. Arendustööde tulemusel valmiva lähtekoodi hoidmiseks on SMITi Git koodirepositoorium

(Atlassian Bitbucket). Täitja meeskonnaliikmetele luuakse tellija poolt ligipääs

koodirepositooriumile lähtekoodi, andmebaasimuudatuste ning muude tulemite või nende

muudatuste üleandmiseks.

13.1.5. Tarkvara järjepidevaks integreerimiseks ja tarnimiseks (Continuous Integration, Continuous

Deployment CI/CD) kasutatakse Atlassian Bamboo-d.

13.1.6. CI töövoogude loomine arenduskeskkonnas on arendaja ülesanne.

13.1.7. Loodavad hanke tulemid antakse üle SMITi koodirepositooriumi kaudu vastavalt tellija

juhistele. Arendustööde tulemite üleandmine (lähtekoodi tarne) toimub pideva integreerimise

(CI) teel või kokkulepitud sagedusega (nt iga arendustööde sprindi/etapi järel).

13.1.8. Tarne pre-live keskkonda toimub täitja ning tellija administraatori koostöös.

13.1.9. Arendamisel lisatakse commitide (lähtekoodi repositooriumisse lisamine) juurde Jira pileti nr,

mille alusel muudatus sisse viiakse ning lühisõnaline lühikirjeldus, mida muudatused

sisaldavad. Commit sõnumi alguses peab olema alati projekti nimi, mille raames commit

tehakse ja informatsioon, kes antud commiti teeb (isiku nimi)

13.1.10. Enne commiti peab kood/teostatud töö/tulem olema:

13.1.10.1. iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus

funktsionaalsust);

13.1.10.2. üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale commiti

katki);

13.1.10.3. SonarQube-i poolt leitud lähtekoodi vead ja halvad lõhnad (code smells)

parandatud (uut tehnoloogilist võlga tekitada ei tohi);

13.1.10.4. läbinud edukalt SMITis kehtiva kvaliteedivärava (SonarQube-is Quality Gate);

13.1.10.5. edaspidi mugavalt kasutatav ja mõistetav, ehk sellel on olemas oma enda

sisseehitatud testid, mis peale järgnevaid võimalikke arendusi/commite/tegevusi

näitaks, kas see konkreetne funktsionaalsuse osa on endiselt korras, või läks katki ja

tuleb korrastada.

13.1.11. Tarnitav lepingu ese peab ühilduma tellija poolt nõutud tehnilise lahendusega (erisused on

lubatud tellija kontaktisiku kirjalikku taasesitamist võimaldavas vormis esitatud nõusolekuga),

sealhulgas:

13.1.12. järgima tellija poolt nõutud tehnilise lahenduse ideoloogiat süsteemsete protseduuride osas ja

infosüsteemi arhitektuurset lahendust ja kasutusloogikat;

13.1.13. taaste- ja varundusprotseduurid peavad olema ühilduvad tellija poolt soovitud tehnilise

lahendusega;

13.1.14. lepingu ese ei tohi põhjustada süsteemi töö terviklikkuse või muid toimimise häireid ega

jõudluse langust;

13.1.15. lepingu ese peab olema tellija poolt nõutud infosüsteemiga ühetaoline ning sobituma

olemasolevatesse ekraanivormidesse ja töövoogu;

13.1.16. tööde teostamine ei tohi tekitada häireid tellija mistahes teiste liidestatud süsteemide või

teenuste talitluses, v.a juhul, kui see on tellija ja täitja poolt eelnevalt kokku lepitud.

13.1.17. Lepingu alusel teostatud tööde raames loodud tulemid peavad olema testitud etteantud

funktsionaalsuste täitmise kinnitamiseks ja vastama SMITis kehtivatele arendusnõuetele.

13.1.18. Tellija jätab endale hankelepingu tingimuste piires õiguse ühepoolselt täiendada ja muuta

üldist töökorraldust, sh arendusnõudeid, teavitades täitjat kirjalikult ette 1 (üks) kuu.

13.2. Nõuded dokumenteerimisele

13.2.1. Kogu lepingu täitmisega seotud teave ja dokumentatsioon luuakse ja säilitatakse SMITi

dokumendihalduskeskkonnas Wiki (Atlassiani Confluence). Hankija tagab nimetatud keskkonna

kättesaadavuse.

13.2.2. Dokumentide struktuur, selle täiendused ja muudatused lepitakse kokku poolte projektijuhtide

vahel.

13.2.3. Dokumenteerimine toimub vastavalt Hankija juhistele või hanke alusdokumentides toodud

lisadele 7.1-7.5

13.2.3.1. Lisa 7.1 - Logimise nõuded;

13.2.3.2. Lisa 7.2 - Lähtekoodi halduse ja ehitamise nõuded;

13.2.3.3. Lisa 7.3 - Nõuded tehnilisele dokumentatsioonile;

13.2.3.4. Lisa 7.4 - Rakendustevahelised integratsioonipõhimõtted;

13.2.3.5. Lisa 7.5 - Tehnilised nõuded tarkvaralahendustele.

13.2.4. Dokumentide lisamise, muutmise ja kustutamise reeglid lepitakse kokku poolte projektijuhtide

vahel, kes tagavad kokkulepitud reeglite järgimise oma meeskonna poolel.

13.2.5. Dokumentatsioon on eesti keeles.

13.2.6. Prototüüp antakse hankijale üle Figma originaalfailina, mida on hankijal võimalik edaspidi

kasutada ja täiendada. Prototüübiga peab kaasas olema asjakohane dokumentatsioon, mis

selgitab selle funktsionaalsust ja kasutamist. Hankijale edastatakse kõik kujundusfailid ning

arenduseks vajalik tehniline kirjeldus jms. Lisatud peavad olema juhised prototüübi edasiseks

täiendamiseks.

13.2.7. Projektimeeskonna liikmed (teostajad) vastutavad, et nende poolt teostatud tööd on teostatud

ja dokumenteeritud vastavalt kokkulepitud töö eesmärgile ning Hankija suunistele ja nõuetele

ning valdkonnas kehtivatele parimale praktikale.

13.2.8. Lõppdokumentatsioon peab vastama punktile 13.2. ning olema loogiliselt struktureeritud,

kirjavigadeta, üheselt arusaadava ja selge lauseehitusega, sh olema koostatud korrektses eesti

keeles, olema selge ja ühtses stiilis ning sisaldama nii dokumendisiseseid kui ka dokumentide

vahelisi viiteid.

13.2.9. Dokumentatsiooni kvaliteedi eest vastutab Pakkuja. Hankijal on õigus nõuda täitja poolt

koostatud või parandatud dokumentatsiooni täiendamist või muul viisil muutmist, kui

dokumentatsioon ei vasta nõuetele või on muul viisil puudulik.

1 / 4

Koostatud 12.03.2025 10:44:00 https://riigihanked.riik.ee/rhr-web/#/procurement/8143784/general-info

VASTAVUSTINGIMUSED Viitenumber: 287849 Hankija: Siseministeeriumi infotehnoloogia- ja arenduskeskus (70008440) Hange: Rahvastikuregistri menetlustarkvara baaslahenduse arendus, I etapp

EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD JA TARNIJAD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. Hankija lükkab tagasi pakkumuse, mille alusel sõlmitav hankeleping oleks RSanS § 7 lg 1 alusel tühine.

Määrust kohaldatakse riigihangetele alates rahvusvahelisest piirmäärast. NÕUKOGU MÄÄRUS (EL) 2022/576, 8. aprill 2022, millega muudetakse määrust (EL) nr 833/2014, mis käsitleb piiravaid meetmeid seoses Venemaa tegevusega, mis destabiliseerib olukorda Ukrainas.

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid ega tarnijaid, kes on: 1. Vene Föderatsiooni kodanik, resident või Vene Föderatsioonis asutatud ettevõtja, sh füüsilisest isikust ettevõtja, juriidiline isik, asutus või muu üksus; 2. rohkem kui 50% ulatuses otseselt või kaudselt punktis 1 nimetatud isiku, asutuse või muu üksuse omandis; 3. punktis 1 või 2 nimetatud isiku, asutuse või muu üksuse esindaja või tegutseb sellise isiku juhiste alusel. (Raadionupp valikutega "Jah/Ei")

ÜHISPAKKUJATE VOLIKIRI Ühispakkujad nimetavad riigihankega ning hankelepingu sõlmimise ja täitmisega seotud toimingute tegemiseks endi seast volitatud esindaja.

Küsimused ettevõtjale: 1. Kas tegemist on ühispakkumusega? (Raadionupp valikutega "Jah/Ei")

2. Kui tegemist on ühispakkumusega, kas olete lisanud pakkumuse "Lisadokumentide" lehele ühispakkujate volikirja? Kui tegemist ei ole ühispakkumusega, vastake "Ei"". (Raadionupp valikutega "Jah/Ei")

PAKKUMUSE ESITAMINE Pakkumuse esitamisega kinnitab pakkuja kõigi riigihanke alusdokumentides esitatud tingimuste ülevõtmist.

Tingimusliku pakkumuse esitamine ei ole lubatud.

Küsimused ettevõtjale: 1. Kas ettevõtja saab kinnitada, et pakkumus vastab hanke alusdokumentides sätestatud tingimustele? (Raadionupp valikutega "Jah/Ei")

2. Pakkuja kinnitab, et tema pakkumus on jõus 4 kuud, pakkumuse esitamisest arvates? (Raadionupp valikutega "Jah/Ei")

3. Andmed lepingusse, mida kasutatakse juhul, kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. ettevõtte aadress; 2. lepingu allkirjastaja nimi; 3. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vm); 4. lepingu allkirjastaja ametinimetus; 5. pakkuja kontaktisik lepingu täitmisel (nimi, ametinimetus, telefoni number ja e-posti aadress). (Suur sisestusala (max pikkus 4000 tähemärki))

2 / 4

Koostatud 12.03.2025 10:44:00 https://riigihanked.riik.ee/rhr-web/#/procurement/8143784/general-info

4. Kas pakkujal on isikuid, kellel on volitus ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, ning kelle olemasolu ei kajastu äriregistris. Pakkuja esitab eelpool nimetatud isikute ees- ja perekonnanime, isikukoodi ning esinduse aluse, et hankija saaks nende puhul viia läbi kõrvaldamise aluste kontrolli vastavalt RHS § 95 lg 1 p 1- p 3. (Suur sisestusala (max pikkus 4000 tähemärki))

SAMAVÄÄRSUS Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud.

Iga viidet, mille hankija teeb riigihanke alusdokumentides mõnele RHS-i § 88 lõikes 2 nimetatud alusele (standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile vms), tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“. Iga viidet, mille hankija teeb riigihanke alusdokumentides ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule, tootmisviisile, märgisele või vastavushindamisasutuse väljastatud katsearuandele või tõendile, tuleb lugeda selliselt, et see on täiendatud märkega „või sellega samaväärne“ (RHS § 88 lg-d 5-6, § 89 lg 2, 114 lg-d 5-7). Hankija aktsepteerib objektiivsetel põhjustel muid asjakohaseid tõendeid, kui pakkuja tõendab hankijale vastuvõetaval viisil, et pakutav asi, teenus või ehitustöö vastab konkreetse märgise või hankija esitatud nõuetele, välja arvatud juhul, kui hankija nõutud märgis, samaväärne märgis või konkreetse või samaväärse vastavushindamisasutuse väljastatud katsearuanne või muu tõend on seaduse alusel eelduseks asja, teenuse või ehitustöö pakkumiseks turul (RHS § 114 lg 7).

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et pakkumus vastab hanke alusdokumentides nõutule ja vajadusel on samaväärsus selgitatud ja tõendid samaväärsuse kohta lisatud. (Raadionupp valikutega "Jah/Ei")

ÄRISALADUS Pakkuja märgib pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe määramist ärisaladuseks.

Teabe ärisaladuseks määramisel lähtutakse ebaausa konkurentsi takistamise ja ärisaladuse kaitse seaduse § 5 lõikes 2 sätestatust. Pakkuja ei või ärisaladusena märkida: 1) pakkumuse maksumust ega osamaksumusi; 2) teenuste hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid numbrilisi näitajaid; 3) asjade ja ehitustööde hankelepingute puhul lisaks punktis 1 nimetatule muid pakkumuste hindamise kriteeriumidele vastavaid pakkumust iseloomustavaid näitajaid (RHS § 46 (1)).

Küsimused ettevõtjale: 1. Kirjeldage lühidalt pakkumuses sisalduvat ärisaladust ja lisage selle määramise põhjendus või märkige, et pakkumus ei sisalda ärisaladust. (Suur sisestusala (max pikkus 4000 tähemärki))

HANKELEPINGU MEESKOND

Pakkuja esitab meeskonnaliikmete (kokku 6) andmed, täites iga nõutud meeskonnaliikme kohta etteantud CV vormi. Üks isik võib katta rohkem kui üht meeskonnaliiget, kui ta täidab meeskonnaliikmele esitatud nõuded.

Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikmete vastavust esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige esitatud andmete alusel:

Pakkuja komplekteerib ja esitab lepingu täitmiseks meeskonna: 1. üks IT-projektijuht. 2. üks IT analüütikut. 3. üks juhtiv java tarkvaraarendaja/tech lead. 4. kaks java fullstack arendajat. 5. üks testija.

3 / 4

Koostatud 12.03.2025 10:44:00 https://riigihanked.riik.ee/rhr-web/#/procurement/8143784/general-info

Loetletud on hankija vaates olulised rollid. Pakkuja otsustada jääb, kui mitu isikut konkreetsesse rolli hankelepingu täitmise eesmärgil pakutakse. Juhul, kui pakkuja peab oluliseks suurendada meeskonda, siis see on lubatud, kuid iga uus liige peab vastama hankes esitatud nõuetele.

Juhul kui hankes ei ole kirjeldatud rolli, mida pakkuja peab vajalikuks meeskonda kaasata, eeldab hankija, et pakutaval isikul on läbitud vähemalt IT-alane kutseõpe keskhariduse baasil (sh on aktsepteeritud ka IT-alane kutsekeskharidus)ja tal on oma rollis vähemalt 5-aastane töökogemus või IT-alane kõrgharidus ja tal on oma rollis vähemalt 3-aastane töökogemus. Nõuetele vastavuse tõendamiseks tuleb esitada CV.

1. Kui tingimuses on nõutud (kõrg)haridus, peab see olema lõpetatud. 2. Kui tingimuses ei ole nõutud töökogemust projektis, võib viidata ka töösuhtele. Projektiks ei loeta (varasemat) töösuhet. 3. Töökogemuse nõude täitmisena ei arvestata vabakutselisena tegutsemist, v.a kui selle perioodi osas on viidatud konkreetsetele projektidele, millel on tellijaks kolmas isik. 4. Töökogemuse nõude täitmisena ei arvestata täiendkoolitust või koolitööd. 5. Kui tingimuses on nõutud konkreetse kestusega töökogemust, siis (ka osaliselt) samaaegsete projektide kattuvaid aegu mitmekordselt ei arvestata. St sama ajaperioodi eest ei ole võimalik omandada mitmekordset kogemust. 6. Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja lühikirjeldus, projekti algus- ja lõppaeg kalendrikuu täpsusega, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida riigihanke number. 7. Viidatud projektid peavad olema pakkumuse esitamise ajaks nõutud mahus/ kompetentsi osas täidetud ja tellija poolt vastu võetud. 8. Hankijal on õigus pöörduda tellija poole esitatud andmete kontrollimiseks. 9. Kui mõne nõutud kompetentsi/kogemuse osas on andmed esitamata või viitab nende andmete mitteesitamise põhjenduseks konfidentsiaalsusele ja/või nende alusel ei ole võimalik järeldada, kas nõue on täidetud, on hankijal õigus tunnistada pakkumus mittevastavaks. Hankija ei avalda pakkumuses esitatud andmeid. 10. Juhul, kui lepingu täitmise käigus meeskonnas liikmeid asendatakse või täiendatakse, siis peab isik nõutud tingimustele vastama sellise taotluse esitamise ajaks. 11. Kui see on objektiivselt võimalik, tuleb lugeda tingimusi täiendatuks märkega "või samaväärne". Samaväärsuse tõendamise kohustus lasub pakkujal, kes sellele tugineda soovib. Tõendid samaväärsuse kohta peavad olema esitatud pakkumuse koosseisus. 12. Tellijal on õigus CV-s esitatud informatsiooni kontrollida ja täpsustada, kuid juhul, kui mõnd nõutud kogemust ei ole CV-s esitatud, lähtub hankija seisukohast, et pakkuja on vastava kogemuse kohta esitanud ammendavad andmed, st vastav kogemus meeskonnaliikmel puudub.

Küsimused ettevõtjale: 1. Pakkuja esitab lepingut täitma IT-projektijuhi, kes vastab hankija vormil (lisa 4.5) seatud vastavustingimustele (Vabas vormis dokument)

2. Pakkuja esitab lepingut täitma IT-analüütiku, kes vastab hankija vormil (lisa 4.2) seatud vastavustingimustele (Vabas vormis dokument)

3. Pakkuja esitab lepingut täitma juhtiv tarkvaraarendaja/Tech lead kes vastab hankija vormil (lisa 4.3) seatud vastavustingimustele (Vabas vormis dokument)

4. Pakkuja esitab lepingut täitma esimese Java fullstack arendaja, kes vastab hankija vormil (lisa 4.1) seatud vastavustingimustele (Vabas vormis dokument)

5. Pakkuja esitab lepingut täitma teise Java fullstack arendaja, kes vastab hankija vormil (lisa 4.1) seatud vastavustingimustele (Vabas vormis dokument)

6. Pakkuja esitab lepingut täitma testija, kes vastab hankija vormil (lisa 4.4) seatud vastavustingimustele (Vabas vormis dokument)

NÕUDED PAKKUMUSELE

4 / 4

Koostatud 12.03.2025 10:44:00 https://riigihanked.riik.ee/rhr-web/#/procurement/8143784/general-info

Pakkuja esitab omapoolse projektiplaani, mille põhjal on võimalik hankijal hinnata Pakkuja ülesandepüstitusest arusaamist.

Käesoleva nõude juures ei teostata projektiplaani sisulist kontrolli. Projektiplaani sisuline hindamine toimub hindamise faasis. Projektiplaani hindamismetoodika on toodud Pakkumuse esitamise ettepaneku (PEE) lisas 5.1.

Projektiplaan peab sisaldama vähemalt töö tegevuste läbiviimise detailse ja loogilise ülesehitusega kirjeldust, mis on koostatud hankedokumendi Lisa 2 (Tehniline kirjeldus) ja Lisa 2.2 (Nõuded pakkumusele) alusel.

Küsimused ettevõtjale: 1. Projektiplaan (Vabas vormis dokument)