Hanke alusdokumentide kinnitamine riigihankes „Kohtute infosüsteemi arendustööd" (296052)

1 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

ALLTÖÖVÕTJATE KONTROLLIMISE TINGIMUSED LEPINGU TÄITMISE ETAPIS Viitenumber: 296052

Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Kohtute infosüsteemi arendustööd

Esimese ringi alltöövõtjaid kontrollitakse:Jah

Teise ja järgmiste ringide alltöövõtjaid kontrollitakse: Ei

Alltöövõtjad peavad esitama hankepassi: Jah

ALLTÖÖVÕTJA ESIMESE RINGI KÕRVALDAMISE ALUSED

A: Kõrvalejätmise alused seoses kriminaalasjas tehtud süüdimõistva otsusega

OSALEMINE KURITEGELIKUS ORGANISATSIOONIS

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kuritegelikus organisatsioonis osalemise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KORRUPTSIOON

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud korruptsiooni eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? See kõrvalejätmise alus hõlmab ka korruptsiooni avaliku sektori hankija (võrgustiku sektori hankija) või ettevõtja riigi õiguses sätestatud määratluses.

Kehtib: Kõik osad

2 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

PETTUS

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kelmuse eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

TERRORIAKTI TOIMEPANEK VÕI TERRORISTLIKU TEGEVUSEGA SEOTUD

ÕIGUSRIKKUMISED

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud terroriakti toimepaneku või terroristliku tegevusega seotud õigusrikkumiste eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Kehtib: Kõik osad

3 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

RAHAPESU VÕI TERRORISMI RAHASTAMINE

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud rahapesu või terrorismi rahastamise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

LASTE TÖÖJÕU KASUTAMINE JA MUUD INIMKAUBANDUSE VORMID

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud laste tööjõu kasutamise või muude inimkaubanduse vormide eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Kehtib: Kõik osad

4 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega

MAKSUDE TASUMINE

Kas ettevõtja on rikkunud oma maksude tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?

Kehtib: Kõik osad

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

5 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

SOTSIAALKINDLUSTUSMAKSETE TASUMINE

Kas ettevõtja on rikkunud oma sotsiaalkindlustusmaksete tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?

Kehtib: Kõik osad

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

C: Kõrvalejätmise alused seoses maksejõuetusega, huvide konfliktiga või ametialaste käitumisreeglite rikkumisega

KESKKONNAÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud keskkonnaõiguse valdkonnas kohaldatavaid kohustusi?

Kehtib: Kõik osad

6 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SOTSIAALÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud sotsiaalõiguse valdkonnas kohaldatavaid kohustusi?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

TÖÖÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud tööõiguse valdkonnas kohaldatavaid kohustusi?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

PANKROT

Kas ettevõtja on pankrotis?

Kehtib: Kõik osad

7 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

MAKSEJÕUETUS

Kas ettevõtja suhtes on algatatud maksejõuetus- või likvideerimismenetlus?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KOKKULEPE VÕLAUSALDAJATEGA

Kas ettevõtja on sõlminud kokkuleppe võlausaldajatega?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SISERIIKLIKU ÕIGUSE KOHANE SAMALAADNE OLUKORD, NÄITEKS PANKROT

Kas ettevõtja on siseriiklike õigusnormide alusel toimuva samalaadse menetluse tõttu samalaadses olukorras?

Kehtib: Kõik osad

8 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

VARA HALDAB LIKVIDEERIJA

Kas ettevõtja vara haldab likvideerija või kohus?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

ÄRITEGEVUS ON PEATATUD

Kas ettevõtja äritegevus on peatatud?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SÜÜDI AMETIALASTE KÄITUMISREEGLITE OLULISES RIKKUMISES

Kas ettevõtja on süüdi ametialaste käitumisreeglite olulises rikkumises? Vt siseriiklikud õigusaktid, asjaomane teade või hankedokumendid, kui see on asjakohane.

Kehtib: Kõik osad

9 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KONKURENTSI MOONUTAMISE EESMÄRGIL TEISTE ETTEVÕTJATEGA

SÕLMITUD KOKKULEPPED

Kas ettevõtja on teiste ettevõtjatega sõlminud kokkuleppeid, mille eesmärk on moonutada konkurentsi?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

HANKEMENETLUSES OSALEMISEGA KAASNEV HUVIDE KONFLIKT

Kas ettevõtja on teadlik hankemenetluses osalemisega kaasnevast mis tahes huvide konfliktist siseriikliku õiguse, asjakohase teatise või hankedokumentide kohaselt?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 4. URL (Url) 5. Kood (Sisestusväli (max pikkus 250 tähemärki)) 6. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

OTSENE VÕI KAUDNE OSALEMINE KÄESOLEVA HANKEMENETLUSE

ETTEVALMISTAMISEL

Kas ettevõtja või temaga seotud ettevõtja on nõustanud avaliku sektori hankijat või võrgustiku sektori hankijat hankemenetluse ettevalmistamisel või olnud muul viisil seotud hankemenetluse ettevalmistamisega?

Kehtib: Kõik osad

10 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 4. URL (Url) 5. Kood (Sisestusväli (max pikkus 250 tähemärki)) 6. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

ENNETÄHTAEGNE LÕPETAMINE, KAHJUTASU VÕI VÕRRELDAVAD

SANKTSIOONID

Kas ettevõtja on kogenud, et varasem riigihankeleping või võrgustiku sektori hankijaga sõlmitud varasem hankeleping või varasem kontsessioonileping on lõpetatud enneaegselt, või on määratud kahjutasu või sellega võrreldavad sanktsioonid seoses kõnealuse varasema lepinguga?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SÜÜDI VALEANDMETE ESITAMISES, ON JÄTNUD TEAVET ESITAMATA, EI SUUDA

NÕUTUD DOKUMENTE ESITADA, HANKINUD KÄESOLEVA MENETLUSE KOHTA

KONFIDENTSIAALSET TEAVET

Kas ettevõtja on olnud ühes järgmistest olukordadest: a) ta on kõrvalejätmise aluste puudumise või valikukriteeriumide täitmise kontrollimiseks nõutava teabe esitamisel esitanud valeandmeid; b) ta on jätnud sellist teavet esitamata; c) ta ei ole esitanud viivitamata avaliku sektori hankija või võrgustiku sektori hankija nõutud täiendavad dokumendid, ja d) ta on tegutsenud eesmärgiga mõjutada lubamatul viisil avaliku sektori hankija või võrgustiku sektori hankija otsustusprotsessi, et saada konfidentsiaalseid andmeid, mis võivad anda talle põhjendamatu eelise hankemenetluses, või hooletusest esitanud eksitavat teavet, mis võib oluliselt mõjutada kõrvalejätmise, valiku või lepingu hindamise kohta tehtavaid otsuseid?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

11 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: SEADUSLIKU ALUSETA VIIBIVALE VÄLISMAALASELE TÖÖTAMISE

VÕIMALDAMINE

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 2 tuleneva kõrvalejätmise alusega seotud kohustusi?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: RAHVUSVAHELISE SANKTSIOONI SUBJEKT

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 5 tuleneva kõrvalejätmise alusega seotud kohustusi?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: HANKIJA ASUKOHAJÄRGSE KOHALIKU MAKSU MAKSUVÕLG

Kas ettevõtja on rikkunud RHS § 95 lg-st 4.1 tuleneva kõrvalejätmise alusega seotud kohustusi?

Kehtib: Kõik osad

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: KARISTATUD MAKSUALASTE SÜÜTEGUDE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 4 p-st 11 tuleneva kõrvalejätmise alusega seotud kohustusi?

Kehtib: Kõik osad

12 / 12

Koostatud 29.05.2025 10:04:41 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

1 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

HANKEPASS

Hankepass ehk Euroopa ühtne hankedokument (ESPD) on ettevõtja enda kinnitus, mis on esialgne tõend ametiasutuste või kolmandate isikute poolt väljastatavate tõendite asemel. Käesolev PDF vormingus registri poolt koostatud dokument on selgitava iseloomuga ja sisaldab hankija sätestatud tingimusi, ettevõtjalt oodatavate vastuste vormingu vaadet ja registri poolt lisatud viiteid RHS-ile. Käesolev dokument ei ole ette nähtud täitmiseks vaid tingimustega tutvumiseks. Ettevõtja täidab hankepassi elektrooniliselt infosüsteemis või ESPD teenuses.

I OSA: HANKE JA HANKIJAGA SEOTUD TEAVE

Teave avaldamise kohta Teate number ELTs:

-

ELT URL:

Riigi ametlik teataja:

296052

Kui Euroopa Liidu Teatajas hankekuulutust avaldatud ei ole või kui selle avaldamist ei nõuta, peab avaliku sektori hankija või võrgustiku sektori hankija ise teabe esitama, et hankemenetlust saaks üheselt identifitseerida (nt viide siseriikliku avaldamise kohta).

Hankija andmed Ametlik nimi:

Registrite ja Infosüsteemide Keskus (70000310)

Riik:

Eesti

Hankija aadress:

Lubja tn 4

Hankija veebiaadress:

http://www.rik.ee/

E-posti aadress:

[email protected]

2 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Teave hankemenetluse kohta Hanke menetlusliik:

Avatud hankemenetlus

Pealkiri:

Kohtute infosüsteemi arendustööd

Lühikirjeldus:

Riigihanke eesmärgiks on raamlepingu sõlmimine ühe edukaks tunnistatud pakkujaga, kes hakkab teostama kohtute infosüsteemi (KIS) arendustöid pakkumuses fikseeritud tunnihinna alusel. KIS arendustööde eesmärk on KIS infosüsteemi täiustamine ja parendamine, sealhulgas protsesside automatiseerimise, tehisaru kasutuselevõtu jms kaudu, et tagada õiguskindlus ja võimalusel lühendada menetluste aegu.

Avaliku sektori hankija või võrgustiku sektori hankija poolt toimikule antud viitenumber (kui on asjakohane):

296052

Hanke liik:

Teenused

Hanke CPV-d: 72200000-7 Tarkvara programmeerimis- ja nõustamisteenused

3 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

II OSA: ETTEVÕTJAGA SEOTUD TEAVE

A: Teave ettevõtja kohta

Nimi:

Registrikood:

Riik:

Aadress:

Üldine veebileht:

Kontaktisikud:

Kontaktide e-posti aadressid:

Kontaktide telefoninumbrid:

Ettevõtte suurus:

Töötajate arv:

Käive:

Valuuta:

Finantsalase võimekuse kirjeldus:

Tehnilise võimekuse kirjeldus:

Teostatud tööde kirjeldus:

Ettevõtja tegevusvaldkond:

4 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

ETTEVÕTJA ON KAITSTUD TÖÖKOHT

Ainult reserveeritud hangete puhul: kas ettevõtja puhul on tegemist kaitstud töökohaga, sotsiaalse ettevõttega või ta täidab lepingut kaitstud tööhõive programmide raames?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Milline on puudega või ebasoodsas olukorras olevate töötajate osakaal? 3. Kui seda on nõutud, täpsustage, millisesse puudega või ebasoodsas olukorras olevate töötajate kategooriasse või kategooriatesse asjaomased töötajad kuuluvad? 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja

ETTEVÕTJA ON KANTUD TUNNUSTATUD ETTEVÕTJATE AMETLIKKU NIMEKIRJA

Kui see on asjakohane, siis kas ettevõtja on kantud tunnustatud ettevõtjate ametlikku nimekirja või kas tal on olemas samaväärne tõend (nt riikliku (eel)kvalifitseerimissüsteemi alusel)?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. a) Vajaduse korral märkige asjakohane registreerimis- või sertifitseerimisnumber: 3. c) Viited, millele registreerimine või sertifitseerimine tugineb ja vajaduse korral ametlikus nimekirjas omistatud klassifikatsioon: 4. d) Kas registreerimine või sertifitseerimine hõlmab kõiki nõutud valikukriteeriume? 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

HANKEMENETLUSES KOOS OSALEVAD ETTEVÕTJAD

Kas ettevõtja osaleb hankemenetluses koos teistega?

Küsimused ettevõtjale: 1. Ettevõtja nimi 2. Ettevõtja ID 3. Ettevõtja roll 4. Kas see teave on elektrooniliselt kättesaadav? 5. URL 6. Kood 7. Väljaandja

TEAVE TEISTE ÜKSUSTE SUUTLIKKUSELE TOETUMISE KOHTA

Kas ettevõtja toetub teiste üksuste suutlikkusele, et täita esitatud valikukriteeriumid ning eeskirjad (kui neid on)?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Ettevõtja nimi 3. Ettevõtja ID 4. Ettevõtja roll 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

5 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

TEAVE NENDE ALLHANKIJATE KOHTA, KELLE NÄITAJATELE ETTEVÕTJA EI TUGINE

Kas ettevõtja kavatseb sõlmida lepingu mis tahes osa kohta allhanke kolmanda isikuga?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Ettevõtja nimi 3. Ettevõtja ID 4. Ettevõtja roll 5. Kas see teave on elektrooniliselt kättesaadav? 6. URL 7. Kood 8. Väljaandja

HANKE OSAD

Hanke osad, mille kohta ettevõtja soovib pakkumuse esitada

Küsimused ettevõtjale: 1. Hanke osa number 2. Kas see teave on elektrooniliselt kättesaadav? 3. URL 4. Kood 5. Väljaandja

ETTEVÕTJA KINNITUSED MAKSUDE TASUMISE KOHTA

Kas ettevõtja saab esitada tõendi sotsiaalkindlustusmaksete ja maksude tasumise kohta või esitada teabe, mis võimaldaks avaliku sektori hankijal või võrgustiku sektori hankijal saada sellise teabe otse ükskõik millise liikmesriigi tasuta andmebaasist?

Küsimused ettevõtjale: 1. Mis on Teie vastus? 2. Kas see teave on elektrooniliselt kättesaadav? 3. URL 4. Kood 5. Väljaandja

B: Teave ettevõtja esindajate kohta

Eesnimi:

Perekonnanimi:

Sünniaeg:

Sünnikoht:

Aadress:

Linn/vald:

Postiindeks:

Riik:

E-post:

Telefon:

Vajaduse korral esitage üksikasjalik teave esindamise kohta (selle vormid, ulatus, eesmärk, ...):

6 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

III OSA: KÕRVALDAMISE ALUSED

A: Kõrvalejätmise alused seoses kriminaalasjas tehtud süüdimõistva otsusega

OSALEMINE KURITEGELIKUS ORGANISATSIOONIS

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kuritegelikus organisatsioonis osalemise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 1 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kuritegelikus ühenduses osalemise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KORRUPTSIOON

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud korruptsiooni eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt? See kõrvalejätmise alus hõlmab ka korruptsiooni avaliku sektori hankija (võrgustiku sektori hankija) või ettevõtja riigi õiguses sätestatud määratluses.

Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud aususe kohustuse rikkumise või korruptiivse teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

7 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

PETTUS

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud kelmuse eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud kelmuse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

TERRORIAKTI TOIMEPANEK VÕI TERRORISTLIKU TEGEVUSEGA SEOTUD

ÕIGUSRIKKUMISED

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud terroriakti toimepaneku või terroristliku tegevusega seotud õigusrikkumiste eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele:

8 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud terroriakti toimepaneku või muu terroristliku tegevusega seotud kuriteo või sellele kihutamise, kaasaaitamise või selle katse eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

RAHAPESU VÕI TERRORISMI RAHASTAMINE

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud rahapesu või terrorismi rahastamise eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 1 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud rahapesualase süüteo või terrorismi rahastamise eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

9 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

LASTE TÖÖJÕU KASUTAMINE JA MUUD INIMKAUBANDUSE VORMID

Kas ettevõtja ise või tema haldus-, juht- või järelevalveorgani liige või isik, kellel on volitused seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on lõpliku süüdimõistva kohtuotsusega süüdi mõistetud laste tööjõu kasutamise või muude inimkaubanduse vormide eest kõige rohkem viimase viie aasta jooksul või kehtib süüdimõistvas kohtuotsuses sätestatud kõrvalejäämise kohustus endiselt?

Viide seadusele: RHS § 95 lg 1 p 3 ja lg 2 "keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud laste tööjõu ebaseadusliku kasutamise või inimkaubandusega seotud teo eest". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Süüdimõistmise kuupäev (Kuupäev) 3. Põhjus (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kes süüdi mõisteti? (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 6. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 7. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 8. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 9. URL (Url) 10. Kood (Sisestusväli (max pikkus 250 tähemärki)) 11. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega

MAKSUDE TASUMINE

Kas ettevõtja on rikkunud oma maksude tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?

Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku maksu, makse või keskkonnatasu maksuvõlg maksukorralduse seaduse tähenduses või maksuvõlg /…/ tema asukohariigi õigusaktide kohaselt“

10 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul, kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SOTSIAALKINDLUSTUSMAKSETE TASUMINE

Kas ettevõtja on rikkunud oma sotsiaalkindlustusmaksete tasumise kohustusi nii asukohariigis kui ka avaliku sektori hankija või võrgustiku sektori hankija liikmesriigis, kui see erineb asukohariigist?

Viide seadusele: RHS § 95 lg 1 p 4 „kellel on riikliku /…/ makse /…/ maksuvõlg maksukorralduse seaduse tähenduses või sotsiaalkindlustusemaksete võlg tema asukohariigi õigusaktide kohaselt

11 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Tingimuse kirjeldus: Piirmäär: 0

Valuuta: EUR

Lisainfo: Maksukorralduse seaduse kohaselt ei väljasta maksuhaldur maksuvõlgade tõendit juhul,kui maksukohustuslasel olev kõikide sama maksuhalduri hallatavate maksude võlg, arvestamata haldusaktiga kindlaksmääramata intressi, on väiksem kui 100 eurot või kui maksuvõla tasumine on ajatatud. Välismaise ettevõtja puhul väljastatakse maksuvõlgade tõend tema asukohariigi õigusaktide kohaselt.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Asjaomane riik või liikmesriik (Riigikood) 3. Asjaomane summa (Summa) 4. Valuuta (Vääring) 5. Kas see kohustuste rikkumine on tuvastatud muude vahenditega kui kohtu- või haldusotsusega? (Raadionupp valikutega "Jah/Ei") 6. Kirjeldage kasutatud vahendeid (Suur sisestusala (max pikkus 4000 tähemärki)) 7. Kui kohustuste rikkumine tuvastati kohtu- või haldusotsusega, märkige, kas see otsus on lõplik ja siduv. (Raadionupp valikutega "Jah/Ei") 8. Süüdimõistmise kuupäev (Kuupäev) 9. Süüdimõistvas otsuses sõnaselgelt esitatud kõrvalejätmise kestus. (Periood) 10. Kas ettevõtja on täitnud oma kohustused tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete tasumisega või siduva kokkuleppe sõlmimisega tasumisele kuuluvate maksude või sotsiaalkindlustusmaksete, sealhulgas vajaduse korral kogunenud intresside ja viiviste tasumise kohta? (Raadionupp valikutega "Jah/Ei") 11. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 12. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 13. URL (Url) 14. Kood (Sisestusväli (max pikkus 250 tähemärki)) 15. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

C: Kõrvalejätmise alused seoses maksejõuetusega, huvide konfliktiga või ametialaste käitumisreeglite rikkumisega

KESKKONNAÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud keskkonnaõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid keskkonnaõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

12 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SOTSIAALÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud sotsiaalõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid sotsiaalõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

TÖÖÕIGUSE VALDKONNAS KOHALDATAVATE KOHUSTUSTE TÄITMATA

JÄTMINE

Kas ettevõtja on enda teada rikkunud tööõiguse valdkonnas kohaldatavaid kohustusi?

Viide seadusele: RHS § 95 lg 4 p 2 „kes on rikkunud õigusaktidest või kollektiivlepingust tulenevaid tööõiguse valdkonnas kohaldatavaid kohustusi“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

13 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

PANKROT

Kas ettevõtja on pankrotis?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

MAKSEJÕUETUS

Kas ettevõtja suhtes on algatatud maksejõuetus- või likvideerimismenetlus?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on likvideerimisel või kelle suhtes on algatatud pankrotimenetlus, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

14 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KOKKULEPE VÕLAUSALDAJATEGA

Kas ettevõtja on sõlminud kokkuleppe võlausaldajatega?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SISERIIKLIKU ÕIGUSE KOHANE SAMALAADNE OLUKORD, NÄITEKS PANKROT

Kas ettevõtja on siseriiklike õigusnormide alusel toimuva samalaadse menetluse tõttu samalaadses olukorras?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt“, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

15 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

VARA HALDAB LIKVIDEERIJA

Kas ettevõtja vara haldab likvideerija või kohus?

Viide seadusele: RHS § 95 lg 4 p 3 „kes on pankrotis, likvideerimisel või kelle suhtes on algatatud pankrotimenetlus või kes on muus sellesarnases olukorras tema asukohamaa õigusaktide kohaselt, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

ÄRITEGEVUS ON PEATATUD

Kas ettevõtja äritegevus on peatatud?

Viide seadusele: RHS § 95 lg 4 p 3 „kelle äritegevus on peatatud, välja arvatud asjade ostmisel RHS § 49 lõikes 4 sätestatud juhul ja tingimustel“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

16 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Märkige põhjused, miks lepingu täitmine on sellest hoolimata võimalik. Seda teavet ei ole tarvis esitada, kui ettevõtja kõrvalejätmine on kohaldatava siseriikliku õiguse alusel muudetud konkreetsel juhul kohustuslikuks ja puudub võimalus teha erandit, isegi kui ettevõtja suudab lepingut täita. (Suur sisestusala (max pikkus 4000 tähemärki)) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SÜÜDI AMETIALASTE KÄITUMISREEGLITE OLULISES RIKKUMISES

Kas ettevõtja on süüdi ametialaste käitumisreeglite olulises rikkumises? Vt siseriiklikud õigusaktid, asjaomane teade või hankedokumendid, kui see on asjakohane.

Viide seadusele: RHS § 95 lg 4 p 4 „kes on raskelt eksinud ametialaste käitumisreeglite vastu ja see muudab tema aususe küsitavaks“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

KONKURENTSI MOONUTAMISE EESMÄRGIL TEISTE ETTEVÕTJATEGA

SÕLMITUD KOKKULEPPED

Kas ettevõtja on teiste ettevõtjatega sõlminud kokkuleppeid, mille eesmärk on moonutada konkurentsi?

Viide seadusele: RHS § 95 lg 4 p 5 „konkurentsi kahjustava kokkuleppe, ettevõtjate ühenduse otsuse või kooskõlastatud tegevuse tõttu“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

17 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

HANKEMENETLUSES OSALEMISEGA KAASNEV HUVIDE KONFLIKT

Kas ettevõtja on teadlik hankemenetluses osalemisega kaasnevast mis tahes huvide konfliktist siseriikliku õiguse, asjakohase teatise või hankedokumentide kohaselt?

Viide seadusele: RHS § 95 lg 4 p 6 „kui huvide konflikti ei ole muude vahenditega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 4. URL (Url) 5. Kood (Sisestusväli (max pikkus 250 tähemärki)) 6. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

OTSENE VÕI KAUDNE OSALEMINE KÄESOLEVA HANKEMENETLUSE

ETTEVALMISTAMISEL

Kas ettevõtja või temaga seotud ettevõtja on nõustanud avaliku sektori hankijat või võrgustiku sektori hankijat hankemenetluse ettevalmistamisel või olnud muul viisil seotud hankemenetluse ettevalmistamisega?

Viide seadusele: RHS § 95 lg 4 p 7 „kelle pakkumuse või taotluse koostamisel on osalenud isik, kes on osalenud sama riigihanke ettevalmistamisel või on muul viisil hankijaga seotud, ja sellele isikule seetõttu teadaolev info annab talle eelise teiste riigihankes osalejate eest ning sellest tingitud konkurentsi moonutamist ei ole muude vahendistega võimalik vältida“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

18 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 4. URL (Url) 5. Kood (Sisestusväli (max pikkus 250 tähemärki)) 6. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

ENNETÄHTAEGNE LÕPETAMINE, KAHJUTASU VÕI VÕRRELDAVAD

SANKTSIOONID

Kas ettevõtja on kogenud, et varasem riigihankeleping või võrgustiku sektori hankijaga sõlmitud varasem hankeleping või varasem kontsessioonileping on lõpetatud enneaegselt, või on määratud kahjutasu või sellega võrreldavad sanktsioonid seoses kõnealuse varasema lepinguga?

Viide seadusele: RHS § 95 lg 4 p 8 „kes on oluliselt või pidevalt rikkunud eelnevalt sõlmitud hankelepingu olulist tingimust või hankelepingute olulisi tingimusi nii, et rikkumise tulemusena on lepingust taganetud või leping üles öeldud, hinda alandatud, hüvitatud kahju või makstud leppetrahvi". Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud. Alates 1.09.2017 alustatud hangete tulemusena sõlmitud riigihankelepingute kohta leiab infot riigihangete registrist.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 3. Kas olete võtnud meetmeid, et tõendada oma usaldusväärsust („Self-Cleaning”)? (Raadionupp valikutega "Jah/Ei") 4. Kirjeldage neid (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 6. URL (Url) 7. Kood (Sisestusväli (max pikkus 250 tähemärki)) 8. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

SÜÜDI VALEANDMETE ESITAMISES, ON JÄTNUD TEAVET ESITAMATA, EI SUUDA

NÕUTUD DOKUMENTE ESITADA, HANKINUD KÄESOLEVA MENETLUSE KOHTA

KONFIDENTSIAALSET TEAVET

Kas ettevõtja on olnud ühes järgmistest olukordadest: a) ta on kõrvalejätmise aluste puudumise või valikukriteeriumide täitmise kontrollimiseks nõutava teabe esitamisel esitanud valeandmeid; b) ta on jätnud sellist teavet esitamata; c) ta ei ole esitanud viivitamata avaliku sektori hankija või võrgustiku sektori hankija nõutud täiendavad dokumendid, ja d) ta on tegutsenud eesmärgiga mõjutada lubamatul viisil avaliku sektori hankija või võrgustiku sektori hankija otsustusprotsessi, et saada konfidentsiaalseid andmeid, mis võivad anda talle põhjendamatu eelise hankemenetluses, või hooletusest esitanud eksitavat teavet, mis võib oluliselt mõjutada kõrvalejätmise, valiku või lepingu hindamise kohta tehtavaid otsuseid?

Viide seadusele: RHS § 95 lg 4 p 9 „kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või RHS §- des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta“;

19 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

RHS § 95 lg 4 p 9 „kes on jätnud andmed käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98-101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta esitamata“; RHS § 95 lg 4 p 9 „kes on jätnud käesoleva seaduse § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata“; RHS § 95 lg 4 p 10 „kes on tegutsenud eesmärgiga mõjutada hankijat või esitanud hooletusest eksitavat teavet, mis on võinud mõjutada hankija otsuseid riigihankes, või on tegutsenud eesmärgiga saada konfidentsiaalset teavet, mis on võinud anda talle põhjendamatu eelise teiste riigihankes osalejate ees“. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: SEADUSLIKU ALUSETA VIIBIVALE VÄLISMAALASELE TÖÖTAMISE

VÕIMALDAMISE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 2 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 1 p 2 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget, prokuristi või muud isikut, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida, on karistatud riigis ilma seadusliku aluseta viibivale välismaalasele töötamise võimaldamise või välismaalase Eestis töötamise tingimuste rikkumise võimaldamise, sealhulgas seaduses sätestatud töötasu määrast väiksema töötasu maksmise eest“. Kohustuslik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: RAHVUSVAHELISE SANKTSIOONI SUBJEKT

Kas ettevõtja on rikkunud RHS § 95 lg 1 p-st 5 tuleneva kõrvalejätmise alusega seotud kohustusi?

20 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Viide seadusele: RHS § 95 lg 1 p 5. Kellega hankelepingu sõlmimine rikuks rahvusvahelist või Vabariigi Valitsuse sanktsiooni rahvusvahelise sanktsiooni seaduse tähenduses. Hankija kontrollib käesoleva seaduse § 95 lõike 1 punktis 5 sätestatud kõrvaldamise alust pakkuja või taotleja kinnituse alusel. Hankija võib põhjendatud kahtluse korral nõuda pakkujalt või taotlejalt täiendavate andmete või tõendite esitamist, mis võimaldavad kõrvaldamise alust kontrollida. (RHS § 96 lg 2.1).

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: KARISTATUD MAKSUALASTE SÜÜTEGUDE EEST

Kas ettevõtja on rikkunud RHS § 95 lg 4 p-st 11 tuleneva kõrvalejätmise alusega seotud kohustusi?

Viide seadusele: RHS § 95 lg 4 p 11 „keda või kelle haldus-, juhtimis- või järelevalveorgani liiget või muud seaduslikku esindajat on karistatud maksualaste süütegude eest“. Vabatahtlik kõrvaldamise alus. Kui hankemenetlusest kõrvaldamise alus esineb, võib ettevõtja soovi korral esitada tõendeid selle kohta, et ta on võtnud meetmeid oma usaldusväärsuse taastamiseks. Heastamise võimalus on ettevõtjal juhul, kui tegemist on rahvusvahelist piirmäära ületava hankega või hankija on selle hanke alusdokumentides ette näinud.

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

AINULT SISERIIKLIKEST ÕIGUSAKTIDEST TULENEVAD KÕRVALEJÄTMISE

ALUSED: OSALEJA PIIRAMINE ETTEVÕTJA ELU- VÕI ASUKOHA PÕHISELT

Kas ettevõtja rikub hankija kehtestatud piirangut pakkumust või taotlust esitada?

Viide seadusele: RHS § 95 lg 4 p 12 „kellel puudub käesoleva seaduse alusel õigus pakkumust või taotlust esitada, välja arvatud § 111 lõikes 6 sätestatud juhul". RHS § 7 lg 3 sätestab, et hankija võib piirata pakkujate ja taotlejate ringi, lubades riigihankes osaleda ainult RHS § 3 punktis 2 nimetatud riikidest pärit ettevõtjatel või andes nendest riikidest pärit ettevõtjate esitatud pakkumustele eeliseid teistest riikidest pärit ettevõtjate esitatud pakkumuste ees. Hankija sätestab piirangu ettevõtja elu- või asukohale hanke alusdokumentides.

21 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Ettevõtjalt oodatavad vastused:

1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

IV OSA: KVALIFITSEERIMISTINGIMUSED

B: Majanduslik ja finantsseisund

ÜLDINE AASTAKÄIVE

Ettevõtja üldine aastakäive on asjaomases teates, hankedokumentides või hankepassis nõutud majandusaastate jooksul järgmine:

Viide seadusele: RHS § 100 lg 1 p 4 „andmed pakkuja või taotleja kogu majandustegevuse netokäibe kohta kuni viimase kolme riigihanke algamise ajaks lõppenud majandusaasta jooksul, sõltuvalt pakkuja või taotleja asutamise või äritegevuse alguse kuupäevast“

Tingimuse selgitus: Pakkuja viimase 2 (kahe) riigihanke algamise ajaks lõppenud majandusaasta netokäive peab olema olnud igal aastal vähemalt 1 000 000 (1 miljon) EUR-i. Eeldusel, et pakkuja majandusaasta kattub kalendriaastaga, on viimaseks kaheks lõppenud majandusaastaks 2024 ja 2023. Pakkuja esitab hankepassis 2024. ja 2023. majandusaastate netokäibed. Hankija kontrollib esitatud andmeid hankijale avalikes andmekogudes kättesaadava info kaudu. Info kohta, mis ei ole hankijale andmekogudes olevate avalike andmete põhjal oluliste kulutusteta kättesaadavad, kohustub pakkuja hankija nõudmisel esitama täiendavad selgitused, andmed või dokumendid kuni 5 (viie) tööpäeva jooksul alates päringu saamisest. Pakkuja esitab hankepassis vastavad andmed. Kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile ja/või tehnilisele ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab pakkuja vastavalt hankija nõudmisele vastuvõetaval viisil tõendama, et sellel ettevõtjal, kelle vahenditele ta tugineb, on vastavad vahendid olemas ning ettevõte on nõus nende vahendite kasutamisega ja pakkuja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest pakkuja, kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta või jätnud need andmed või § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata. Hankepassi esitamine on kohustuslik ka ühispakkujatele.

22 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Tingimuse kirjeldus: Miinimumnõue: 1000000

Valuuta: EUR

Ettevõtjalt oodatavad vastused:

1. Ajavahemik (Periood) 2. Käive (Summa) 3. Valuuta (Vääring) 4. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 5. URL (Url) 6. Kood (Sisestusväli (max pikkus 250 tähemärki)) 7. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

C: Tehniline ja kutsealane suutlikkus

TEENUSLEPINGUTE PUHUL: TÄPSUSTATUD LIIKI TEENUSTE OSUTAMINE

Ainult teenuste riigihankelepingute puhul: "nimekiri hankija kindlaksmääratud tunnustele vastavate teenuste osutamise lepingutest, mis on täidetud riigihanke algamisele eelneva 36 kuu jooksul, koos teabega nende maksumuse, kuupäevade ja teiste lepingupoolte kohta." Avaliku sektori hankijad võivad võtta arvesse rohkem kui kolme aasta vanuseid kogemusi.

Viide seadusele: RHS § 101 lg 1 p 2 „nimekiri hankija kindlaks määratud tunnustele vastavate teenuste osutamise lepingutest, mis on täidetud riigihanke algamisele eelneva 36 kuu jooksul, koos teabega nende maksumuse, kuupäevade ja teiste lepingupoolte kohta“ RHS § 101 lg 2 „hankija võib piisava konkurentsi tagamiseks arvesse võtta andmeid rohkem kui 36 kuu eest täidetud teenuste osutamise lepingute kohta“

Tingimuse selgitus: Pakkuja või taotleja viimase 3 (kolme) aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) hanke objektiga samaväärset lepingut ning esitatavate lepingute maksumus ilma käibemaksuta on vähemalt 200 000 EUR iga lepingu kohta. Lepingud peavad vastama järgmistele tingimustele: 1) programmeerimiskeel on C#, Javascript (nimetatud programmeerimiskeeled ei pea esinema koos ühes lepingus); 2) peab omama graafilist kasutajaliidest; 3) peab sisaldama liidestusi X-teega; 4) andmebaasikiht on realiseeritud MSSQL või MySQL relatsioonilisel andmebaasiplatvormil. Antud neli tingimust ei pea esinema ühes lepingus korraga. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud). Kui lepingu või teenuse eripära võimaldab töid üle anda ja vastu võtta etapiviisiliselt, loetakse teostatuks ka sellised pakkumuste esitamise tähtpäeval kehtivad lepingud, mille alt on teostatud töid ülaltoodud mahus ja maksumusega, mis on tellija poolt ka vastu võetud. Pakkuja peab hankepassi korrektselt sisestama referentslepingu maksumused, lepingut) kuupäevad ja info teise lepingupoole kohta (sh tellija kontaktisiku telefoninumber, e-posti aadress). Juhul, kui tegemist on riigihankega, siis märkida hankepassis ka viitenumber. Kui hankija soovib kontrollida hankepassis esitatud andmeid seoses täidetud lepingutega võib hankija küsida teise lepingu poole käest kinnitusi ja/tõendeid. Kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile ja/või tehnilisele ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab pakkuja vastavalt hankija nõudmisele vastuvõetaval viisil tõendama, et sellel ettevõtjal, kelle vahenditele ta tugineb, on vastavad vahendid olemas ning ettevõte on nõus nende vahendite kasutamisega ja pakkuja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest pakkuja, kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse kohta või jätnud need andmed või § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata.

23 / 23

Koostatud 02.07.2025 10:43:07 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 3

Kirjeldus: Pakkuja või taotleja viimase 3 (kolme) aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) hanke objektiga samaväärset lepingut ning esitatavate lepingute maksumus ilma käibemaksuta on vähemalt 200 000 EUR iga lepingu kohta. Lepingud peavad vastama järgmistele tingimustele: 1) programmeerimiskeel on C#, Javascript (nimetatud programmeerimiskeeled ei pea esinema koos ühes lepingus); 2) peab omama graafilist kasutajaliidest; 3) peab sisaldama liidestusi X-teega; 4) andmebaasikiht on realiseeritud MSSQL või MySQL relatsioonilisel andmebaasiplatvormil. Antud neli tingimust ei pea esinema ühes lepingus korraga.

Ettevõtjalt oodatavad vastused:

1. Kirjeldus (Suur sisestusala (max pikkus 4000 tähemärki)) 2. Kogusumma (Summa) 3. Valuuta (Vääring) 4. Ettevõtja vastutusala (Suur sisestusala (max pikkus 4000 tähemärki)) 5. Summa (Summa) 6. Valuuta (Vääring) 7. Ajavahemik (Periood) 8. Kas info on konfidentsiaalne? (Raadionupp valikutega "Jah/Ei") 9. Tellija nimi (Sisestusväli (max pikkus 250 tähemärki)) 10. Kontaktisiku nimi (Sisestusväli (max pikkus 250 tähemärki)) 11. E-mail (Sisestusväli (max pikkus 250 tähemärki)) 12. Telefon (Sisestusväli (max pikkus 250 tähemärki)) 13. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 14. URL (Url) 15. Kood (Sisestusväli (max pikkus 250 tähemärki)) 16. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

ALLHANKE OSAKAAL

Ettevõtja kavatseb sõlmida allhankelepinguid järgmise lepinguosa (st protsent) suhtes: Kui ettevõtja on otsustanud sõlmida lepinguosa suhtes allhankelepingu ja toetub asjaomase lepinguosa täitmisel allhankija suutlikkusele, täitke selliste allhankijate kohta eraldi hankepass (Euroopa ühtne hankedokument).

Viide seadusele: RHS § 101 lg 1 p 10 „hankelepingu selle osa suurus, mille suhtes pakkuja või taotleja kavatseb sõlmida allhankelepinguid“

Ettevõtjalt oodatavad vastused:

1. Täpsustage (Suur sisestusala (max pikkus 4000 tähemärki)) 2. Kas see teave on elektrooniliselt kättesaadav? (Raadionupp valikutega "Jah/Ei") 3. URL (Url) 4. Kood (Sisestusväli (max pikkus 250 tähemärki)) 5. Väljaandja (Sisestusväli (max pikkus 250 tähemärki))

Koostatud 03.07.2025 15:39:34 1 / 3 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8912744/general-info

HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD

Viitenumber: 296052 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Kohtute infosüsteemi arendustööd

Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Osakaaludega Elektroonilist oksjoni kasutatakse: ei

Jrk nr

Nimetus Kirjeldus Tüüp / hindamismeetod

Osakaal Kogus Ühik Pakkuja täidetav

1 Raamlepingu sõlmimise järgselt tellitava arendus- ja hooldustöö tunnihind maksimaalse piirhinnana.

Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke alusdokumentidele ning seal nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus esitatakse täpsusega kaks kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale mingeid täiendavaid kulusid ega tee täiendavaid makseid. Hindamiskriteeriumite juures toodud osakaaludes ei ole ristsubsideerimine lubatud.

Maksumus - vähim on parim

20 jah

2 Esimese hankelepingu kogumaksumus Esimese hankelepingu esemeks on kohtumenetluse protsesside analüüsimine kohtulahendite andmete automatiseeritud edastamiseks kohtute infosüsteemi ja rahvastikuregistri vahel. Lepingu sisu on kirjeldatud raamlepingu

Kulu - vähim on parim

30 jah

Koostatud 03.07.2025 15:39:34 2 / 3 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8912744/general-info

tehnilise kirjelduse punktis 5. Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke alusdokumentidele ning seal nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus esitatakse täpsusega kaks kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale mingeid täiendavaid kulusid ega tee täiendavaid makseid. Hindamiskriteeriumite juures toodud osakaaludes ei ole ristsubsideerimine lubatud.

3 Töökogemus, haridus ja/või osalemine varasemates tarkvara projektides.

Kvaliteet - hankija hinnatav

25

4 Meeskonnaliikmete töökogemus Kvaliteet - hankija hinnatav

20

5 Sotsiaalselt vastutustundlik ettevõtja Tingimuste täitmisel on pakkujal võimalik saada 5 punkti. Tingimuse mittetäitmisel omistatakse 0 punkti.

Kvaliteet - hankija hinnatav

5

Kokku: 100

Koostatud 03.07.2025 15:39:34 3 / 3 https://riigihanked.riik.ee/rhr-web/#/procurement/ 8912744/general-info

Hindamismetoodika kirjeldus 1.   Raamlepingu sõlmimise järgselt tellitava arendus- ja hooldustöö tunnihind maksimaalse piirhinnana.

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

2.   Esimese hankelepingu kogumaksumus Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

3.   Töökogemus, haridus ja/või osalemine varasemates tarkvara projektides. Kokku on võimalik saada 25 punkti, kui pakutav analüütik on omandanud ühe alljärgnevatest kogemustest riigihanke algamisele eelneva 4 aasta jooksul: 1. Kohtuasjade (v.a registriasjad) menetlemiseks kasutatava infosüsteemi arendusprojektis osalemine arendajana, süsteemianalüütikuna, ärianalüütikuna või testijana (kellegina, kes on kokku puutunud ärimõistetega) vähemalt 6 kuud. 2. Vähemalt 1 aastane töötamise kogemus ametikohal, mille ametijuhendijärgseks ülesandeks on kohtumenetluse läbiviimiseks vajalik asjaajamine või isikute esindamine kohtumenetluses. 3. Kohtumenetluse õppeaine läbimine Eesti ülikoolis.

4.   Meeskonnaliikmete töökogemus Kokku on võimalik saada 20 punkti.

1) Pakkumus, milles töökogemus tarkvara arendamisel ületab tehnilise kirjelduse p 6.7.25 selliselt, et meeskonnaliikmel on vähemalt 60-kuuline töökogemus tarkvara arendajana - omistatakse 6 punkti; 2) Pakkumus, milles töökogemus tarkvara analüüsi läbiviimisel ületab tehnilise kirjelduse p 6.2.27 selliselt, et meeskonnaliikmel on vähemalt 60-kuuline töökogemus tarkvara analüüsi läbiviimisel - omistatakse 8 punkti; 3) Pakkumus, milles projektijuhtimise töökogemus ületab tehnilise kirjelduse p 6.7.28 selliselt, et meeskonnaliikmel on vähemalt 72-kuuline projektijuhtimise töökogemus tarkvara arenduses - omistatakse 6 punkti.

5.   Sotsiaalselt vastutustundlik ettevõtja Tingimuse täitmise alternatiivid: 1. 5 punkti saab pakkuja, kes on Vastutustundliku Ettevõtluse Foorumi liikmed. Palume liikmesuse tõend lisada pakkumuse koosseisu. 2. 5 punkti saab pakkuja, kellele on omistatud vastutustundliku ettevõtte märgis või samaväärne. Palume märgis lisada pakkumuse koosseisu. Hankija peab samaväärseks näiteks "Hea Töökeskkonna auhind" või muud taolist. 3. 5 punkti saab pakkuja, kes täidab järgmist tingimust: Pakkumus saab 5 punkti, kui pakkuja võtab kasutusele vähemalt kaks töötajate töö- ja eraelu tasakaalu toetavat meedet, mida pakkuja rakendab hankelepingu täitmisel. Näiteks on töö- ja eraelu tasakaalu toetavaks meetmeks töötajatele ühe vaba päeva võimaldamine kuus seoses eraelulise sündmusega või tervisepäeva võimaldamine. Tervisepäev on tasustatud tööpäev ilma haiguslehte võtmata, mida töötaja saab kasutada näiteks massaažis käimiseks või enda koduseks ravimiseks. Pakkuja esitab pakkumuses nimekirja, millised on kaks kasutusele võetavat töö- ja eraelu tasakaalu toetavat meedet ning selgitab, kuidas toetavad need meetmed töö- ja eraelu tasakaalu ning millal on töötajatel õigus neid meetmeid rakendada.

1 / 3

Koostatud 02.07.2025 10:41:40 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

VASTAVUSTINGIMUSED Viitenumber: 296052 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Kohtute infosüsteemi arendustööd

Keskkonnahoidlik hange või hanke osa!

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. Andmed lepinguks, mida kasutatakse juhul kui pakkumus tunnistatakse edukaks. Pakkuja esitab andmetena: 1. lepingu allkirjastaja nimi ja ametinimetus 2. alus lepingu allkirjastamiseks (juhatuse liige, volikiri vms) 3. pakkuja kontaktisik(ud) lepingu täitmisel (nimi, ametinimetus, telefoni number, e-posti aadress). (Suur sisestusala (max pikkus 4000 tähemärki))

3. Pakkumuse esitamisega kinnitab pakkuja, et: • võtab üle kõik hanketeates ja hankedokumentides esitatud tingimused ja esitab pakkumuse üksnes kõigi nende asjaolude kohta, mille kohta hankija soovib võistlevaid pakkumusi; • tal on olemas hankelepingu täitmiseks vajalikud intellektuaalse omandi õigused; • tal on olnud piisavalt aega lepingus sisalduvate tüüptingimustega tutvumiseks, selgitustaotluste esitamiseks ning tüüptingimustega mittenõustumisel vaidlustuse esitamiseks; • kõik tüüptingimused lepingus on pakkujale arusaadavad ja mõistetavad. (Raadionupp valikutega "Jah/Ei")

PAKKUMUSE MAKSUMUS Pakkumuse maksumus tuleb esitada töölehel "Hindamiskriteeriumid ja hinnatavad näitajad" toodud struktuuri kohaselt.

Küsimused ettevõtjale: 1. Kas ettevõtja kinnitab, et täidab pakkumuse lehe "Hindamiskriteeriumid ja hinnatavad näitajad" lehel ette antud struktuuri kohaselt? (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? Kui vastate jah, siis tuleb lisada pakkumuse "Lisadokumentide" lehele ühispakkujate volikiri. (Raadionupp valikutega "Jah/Ei")

EL NÕUKOGU SANKTSIOON. ALLTÖÖVÕTJAD, TARNIJAD JA TUGINETAVAD

ISIKUD. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid, tarnijaid ega tugine kvalifitseerimistingimuste täitmisel selliste ettevõtjate näitajatele, 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.

2 / 3

Koostatud 02.07.2025 10:41:40 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

Hankija lükkab tagasi pakkumuse, mille alusel sõlmitav hankeleping oleks RSanS § 7 lg 1 alusel tühine.

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. Määrust kohaldatakse riigihangetele alates rahvusvahelisest piirmäärast.

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et ta ei kaasa üle 10% hankelepingu maksumusest hankelepingu täitmisele alltöövõtjaid, tarnijaid ega tugine kvalifitseerimistingimuste täitmisel selliste ettevõtjate näitajatele, 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")

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))

KINNITUS KESKKONNAHOIDLIKE NÕUETE TÄITMISE KOHTA.

Pakkuja kinnitab, et ta järgib teenuse osutamisel keskkonnaalaseid nõudeid ning väldib teenuse osutamisega kaasneva negatiivse kõrvalmõju tekkimist keskkonnale, sh: a) teenuse osutamise tulemusena valminud materjalid esitatakse hankijale eelkõige digitaalsel kujul (keskkonnahoidlikel põhjustel vältida materjali printimist), v.a juhul, kui see on vajalik töö eesmärgipäraseks läbiviimiseks);

3 / 3

Koostatud 02.07.2025 10:41:40 https://riigihanked.riik.ee/rhr-web/#/procurement/8912744/general-info

b) digitaalsel kujul edastatavad materjalid peavad olema ökoloogilise jalajälje ja digiprügi vähendamise eesmärgil salvestatud ja edastatud optimaalsel mahul (vältida otstarbetult suuri andmefaile). Mustandfailid, säilitamiseks mittevajalikud töödokumendid jms, kustutada esimesel võimalusel, kuna IT-serverites failide otstarbetu hoidmine on keskkonda kurnava mõjuga; c) kui lepingu täitmise käigus on vajadus printida infomaterjale, siis eelistatakse printimisel tooteid, millel on olemas I tüüpi ökomärgis.

Küsimused ettevõtjale: 1. Pakkuja kinnitab, et täidab keskkonnahoidlikke nõudeid. (Raadionupp valikutega "Jah/Ei")

PAKKUJA ARENDUSMEESKOND

Pakkuja esitab meeskonnaliikmete nõuetele vastavuse tõendamiseks vajaliku teabe hankija poolt etteantud cv vormil.

Küsimused ettevõtjale: 1. CV vorm (Dokumendi vorm / CV vorm.docx)

PAKKUJA VOLITATUD ISIKUD

Kõrvaldamise aluste kontrolli (RHS § 95 lg 1 p 1-3) teostamiseks peab pakkuja esitama ettevõtja muud isikud, kellel on volitus seda ettevõtjat esindada, tema nimel otsuseid teha või teda kontrollida ning kes ei ole hankijale nähtavad äriregistri registrikaardilt. Eelpool nimetatud isikuteks on näiteks tegevdirektor, kes ei ole juhatuse liige jms. Pakkuja peab kontrolli teostamiseks esitama volitatud isiku nime ja isikukoodi või kinnituse, et selliseid isikuid pakkujal ei ole.

Küsimused ettevõtjale: 1. Volitatud isiku(te) nime(d) ja isikukoodi(d) või kinnitus nimetatud isikute puudumise kohta. (Suur sisestusala (max pikkus 4000 tähemärki))

ESIMESE HANKELEPINGU TÖÖDE TEOSTAMISE PROJEKTIPLAAN

Esimese hankelepingu (tehnilise kirjeldus p 5) tööde (analüüsitööd) teostamise projektiplaan. Pakkuja peab esitama esimese hankelepingu analüüsi teostamise projektiplaani, milles toodud tegevuste kestus ei tohi ületada 6 kuud. Projektiplaan peab sisaldama järgmist: 1) pakkuja arusaama analüüsiprobleemist – maksimaalselt 1 A4; 2) pakutava analüüsimetoodika kirjeldus ja põhjendatus, sh piirangud analüüsile koos metoodiliste lahendustega – maksimaalselt 1 A4; 3) pakkuja nägemus analüüsi läbiviimise tegevuskavast ehk projektiplaan. 4) kasutusele võetava agiilse arendusmetoodika kirjeldus - maksimaalselt 1 A4 5) riskianalüüs ja juhtimise kava - maksimaalselt 1 A4 Projektiplaan peab vastama tehnilise kirjelduse punktile 6.6. Projektiplaan peab olema esitatud piisava täpsuse ja põhjalikkusega, et hankijal oleks võimalik pakkuja esitatu alusel hinnata projektiplaani vastavust hanke alusdokumentidele.

Küsimused ettevõtjale: 1. Esimese hankelepingu tööde teostamise projektiplaan. (Vabas vormis dokument)

KINNITATUD

Direktori 04.07.2025

Käskkiri nr 44

Lisa 2

2025

„Kohtute infosüsteemi arendustööd“

Riigihanke viitenumber 296052

Hankedokumendid

REGISTRITE JA INFOSÜSTEEMIDE KESKUS

Registrite ja Infosüsteemide Keskus teeb hankemenetluses osalemisest huvitatud isikutele

ettepaneku esitada pakkumusi vastavalt hanketeates ja hankedokumentides sisalduvatele

tingimustele.

Lk 2/4

1. Üldosa

1.1. Hankija nimi: Registrite ja Infosüsteemide Keskus

1.2. Hankija aadress: Lubja tn 4, 10115 Tallinn

1.3. Riigihanke nimetus: „Kohtute infosüsteemi arendustööd"

1.4. Riigihanke viitenumber: 296052.

1.5. Hankedokumendid on kohaldatavad ainult koos riigihangete seaduse ja selle alusel kehtestatud õigusaktidega. Hankija eeldab,

et huvitatud isik või pakkuja tunneb riigihangete seadust (RHS) ja selle alusel kehtestatud õigusakte.

1.6. Riigihankes saavad osaleda ainult pakkujad või taotlejad, kelle elu- või asukoht on Eestis, mõnes muus Euroopa Liidu

liikmesriigis, muus Euroopa Majanduspiirkonna lepinguriigis või Maailma Kaubandusorganisatsiooni riigihankelepinguga

ühinenud riigis. Riigihankes ei ole lubatud osaleda ettevõtjatel, kelle elu- või asukoht on Venemaa Föderatsioonis või Valgevene

Vabariigis.

1.7. Huvitatud isik või pakkuja kannab hankemenetluses osalemisega seotud kogukulud ja -riski, kaasa arvatud vääramatu jõu (force

majeure) toime võimalused.

1.8. Hankija ei ole otstarbekuse kaalutlusel hanget osadeks jaganud, sest hanke osadeks jaotamine ei ole lepingu olemusest

tulenevalt võimalik.

1.9. Hankija ei arvesta olelusringi kulusid, kuivõrd antud hanke puhul on pakkujatel võimatu esitada RHS § 86 lg 2 p 2 nimetatud

kulude osas näitajaid, mida oleks võimalik omavahel võrrelda.

2. Lepingu ese

2.1. Lepingu eseme tehniline kirjeldus on esitatud punktis 3.1 märgitud ühes või mitmes vastavas lisas.

3. Hankedokumendid

3.1. Hankedokumendid koosnevad käesolevast hankedokumentide põhitekstist ja selle lisadest:

3.1.1 Lisa 1 kõrvaldamise alused ja kvalifitseerimistingimused (hankepass);

3.1.2 Lisa 2 vastavustingimused;

3.1.3 Lisa 3 hindamismetoodika ja hindamiskriteeriumid;

3.1.4 Lisa 4 tehniline kirjeldus;

3.1.5 Lisa 4-1 nõuded arendustele;

3.1.6 Lisa 4-2 nõuded süsteemianalüüsile;

3.1.7 Lisa 4-3 nõuded testimisele;

3.1.8 Lisa 4-4 kasutajaliidese ja WCAG nõuded;

3.1.9 Lisa 4-5 Front-End nõuded;

3.1.10 Lisa 4-6 arenduse tavad ja töökorraldus;

3.1.11 Lisa 5 raamlepingu projekt;

3.1.12 Lisa 6 arenduslepingu eritingimuste projekt;

3.1.13 Lisa 7 arenduslepingu üldtingimuste projekt;

3.1.14 Lisa 8 alltöövõtjate kontrollimise tingimused lepingu täitmise etapis.

3.2. Hankedokumentide põhitekst ja selle juurde kuuluvad dokumendid on teineteist täiendavad.

3.3. Hankedokumentide lahutamatuks osaks on hankepass, mis täidetakse riigihangete registris (RHR, https://riigihanked.riik.ee/).

Hankepassi esitavad pakkujad hankijale esialgse tõendina kõrvaldamise aluste puudumise ja kvalifitseerimistingimuste

vastavuse kontrolliks. Lisaks on hankija poolt koostatud CV vorm pakkujate meeskonnaliikmete vajalike andmete edastamiseks.

3.4. RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest pakkuja, kes on esitanud valeandmeid käesolevas paragrahvis

sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija kehtestatud kvalifitseerimise tingimustele vastavuse

kohta või jätnud need andmed või § 104 lõigete 7 ja 8 alusel hankija nõutud täiendavad dokumendid esitamata. Hankepassi

esitamine on kohustuslik kõigile pakkujatele, kaasa arvatud ühispakkujad ning alltöövõtjad, kelle majandus-ja/või

finantsnäitajatele tuginetakse. Alltöövõtjate osas tuleb hankepass esitada ka juhul, kui tema näitajatele ei tugineta, kuid keda

kavatsetakse kasutada lepingu täitmisel.

3.5. Juhul kui pakkujal esineb RHS § 97 nimetatud olukord, esitab ta hankepassis rikkumised ning info, et kohaldatud on

heastamismeetmeid. Heastamismeetmetena esitab pakkuja vastavad tõendid hankija sellekohase küsimise peale.

4. Täiendav teave ja selgitused

4.1. Hankija ootus on, et huvitatud isikud või pakkujad teavitaks hankijat aegsasti RHR kaudu riigihanke alusdokumentides avastatud

vigade, ebatäpsuste ja ebaselguste parandamiseks ja/või teeks ettepaneku pakkujate hinnangul riigihanke eseme hankimiseks

seatud ebaproportsionaalsete või põhjendamatute piirangute leevendamiseks.

4.2. Küsimuse või taotluse täiendava teabe või selgituste saamiseks hanke alusdokumentide kohta esitamisel peab huvitatud isik või

pakkuja arvestama, et hankijal on õigus tulenevalt riigihangete seaduse § 46 lõikest 1 vastata nimetatule 3 (kolme) tööpäeva

jooksul.

4.3. Juhul, kui huvitatud isiku hanke alusdokumentidega seotud selgitustaotluse hankijale laekumisega ja pakkumuste esitamise

tähtpäeva vahele ei jää vähemalt 6 (kuus) päeva, RHS § 93 lõike 2 punktis 2 ja § 94 lõike 4 punktis 2 nimetatud juhtudel 4 (nelja)

päeva, ei ole hankijal kohustust selgitustaotlusele vastata.

4.4. Punktis 4.2. märgitud küsimus või taotlus esitatakse eesti keeles.

Lk 3/4

4.5. Huvitatud isik või pakkuja esitab punktis 4.2. märgitud küsimuse või taotluse kirjalikku taasesitamist võimaldavas vormis

elektrooniliselt riigihangete registris. Registri töö tõrgete korral esitatakse küsimus või taotlus hanketeates märgitud hankija

kontaktisiku elektronposti aadressile. Telefoni teel esitatud küsimusi vastu ei võeta.

4.6. Hankija esitab hankemenetluse käigus koostatud dokumendid ja antava täiendava teabe ning selgitused huvitatud isikule või

pakkujale elektrooniliselt läbi riigihangete registri.

5. Pakkumuse koostamine

5.1. Pakkumuse koostamisel lähtutakse muu hulgas lepingu(te) projekti(de)s sätestatud tingimustest.

5.2. Vastavalt RHS-le märgib pakkuja pakkumuses, milline teave on pakkuja ärisaladus ning põhjendab teabe ärisaladuseks

määramist. Pakkumus on konfidentsiaalne kuni nimetatud pakkumuse edukaks tunnistamise otsuse tegemiseni. Hankija ei

avalikusta pakkumuste sisu ärisaladusega kaetud osas. Hankija ei ole kohustatud täpsustama pakkujalt ärisaladuse ja/või

pakkuja huve kahjustada võiva tehnoloogilise lahenduse sisaldumist juhul, kui nimetatud asjaolu on jäänud pakkumuses

märkimata. Hankija ei vastuta ärisaladuse avaldamise eest osas, milles pakkuja ei ole seda ärisaladuseks märkinud.

5.3. Pakkumus peab vastama riigihanke alusdokumentides sätestatud tingimustele, sisaldama nõutud dokumente ning olema

vormistatud nõuetekohaselt. Pakkumuses esitatud andmed peavad olema esitatud mahus ja viisil, mis võimaldavad hankijal

kontrollida nende vastavust riigihanke alusdokumentides toodud tingimustele.

5.4. Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke alusdokumentidele ning seal

nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud

kasutada ja sellised pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus esitatakse

täpsusega kaks kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale mingeid täiendavaid kulusid ega tee täiendavaid

makseid.

5.5. Iga viidet, mille hankija teeb ükskõik millises riigihanke alusdokumendis mõnele RHS-i § 88 lõikes 2 nimetatud alusele

(standardile, tehnilisele tunnustusele, tehnilisele kontrollisüsteemile vms) kui vastavuse kriteeriumile, tuleb lugeda selliselt, et

see on täiendatud märkega „või sellega samaväärne“. Iga viidet, mille hankija teeb ükskõik millises riigihanke alusdokumendis

ostuallikale, protsessile, kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et see on täiendatud

märkega „või sellega samaväärne“.

5.6. Kui pakkuja soovib pakkuda samaväärset lepingu eset, tuleb teha sellekohane märge pakkumuses ning esitada koos

pakkumusega samaväärsust tõendavad andmed, dokumendid jms. Alternatiivseid lahendusi ei ole lubatud pakkuda.

6. Dokumentide vormistamise üldnõuded

6.1. Dokumentide vormistamisel lähtutakse võimalusel punktis 3.3 märgitud ühes või mitmes lisas esitatud vormidest.

6.2. Dokumendid koostatakse eesti keeles.

6.3. Dokumendid esitatakse hankijale kirjalikku taasesitamist võimaldavas vormis (see tähendab, et dokumendid peavad olema

püsivat kirjalikku taasesitamist võimaldaval viisil ja sisaldama pakkumuse esitanud isiku(te) nimesid, kuid ei pea olema

omakäeliselt (sh ka digitaalselt) allkirjastatud).

7. Kvalifitseerimise dokumentide vormistamise erinõuded

7.1. Esialgse tõendina pakkuja suhtes kõrvaldamise aluste puudumise ja tema kvalifitseerimise tingimustele vastavuse hindamiseks

kasutatakse hankepassi. Juhul, kui pakkuja soovib tõendada enda vastavust majanduslikule ja finantsseisundile ja/või tehnilisele

ja kutsealasele pädevusele esitatud nõuetele teiste ettevõtjate vahendite alusel, peab pakkuja esitama hankepassi ka selle isiku

kohta, kelle vahenditele ta tugineb. Samuti tuleb esitada hankepass alltöövõtjate kohta.

7.2. Juhul kui pakkuja kasutab alltöövõtjat, võib hankija nõuda lisaks hankepassis esitatule pakkuja poolset kirjeldust, millises tööde

etapis ja suuruses alltöövõtjat kasutatakse.

7.3. Hankija võib nõuda alltöövõtja asendamist juhul, kui kontrolli käigus tuvastatakse alltöövõtja suhtes kõrvaldamise alus.

7.4. Enne lepingu sõlmimist võib hankija nõuda edukalt pakkujalt kõikide asjakohaste hankepassis esitatud kinnitustele vastavate

dokumentide esitamist. Hankija võib vastavaid dokumente nõuda ka kvalifitseerimise etapis. Pakkuja võib esitada enda

kvalifikatsiooni tõendamiseks lisaks hanketeates märgitud kõrvaldamise aluste puudumist tõendavatele ja kvalifikatsiooni

tõendavatele dokumentidele (edaspidi koos nimetatud kvalifitseerimise dokumendid) ka muid dokumente.

7.5. Hankija võib pakkuja esitatud andmete põhjal küsida tõendeid ja kinnitusi teiselt lepingu poolelt kõigi nende lepingute kohta,

millele tuginetakse kvalifikatsiooni tõendamisel.

7.6. Alates maist 2019 saab Euroopa hankepassi vormi täita RHRis või mõnes muus ESPD teenuses - nimekiri on kättesaadav

https://ec.europa.eu/docsroom/documents/34484. Hankepassi ei ole vaja esitada juhul kui RHRis on olemas hankepassi osa ja

ettevõte täidab selle RHR vormil. Hankepassi juhend https://www.fin.ee/riigihanked-riigiabi-osalused/riigihanked/kasulik-teave-

oigusaktid#hankemenetlus.

8. Pakkumuse dokumentide vormistamise erinõuded

8.1. Pakkumuse dokumendid on järgnevad:

8.1.1 hankepass;

8.1.2 vastavustingimused;

8.1.3 hindamiskriteeriumid;

8.1.4 CV-d;

8.1.5 projektiplaan.

8.2. kui hankedokumentides on nõutud, tuleb esitada lisaks punktis 8.1 toodule muud andmed ja dokumendid.

Lk 4/4

9. Elektrooniliselt dokumentide esitamine

9.1. Kvalifitseerimise dokumendid ja punktis 8.1 märgitud pakkumuse dokumendid esitatakse elektrooniliselt RHRis.

9.2. Elektrooniliselt esitatavad dokumendid vormistatakse PDF-vormingus või mõnes muus üldlevinud vormingus.

9.3. Kui esitatavate dokumentide koosseisus on dokumente, mida ei ole võimalik esitada elektrooniliselt, esitatakse need, lisaks

elektroonilistele koopiatele, paberkandjal enne pakkumuste esitamise tähtpäeva vastavalt punktile 10.

9.4. Kui esitatavate dokumentide koosseisus on kolmanda osapoole poolt kirjalikult allkirjastatud dokumente, esitatakse dokument

skaneeritud kujul ning originaaldokument esitatakse ainult juhul, kui hankijal on tekkinud kahtlus dokumendi osas.

9.5. Kui esitatavate dokumentide koosseisus on elektroonilisi dokumente, mida ei ole võimalik terviklikult esitada RHRis, siis esitatakse

need, lisaks RHRis esitatud väljavõtetele, terviklikult CD-l või muul üldlevinud andmekandjal enne pakkumuste esitamise

tähtpäeva vastavalt punktile 10.

10. Paberkandjal dokumentide esitamine

10.1. Paberkandjal dokumendid esitatakse ainult punktis 9.3 märgitud juhul.

10.2. Paberkandjal dokumendid esitatakse 1 (ühes) kinnises läbipaistmatus pakendis.

10.3. Punktis 10.2 märgitud pakendile kantakse järgmised andmed:

10.3.1 riigihanke nimetus – „Kohtute infosüsteemi arendustööd“

10.3.2 riigihanke viitenumber – 296052,

10.3.3 kõikide pakkujate nimed ja registrikoodid,

10.3.4 märge „Mitte avada enne pakkumuste avamise tähtaega“.

10.4. Paberkandjal dokumendid esitatakse posti teel või isikliku kättetoimetamisega.

10.5. Isikliku kättetoimetamisega esitatakse dokumendid pakkumuste esitamise tähtpäeval vähemalt 15 minutit enne pakkumuste

avamist hankija asukohas (Registrite ja Infosüsteemide Keskus, Lubja tn 4, 10115 Tallinn) II korrusel.

11. Raam- ja hankelepingute sõlmimine

11.1. Kõik lepingute olulised tingimused on esitatud punktis 3.1 märgitud vastavas lisas.

11.2. Hankija jätab endale õiguse anda nõustumus lepingu sõlmimiseks kuni 30 (kolmekümne) päeva jooksul alates lepingu sõlmimise

otsuse või pakkumuse edukaks tunnistamise otsuse kohta teate edastamisest.

11.3. Leping jõustub selle poolte poolt allkirjastamise hetkest.

11.4. Pakkuja peab talle allkirjastamiseks edastatud lepingu allkirjastama hiljemalt 5 tööpäeva jooksul. Antud tähtaja jooksul lepingu

allkirjastamisest keeldumist on hankijal õigus käsitleda kui RHS § 119 nimetatud eduka pakkumuse esitanud pakkuja poolset

lepingu sõlmimisest keeldumist ja pakkumuse tagasi võtmist.

12. Hankemenetluse kehtetuks tunnistamine

12.1. Hankijal on õigus kõik esitatud või vastavaks tunnistatud pakkumused tagasi lükata igal ajal enne lepingu sõlmimist vastavalt

RHS §-s 116 lg 1 sätestatule. Kõigi pakkumuste tagasilükkamisel teeb hankija sellekohase põhjendatud otsuse.

12.2. Hankija jätab endale õiguse tunnistada hankemenetlus põhjendatud vajadusel kehtetuks, kui:

12.2.1 hankemenetluse toimumise ajal on hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad

ebaotstarbekaks hankemenetluse lõpuleviimise hanke alusdokumentides sätestatud tingimustel;

12.2.2 vajadus on lepingu eset olulisel määral muuta;

12.2.3 pakkumuste maksumused ülevatav hanke eeldatavat maksumust;

12.2.4 hankija projektile otsustatakse rahastust mitte tagada;

12.2.5 on toimunud sündmus, mida saab lugeda vääramatuks jõuks (force majeure). Vääramatu jõud on asjaolu, mida hankija ei

saa mõjutada ja mõistlikkuse põhimõttest ei saa temalt oodata, et ta hankemenetluse ajal selle asjaoluga arvestaks või

seda väldiks või takistava asjaolu või selle tagajärje ületaks.

/allkirjastatud digitaalselt/

Rivo Reitmann

Direktor

Riigihanke „Kohtute infosüsteemi arendustööd“ (296052) hankedokumentide juurde

Hindamismetoodika ja hindamiskriteeriumid

Hindamismetoodika

Punktide ja koondhinde arvutamine

1. Pakkumused järjestatakse koondhinde alusel. Edukaks tunnistatakse vastavad

pakkumused (kuni 3), mis on kogunud enim punkte.

2. Raamlepingu täitmiseks luuakse pakkujate paremusjärjestus, kus esimesele

järjekohal on enim punkte kogunud edukaks tunnistatud pakkumus, teisel

järjekohal teine enim punkte kogunud edukaks tunnistatud pakkumus ning

kolmandal järjekohal kolmas enim punkte kogunud edukaks tunnistatud pakkumus.

Võrdsete punktidega pakkumuste korral seatakse paremusjärjestus vastavalt

punktile 5.

3. Pakkumusele antav maksimaalne võimalik punktide koondhinne on 100.

4. Pakkumuse koondhinne saadakse kriteeriumite punktide summeerimisel.

5. Võrdsete punktidega pakkumuste korral tunnistatakse edukaks pakkumus, millele

on omistatud esimese hankelepingu kogumaksumuse eest suurim arv punkte.

Juhul, kui ka seejärel on punktid võrdsed, tunnistatakse edukaks pakkumus, millele

on omistatud arendus- ja hooldustöö tunnihind maksimaalse piirhinnana eest

suurim arv punkte. Juhul, kui ka seejärel on punktid võrdsed, siis visatakse

pakkujate vahel liisku.

Hindamiskriteeriumid

Pakkumuse maksumust hinnatakse - Ilma maksudeta

Nr Kriteerium Kriteeriumi hindamismetoodika Osakaal

1. Raamlepingu sõlmimise järgselt tellitava arendus- ja hooldustöö tunnihind maksimaalse piirhinnana.

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

20

2. Esimese hankelepingu kogumaksumus

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") / "suurim väärtus" * "osakaal".

30

3. Töökogemus, haridus ja/või osalemine varasemates tarkvara projektides.

Hindamismetoodika kirjeldatud p 3. 25

4. Meeskonnaliikmete töökogemus

Hindamismetoodika kirjeldatud p 4. 20

5. Sotsiaalselt vastutustundlik ettevõtja

Hindamismetoodika kirjeldatud p 5. 5

KOKKU 100

1. Raamlepingu sõlmimise järgselt tellitava arendus- ja hooldustöö tunnihind

maksimaalse piirhinnana. (Maksumus - vähim on parim, osakaal 20)

Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke

alusdokumentidele ning seal nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks

täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised

pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus

esitatakse täpsusega kaks kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale

mingeid täiendavaid kulusid ega tee täiendavaid makseid.

Hindamiskriteeriumite juures toodud osakaaludes ei ole ristsubsideerimine lubatud.

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused

saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") /

"suurim väärtus" * "osakaal".

2. Esimese hankelepingu kogumaksumus (Maksumus - vähim on parim, osakaal

30)

Esimese hankelepingu esemeks on kohtumenetluse protsesside analüüsimine kohtulahendite

andmete automatiseeritud edastamiseks kohtute infosüsteemi ja rahvastikuregistri vahel.

Lepingu sisu on kirjeldatud raamlepingu tehnilise kirjelduse punktis 5.

Pakkumuse maksumus peab olema lõplik ja sisaldama kõiki kulusid vastavalt riigihanke

alusdokumentidele ning seal nimetamata kulusid, mis on vajalikud lepingu nõuetekohaseks

täitmiseks. 0 või negatiivse väärtusega maksumusi ei ole lubatud kasutada ja sellised

pakkumused on hankijal õigus tunnistada mittevastavaks ning tagasi lükata. Maksumus

esitatakse täpsusega kaks kohta pärast koma. Hankija ei hüvita lepingu täitmisel pakkujale

mingeid täiendavaid kulusid ega tee täiendavaid makseid.

Hindamiskriteeriumite juures toodud osakaaludes ei ole ristsubsideerimine lubatud.

Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused

saavad punkte arvutades valemiga: "osakaal" - ("pakkumuse väärtus" - madalaim väärtus") /

"suurim väärtus" * "osakaal".

3. Töökogemus, haridus ja/või osalemine varasemates tarkvara projektides.

(Kvaliteet - hankija hinnatav, osakaal 25)

Kokku on võimalik saada 25 punkti, kui pakutav analüütik on omandanud ühe alljärgnevatest

kogemustest riigihanke algamisele eelneva 4 aasta jooksul:

1. Kohtuasjade (v.a registriasjad) menetlemiseks kasutatava infosüsteemi arendusprojektis

osalemine arendajana, süsteemianalüütikuna, ärianalüütikuna või testijana (kellegina, kes on

kokku puutunud ärimõistetega) vähemalt 6 kuud.

2. Vähemalt 1 aastane töötamise kogemus ametikohal, mille ametijuhendijärgseks ülesandeks

on kohtumenetluse läbiviimiseks vajalik asjaajamine või isikute esindamine kohtumenetluses.

3. Kohtumenetluse õppeaine läbimine Eesti ülikoolis.

4. Meeskonnaliikmete töökogemus (Kvaliteet - hankija hinnatav, osakaal 20)

Kokku on võimalik saada 20 punkti.

1) Pakkumus, milles töökogemus tarkvara arendamisel ületab tehnilise kirjelduse p 6.7.25

selliselt, et meeskonnaliikmel on vähemalt 60-kuuline töökogemus tarkvara arendajana -

omistatakse 6 punkti;

2) Pakkumus, milles töökogemus tarkvara analüüsi läbiviimisel ületab tehnilise kirjelduse p

6.2.27 selliselt, et meeskonnaliikmel on vähemalt 60-kuuline töökogemus tarkvara analüüsi

läbiviimisel - omistatakse 8 punkti;

3) Pakkumus, milles projektijuhtimise töökogemus ületab tehnilise kirjelduse p 6.7.28 selliselt,

et meeskonnaliikmel on vähemalt 72-kuuline projektijuhtimise töökogemus tarkvara arenduses

- omistatakse 6 punkti.

5. Sotsiaalselt vastutustundlik ettevõtja (Kvaliteet - hankija hinnatav, osakaal 5)

Tingimuste täitmisel on pakkujal võimalik saada 5 punkti.

Tingimuse mittetäitmisel omistatakse 0 punkti.

Tingimuse täitmise alternatiivid:

1. 5 punkti saab pakkuja, kes on Vastutustundliku Ettevõtluse Foorumi liikmed. Palume

liikmesuse tõend lisada pakkumuse koosseisu.

2. 5 punkti saab pakkuja, kellele on omistatud vastutustundliku ettevõtte märgis või

samaväärne. Palume märgis lisada pakkumuse koosseisu. Hankija peab samaväärseks

näiteks "Hea Töökeskkonna auhind" või muud taolist.

3. 5 punkti saab pakkuja, kes täidab järgmist tingimust:

Pakkumus saab 5 punkti, kui pakkuja võtab kasutusele vähemalt kaks töötajate töö- ja eraelu

tasakaalu toetavat meedet, mida pakkuja rakendab hankelepingu täitmisel. Näiteks on töö- ja

eraelu tasakaalu toetavaks meetmeks töötajatele ühe vaba päeva võimaldamine kuus seoses

eraelulise sündmusega või tervisepäeva võimaldamine. Tervisepäev on tasustatud tööpäev

ilma haiguslehte võtmata, mida töötaja saab kasutada näiteks massaažis käimiseks või enda

koduseks ravimiseks. Pakkuja esitab pakkumuses nimekirja, millised on kaks kasutusele

võetavat töö- ja eraelu tasakaalu toetavat meedet ning selgitab, kuidas toetavad need

meetmed töö- ja eraelu tasakaalu ning millal on töötajatel õigus neid meetmeid rakendada.

Registrite ja Infosüsteemide Keskus

„Kohtute infosüsteemi arendustööd“

(296052)

Hanke raamlepingu tehniline kirjeldus

Tallinn 2025

2

Sisukord

1. Mõisted ja lühendid ........................................................................................................ 3

2. Hanke üldinfo ................................................................................................................. 3

3. Kohtute infosüsteemi lühitutvustus ................................................................................. 4

3.1 Tehnoloogilised nõuded ......................................................................................... 4

3.2. KIS arhitektuur AS-IS ............................................................................................. 5

4. Üldtingimused hankeobjektile ......................................................................................... 5

4.1. Üldnõuded ............................................................................................................. 5

4.2. Raamlepingu alusel sõlmitud hankelepingu(te) tulem on ........................................ 6

4.3. Tööde teostamine .................................................................................................. 6

5. Esimene ja teine hankeleping ......................................................................................... 7

5.1. Hetkeolukorra kirjeldus ........................................................................................... 7

5.2. Probleemid ............................................................................................................. 8

5.3. Kasutajagrupid ....................................................................................................... 8

5.4. Esimese ja teise hankelepingu eesmärgid ja tulem ................................................ 9

5.5. KIS-RR edastatavad andmed ................................................................................10

5.6. Andmete edastamise sagedus ja kord vastavalt hetkel kehtivale seadusele .........11

6. Projektipõhised nõuded ja töökorraldus .........................................................................12

3

1. Mõisted ja lühendid

Tehnilises kirjelduses kasutatavad ärimõisted ja lühendid ning nende selgitused

Mõiste Selgitus

AET Avalik e-toimik

Back-end

arendus

Tarkvaraarenduse selline osa, mis tegeleb funktsionaalsustega, mida

otseselt kasutaja ei näe. Back-end arenduse käigus ühendatakse

kasutajatele nähtav veebilehe poolne osa andmebaasiga, haldab kasutajate

ühendusi ja "paneb tööle" veebirakenduse enda.

ET E-toimiku süsteem

Front-end

arendus

Infosüsteemi arenduse selline osa, mille tulem on veebilehtedel ja

veebirakendustel külastajale silmaga nähtav

KIS Kohtute infosüsteem

KOV Kohalik omavalitsus

RIK Registrite ja Infosüsteemide Keskus

RR Rahvastikuregister

2. Hanke üldinfo

2.1. Riigihanke eesmärgiks on sõlmida raamleping kaskaadmeetodil kuni kolme edukaks

tunnistatud pakkujaga, kes hakkavad teostama kohtute infosüsteemi (KIS) arendustöid

(k.a konsultatsioonid) pakkumuses fikseeritud tunnihinna alusel.

2.2. KIS arendustööde eesmärk on KIS infosüsteemi täiustamine ja parendamine,

sealhulgas protsesside automatiseerimise, tehisaru kasutuselevõtu jms kaudu, et

tagada õiguskindlus ja võimalusel lühendada menetluste aegu.

2.3. Raamleping jõustub allkirjastamise hetkest. Raamleping kehtib 48 kuud raamlepingu

sõlmimisest või kuni raamlepingu eeldatava maksumuse täitumiseni.

2.4. Raamlepingu eeldatavaks maksumuseks on 4 000 000 eurot (km-ta).

2.5. Raamlepingu alusel sõlmitavaid hankelepinguid võidakse rahastatakse 2021-2027

Euroopa Liidu ühtekuuluvus- ja siseturvalisuspoliitika fondidest - „Ühtekuuluvuspoliitika

fondide rakenduskava 2021–2027” poliitikaeesmärgi 1 „Nutikam Eesti“ erieesmärgi 2

„Digitaliseerimisest kasu toomine kodanike, ettevõtjate, teadusasutuste ja avaliku

sektori asutuste jaoks“ raames toetatava meetme 21.1.2.1 „Digiriik” sekkumise

21.1.2.11. „Digilahenduste ja uuenduste väljatöötamine ja kasutuselevõtt avalikus

sektoris” tegevuste elluviimiseks.

2.6. Iga viidet, mille hankija teeb käesolevas dokumendis mõnele riigihangete seaduse

paragrahvi 88 lõikes 2 nimetatud alusele kui pakkumuse tehnilisele kirjeldusele

vastavuse kriteeriumile, tuleb lugeda selliselt, et see on täiendatud märkega „või

sellega samaväärne“.

4

2.7. Iga viidet, mille hankija teeb käesolevas dokumendis ostuallikale, protsessile,

kaubamärgile, patendile, tüübile, päritolule või tootmisviisile, tuleb lugeda selliselt, et

see on täiendatud märkega „või sellega samaväärne“.

3. Kohtute infosüsteemi lühitutvustus

Kohtud kasutavad oma igapäevases töös kohtute infosüsteemi, mis on riigi infosüsteemi

kuuluv andmekogu1. Kohtute infosüsteem on õigusemõistmise elektrooniline töökeskkond, kus

registreeritakse kõikide kohtuasjade menetlused ning menetlustes teostatud toimingud, sh

kohtupoolsed menetlustoimingud, istungid, kohtulahendid ning menetlusosaliste esitatud

dokumendid. Ehk kogu kohtumenetlust puudutav informatsioon on kohtule läbi KIS-i

elektrooniliselt kättesaadav.

Kohtute infosüsteemi peetakse ühetasandilise infotehnoloogilise andmekoguna, mis on

liidestatud e-toimiku süsteemiga (ET). Kuigi kohtute infosüsteemil on olemas ka lokaalne

andmebaas, siis suurem osa kohtute infosüsteemis käideldavatest andmetest hoitakse ja

päritakse e-toimiku süsteemist, et tagada õigusemõistmisega seotud andmete ligipääsetavus

menetlusosalistele läbi avaliku e-toimiku (AET) ning kohtuvälistele menetlejatele läbi nende

kasutuses olevate süsteemide, mis on samuti liidestatud ET-ga. Seega seab kohtute

infosüsteemi arendamisele piiranguid ka E-toimiku süsteem, kuivõrd kohtute infosüsteem

kasutab e-toimiku süsteemi poole pöördumiseks e-toimiku teenuseid. E-toimiku süsteem on

riigi infosüsteemi hulka kuuluv andmekogu, mida peetakse menetlusandmete ja isikuandmete

töötlemiseks2 ja sellel puudub oma kasutajaliides. Vastavalt e-toimiku süsteemi põhimäärusele

esitavad e-toimiku süsteemi andmeid väärtegude kohtuvälised menetlejad, uurimisasutus,

prokuratuur, kohus, menetlusosalised ja teised menetluses osalevad isikud. E-toimiku

süsteemi esitatakse andmed kas e-toimiku süsteemi liidese või e-toimiku süsteemiga

liidestatud teise andmekogu kaudu. E-toimiku süsteemiga liidestatud andmekoguks on ka

muuhulgas kohtute infosüsteem.

3.1 Tehnoloogilised nõuded

3.1.1. KISi keskkond jaguneb kaheks – front-end ning back-end. Front-end’i puhul on

kasutusel Angular ning back-end’i puhul kasutatakse puhas arhitektuuri (Clean

Architecture) ja DDD printsiipi.

3.1.2. Kasutatakse .NET Core raamistikku.

3.1.3. Andmebaasisüsteemina on kasutusel Microsoft SQL Server.

3.1.4. Rakendus on integreeritud teiste infosüsteemidega üle x-tee või muude

veebiteenuste.

3.1.5. Arendamiskeel on eesti keel;

3.1.6. Äri- ja süsteemianalüüs dokumenteeritakse Confluence’i keskkonnas. Prototüüp

(klikitav, testitav) luuakse Figma tarkvaralist lahendust kasutades. Keerukamate

lahenduste ja andmemudelite jaoks valib süsteemianalüütik ise sobivaima tasuta

lahenduse, arvestades, et äriprotsesside modelleerimisel tuleb lähtuda standardist

1 Justiitsministri määrus Kohtute infosüsteemi põhimäärus, Riigi Teataja, RT I, 21.03.2025, 8.

2 Vabariigi Valitsuse määrus E-toimiku süsteemi asutamine ja e-toimiku süsteemi pidamise põhimäärus, Riigi

Teataja, RT I, 29.12.2024. 12.

5

BPMN (Business Process Modelling Notation). Valitud lahenduse kasutamine

lepitakse Hankijaga kokku.

3.1.7. Autoriõiguste realiseerimise viis on EUPL.

3.1.8. Arendus- ja testkeskkondades kasutatakse ainult testandmeid. Andmetöötluse

vajaduse ilmnedes Live keskkonnast antakse töödeldavad andmed reeglina

hägustatud või muul viisil anonümiseeritud kujul.

3.2. KIS arhitektuur AS-IS

4. Üldtingimused hankeobjektile

4.1. Üldnõuded

4.1.1. Pakkuja peab teostama arendustöid vastavalt tellimustele, kirjeldatud tehnilisele

kirjeldusele ja raamlepingu alusel sõlmitud hankelepingutele.

4.1.2. Kui hankelepingus ei ole märgitud teisiti, tuleb arendustöid teostada vastavalt

raamlepingule ja käesoleva tehnilise kirjelduse tingimustele.

4.1.3. Arendustöödena tellitakse eeldatavalt infosüsteemi uuendusi, funktsionaalsuse

parandamise ja täiendamisega seonduvaid töid jne. Arendustöödena mõistetakse

6

näiteks tehnilist konsultatsiooni, disainitööde teostamist, süsteemi- ja detailanalüüsi

läbiviimist, programmeerimistöid, testimist (sh automaattestid), dokumentatsiooni

koostamist, vajadusel koolitusi jms. Täpne arendustöö kirjeldus esitatakse

tellimuses.

4.2. Raamlepingu alusel sõlmitud hankelepingu(te) tulem on

4.2.1. Hankelepingu tehnilises kirjelduses kirjeldatud nõuete täitmiseks loodud või

kasutatud lähtekood.

4.2.2. Dokumentatsioon (näiteks analüüsi dokument, arenduskeskkonna seadistusjuhend,

süsteemi arhitektuuri joonis, kontseptuaalsete elementide kirjeldus ja

kasutamisreeglid, ärisõnastik, arenduste ja arhitektuuri kirjeldus, Tarkvara kasutus-

ja haldusjuhendid, administreerimisjuhend, testimise tulemusena valminud

dokumendid, varundus/taasteplaan, versiooni kirjeldus, mittefunktsionaalsete

nõuete vastavustabel, andmekogude semantiline kirjeldus ja andmekoosseis vms).

4.2.3. Testimiseks koostatud skriptid.

4.3. Tööde teostamine

4.3.1. Tööde teostamiseks sõlmitakse hankelepinguid tellimuste alusel.

4.3.2. Tellimuste raames peab pakkuja olema valmis pakkumuses fikseeritud tunnitasu

alusel teostama arendustöid:

4.3.2.1. Sisendiks on konkreetne tulemi (skoobi) tellimus (kirjalikus taasesitamist

võimaldavas vormis, nt e-post), sh tähtaeg.

4.3.2.2. Pakkuja esitab omapoolse pakkumuse täpsustuse, sh tööde mahu hinnangu,

teostamise tähtaja ning hankija nõudmisel projektiplaani (.pdf või .xls

vormingus avatav). Tööd on jaotatud hankelepingu täitmiseks sobiva

kestusega etappideks, etapi tööde mahuhinnangud on realistlikud arvestades

etapi tulemite mahtu.

4.3.2.3. Pakkuja annab valminud tööd hankijale üle tööde üleandmisaktiga. Pärast

hankija poolset töö vastuvõtmist esitab pakkuja hankijale arve.

4.3.2.4. Täpsem tellimuste esitamise kord sätestatakse raamlepingus.

4.3.3. Hankija poolt tellimuses antav töö teostamise tähtaeg on hankija hinnang. Juhul, kui

pakkuja leiab, et hankija poolt etteantud tähtaeg on ebarealistlik, siis on pakkuja

kohustatud sellele viitama pakkumuse täpsustuses. Hankelepingu täitmisel on

vastavate sooviavalduste esitamine välistatud, v.a hankija poolt lisatööde tellimise

olukorras või muul riigihangete seaduse §-s 123 toodud lepingu muudatust

võimaldavas olukorras.

4.3.4. Lepingujärgsete tööde teostamisel on pakkujal õigus teha omapoolseid täiendus- ja

muudatusettepanekuid. Kui hankija nõustub pakkuja poolsete täiendus- ja/või

muudatusettepanekutega, ei ole pakkuja kohustatud tööde teostamisel lähtuma

sõlmitava tellimuse kirjeldusest määral, mis vastab uutele kokkulepetele. Vajadusel

koostatakse vastav lepingu lisa. Pakkuja peab rõhutama juhul kui pakkuja poolne

muudatusettepanek tähendab lisatöid hankijale. Vastava teavituse puudumisel

eeldab hankija, et muudatuse realiseerimiseks ei teostata lisatöid.

7

4.3.5. Hankelepingu alusel teostavate tööde prioriteetide seadmiseks, aja

raporteerimiseks ning tööülesannete jälgimiseks ja haldamiseks kasutatakse RIKi

projektijuhtimise keskkonda JIRA.

4.3.6. Hankija täpsustab vajadusel tellimuses arendustööde üleandmise ja vastuvõtmise

tähtajad.

4.3.7. Pakkuja poolt teostatavate arendustööde garantiiperiood täpsustatakse tellimuses.

5. Esimene ja teine hankeleping

Antud hanke tulemusena sõlmitud raamlepingu esimese hankelepingu esemeks on

kohtumenetluse protsesside analüüsimine kohtulahendite andmete automatiseeritud

edastamiseks kohtute infosüsteemi ja rahvastikuregistri vahel.

Esimese hankelepingu tulemusena valmiv analüüs peab olema sobilik ning piisav teise

hankelepingu arendustööde läbiviimiseks.

5.1. Hetkeolukorra kirjeldus

Rahvastikuregistri seaduse (RRS) kohaselt on kohtud andmeandjaks. Rahvastikuregistri (RR)

andmeandjateks on asutused ja isikud, kes annavad välja või koostavad RRS § 22 lõikes 1

loetletud dokumente (sh kohtulahend), annavad rahvastikuregistrisse andmeid nendelt

dokumentidelt või kelle tegevuse tulemusel muutuvad RRS § 21 lõikes 1 sätestatud

isikuandmed (RRS § 29 lg 1). Kohtud on kohustatud andma kohtulahendi väljaandmise,

jõustumise, muutmise ja kehtetuks tunnistamise andmed, mis tekitavad, muudavad või

täpsustavad rahvastikuregistri andmeid (RRS § 28).

Käesoleval ajal toimub automatiseeritud andmete edastamine kohtu ja RR-i vahel vaid

abielulahutuse kohtulahendite korral.

Täna on KISis lahendite osas andmetena olemas ja kättesaadavad lahendi põhiandmed, kuid

mitte seda osa andmetest, mida on vaja sisestada RR-i täieliku kande sooritamiseks. RR-i

sisestatavad (va. lahendi põhiandmed) andmed on täna olemas vaid lahendi failis teksti kujul.

Teistes kohtuasjades (näiteks eestkostja määramine, isiku põlvnemine, lapsendamine jms)

edastavad kohtud lahendid kohalike omavalitsuste (KOV) perekonnaseisuametnikele RRi

sisestamiseks. Lahend saadetakse elektronposti teel KOV-ile, eelnevalt vastavale KOVi

ametniku nimele krüpteerides. Ametnik kontrollib, kas kohtulahend on jõustunud või muutunud

täidetavaks ning kas lahend muudab RR-is olevaid andmeid. Kui kohtulahend vastab

seaduses sätestatud nõuetele, avab ametnik toimiku, valides toimiku liigi vastavalt

kohtulahendi sisule.

Andmeid sisestatakse KOV ametniku poolt RR-is vastavalt kohtulahendi resolutsioonile ja

kohtulahendite sisestamise juhendile. Liigiti tuleb täita erinevaid andmevälju ja andmehõive

sakke.

Näiteks teovõime lahendi puhul tuleb täna vastavalt kohtulahendi resolutsioonile ametnikul

täita „Teovõime liik“ andmeväli ja sisestada otsus „Märkus“ andmeväljale. Teovõime liik on

alati tühi, kui isikul puudub varasem kogemus temale eestkoste määramisega. Vastavalt

kohtulahendi resolutsioonile valib ametnik isiku teovõime liigiks kas „Piiratud (valimisõiguseta)“

8

või „Piiratud (valimisõigusega)“. Juhul, kui uus kohtulahend tühistab olemasoleva piirangu, siis

lisatakse isikule teovõime liigiks „Teovõimeline“.

Muude lahendi liikide puhul täpsustatakse andmestikku lepingu täitmisel.

2024.a edastati kohtute poolt KOV ametnikele andmete RRi sisestamiseks 3487

kohtulahendit:

 Eestkostja määramise, muutmise, tühistamise kohtulahendid - 2457;

 Isiku põlvnemise, tühistamise tuvastamise kohtulahendid - 66;

 Ruumist väljatõstmise kohtulahendid – 3;

 Surnuks tunnistamise kohtulahendid – 35;

 Vanema hooldusõiguse muutmise kohtulahendid – 779;

 Vanema kande vaidlustamise kohtulahendid – 15;

 Lapsendamise kohtulahend – 52.

5.2. Probleemid

Peamised probleemid tänase elektronpostiga andmete edastamise protsessi osas:

aeganõudev ja töömahukas andmete käsitsi sisestamine, lahendite tõlgendamisest tingitud

vead, kohtulahendite hilinenud või ebaühtlane edastamine, koormus Siseministeeriumile

järelevalve ja koolituse osas. Kohtunikul puudub võimalus koostada lahend andmete põhjal.

Kohtulahendi andmete sisestamisele RR-is kulub KOV perekonnaseisuametnikul täna

keskmiselt 40 minutit. Lahendi sisestamine nõuab tihti kohtulahendist arusaamiseks lahendi

tõlgendamist ja sellest tulenevalt ka aeg ajalt kohtu või Siseministeeriumiga suhtlemist. KOV

ametniku poolt lahendi tõlgendamine võib kaasa tuua aga tõlgendusvigu.

Samuti on ette tulnud probleeme kohtulahendite õigeaegse edastamisega. On kohtuid, kes

edastavad lahendid viivitamata, samal päeval, kuid on ka kohtuid, kes edastavad lahendi alles

siis, kui KOV ametnikul tekib põhjus lahendit küsida või ta saab osapoolelt teada, et lahend on

tehtud.

Kohtu poolt andmete sisestamine KIS-is ja nende automaatne edastamine RR-i aitab oluliselt

kaasa ülaltoodud probleemide ärahoidmisele ning lisaks väheneb nii KOV ametniku töömaht

kui ka üldine halduskoormus riigis, kuna protsessis jääb üks lüli vahelt välja.

Kohtu poolt andmete sisestamine KIS-is suurendab ka õiguskindlust, sest kohus sisestab enda

tehtud lahendit ning perekonnaseisuametnik ei pea lahendit enam tõlgendama. See tähendab

vähem vigu, mis seotud lahendist valesti arusaamisega.

Siseministeerium teeb rahvastikuregistris erinevaid kvaliteeditöid, sealhulgas selliseid, mis

puudutavad kohtulahendite alusel tehtud muudatusi rahvastikuregistris. Kui andmed liiguksid

kohtust otse RR-i, väheneks oluliselt ka Siseministeerium töömaht, kuna edastatud

kohtulahendite sisestamise üle ei pea Siseministeerium teostama enam järelevalvet ega

koolitama selles osas perekonnaseisuametnikke ega kohtuid.

5.3. Kasutajagrupid

KISi kasutajad jagunevad kolme peamisesse kasutajagruppi: menetleja, menetlusgrupi liige,

kantselei. Esimese hankelepingu raames analüüsitav ja teise hankelepingu raames arendatav

lahendus on suunatud neist kahele: kohtunik (menetleja) ja menetlusgrupi liige. Vajadusel

9

peab ka kantselei ametnikul olema võimalik lahendust kasutada. Kasutajagruppide vajadused

kohtulahendite andmete edastamise osas sõltuvad järgnevast:

a) Kohtuaste – I astme, II astme ja III astme menetlevate kasutajate vajadused on

erinevad;

b) Töökorraldus – Erisused töökorralduses sõltuvad nii kohtust kui ka kohtunikust;

c) Kasutaja roll menetluses – Kohtunike kasutajagrupis on neli eristatavat rolli ja

menetlusgrupi liikme kasutajagrupis on kolm eristatavat rolli.

5.4. Esimese ja teise hankelepingu eesmärgid ja tulem

5.4.1. „Kohtulahendite andmete automatiseeritud edastamine kohtute infosüsteemi ja

rahvastikuregistri vahel“ projekti üldeesmärgiks on tagada õigeaegne, täpne ja sujuv

kohtulahendite kajastumine rahvastikuregistris, toetades seeläbi usaldusväärset

andmekvaliteeti ning õiguskindlust. Andmete edastamine kohtute infosüsteemi ja

rahvastikuregistri vahel toimub automaatselt kohtulahendi koostamisel ning seeläbi

on tagatud andmete ühekordne sisestamine ja õigsus - kohtulahendis olevad

andmed liiguvad automaatselt RRi.

5.4.2. Üldeesmärgist lähtuvalt on esimese hankelepingu objektiks kasutajakeskse ja

(töö)aega säästva lahenduse loomine, mis arvestab erinevate kasutajagruppide

vajadustega ning sisaldab järgmisi tegevusi: ideatsioon ja äri- ning

süsteemianalüüs, kasutajaliidese prototüübi loomine ja tagasisidestamine. Silmas

tuleb pidada, et erinevate kasutajagruppide vajadustega arvestamine toob kaasa

mitmete spetsiifiliste vormide loomise.

5.4.3. Erinevaid kasutajagruppe esindavate kasutajatega viiakse läbi detailsem vajaduste

analüüs, mis on täiendavaks sisendiks analüüsile järgnevale tööprotsesside

optimeerimisele ja töökeskkonna disainile.

5.4.4. Pakkuja süstematiseerib kasutajatelt kogutud probleemide ja ettepanekute

kirjeldused tööprotsesside etappide või teemavaldkonna põhiselt ning esitab

analüüsi käigus kogutud teabe ja analüüsi tulemused Hankijale tagasiside

andmiseks. Analüüsis väljapakutavad lahendused kooskõlastatakse hankijaga.

5.4.5. Esimese hankelepingu tulemi (analüüsi) alusel teostatava teise hankelepingu

arendustööde tulemusena on lihtsustatud ja automatiseeritud kohtulahendite

andmete edastamine ja RR-i kandmise protsess resolutsiooni klassifikaatorite

loomise abil. Andmete edastamine KIS  RR teostatakse tulevikus kokkulepitud

klassifikaatorite kaudu ja ametnik ei pea RR-i enam andmeid sisestama. RR hakkab

küsima kohtulahendite andmeid KIS-i poolt klassifikaatorite kaudu. Käsitsi andmete

sisestamist RRis enam ei toimu.

5.4.6. Kasutajaliides peab võimaldama hõlpsalt sisestada ja muuta lahendi osas RR-i

edastatavaid andmeid. Analüüsi ja arenduse käigus tuleb arvestada ka

olukordadega, kus esitatakse algsele lahendile kaebus ja seda menetletakse edasi

enne lõplikku otsuse jõustumist, sealjuures algne lahend saab mõjutatud uuest

otsusest teises sama kohtuasja menetluses. Näiteks kui kohtulahendi peale

esitatakse määruskaebus, peab lahendus automaatselt tuvastama edasikaebamise

fakti ja jälgima määruse kehtivust. Lahendus peab tagama, et edasikaebuse

rahuldamisel, lahendi muutmisel või tühistamisel edastatakse RRi ajakohastatud

andmed. Süsteem peab võimaldama määruskaebuse lahendamist kõigil

kohtutasanditel (maakohus, ringkonnakohus ja Riigikohus).

10

5.4.7. KIS-i sisestatud andmete põhjal peavad moodustuma lisaks RRi minevatele

andmetele ka lahendi erinevad osad tekstilisel kujul. Tekstilist osa peab olema näha

ja võimalik mõjutada muutes vastavaid algandmeid, millest tekst moodustub. Lisaks

peab olema vajadusel võimalik genereerida andmete pealt tervik kohtulahendi fail

või selle osa (nt resolutiivosa), mida saab vajadusel kasutada näiteks pankadele

esitamiseks.

5.4.8. Esimese ja teise hankelepingu tulemuseks peab olema automatiseeritud lahendus,

mille kaudu edastatakse kohtulahendite andmeid RR-i ilma manuaalse

sekkumiseta.

5.4.9. Esimese ja teise hankelepingu eesmärke, tingimusi ja tulemeid täpsustatakse

vajadusel tellimuse esitamisel.

5.5. KIS-RR edastatavad andmed

Kasutajaliideses peab saama sisestada ja muuta eestkoste seadmise, lõpetamise ja

muudatustega seotud määruseid; teovõime piiramisega seotud määruseid (sh

valimisõigusega seotud); vanema õiguste äravõtmise, taastamise ja hooldusõiguse

muudatusi; isiku surnuks tunnistamise määrusi ja sellega seotud määruste tühistamisi; isiku

põlvnemise tuvastamise ja selle tühistamise määruseid ning lapsendamise määruseid.

5.5.1. Kohtulahendi andmed:

 Dokumendi liik (kohtulahend)

 Dokumendi nimetus (kohtumäärus)

 Dokumendi number

 Dokumendi koostamise, jõustumise, kehtetuks tunnistamise või tühistamise

kuupäev

 Dokumendi koostanud kohtu nimetus

5.5.2. Eestkoste andmed:

 Eestkostja(te) ees- ja perekonnanimi või asutuse nimetus

 Eestkostja(te) isiku- või registrikood

 Eestkoste alguse ja lõppemise kuupäev

 Eestkoste lõpp/pikendamine (määrus kehtib kuni 5 aastat määruse tegemisest).

 Piiratud teovõimega isiku poolt iseseisvalt tehtavad tehingud:

 Rahaliste tehingute tegemise tingimused (summa, periood, % sissetulekust)

 Vabatekstiväli muude tehingupiirangute kirjeldamiseks

 Perekonnaõiguslike tehingute luba

 Kohus võib lisaks: eestkostja ülesannete ringi laiendada; eestkostja ametiaega

pikendada; lõpetada eestkoste; eestkostja ülesannete ringi kitsendada; laiendada

eestkostetava iseseisvalt tehingute tegemise õigust; eestkostja ametist vabastada.

5.5.3. Teovõime piiramise andmed:

 Teovõime piiramise fakt

 Valimisõiguse tähenduses teovõimetuks tunnistamise fakt

5.5.4. Vanema hooldusõiguse muudatuste andmed:

 Vanema nimi ja isikukood

 Lapse nimi ja isikukood

11

 Hooldusõiguse liik: täielik isikuhooldusõigus, täielik varahooldusõigus, piiratud

isikuhooldusõigus, piiratud varahooldusõigus, osaline isikuhooldusõigus, osaline

varahooldusõigus, lapse eraldamine vanemast (Kõik hooldusõiguse liigid tuleb valida

eraldi, korraga liiki valida ei ole võimalik)

 Hooldusõiguse olek: kehtiv, peatatud, piiratud, osaliselt üle antud, täielikult üle antud,

täielikult ära võetud, taastatud, lõppenud, tühistatud

 Hooldusõiguse kehtivuse algus- ja lõppkuupäev

 Hooldusõiguse sisu ja kohtulahendi resolutsiooni kokkuvõte (vabatekstiväli)

 Muuta peab saama kõiki hooldusõiguste liike ja olekuid, lisaks peab saama muuta ka

hooldusõiguse alguse ja lõpukuupäeva.

5.5.5. Andmete sisestuse osas jagatakse andmesisestus kaheks blokiks (vaateks):

1) vanemate hooldusõiguse muudatusega seotud andmed ning

2) eestkostet puudutavad andmed (millega on seotud ka alaealise isiku eestkostja

hooldusõiguse andmed vähemalt alaealisele esmasel konkreetse eeskostja

määramisel).

 Teatud tingimustel peab kohtukasutajal olema võimalik sisestada mõlemaid andmeid

ühe lahendi juurest ning võimalikud on ka olukorrad, kus kasutaja peab saama

sisestada kas üksnes hooldusõiguse muutustega seotud andmeid või eestkostet

puudutavaid andmeid.

5.5.6. Isiku põlvnemise tuvastamise kohtulahend

 KIS - RRi läheb isa kanne ja hooldusõigus (hooldusõiguse kohtulahend)

5.5.7. Isiku põlvnemise tühistamise kohtulahend

 Kohus tühistab isiku põlvnemise

5.5.8. Surnuks tunnistamise kohtulahend

 Isik tunnistatakse surnuks ja määratakse surmakuupäev

5.5.9. Vanema kande vaidlustamise kohtulahend

 Kohus tuvastab, et laps ei põlvne sellest isast. Lisaks määrab kohus isa, kellest laps

põlvneb (isiku põlvnemise tuvastamise kohtulahend)

5.5.10. Lapsendamise kohtulahend

 Uue/uute vanemate andmed

 Andmete sisestamise eeldus on ka õiguste süsteemi täiendamine uue tasemega

5.6. Andmete edastamise sagedus ja kord vastavalt hetkel kehtivale seadusele

5.6.1. Esialgse õiguskaitse korras tehtud lahendite andmed edastatakse RR-i lahendi

tegemise kuupäeval.

5.6.2. Eestkoste seadmist puudutavad andmed edastatakse RR-i samuti lahendi tegemise

kuupäeval.

5.6.3. Vanema hooldusõiguse andmed edastatakse RR-i pärast lahendi jõustumist.

5.6.4. Kui määrus vaidlustatakse, edastatakse RR-i info peale kaebuse menetlemist

tekkinud muudatused kohe pärast uue määruse jõustumist.

12

Andmeliidese KIS-ET-RR tööpõhimõtted selguvad analüüsis ja vajadusel täpsustatakse

arendustellimuses.

6. Projektipõhised nõuded ja töökorraldus

6.1. Projekti ja arendustöid juhib pakkuja. Pakkuja peab kinni pidama hanke

alusdokumentidest ja tellimustest ning esitatud pakkumustest. Projekti elluviimisel on

oluline tihe koostöö RIKi kohtute infosüsteemi tiimiga, JDM Tellijaga ning kohtutest

kasutajate esindajatega. Koostööna jõutakse ühistele arusaamadele

kooskõlastatavate tegevuste osas ning üleantavate tulemite detailides, sh peab hankija

olema pakkujaga samas infoväljas ning omama ülevaadet teostatavate tööde seisust

ja pakkumuse koosseisus esitatava projektiplaani järgimisest. Kõik arhitektuursed

lahendused peavad olema enne tööde alustamist kooskõlastatud hankijaga. Vajadusel

moodustatakse juhtrühm.

6.2. Projekti arendustööd peavad vastama RIKis kehtestatud nõuetele, mille hulgas tuleb

lähtuda alljärgnevatest nõuetest. Vajadusel täpsustatakse tellimuses, kui teatud

nõuded ei kohaldu.

6.2.1. Arendustele (Lisa 1 – Nõuded arendustele);

6.2.2. Süsteemianalüüsile (Lisa 2– Nõuded süsteemianalüüsile)

6.2.3. Testimisele (Lisa 3 – Nõuded testimisele);

6.2.4. Kasutajaliidese ja WCAG 2.1 nõuded (Lisa 4);

6.2.5. Front-End nõuded (Lisa 5).

6.3. Projekti raames tuleb järgida RIKi sätestatud arendamise tavasid ja töökorraldust (Lisa

6 – Arenduse tavad ja töökorraldus).

6.4. Pakkuja poolt üleantud ja testitud arendusi testitakse RIKi hallatavas keskkonnas.

6.5. Projekti raames koostatud dokumentatsioon peab vastama järgmistele

vormistusnõuetele:

6.5.1. Dokumentide teemad ja peatükid on loogiliselt struktureeritud ja esitatud koos

sisukorraga (või seda asendava funktsionaalsusega).

6.5.2. Dokumendid ei sisalda kirjavigu ja on koostatud võimalikult üheselt arusaadava ja

selge lauseehitusega.

6.5.3. Dokumentide sisu osas vastutuse selgemaks eristamiseks on dokumendis märgitud

kõik selle koostajad eraldi nende osade juures, mida iga koostaja koostas.

6.5.4. Kõik kasutatud allikmaterjalid peavad olema viidetes ära märgitud ning viitamine

teistele dokumentidele on selge ja ühtses stiilis.

6.5.5. Dokumendid on koostatud eesti keeles.

6.6. Hankelepingute raames hangitavate tööde teostamise tegevuskava kirjeldatakse

hankija nõudmisel ära pakkumuse osana esitatavas projektiplaanis. Tegevuste ajalise

järjestuse ja korduvuse valib pakkuja. Projektiplaan, peab sisaldama ajakava kõikide

hanke tehnilises kirjelduses (tellimuses) kirjeldatud tööde läbiviimiseks ja vastama

vähemalt järgmistele nõuetele:

6.6.1. Projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud

hankelepingu raames soovitud tööd. Projektiplaanis peavad kajastuma need

tegevused, mis on vajalikud lõpptulemuse saavutamiseks.

13

6.6.2. Tegevused tuleb planeerida selliselt, et iga planeeritud etapi eel kooskõlastatakse

tegevused Hankijaga.

6.6.3. Pärast iga etapi lõppemist tuleb planeerida etappide tulemite presenteerimine

Hankijale.

6.6.4. Iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te)

roll/nimi, ajaline kestus ja tähtaeg.

6.6.5. Projektiplaanis peab kajastuma töö tegemiseks vajalikud eeldused/lähteandmed

ning töö mõõdetav(ad) tulem(id). Projektiplaan peab sisaldama mh. tähtaegu, mis

on rakendatavad hankijale/välisele osapoolele projekti edukaks realiseerimiseks

vajalike sisendite tagamise kohta.

6.6.6. Kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud ja

jaotatud iteratsioonidena.

6.6.7. Projektiplaan peab sisaldama ka töid, mille teostamist eeldatakse Hankijalt või teiste

kaasatud väliste osapoolte poolt.

6.6.8. Projektiplaan peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike

pühade, puhkepäevade ja projektimeeskonna puhkustega.

6.6.9. Projektiplaan peab olema ajakohastatud kogu projekti teostamise vältel.

6.6.10. Lisaks projektiplaanile tuleb kirjeldada, millist agiilset arendusmetoodikat

kasutatakse ja kuidas seda plaanitakse praktiliselt rakendada (pakkumuse eraldi

dokument).

6.6.11. Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada

kavatsetakse (pakkumuse eraldi dokument). Riskide maandamise võimalused ja

halduse ettepanekud (lähtuvalt käesolevast projektist) on esitatud selgelt, detailselt,

läbimõeldult, struktureeritult ja põhjendatult.

6.7. Pakkuja peab komplekteerima lepingute täitmiseks arendusmeeskonna, kes

vastab vähemalt järgmistele nõuetele:

6.7.1. Pakkuja arendusmeeskonnas peavad olema kaetud vähemalt järgmised rollid:

projektijuht, (süsteemi)analüütik, arendaja, arhitekt, testija, UI disainer. Meeskonnas

peab olema vähemalt 5 liiget.

6.7.2. Meeskonnaliikmete rollid võivad kattuda projektijuhi ja analüütiku või analüütiku ja

UI disaineri rollides esitatud isikute osas.

6.7.3. Pakkumuses võib ära nimetada ja lepingu täitmisel kaasata ka teisi

meeskonnaliikmeid, kuid nende arvu ja kompetentsi hanke raames ei hinnata.

6.7.4. Meeskonda kokku pannes peab pakkuja arvestama, et hankelepingutega tellitavad

tööd saaksid teostatud vastavalt hankija sätestatud nõuetele.

6.7.5. Hankija võib tellimuse esitamisel täpsustada töid teostava meeskonna suurust ja

pakkujal võib olla vajadus meeskonda suurendada, et püstitatud eesmärke täita.

6.7.6. Meeskonnaliikmete esitamisega kinnitab pakkuja, et esitatud meeskonnaliikmed

hakkavad riigihanke tulemusel sõlmitud lepingu alusel töid teostama. Pakkumuses

esitatud meeskonnaliikme saab hankija eelneval nõusolekul vahetada üksnes uue

meeskonnaliikme vastu, kes vastab hankes esitatud tingimustele.

6.7.7. Kõigil meeskonnaliikmetel peab olema eesti keele oskus heal tasemel.

6.7.8. Vähemalt ühel meeskonnaliikmel peab olema .NET platvormi ning ASP.NET CORE

raamistiku kasutamise praktiline kogemus.

6.7.9. Vähemalt ühel meeskonnaliikmel peab olema JavaScripti või Typescript keele

kasutamise praktiline kogemus.

6.7.10. Vähemalt ühel meeskonnaliikmel peab olema React ja Angular raamistiku

kasutamise praktiline kogemus.

14

6.7.11. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus Entity Framework

Core ja MSSQL´iga.

6.7.12. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus mikroteenustel

põhinevate arhitektuurilahenduste projekteerimisel ja realiseerimisel.

6.7.13. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus Git

versioonihalduse kasutamisega.

6.7.14. Vähemalt ühel meeskonnaliikmel peab olema praktiline prototüübi loomise kogemus

Figmas, UXPin’s või samaväärses tarkvaras.

6.7.15. Vähemalt ühel meeskonnaliikmel peab olema praktiline süsteeminõuete

(requirements), funktsionaalsuste ja kasutaja tegevuste (use case ja/või user story)

kaardistamine ja visualiseerimise kogemus.

6.7.16. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus REST APIga

(https://restfulapi.net/).

6.7.17. Vähemalt ühel meeskonnaliikmel peab olema infosüsteemide arendamisel praktiline

kogemus SOAP päringutega.

6.7.18. Vähemalt üks meeskonnaliige on osalenud projektis, kus on kasutatud X-tee

liidestust.

6.7.19. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus CI/CD pipeline

kasutamisel.

6.7.20. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus tarkvara arenduse

projektis testide automatiseerimise.

6.7.21. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus koormustestide

automatiseerimises Gatlingus või JMeteris või samaväärses tehnoloogias.

6.7.22. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus Kubernetesega ja

Helm chartide loomisega.

6.7.23. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus

Selenium/Selenide testide või samaväärsete testide koostamisega.

6.7.24. Vähemalt ühel meeskonnaliikmel peab olema praktiline kogemus testlugude ja

testplaani koostamisega.

6.7.25. Vähemalt ühel meeskonnaliikmel peab olema vähemalt 36-kuuline töökogemus

tarkvara arendajana.

6.7.26. Vähemalt ühel meeskonnaliikmel peab olema vähemalt 36-kuuline töökogemus

tarkvara arenduses arhitektina.

6.7.27. Vähemalt ühel meeskonnaliikmel peab olema vähemalt 36-kuuline töökogemus

tarkvara analüüsi läbiviimisel.

6.7.28. Vähemalt ühel meeskonnaliikmel peab olema vähemalt 36-kuuline projektijuhtimise

töökogemus tarkvara arenduses.

6.7.29. Kui lepingu täitmisel tekib hankijal põhjendatud kahtlus, et meeskonnaliige ei vasta

hanke tehnilises kirjelduses toodud nõuetele on pakkuja hankija nõudmisel

kohustatud vastavalt lepingule isiku asendama.

6.7.30. Pakkuja esitab meeskonnaliikmete nõuetele vastavuse tõendamiseks vajaliku teabe

hankija poolt etteantud cv vormil.

Nõuded arendustele versioon 7.0 §Requirements

Võti Noude liikKokkuvõte Kirjeldus Olek Täitmise

eest

vastutaja

NA-1 Andme kvalitee t ja standar did

Loodavate lahenduste X-tee teenused peavad vastama RIA x-tee juhendis toodud nõuetele.

KEHTIV Arhitekt /juhtiv arendaja

NA-2 Andme kvalitee t ja standar did

Lahendusega koos tarnitav standardtarkvara peab vastama RIK nõuetele.

Kui hankes ei spetsifitseerita tarkvaralist lahendust tuleb kasutada vastaval konkreetsele vajadusel allpool toodud tarkvarade viimaseid stabiilseid versioone.

Serverite operatsioonisüsteemina: 1) Linux RedHat Enterprise/Rocky 2) Windows

Andmebaasidena: 1) Microsoft SQL 2) Postgre SQL 3) MariaDB

Veebiserverina: 1) Nginx 2) Microsoft IIS 3) Apache

Rakendusserverina: 1) Tomcat

Programmeerimiskeelena : 1) C# 2) Java 3) Python

Kui koos tarnega tarnitakse kommertstarkvara peab selle litsents sisaldama vähemalt 5 aasta turvaparandusi

KEHTIV Arhitekt /juhtiv arendaja

NA-3 Andme kvalitee t ja standar did

Rakendus peab olema loodud vastavalt Eesti Infoturbestandardi nõuetele.

Aluseks tuleb võtta hanke väljakuulutamise hetkel kehtiva versiooni meetmeid. KEHTIV Arhitekt /juhtiv arendaja

NA-4 Andme kvalitee t ja standar did

Avalik sektor arendab riigi tarkvara eelkõige avatult ja avaldab tarkvara vaba litsentsiga vastavalt litsentsi nõuetele.

Antud nõudes võib erandeid teha ainult juhul, kui on teisiti ette nähtud seadusega või muul tellijaga kokku lepitud põhjendatud juhul.

RIKis kasutatavad levinuimad vaba tarkvara litsentsid on EUPL, GNU GPL, MIT. Litsentsi valik sõltub vajadustest ja kohustustest ning tuleb kokku leppida tellijaga.

Litsentside litsentsitingimustes sisalduvad nõuded, mida tuleb litsentsi kasutamisel täita, on järgmised: EUPLi puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>), mille järel on märge „Litsentsitud EUPL alusel “).

GNU GPL puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>); 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistamise kohta.

MIT puhul on nõutav mh: 1) autoriõiguse märge päises (Copyright © <aasta> <autori nimi>) koos litsentsis ette nähtud teavitusega; 2) litsentsitingimustes ette nähtud teavitus töö osas garantii välistuse kohta.

Täpsemalt tuleb nõuetega tutvuda lähtudes valitud litsentsitüübi litsentsitingimustest. Valitud litsentsi litsentsitingimused esitatakse ühel või mõlemal alljärgnevatest viisidest: 1) LICENCE-fail peab olema repositooriumis avalikustatud koos tarkvara koodiga; 2) litsentsitingimuste tekst iga faili päises; 3) lisades päisesse link asukohale, kus on võimalik litsentsitingimustega tutvuda.

KEHTIV Tiimijuht

NA-5 Arhitekt uur

Komponendid peavad olema sellised, mille eluea lõpp (EOL) pole teadaolevalt vähem kui 2 aasta pärast.

Erindid tuleb eraldi kokku leppida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-6 Arhitekt uur

Infosüsteemide komponendid ja topoloogia peab olema enne reaalse arenduse algust RIK-iga kooskõlastatud.

Kooskõlastamist koordineerib Strateegia tiim (peaarhitekt). KEHTIV Arhitekt /juhtiv arendaja

NA-7 Arhitekt uur

Rakendusserver peab võimaldama töötamist andmebaasiserverist eraldi serveril.

KEHTIV Arhitekt /juhtiv arendaja

NA-8 Arhitekt uur

Rakendust peab saama ilma ümber programmeerimata liigutada erinevate domeenide ja domeeni saitide vahel

Lahendus ei tohi olla sisse kompileeritud absoluutseid URL-e. KEHTIV Arhitekt /juhtiv arendaja

NA-9 Arhitekt uur

Väliseid liidestusi peab olema nii vähe, kui võimalik. Liideseid peab saama konfiguratsioonist välja lülitada. Väliste liidestuste veaolukorrad peavad olema käsitletud. Süsteem peab toimima mitte-ärikriitiliste liidestusteta.

KEHTIV Arhitekt /juhtiv arendaja

NA-10 Arhitekt uur

Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi kuuluvate andmekogude vahel toimub läbi riigi infosüsteemi andmevahetuskihi (x-tee).

Avaliku teabe seaduse § 43 (9) lõige 5. Kui X-tee päringut teostab inimene, siis peab olema päringu päises autentinud kasutaja andmed.

KEHTIV Arhitekt /juhtiv arendaja

NA-11 Arhitekt uur

Rakenduste keskkonnad peavad kasutama vastavate X-tee turvaserverite otspunkte.

Arendus vastu arenduse otspuntki jne. KEHTIV Arhitekt /juhtiv arendaja

NA-12 Arhitekt uur

Rakendus peab olema konfigureeritav ühest kohast ilma kompileerimisvajaduseta.

Konfiguratsiooni võib vajadusel automaatselt kopeerida, ilma muutmata, kesksest kohast mujale (näiteks helm chartis values failist kopeerimine mitmesse configmapi). Logimise seaded võivad olla rakenduse konfiguratsioonifailist eraldi ühes lisakonfiguratsioonifailis (näiteks Log4net).

KEHTIV Arhitekt /juhtiv arendaja

NA-13 Arhitekt uur

Kompileeritud rakenduse paigaldamine peab toimuma mõistliku aja jooksul.

Mõistlik aeg on kuni 1 minut. KEHTIV Arhitekt /juhtiv arendaja

NA-14 Arhitekt uur

Rakendus peab olema 64-bitine. KEHTIV Arhitekt /juhtiv arendaja

NA-15 Arhitekt uur

Andmebaas ja rakendus peavad kasutama UTF-8 kodeeringut.

Nõue kehtib Oracle ja Postgre andmebaaside puhul. Erindid lepitakse eraldi Strateegia tiimiga kokku. Näiteks UTF-16.

KEHTIV Arhitekt /juhtiv arendaja

NA-16 Arhitekt uur

Failid peab katalogiseerima aasta > kuu > kuupäev. Täpsem lahendus leppida Strateegia tiimiga kokku. KEHTIV Arhitekt /juhtiv arendaja

NA-17 Arhitekt uur

Üldine programmeerimise paradigma on objekt- orienteeritud.

Erindid tuleb eraldi Strateegia tiimiga kokku leppida. KEHTIV Arhitekt /juhtiv arendaja

NA-18 Arhitekt uur

Kõik baasitabelite välisvõtmed peavad olema indekseeritud.

Indekseid ja muid meetmeid kasutatakse andmebaasi jõudluse tõstmiseks. Väliseid võtmeid tuleb kasutada ka ühest andmebaasist teisele viitamisel.

KEHTIV Arhitekt /juhtiv arendaja

NA-19 Arhitekt uur

Tuleb kasutada päringumuutujaid (inglise keeles "Parameter Binding")

SQL päringute väljakutsumisel väljastpoolt andmebaasi peab kasutama päringumuutujaid, et vältida SQL vahemälu fragmenteerumist.

KEHTIV Arhitekt /juhtiv arendaja

NA-20 Arhitekt uur

Andmebaasitabelites peab olema tehniline primaarvõti.

Nimetus peab olema „ID“ KEHTIV Arhitekt /juhtiv arendaja

NA-21 Arhitekt uur

Failid ja failide indeks peavad olema replikeeritavad teise serveriruumi.

Failide hoidmise asukoht ja loogika on vastavalt kokkuleppele. KEHTIV Arhitekt /juhtiv arendaja

NA-22 Arhitekt uur

Haldustoimingute tegemiseks peab olema vastav haldusliides.

Eemärk on vähendada otse baasis tehtavaid toiminguid. KEHTIV Arhitekt /juhtiv arendaja

NA-23 Arhitekt uur

Andmebaas peab toetama külm- ja kuumvarundamist teise serveriruumi.

Ei tohi kasutada teenuseid, mis välistavad andmebaasi peegeldamist (nt "failstream"). KEHTIV Arhitekt /juhtiv arendaja

NA-24 Arhitekt uur

Sorteerimisreeglistik peab vastama eesti keele tähestikule.

Peab kasutama case-insensitive, accent-sensitive sorteerimist. KEHTIV Arhitekt /juhtiv arendaja

NA-25 Arhitekt uur

Kasutama peab RIK-i elektronposti serverit. Kirjade saatmine ja mall peavad olema konfigureeritavad. Juhul kui elektronposti server ei võta kirju vastu, siis tuleb need uuesti saata elektronposti teenuse taastumisel.

KEHTIV Arhitekt /juhtiv arendaja

NA-26 Arhitekt uur

Konfiguratsiooniparameetrite nimed peavad olema sisulised.

Näiteks : X-tee Turvaserver, mitte XTTS või viitenumber, mitte vk_seb jne. KEHTIV Arhitekt /juhtiv arendaja

NA-27 Arhitekt uur

Ees -ja tagasüsteemid peavad olema arhitektuuriliselt selgelt lahutatud.

Ees -ja tagasüsteemid peavad olema eraldi paigaldatavad ja konfigureeritavad. KEHTIV Arhitekt /juhtiv arendaja

NA-28 Arhitekt uur

Konfiguratsioonifailid peavad olema vaikimisi kaitstud failid.

Näiteks IIS: *.config , *.resources Apache: *.conf, .htaccess. Kui neid on mitu, siis arendaja peab need eraldi välja tooma konfiguratsioonifailide listis. 

KEHTIV Arhitekt /juhtiv arendaja

NA-29 Arhitekt uur

Lõpp-kasutaja näeb vaid faile, mida ta peab nägema.

KEHTIV Arhitekt /juhtiv arendaja

NA-30 Arhitekt uur

Konfiguratsioonis ei tohi olla sisult dubleerivaid parameetreid.

Kõiki parameetreid tuleks konfiguratsioonis kirjeldada vaid üks kord.

Näiteks nii ei tohi olla: = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;connectionString

Password=myPassword;" = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;"_cString

KEHTIV Arhitekt /juhtiv arendaja

NA-31 Arhitekt uur

Rakendused peavad olema kõrgkäideldavad. Meie arendatud rakendused ja kasutatavad karbitooted peavad olema kõrgkäideldavad. ei ole Sticky sessionid soovitatud, vajadus eraldi läbi rääkida.

KEHTIV Arhitekt /juhtiv arendaja

NA-32 Arhitekt uur

Süsteemiintegratsioonid peavad klientrakendusele olema peidetud.

Näiteks klientrakendus ei tohi pöörduda otse andmebaasi ja x-tee poole. KEHTIV Arhitekt /juhtiv arendaja

NA-33 Arhitekt uur

Keskkonnapõhiseid muutujad peavad olema konfiguratsioonist seadistatavad.

Näiteks WSDL ei tohi sisaldada viiteid arendusserveritele. KEHTIV Arhitekt /juhtiv arendaja

NA-34 Arhitekt uur

Windows teenuste nimed peavad olema konfigureeritavad.

KEHTIV Arhitekt /juhtiv arendaja

NA-35 Arhitekt uur

Andmebaasi ei tohi realiseerida rakenduse äriloogikat.

Andmebaas võib sissetulevate andmetega teha ainult tehnilisi tegevusi. Välja arvatud taustatööd. Näiteks õiguste arvutamine või unikaalsete võtmete genereerimine.

KEHTIV Arhitekt /juhtiv arendaja

NA-36 Arhitekt uur

Andmebaasi peab olema võimalik viia MS-SQL standarditele.

Ei tohi kasutada platvormispetsiifilist lahendusi. Erindid eraldi kokku leppida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-37 Arhitekt uur

Rakendus peab kasutama autentimiseks RIK poolt heaks kiidetud OpenID põhist autentimislahendust.

Autentimisviisid peavad olema konfigureeritavad. Samuti peab rakenduse konfiguratsioonist olema määratav, kas ID-kaardiga autentimise korral kasutatakse OCSP või tühistusnimekirjade põhist autentimist.

KEHTIV Arhitekt /juhtiv arendaja

NA-38 Arhitekt uur

Uniform resource identifier (URI) pikkus ei tohi ületada ühegi IS poolt toetatava brauseri maksimaalset lubatud väärtust.

Max uri < 2000. KEHTIV Arhitekt /juhtiv arendaja

NA-39 Arhitekt uur

Rakenduse teenusekirjeldus peab olema üles ehitatud nii, et see toetaks teenuse versioneerimist.

Teenuste kirjelduses võimalike complexType versioonide väärtus "any" KEHTIV Arhitekt /juhtiv arendaja

NA-40 Arhitekt uur

Rakenduse operatiivbaas peab olema arhiveeritav. Enamasti tehakse seda osadena, näiteks juriidiliselt aegunud menetlused, mida kasutajad enam ei näe. KEHTIV Arhitekt /juhtiv arendaja

NA-41 Arhitekt uur

Rakendusega tarnitavad litsentsid peavad olema vähemalt 5-aastase kehtivusajaga.

EU projektide korral tuleb kehtivusaja suhtes lähtuda EU või RIA nõuetest. KEHTIV Tiimijuht

NA-42 Arhitekt uur

Rakendus peab olema jaotatud loogilisteks tehnilisteks osadeks.

Loogiline jaotus lähtub äri vajadustest, haldusest ja arendusest. Tehnilised osad peavad olema eraldi paigaldatavad.

KEHTIV Arhitekt /juhtiv arendaja

NA-43 Arhitekt uur

Failide konverteerimised tuleb teha kasutades RIKi poolt heaks kiidetud teenuseid.

KEHTIV Arhitekt /juhtiv arendaja

NA-44 Arhitekt uur

Kasutaja ei tohi pääseda ligi süsteemi tehnilisele informatsioonile.

Näiteks stack trace, tehnilised logid, täispikavad failinimed, kasutatavad tehnoloogiad ja raamistikud ning nende versioonid.

KEHTIV Arhitekt /juhtiv arendaja

NA-45 Arhitekt uur

Rakendus peab olema stateless. Peab töötama koormusjaoturiga, ei kasuta , SSL offload.sticky sessioneid KEHTIV Arhitekt /juhtiv arendaja

NA-46 Arhitekt uur

Rakenduse failide ligipääsuvajadus peab olema read-execute.

Konteinerite puhul vastutab arendaja, muul juhul administraator. KEHTIV Arendaja /juhtiv arendaja /administraat or

NA-47 Arhitekt uur

Windows serverid peavad töötama windows core serveritel.

KEHTIV Arhitekt /juhtiv arendaja

NA-48 Arhitekt uur

Andmebaasis tuleb veerutüübiks määrata selleks sisuliselt sobivaim andmetüüp.

Lähtuda andmebaasimootori dokumentatsioonist. Keelatud on kasutada (max) tüüpe, kui see pole põhjendatud ja vajalik.

KEHTIV Arhitekt /juhtiv arendaja

NA-49 Arhitekt uur

Rakenduste masinliidestel peab olema publitseeritud tehniline spetsifikatsioon.

Ei kehti karbitoodetele. Näiteks SOAP WSDL ja REST OpenApi Swagger ei tohi olla publitseeritud.

Tehnilises spetsifikatsioonis peavad olema: otspunkti kirjeldus, otspunkti kirjelduse väljalülitamine.

KEHTIV Arhitekt /juhtiv arendaja

NA-50 Arhitekt uur

Active Directory(AD) autentimise kasutamisel peab rakendus kasutama kehtivaid standardeid.

SAML2.0 (Security Assertion Markup Language) ja ADFS (Active Directory Federation Services). KEHTIV Arhitekt /juhtiv arendaja

NA-51 Arhitekt uur

ID-kaardiga autentimise korral kliendipoolne veebirakendus suhtleb veebirakendusega ainult kontrollküsimuse tarbeks.

Edasine koodi täitmine ja võimalike veaolukordade töötlus peab toimuma rangelt ainult kliendi poolel.

Kliendi autentimissertifikaadi kehtivus- ja autentsusekontroll teostatakse maksimaalses võimalikus mahus veebiserveri või proxy poolt.

Autentimissertifikaadil on veebiserveri või proxy poolt kohustuslikult nõutav: Apache: SSLVerifyClient require; NGINX: ssl_verify_client on; Pulse TM: ssl.requireCert(); HAProxy: verify required; Tomcat: clientAuth="true"; jne…                    

Juhul kui toimub pöördub URL poole, kus on nõutud kliendi autentimissertifikaat ning server vastab veaga, peab klientrakendus kuvama korrektse veateate eesti keeles.

KEHTIV Arhitekt /juhtiv arendaja

NA-52 Arhitekt uur

Robotilõksude kasutamine ja valik tuleb kooskõlastada RIK-ga.

Soovitus on robotlõkse vältida ja lahendada potentsiaalne probleem kasutades koormusjaotureid ja IP-põhiseid reegleid.

KEHTIV Arhitekt /juhtiv arendaja

NA-53 Arhitekt uur

Rakendusetevaheline suhtlus peab olema masintöödeldav.

Üldiselt kasutame REST, SOAP(x-tee) või message queued. Muud juhud eraldi läbi rääkida Strateegia tiimiga. KEHTIV Arhitekt /juhtiv arendaja

NA-54 Arhitekt uur

Rakendusserverite otspunktid peavad olema piiratud ja dokumenteeritud.

Rakendus vastab ainult lubatud HTTP-meetoditele, ülejäänud annavad veakoodiga "405" viga. KEHTIV Arhitekt /juhtiv arendaja

NA-55 Arhitekt uur

Rakendusserver peab valideerima ja võimalusel verifitseerima e-posti aadresse.

Peab vastama RFC5322 ja/või RFC6854 standardile.

Võimalusel peab süsteem tõendama kasutaja e-posti aadresse(verifitiseerima)

KEHTIV Arhitekt /juhtiv arendaja

NA-56 Arhitekt uur

Rakendusel peab olema minimaalne CSP header, et funktsionaalsust tagada.

Erandid tuleb hoolikalt läbi mõelda. Väikeväärtus "self"

Täiendav info:

https://csp-evaluator.withgoogle.com/ https://www.hardenize.com/dashboards https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-WebSocket-Accept

KEHTIV Arhitekt /juhtiv arendaja

NA-57 Infoturv e

Kliendi ja serveri vaheline suhtlus peab kasutama TLS-protokolli.

Uusim või kehtiva toega versioon. KEHTIV Arhitekt /juhtiv arendaja

NA-58 Infoturv e

Andmete salvestamisel kliendi arvutisse kasutada baruseri vault-i.

Erandiks on mitmekeelse süsteemi puhul keelevalik. KEHTIV Arhitekt /juhtiv arendaja

NA-59 Infoturv e

Sessiooni lõpetamisel või aegumisel ei tohi kasutajal olla võimalik sessiooni värskendada või uuesti kasutada.

KEHTIV Arhitekt /juhtiv arendaja

NA-60 Infoturv e

Andmebaasis olevate terviklikkuse turvaosaklass 2 või 3 andmete andmebaasi kirjed peab versioneerima.

Versioneerimisel peavad säilima vanad kirjed muutumatul kujul. Uue kirje tehnilistel väljadel peab olema: Kasutaja, kes kirje lõi ja loomise aeg. Kehtetuks tunnistatud kirje peab sisaldama: Kirje muutja, muutmise /kustutamise aeg.

KEHTIV Arhitekt /juhtiv arendaja

NA-61 Infoturv e

Live andmed ei kasutata testimiseks. Testimiseks kasutatakse sünteetilisi, genereeritud andmeid. Erindid tuleb Strateegia tiimiga eraldi kokku leppida.

KEHTIV Arhitekt /juhtiv arendaja

NA-62 Infoturv e

Rakenduse andmebaasikontod peavad omama minimaalseid õigusi.

Rakendus ei kasuta kontot. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse schema installatsioonijuhendis.

KEHTIV Arhitekt /juhtiv arendaja

NA-63 Infoturv e

Rakenduse lõppkasutajatele peavad olema õigused defineeritud läbi rollide(RBAC).

Kasutada KeyCloaki. AD OU ei tohi anda rolli. KEHTIV Arhitekt /juhtiv arendaja

NA-64 Infoturv e

Rakendusse ja andmebaasi ligipääsemiseks peab kasutama ainult kokkulepitud dokumenteeritud autentimisprotseduure.

KEHTIV Arhitekt /juhtiv arendaja

NA-65 Infoturv e

Salasõnad salvestatakse turvaliselt. Krüpteering peab olema CBC, CRT vms režiimis. Kasutada ei tohi ECB režiimi. Räsi+sool+pipar osas lähtuda OWASP-i juhisest https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

KEHTIV Arhitekt /juhtiv arendaja

NA-68 Infoturv e

Kõik avalikud veebirakendused peavad kasutama veebitulemüüre.

IIS puhul peab kasutama näiteks URL scan, apache puhul modsecurity või vastavat tööriista. Võimalikud piirangud tuleb kokku leppida tellijaga detailanalüüsi käigus lähtuvalt tellija vajadustest ja nõudmistest. Kasutama peab whitelisting põhimõtet, mitte blacklistingut. Täiendavalt on kasutusel veebitulemüür (CloudFlare)

KEHTIV Arhitekt /juhtiv arendaja

NA-69 Infoturv e

Rakendus peab õnnestunud sisselogimise järgselt näitama eelmise õnnestunud sisselogimise aega.

EU-direktiiv https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf KEHTIV Arhitekt /juhtiv arendaja

NA-70 Infoturv e

Kasutajaliidesega rakendusel peab olema esilehel rakenduse versioon.

Mõeldud on majas sees arendatud rakendusi. Rakendusserverite ja andmebaaside puhul kehtib vastupidine nõue: .NA-44

KEHTIV Arhitekt /juhtiv arendaja

NA-71 Infoturv e

Sessioonide lõpetamine tuleb teostada serveri poolel ja kõigil rakendustel peab olema konfigureeritav kasutajasessiooni aegumise aeg.

Aeg peab olema muudetav koos teiste konfiguratsiooniparameetritega. Kui kliendilt pole etteantud aja jooksul ühtegi päringut tulnud, tuleb sessioon serveri enda algatusel lõpetada.

Täiendavalt saab lugeda https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet. html

KEHTIV Arhitekt /juhtiv arendaja

NA-72 Infoturv e

Kõik sisendandmed tuleb kodeerida, filtreerida ja valideerida.

Siia hulka kuuluvad vormid, masin-masin liidesed ja veebiteenused. Tuleb teha enne igasugust äriloogika täitmist.

KEHTIV Arhitekt /juhtiv arendaja

NA-73 Infoturv e

Veebipõhiste rakenduste poolt saadetavad vormidel peab paiknema peidetud unikaalne räsi, mida kontrollitakse vormi vastuvõtmisel.

Eesmärk on vältida CSRF rünnakuid. KEHTIV Arhitekt /juhtiv arendaja

NA-74 Infoturv e

Krüpteerimisel ja räsimisel tuleb lähtuda RIA uuringust.

Lähtuda viimasest dokumendist siin nimekirjas https://www.id.ee/artikkel/kruptograafiliste-algoritmide-elutsukli- uuringud-2/

KEHTIV Arhitekt /juhtiv arendaja

NA-75 Infoturv e

Sessiooni tunnused ei tohi olla URL-st kopeeritavad.

https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html KEHTIV Arhitekt /juhtiv arendaja

NA-76 Infoturv e

Konfiguratsioonifaile võivad muuta vaid administraatorid.

Kui rakendusel on admin liides arendatud siis seal muudatuste tegemine on OK. Muud erindid rääkida läbi strateegiatiimiga.

KEHTIV Arhitekt /juhtiv arendaja

NA-77 Infoturv e

Kliendi sertifikaadiga rakenduse poolsel autentimisel (näiteks ID-kaart) peab rakendus vastu võtma sertifikaati HTTP päises.

Kliendi sertifikaadiga autentimisel peaks süsteem vastu võtma kliendi sertifikaati kokkulepitud päises, päise nimi peaks olema rakenduse seadistustega muudetav. Vajadus tuleneb kliendi sertifikaatide usaldusnimekirjade GLB taseme haldusest. Sertifikaat võetakse vastu kliendi veebilehitseja poolt ning edastatakse GLB’le, GLB määrab selle kokkulepitud päisesse sobivuse korral, GLB edastab juba kontrollitud sertifikaadi süsteemi kokkulepitud päises.

Sama asi kehtib mistahes kliendi sertifikaadiga autentimisel ning suvalisest kohast ei tohikski süsteem sertifikaate vastu võtta.

KEHTIV Arhitekt /juhtiv arendaja

NA-78 Infoturv e

Kõik digitembeldamist vajavad rakendused peavad kasutama RIK-i digitembeldamise teenust.

KEHTIV Arhitekt /juhtiv arendaja

NA-79 Infoturv e

Rakenduse turvalisuse tagamiseks tuleb järgida OWASP-i parimaid praktikaid.

Veebirakendus peab probleemideta läbima OWASP ASVS põhineva testi. Esmane väline turvatestimine tellitakse tellija finantseeringul. Kui selle tulemusel leitakse arendaja poolsest tegevusest või tegevusetusest põhjustatud vigu, võib tellija nõuda OWASP järeltestide kompenseerimist arendajalt. Täiendavalt saab uurida https://github. com/OWASP/ASVS

KEHTIV Arhitekt /juhtiv arendaja

NA-80 Arhitekt uur

Rakendus peab olema optimeeritud toodangukeskkonnas toimimiseks.

Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis on ebavajalikud. NT. Debug logi, testimiseks vajalikud erisused äriloogikast. Rakendust peab olema võimalik uuesti pakendamata tarnida vabalt valitud keskkonda(arendus,test).

KEHTIV Arhitekt /juhtiv arendaja

NA-81 Infoturv e

Ajatemplite kasutamisel eelistatakse RIK-i heaks kiidetud lahendust.

Heaks kiidetud lahenduste kohta info annab OPS-tiim. KEHTIV Arhitekt /juhtiv arendaja

NA-82 Infoturv e

Rakendused peavad toetama SSO kasutamist. Sessioon peab olema stateless KEHTIV Arhitekt /juhtiv arendaja

NA-83 Infoturv e

Süsteemile määratud turvaosaklass peab olema täidetud vastavalt määruse "Võrgu- ja infosüsteemide küberturvalisuse nõuded" paragrahv 10-le.

https://www.riigiteataja.ee/akt/113122022030

Enne arenduste algust tuleb turvaosaklassist tulenevad vajadused kooskõlastada Infoturbe ja IS halduse tiimiga

KEHTIV Arhitekt /juhtiv arendaja

NA-86 Infoturv e

Paks klient peab krüpteerima ajutised failid, mis sisaldavad delikaatseid/konfidentsiaalseid andmeid ja need sulgemisel kustutama.

Kui paks klient kasutab ajutisi faile, tuleb tagada nende perioodiline kustutamine tagamaks, et ei koormata liigselt kasutaja arvutit. Eesmärk on tagada, et rakenduse sulgemisel ei jääks kasutaja arvutisse maha informatsiooni, mida sinna jääda ei tohiks.

KEHTIV Arhitekt /juhtiv arendaja

NA-87 Infoturv e

Rakendus peab serverist kustutama kõik ajutised failid koheselt, kui neid enam ei kasutata.

Ajutiste failide kaust peab olema konfigureeritav. KEHTIV Arhitekt /juhtiv arendaja

NA-88 Infoturv e

Rakendus tohib aksperteerida ainult enda väljastatud sessioonivõtmeid.

KEHTIV Arhitekt /juhtiv arendaja

NA-89 Infoturv e

Rakendusse üleslaetavad failid peab filtreerima, valideerima ja need peavad läbima viirusetõrje.

Tuleb teha tüübi ja faili laiendi vastavause kontroll. Failide üleslaadimise ülempiir peab olema analüüsis kirjeldatud.

Filtreerimine - whitelisting, sh suurus

Valideerimine - äriloogiline vastavus

Viirusetõrje - Rik.Icap.VirusScanner: https://hoidla.rik.ee/#browse/browse:nuget-hosted:Rik.Icap.VirusScanner% 2F1.0.0%2FRik.Icap.VirusScanner-1.0.0.nupkg Kontrollib, kas failis on viirus. Kasutamise näited: KrisDoc2 ( ), KRIS4 ( ), KrAvalik ( ), KAEP ( )KRIS-4642 KRIS-4645 KRIS-4643 KRIS-4644 Alternatiivselt võib dll-i kompileerida lähtekoodist: https://svn.just.ee/!/#riksvn/view/head/VirusScanner/trunk

KEHTIV Arhitekt /juhtiv arendaja

NA-90 Infoturv e

Rakendusse üleslaetava faili peab salvestama unikaalse genereeritud nimega.

Faili originaalnimi tuleb salvestada andmebaasi. KEHTIV Arhitekt /juhtiv arendaja

NA-91 Infoturv e

Rakendus ei tohi lubada ennast kasutada iframe sees.

Kasutada CSP headerit.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Mode

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

KEHTIV Arhitekt /juhtiv arendaja

NA-92 Infoturv e

Sessiooni küpsisel peavad olema turvalisuse lipud ja prefix __Host.

Sessiooni küpsise korrala tuleb lisada lipud Secure, HttpOnly ja SameSite. Küpsise nime prefiks peab olema "__Host-". Täiendav info: 1)https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie

2) https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06- Session_Management_Testing/02-Testing_for_Cookies_Attributes

3) https://owasp.org/www-community/HttpOnly

4) https://owasp.org/www-community/controls/SecureCookieAttribute

5) https://owasp.org/www-community/SameSite#:~:text=SameSite%20prevents%20the%20browser%20from, .none%20%2C%20lax%20%2C%20or%20strict%20

KEHTIV Arhitekt /juhtiv arendaja

NA-93 Lähtek ood

Rakenduse kõik üleantavad versioonid peavad enne tellijale üle andmist olema testitud.

Testplaan ja skoop tuleb arenduse käigus tellijaga kokku leppida. KEHTIV Arhitekt /juhtiv arendaja

NA-94 Logimin e ja monito oring

Kriitilised sündmused - sessiooni algamine ja lõppemine ning rolli muutumine tuleb eraldi logida turvalogide tabelis.

Väliste rakenduse puhul tuleb logida kasutaja IP. Sessiooni võtmete väärtused, privaatvõtmed, kasutaja salasõnad ja muu info, mis võimaldab kasutaja isiku kindlakstegemist või on andmekaitset ohustav ei või logisse jääda.

KEHTIV Arhitekt /juhtiv arendaja

NA-95 Logimin e ja monito oring

Rakendus peab logima kõiki väliste süsteemidega vahetatavaid (ka X-tee teenuste kaudu liikuvaid) pöördumisi andmevahetuslogisse.

Parim vahend on Graylog, teine valik baas, kolmas valik on faili logimine. Peab olema võimalus antud logimist välise süsteemi kaupa sisse-välja lülitada. Logi peab olema struktureeritud selliselt, et päring ja vastus on eraldi failides. Logifaili asukoht peab olema administraatori poolt ilma rakendust uuesti kompileerimata seadistatav.

KEHTIV Arhitekt /juhtiv arendaja

NA-98 Logimin e ja monito oring

Rakendus peab logima kõiki rakenduses tekkivaid tehnilisi vigu.

Logi peab sisaldama minimaalselt aega(timestamp), veakoodi, vea sisu (komponent, stack trace, traceback vms), kogu HTTP päringut ja võimalusel kasutaja ID-d. Logimine peab olema konfigureeritav rakenduse taaskäivituseta.

KEHTIV Arhitekt /juhtiv arendaja

NA-99 Logimin e ja monito oring

Failisüsteemi logimise korral peavad logid olema katalogiseeritud, tunnustatud faililaiendiga, roteeruvad.

Peab olema võimalus logimist välise süsteemi kaupa sisse-välja lülitada. Failisüsteemi kausta ei teki rohkem kui 10000 faili. Peab tagama, et iga rakendusserver saaks vajadusel kirjutada logid oma logifaili. Logimine peab olema konfigureeritav rakenduse taaskäivituseta.

KEHTIV Arhitekt /juhtiv arendaja

NA-100 Logimin e ja monito oring

Rakenduse logid peavad olema ühesuguse formaadiga, masinloetavad ja täielikud.

Logiväljad, mida lõppkasutaja saab manipuleerida (IP, useragent, URL) peavad salvestuma logisse kodeeritud ja puhastatud kujul. Igas logikirjes peab olema päringu unikaalne identifikaator. Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega “-”. Logi kuupäeva ja ajaformaat peab vastama ISO 8601 standardile ja olema Eesti ajavööndis.

KEHTIV Arhitekt /juhtiv arendaja

NA-101 Logimin e ja monito oring

Logi tabelid peavad olema arhiveeritavad operatiivbaasist välja.

Tabeli suurenedes peab olema võimalik hoida vanu kirjeid, näiteks kuude või aastate kaupa, iseseisvates tabelites või teises baasis. Mehhanism peab töötama ka krüptoaheldatud logi korral.

KEHTIV Arhitekt /juhtiv arendaja

NA-102 Logimin e ja monito oring

Kui rakendus kasutab või pakub väliseid teenuseid peab nende kohta arvestust pidama.

Peab kasutama statisikamoodulit või OpenTelemetry-t. KEHTIV Arhitekt /juhtiv arendaja

NA-103 Lähtek ood

Süsteem peab enne toodangusse minemist läbima jõudlustestid.

Täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Lähtuda sellest -> https://dok.rik.ee/display/SUS /Koormustestimise+tellimise+eeldused+-+Beeta

KEHTIV Arhitekt /juhtiv arendaja

NA-104 Logimin e ja monito oring

Rakendusel peab olema masinloetav staatusleht. KEHTIV Arhitekt /juhtiv arendaja

NA-106 Lähtek ood

Kõik kommentaarid peavad olema põhjendatud. Lähtekoodi kommentaarid peavad olema: 1. Kood peab olema kirjutatud selliselt, et see on loetav ka ilma kommentaarideta. Kommentaarid on mõeldud keeruliste ja/või kohendamist ja/või edasist tööd (viimaste juurde tuleks märkida TODO) vajavate kohtade jaoks. 2. Aktuaalsed - kommentaar ja kood peavad olema üksteisega vastavuses. 3. Selged ja üheselt mõistetavad. 4. Korrektselt kirjutatud - grammatika ja lauseehitus peavad olema korrektsed. 5. Andmebaasi falid ning muud koodid samadel alustel 6. Peavad olema kirjutatud eesti keeles

KEHTIV Arhitekt /juhtiv arendaja

NA-107 Lähtek ood

Nimetused koodis peavad olema sisulised ja andma selget informatsiooni nende otstarbest.

Projekti skoobis peab olema kokku lepitud nimetamis-reeglistik. KEHTIV Arhitekt /juhtiv arendaja

NA-108 Lähtek ood

Koodis kasutatavad konstandid tuleb defineerida muutujatena.

Siia alla ei kuulu klassifikaatorid. Need peavad olema baasis. KEHTIV Arhitekt /juhtiv arendaja

NA-109 Lähtek ood

Koodis defineeritud andmetüübid peavad olema nimetava käände ainsuses. Kõik andmemassiivid tuleb nimetada nimetava mitmuses.

Näiteks "Isik", "Menetlus" jne. Andmebaasides ei tohi kasutada täpitähti.

Lisainformatsioon:

1) C# - https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions

2) JAVA - https://www.oracle.com/java/technologies/javase/codeconventions-namingconventions.html

3) Python - https://peps.python.org/pep-0008/

KEHTIV Arhitekt /juhtiv arendaja

NA-110 Lähtek ood

Andmetabelites sisalduvad võõrvõtmed peavad nime järgi seostuma tabeli ja väljaga millele need viitavad.

Näiteks kui on tegu tabelitega ’Isik’ ja ’Auto’, siis seos ’isik_auto’ oleks: Isik.ID=Auto.Isik_ID KEHTIV Arhitekt /juhtiv arendaja

NA-111 Lähtek ood

Andmebaasi väljade pikkused peavad lähtuma analüüsis kirjeldatud nõuetest.

Tuleb meeles pidada, et 1 byte ei pruugi võrduda 1 tähemärgiga, näiteks täpitähed. KEHTIV Arhitekt /juhtiv arendaja

NA-115 Lähtek ood

Koodi valideerimiseks kasutame SonarQube reegleid.

Koos SonarQube-ga peab tegema ka Trivy skaneerimise. KEHTIV Arhitekt /juhtiv arendaja

NA-118 Lähtek ood

Lähtekoodis ei tohi olla mitte kasutatavaid osasid. KEHTIV Arhitekt /juhtiv arendaja

NA-120 Lähtek ood

Koodibaasis olevad ärilised terminid peavad olema eesti keeles.

Ärianalüüs ja kood peavad teineteist peegeldama. Ka andmebaasis olevad nimetused peavad olema eesti keeles. KEHTIV Arhitekt /juhtiv arendaja

NA-121 Andme kvalitee t ja standar did

Aadressiandmete käitlemisel lähtuda määrusest "Aadressiandmete süsteem."

Kasutada ADS-i. Link määrusele https://www.riigiteataja.ee/akt/128122024043 KEHTIV Arhitekt /juhtiv arendaja

NA-123 Infoturv e

Iga transaktsiooni juures tuleb kontrollida kasutaja õiguseid ja rollikuuluvust.

OWASP nõuetest -> "Validate the Permissions on Every Request" https://cheatsheetseries.owasp.org /cheatsheets/Authorization_Cheat_Sheet.html#validate-the-permissions-on-every-request

KEHTIV Arhitekt /juhtiv arendaja

NA-124 Andme kvalitee t ja standar did

Tegevusalade käitlemisel lähtuda määrusest "Klassifikaatorite süsteem."

Kasutada RIK EMTAK teenust. https://www.riigiteataja.ee/akt/12910889 KEHTIV Arhitekt /juhtiv arendaja

NA-126 Infoturv e

Süsteemist väljaminevad veateated ei tohi sisaldada süsteemiinfot.

Näiteks: "Tekkis tehniline viga. Päringu ID: XXXXX". Reaalne veateade peab logis säilima! KEHTIV Arhitekt /juhtiv arendaja

NA-127 Dokum entatsio on

Kogu rakenduse dokumentatsioon peab olema kirjutatud eesti keeles.

Erandiks kolmandate osapoolte komponendid. KEHTIV Arhitekt /juhtiv arendaja

NA-128 Dokum entatsio on

Dokumentatsioon peab vastama RIK dokumentatsiooniplaani nõuetele.

https://dok.rik.ee/pages/viewpage.action?pageId=190751639 KEHTIV Arhitekt /juhtiv arendaja

Lisad:  Lisa 1.1.1 – Staatuslehe näidis

NA-129 Dokum entatsio on

Iga uue versiooniga käib kaasas muudatuste kirjeldus.

Changelog või .release notes KEHTIV Arhitekt /juhtiv arendaja

NA-130 Version eerimin e

Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle antavad tarkvarapaketid peavad asuma RIK koodihoidlas.

Arendajale antakse selleks õigused RIK-i koodihoidlas. KEHTIV Arhitekt /juhtiv arendaja

NA-133 Version eerimin e

Peab kasutama RIK piletihalduskeskkonda. Kasutusel on JIRA. Kaasa arvatud välised osapooled. KEHTIV Arhitekt /juhtiv arendaja

NA-137 Version eerimin e

Kolmanda osapoole teegid peavad asuma RIK-i hoidlas.

hoidla.rik.ee KEHTIV Arhitekt /juhtiv arendaja

NA-138 Version eerimin e

Andmebaasi skriptide sisu peab olema kontrollitav. Administraator peab saama veenduda skriptide sisus. KEHTIV Arhitekt /juhtiv arendaja

118 teemat

Nõuded süsteemianalüüsile versioon 1.0

Sisukord:

Sissejuhatus I. Vormistus

SA-v 1. Loomise ja muutmise info: SA-v 2. Oleku info: SA-v 3. Identifitseerimise info:

II. Sisu SA-s 1. Loetavus ja mõistetavus. SA-s 2. Infosüsteemi terviku kirjeldus SA-s 3. Vormide kirjeldused SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused SA-s 5. Infosüsteemi teenuste kirjeldused SA-s 6. Pildid, skeemid, diagrammid:

III. Töövahendid

Sissejuhatus

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused.

Antud nõueteloetelu kehtib nii RIKi majasisestele projektidele kui välistele projektidele (majavälised arendajad).

I. Vormistus

Alljärgnevalt on kirjeldatud vormistuse nõuded kõiksugustele nõuetele, nõuete komplektidele, reeglitele, vormidele. Muudatuste haldamine ja seotud viitamine peavad olema kooskõlastatud ja kokkulepitud enne süsteemianalüüsi algust.

SA-v 1. Loomise ja muutmise info:

Loomise eesmärk/taustSA-v 1.1

Tekkimise aegSA-v 1.2

AutorSA-v 1.3

Viimase muutmise põhjusSA-v 1.4

Viimase muutmise aegSA-v 1.5

MuutjaSA-v 1.6

Kui on tegemist nõuete komplektiga (või plokiga), siis peavad olema selgelt eristatavad pealkiri ja sisuSA-v 1.7

SA-v 2. Oleku info:

Kinnitaja ja kooskõlastajadSA-v 2.1

Nõude/nõuete komplekti seis - kasutusel olevad olekunäitajad peavad olema kokkulepitud vastavalt antud projekti vajadustele. SA-v 2.2 Näiteks võivad nõude/nõuete komplekti olekud olla:

tegemisel kooskõlastamisel kinnitatud implementeeritud kehtetu

SA-v 3. Identifitseerimise info:

Igal nõudel/reeglil ja nõete komplektil peab olema unikaalne identifikaatorSA-v 3.1

II. Sisu

Alljärgnevalt on kirjeldatud nõuded süsteemianalüüsi sisule.

SA-s 1. Loetavus ja mõistetavus.

Süsteemianalüüs peab olema:

Loetav ja selgeSA-s 1.1

Kindlas kõneviisisSA-s 1.2

Sisaldama üheselt defineeritud äri- ja süsteemi mõisteidSA-s 1.3

Sisaldama ainult täpseid andmeolemite/andmeväljade nimetusiSA-s 1.4

SA-s 2. Infosüsteemi terviku kirjeldus

Infosüsteemi terviku kirjelduses peavad olema:

Kõikide kasutatavate mõistete definitsioonidSA-s 2.1

Kõikide äriobjektide ja neile vastavate andmeolemite ning seoste kirjeldused ning üldised tööpõhimõttedSA-s 2.2

Andmeolemite kõik andmeväljad ja nende sisu vastastikune mõju üksteiseleSA-s 2.3

Infosüsteemi erinevate kihtide kirjeldused: andmevahetus/kasutajaliides, domeen ja andmebaas.SA-s 2.4

Andmete käitlemine antud süsteemis:SA-s 2.5

versioneerimineSA-s 2.5.1

sünkroniseerimineSA-s 2.5.2

arhiveerimineSA-s 2.5.3

kustutamineSA-s 2.5.4

Kasutusel väljade ja kasutatavate andmeolemite täpsed nimetusedSA-s 2.6

Õiguste kirjeldused: kasutajad, rollid, grupidSA-s 2.7

Süsteemi üldised valideerimisedSA-s 2.8

SA-s 3. Vormide kirjeldused

Kõik kasutajaliidesevormid ja vormide elemendid peavad olema nõuetega/reeglitega kaetudSA-s 3.1

Peab olema loodud prototüüp, mis kajastab kõike realiseeritavat.SA-s 3.2

Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.

Iga vormi/vormi osa eesmärk peab olema selge - lühike ja täpne kirjeldus, milleks seda vormi on vaja.SA-s 3.3

Iga vormi jaoks peavad olema välja toodud kõik vormiga seotud sisulised veateated.SA-s 3.4

Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.

Iga vormi toimimise juures peavad olema välja toodud erandid, kui need on olemas, võrreldes selle konkreetse süsteemi üldiselt SA-s 3.5 kehtivate reeglitega

Igal vormil peavad olema välja toodud kõik sellega seotud valideerimised ning nendega seotud süsteemi poolt tagastatavad SA-s 3.6 veateated ja hoiatused

Vormi andmeväljade sisestamise ja muutmise kirjeldused; kes (süsteem, kasutaja, sidussüsteem, genereeritakse jooksvalt, ...), SA-s 3.7 mis tingimustel, kuidas?

Millised andmeväljad onSA-s 3.8

kohustuslikudSA-s 3.8.1

valikulisedSA-s 3.8.2

ainult kuvatavadSA-s 3.8.3

tingimuslikult kuvatavad vs alati kuvatavadSA-s 3.8.4

vaikeväärtustega täidetavad + millised need vaikeväärtused onSA-s 3.8.5

Lubatud väärtused väljadele (tekst, numbrid, e-mail, komakohad, jne)SA-s 3.9

Kuidas antud vormile saab - kui see ei tule välja punktis SA-s 4 nõutud kirjeldustestSA-s 3.10

SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused

Kuidas on erinevad vormid omavahel seotudSA-s 4.1

Kasutajate tegevuste ja tegevuste kogumite kirjeldusedSA-s 4.2

Süsteemi terviklikud kasutamise protsessid/kasutusloodSA-s 4.3

Kriitiliste funktsionaalsuste jaoks testimise stsenaariumidSA-s 4.4

SA-s 5. Infosüsteemi teenuste kirjeldused

Kui tegemist on teenusepõhise (XML-teenuseid pakkuva) infosüsteemiga või liidetustumisega mingi teise infosüsteemiga (teenuste tarbimisega), siis peavad olema kirjeldatud:

Tarbitavad teiste süsteemide teenused (kui on)SA-s 5.1

Kõik edastatavad sisendidSA-s 5.1.1

Kõik tarbitavad väljundid - millised ja kus, kuhu edasi saadetakse/märgitakse/salvestatakseSA-s 5.1.2

Kõik infosüsteemi enda poolt pakutavad teenused (kui on)SA-s 5.2

Iga teenuse kohta detailne sisendite kirjeldusSA-s 5.2.1

Iga teenuse kohta detailne väljundite kirjeldusSA-s 5.2.2

Iga teenusega kaasnevad valideerimised ja sisulised veateatedSA-s 5.2.3

Iga teenuse enda loogika ja funktisonaalsuse kirjeldusSA-s 5.2.4

SA-s 6. Pildid, skeemid, diagrammid:

Peavad:

toetama kirjeldatavat - olema tervikliku kirjelduse osa, mitte tühjalt genereeritud pildialbumSA-s 6.1

omama selget eesmärki - milleks see pilt/skeem/diagramm on, mida ta annab?SA-s 6.2

olema intuitiivselt loetavadSA-s 6.3

Lisaks:

Teenuste puhul on hea lisada ka XML .SA-s 6.4 schema

III. Töövahendid

SA-t 1. Süsteemianalüüsi kajastavad töövahendid peavad olema eelnevalt kokkulepitud

SA-t 2. Spetsifikatsioon peab olema üle antud taaskasutataval kujul.

Näiteks:

skeemi/diagrammi/pildi algfail (mitte suvaline link sellele) *.eap fail Confluence eksportfail ...

Nõuded testimisele v1.2 versioon 1.2

Sisukord

Sissejuhatus 1. Üldine AO-N-TE-Y 2. Dokumentatsioon  AO-N-TE-D 3. Testplaan ja -lood  AO-N-TE-T 4. Logimine, raporteerimine  AO-N-TE-R 5. Nõuded testidele  AO-N-TE-N 6. Lähtekood ja spetsiaalsed tööriistad  AO-N-TE-I 7. Alusandmed  AO-N-TE-A 8. Koormus- ja stressitestid  AO-N-TE-S

Sissejuhatus

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised punktid vastavas projektis ei rakendu (pole võimalik/vajalik) ja kas rakenduvad mingid täiendavad punktid või all-loetletud punktidele täpsustused.

1. Üldine AO-N-TE-Y

Nõue Sisu

AO-N- TE-Y-1

Kõikide üle antavate tarkvara versioonidega peavad kaasas olema vastavad testid, nendega seotud dokumentatsioon ning kirjelduse või raporti leitud ja parandatud vigadest.

AO-N- TE-Y-2

Tarkvara vastuvõtmiseks vajalikud hankevõitja poolsed testimised ja skoop (osa testplaanist) lepitakse kokku projekti alguses ning seda muudetakse poolte kokkuleppel.

AO-N- TE-Y-3

Vastavalt kokkuleppele tuleb koostada ning üle anda punktis  nimetatud testplaan ja testlood ning eraldi testprojekti ja -programmi puhul ka vajaminev dokumentatsioon ja AO-N-TE-Y-2 kirjeldus.

AO-N- TE-Y-4

Testitava tarkvara lõplik versioon peab läbima vastavad nõuded koormusele/jõudlusele (ISKE,SLA jm.). Selle tõestamiseks tuleb tarnida ka vastavad testid.

AO-N- TE-Y-5

Üle antud testides või vastuvõtutestimisel esinenud probleemid tuleb parandada sarnaselt põhiarendusega.

AO-N- TE-Y-6

Testid peavad olema loogiliselt grupeeritud ning numereeritud, nii et skriptide või tööriistade abil saab kindlat osa käivitada. Näiteks teenuse- või tüübi kaupa (süsteemitestid, koormustestid vm.).

AO-N- TE-Y-7

Üle antud testide käivitamiseks ei pea RIK soetama lisatarkvara. Näiteks automaattestid, koormustestid jm. võiks olla kirjutatud C#+NUnit'is, Selenium'is, JMeter'is, Robot Framework'is või Gattling'us. Kokkuleppel Java+JUnit, Cypress või muu.

2. Dokumentatsioon  AO-N-TE-D

Nõue Sisu

AO-N-TE-D- 1

Dokumentatsiooni eesmärgiks on edasi anda kogu vajalik informatsioon testide kohta (testplaanid, testlood, testide käivitamiseks, jooksutamiseks ja valideerimiseks vajalik informatsioon jne).

AO-N-TE-D- 2

Dokumentatsioon peab olema versioneeritud ning iga punkti (Näiteks Testlugu) juures peab olema tekkimise aeg, viimase muudatuse aeg, autor, muutja.

3. Testplaan ja -lood  AO-N-TE-T

Nõue Sisu

AO-N- TE-T-1

Testplaanile ja –lugudele rakendub peatükk .AO-N-TE-D-2

AO-N- TE-T-2

Testplaan kirjeldab ning selgitab kogu tarkvaraga seotud testimist, kui ei ole kokku lepitud teisiti.

AO-N- TE-T-3

Testlood tulenevad kasutuslugudest ja/või süsteemianalüüsi nõuetest, nende kattumisel piisab testimise kirjeldusest, et vältida dokumentatsiooni dubleerimist.

AO-N- TE-T-4

Testloos peab minimaalselt olema: testi kirjeldus, viide nõudele või kasutusloole, etapid, oodatud tulemus, tegelik tulemus.

AO-N- TE-T-5

Testprojekti ja –programmi puhul võib kood koos kommentaaridega täita testloo rolli (Näiteks Testi nimetus viitab kindlale testloole või süsteeminõudele, C# kirjutatud süsteemitesti nimetamisloogika ja kommentaarid teevad kergelt selgeks tegevuste ahela).

4. Logimine, raporteerimine  AO-N-TE-R

Nõue Sisu

AO-N- TE-R-1

Raportitele rakendub peatükk  AO-N-TE-D-2 . Eraldi raporteid pole tingimata vaja kui kasutatakse ühist JIRA + Confluence keskkonda.

AO-N- TE-R-2

Testraportis kajastatud vigade juures peab olema märgitud tarne versioon, milles viga leiti ning milles see on kõrvaldatud.

AO-N- TE-R-3

Automaatsete testide puhul peab automaatselt genereeruma testraport või statistika tegemiseks vajalik logi (Näiteks NUnit genereerib ise raporti, JMeteris Summary Report+ Aggregate Report või eraldi .csv fail jne.).

AO-N- TE-R-4

Koormus- ja stressitestide puhul peab raport kajastama, millise koormuse juures hakkasid testid negatiivseid tulemusi saama ning millised vead esinesid.

AO-N- TE-R-5

Koormus- ja stressitestide juures on vaja minimaalselt välja tuua: saadetud päringute arv, min. päringu käitlemise aeg(ms), max. päringu käitlemise aeg(ms), päringute käitlemise standardhälve (ms), keskmine päringu käitlemise aeg(ms), vigade %, läbilaskevõime(tegevust/sek.), 90/95/99 protsentiilid.

5. Nõuded testidele  AO-N-TE-N

Nõue Sisu

AO-N-TE- N-1

Testprojekti ja –programmi testide juures rakendub peatükk  AO-N-TE-D-2 , lisaks peab testi juurde märkima testi tegija ning tarkvara versiooni, millele test koostati. 

AO-N-TE- N-2

Süsteemitestidega peavad olema kaetud kõik süsteemi osad, kui ei ole kokku lepitud teisiti (Näiteks kõik arendatud teenused, kasutajaliidesega rakenduse testlood jne.).

AO-N-TE- N-3

Iga test peab olema süsteemi- või ärianalüütiliselt terviklik põhjendatav kooslus (Näiteks ühes testis ei testita kahte erinevat teenust või süsteemi viga).

AO-N-TE- N-4

Iga teenuse kohta peab olema Smoke test, mis kontrollib lihtsaima sisendiga teenuse töökorda.

AO-N-TE- N-5

Kuna RIKis arendatakse pideva integratsiooni mudelit järgides, siis peab olema võimalik teste valikuliselt grupeerida ning neid automaatselt käivitada (Näiteks Grupp „Nightly" öiste integratsioonitestide jaoks).

AO-N-TE- N-6

Testsessioonid ning omavahel mitte seotud testid ei tohi üksteist mõjutada.

6. Lähtekood ja spetsiaalsed tööriistad  AO-N-TE-I

Nõue Sisu

AO-N-TE-I- 1

Spetsiaalselt arendatud testprojektile ja -programmile rakenduvad „Nõuded arendustele –Nõuded rakenduse koodile" .

AO-N-TE-I- 2

Spetsiaalselt arendatud testprojektid peavad kasutama üldtuntud raamistikke Näiteks NUnit, JUnit.

AO-N-TE-I- 3

Kui testprojekt kasutab Objektide kihte, omab teenuste kihti või koodi osa, mida saab WSDL, andmebaasi või muu pealt genereerida, siis selleks peab kasutama tööriistu (Näiteks DTOd ei kirjutata käsitsi).

AO-N-TE-I- 4

Punktis mainitud tööriistad ja nende parandused tuleb tarnida koos testidega.AO-N-TE-I-3

7. Alusandmed  AO-N-TE-A

Nõue Sisu

AO-N-TE- A-1

Alusandmete genereerimiseks vajalik peab olema vastavate testidega kaasas.

AO-N-TE- A-2

Kui testimiseks on vajalikud andmed teistest süsteemidest, siis nende saamine lepitakse eelnevalt kokku.

AO-N-TE- A-3

Alusandmed peavad töötama erinevates keskkondades, kaasa arvatud andmed, mida päritakse teistest süsteemidest.

AO-N-TE- A-4

Peab vältima teiste süsteemide andmete rikkumist, selle vältimiseks vt. punkt .AO-N-TE-A-2

AO-N-TE- A-5

Eelistama peaks alusandmete genereerimist või eraldi üldkasutatavat kihti, millest andmed võetakse, mitte koodi sisse kirjutatud andmeid (Näiteks Isikukoodid võetakse üldisest jadast või eraldi testandmete alamprojektist).

AO-N-TE- A-6

Võimalusel kasutada sünteetilisi, mitte reaalseid andmeid (Näiteks reaalsuses mitte eksisteerivad Isikud), eriti kui arendatavas tarkvaras on automaatseid teavitusi või muud samalaadset (Näiteks automaatne e-mailide saatmine).

8. Koormus- ja stressitestid  AO-N-TE-S

Nõue Sisu

AO-N-TE-S-1 Testide üleandmisel peab kaasa andma nendega kaasneva dokumentatsiooni, kasutatud konfiguratsiooni ning vajadusel riistvara ja arhitektuuri kirjelduse.

AO-N-TE-S-2 Kasutatud konfiguratsioon ning riistvara ja arhitektuur võiks tugevalt sarnaneda vastuvõtja test- või toodangukeskkonna riistvaraga.

AO-N-TE-S-3 Testid peavad olema üldisest konfiguratsioonist skaleeritavad: kasutajate arv, kasutajate etapilisus (ramp-up), testide ajastamine jm. on üldised muutujad või üldises konfiguratsioonis.

AO-N-TE-S-4 Igal testil peab olema konkreetne kontekst (Näiteks SLA nõue, teenuse või baasiprotseduuri jõudluse hindamine vm.).

Kasutajaliidese ja WCAG nõuded v2 Sisukord

Üldnõuded Abiinfo Failid Heli ja video Jalus Lingid Modaalaknad Navigeerimine Nupud Otsing Pildid ja ikoonid Printimine ja salvestamine Tabelid ja andmeplokid Teated Tekstid, sisu ja fondid Tuvastus Vormid Värvid ja mustrid

Käesoleva eesmärgiks on kirjeldada erinevate sisuelementide rakendamise reegleid ja juhiseid kasutajaliidestes, et tagada ligipääsetavus ja vastata UX headele tavadele. Nõuded on mõeldud analüütikutele ja programmeerijale kujunduselementide kasutamise näitlikustamiseks ja nendega seonduvate nõuete kirjeldamiseks. Lehele on kokku koondatud RIK kasutajaliidestele kehtivad nõuded/hea praktika, kui . WCAG nõuetele vastamist reguleerib .WCAG 2.1 AA nõuded AvTs Arendustööde/projekti alguses tuleb käesolevate nõuetega tutvuda. Töö käigus rakendatakse vaid neid nõudeid, mis on teostatava arendusprojekti raames relavantsed. Sisemiseks kasutamiseks mõeldud rakendustes ei pea järgima ekraanilugerite ligipääsetavuse tagamiseks mõeldud nõudeid. Projektis võib kokkuleppeliselt mööndusi teha nõuetele vastavuse osas, kui tegemist on nö "sisemiseks" kasutamiseks, st mitte avalikkusele suunatud kasutajaliidesega. Avalikkusele suunatud kasutajaliides peab olema laia kasutajaskonda arvestades võimalikult ligipääsetav ja UX parimaid praktikaid jälgiv. Nõuded kehtivad eelkõige uuele, st projekti käigus lisatavale osale, kuid kui platvormi piirangutest tulenevalt ei ole võimalik osasid nõudeid täita, siis neist nõuetest võib loobuda. Nõudeid, mida on võimalik täita, tuleb järgida. See põhimõte kehtib nii edasiarenduste kui uute arenduste puhul. Edasiarenduste projekti korral ei ole kohustust olemasoleva vastavusse viimist nõuetega. Lehe eest vastutab Loori Paadik

Üldnõuded

1 Veebileht peab olema kasutatav vähemalt 320 CSS piksli laiusel ekraanil ilma horistontaalse kerimisriba tekkimiseta või 256 CSS piksli kõrgusel ekraanil ilma vertikaalse kerimisriba tekkimiseta. (WCAG 1.4.10) Leht peab olema kohanduv (responsive). Lehte peab olema võimalik mobiilis suurendada – ei tohi kasutada  märgendi user-scalable=”no” atribuuti. (WCAG 1.4.4)meta

2 Tuleb kasutada HTML5 struktuurielemente: article - suure iseseisva sisuosa jaoks, section - sektsioonide eristamiseks, header - päise esitamiseks, main - põhisisu märkimiseks, footer - jaluse märkimiseks, nav - menüü jaoks, aside - külgriba jaoks, address - kontaktinfo (soovitatavalt e-posti aadressi) jaoks. Elementidele tuleb lisada pealkiri aria-label=”...” atribuudiga või kirjutada vastava pealkirja id aria-labelledby=”...” atribuuti. (WCAG)

3 Vältida tuleb raame nagu või , sest paljud mobiilseadmed ei toeta neid ning nad on üldiselt vananenud ja problemaatilised. Kui siiski kui kasutatakse raame, tuleb neile anda frameset ifram kirjeldavad title=”...” atribuudid. (WCAG)

4 Kujundus tuleb luua kasutades laadilehti (stylesheets), mitte style=“…” atribuute. Sisu peab olema kättesaadav ja loogilises järjekorras ka laadilehti kasutamata ehk CSS-iga ei tohi lehe sisu järjekorda oluliselt muuta (WCAG 1.3.2)

5 Peidetud elemendile tuleb anda CSS-is nii display: none kui ka visibility: hidden stiilid, et ükski ekraanilugeja ei näeks peidetud elementi. (WCAG)

6 Lehel peab olema võimalik teha kõiki tegevusi (välja arvatud nt joonistamine) kasutades ainult klaviatuuri - tab klahvi või nooleklahve - (WCAG 2.1.1) ja ka ainult hiirt. Lehel ei tohi leiduda klaviatuurilõkse ehk olukordi, kus klaviatuuriga mingi funktsiooni juurde minna on võimalik, kuid sealt ära enam mitte. (WCAG 2.1.2)

7 Klaviatuuri kiirvalikud ei tohi koosneda ainult tähtedest või numbritest. Lisaks tähele või numbrile peab kiirvalik sisaldama ka mõnda teist klahvi (Ctrl, Shift, Alt vms). Kui aga neid siiski kasutatakse, peab kasutajal olema võimalus neid ümber seadistada. Erandiks on kiirvalikud, mis töötavad ainult siis, kui mingi element on parajasti fookuses. (WCAG 2.1.4)

8 Veebileht või mobiilirakendus ei tohi olla kasutatav ainult portrait või ainult landscape asendis. Erandiks on lehed, mida ei ole võimalik loomupoolest mõlemas suunas kasutada, näiteks klaveri äpp. (WCAG 1.3.4)

9 Motoorikahäiretega kasutajal võib olla võimatu seadet raputada või keerata. Kõiki liikumise peale aktiveeritavaid tegevusi peab saama teha ka muud moodi. Nt pangaäpis saab telefoni raputades kontojääki näha, kuid on olemas ka nupp “Vaata kontojääki”. (WCAG 2.5.4)

10 Motoorikahäiretega kasutajal võib olla keeruline liigutada ekraanil sõrmi kindlat rada pidi. Selliste liigutuste jaoks peab võimaldama alternatiivi. Nt kaardi rakenduses, kus kaardi suurendamiseks tuleb sõrmi üksteisest eemale viia, on olemas ka nupud kaardi suurendamiseks ja vähendamiseks. (WCAG 2.5.1) 

11 Päästiksündmustena tuleb vältida hiire allavajutust (onmousedown), lahtilaskmist (onmouseup), topeltklõpsu (ondblclick), kursori peale viimist (onmouseover) ja kursori eemaldamist (onmouseout), sest need pole juurdepääsetavad klaviatuuri ja tugitehnoloogiatega. (WCAG 4.1.2)

12 Kasutajal peab olema võimalik päästiksündmust nagu hiire allavajutus (onmousedown) tagasi võtta. Nt kui nupu peale vajutada, kuid lahti laskmata nupu pealt ära liikuda, ei tohi seda lugeda nupu vajutuseks. (WCAG 2.5.2)

13 Kui mingi elemendi peal hiirega hõljumine või millegi tab-iga fokusseerimine toob nähtavale lisasisu, siis peab kasutajal olema võimalik seda sisu kinni panna ilma hiirt või fookust liigutamata (nt vajutades ESC klahvi). Tal peab olema ka võimalus liikuda tekkinud sisu peale, ilma et see kinni läheks. Motoorikahäiretega kasutajal võib olla keeruline hoida hiirt ühe koha peal paigal või liigutada seda väga täpset rada pidi. (WCAG 1.4.13)

14 Leht ei tohi ennast automaatselt värskendada, sest see võib kustutada kasutaja pooleli jäänud töö ning kasutada piiratud mobiilse interneti mahtu. (WCAG 2.2.1)

15 Ei tohi kasutada animatsioone, kus info tekib ja kaob, sest kasutaja ei pruugi jõuda piiratud ajaga infot kätte saada. Kui neid siiski kasutatakse, peab olema võimalik neid välja lülitada. (WCAG 2.2.1) Kui veebilehe sisu laetakse osade kaupa, võib olla ekraanilugejatel keeruline lugemisjärge hoida. (WCAG 1.3.2)

16 Miski veebilehel ei tohi miski sähvida rohkem kui 3 korda sekundis, sest see võib tekitada haigushooge. (WCAG 2.3.1) Sähvimist peab saama välja lülitada. (WCAG 2.2.2)

17 Elementi fokuseerides ei tohi juhtuda midagi ettearvamatut – fookus ei tohi minna mõnele teisele elemendile, vorm ei tohi ennast ise ära saata jne. (WCAG 3.2.1)

18 Märgistuskeeles kirjutatud kood peab valideeruma formaalseid validaatoreid (näiteks W3 validaator) kasutades. (WCAG 4.1.1)

19 Lehe keel peab olema märgitud ISO 639-1 koodiga elemendi lang=“…” atribuudis. (WCAG 3.1.1)html

20 Kasutajalt ei tohi nõuda hõljutamist (hover), lohistamist (drag) ega libistamist (slide), vaid peab lubama ka tavalist hiireklõpsu. Lohistamise asemel peab lubama kopeerimist ja kleepimist.

21 Elementide suurused tuleb määrata relatiivsetes ühikutes nagu rem ja em. Eranditeks on veerised, raamid ja vooderdus (margin, border ja padding) ning pildi suurused, mis võivad olla määratud pikslites.

22 Lehe aadress tuleb hoida võimalikult lühikesena, sest mobiilseadmetel veebilehitsejasse aadressi trükkimine on ebamugav. Lühike aadress, näiteks firma.ee peab suunama lehele http://www.firma. ee/index.html ja firma.ee/leht lehele http://www.firma.ee/leht.html. Lehe aadress peab avama alati sama temaatikaga lehe, olenemata seadmest.

23 Kui võimalik, vältida kaasapandud objekte (nt pistikprogramme) ja skripte, sest need ei pruugi olla toetatud ning võivad pikendada lehe laadimisaega. Kui leht ei tööta ilma JavaScriptita, tuleb kasutajat sellest teavitada.

24 Vältida tuleb hüpikaknaid ja modaale. Kui neid siiski kasutatakse, peab olema selgelt arusaadav, kuidas neid sulgeda.

25 Mõistlik on alustada tiitlit alamlehe nimega. Nt: “Kontakt | Firmanimi OÜ” mitte “Firmanimi OÜ | Kontakt”, sest kui vahelehed on kitsad, pole viimasel juhul võimalik alamlehti üksteisest eristada.

26 Kui lehel on teateid või vigu, tuleb need kirjutada tiitli algusesse. Nt: “1 uus sõnum | Foorum”.

27 Veebi vaated, vormid ja nende elemendid peavad olema üle veebi ühtlustatud paigutuslikku ja kujundusliku ülesehitusega. Sama tüüpi elemendid nagu näiteks nupud, lingid, sisestusväljad, tabelid jms peavad olema veebi üleselt sarnased.

28 Sarnaste tegevuste sooritamisviisid peavad toimima sarnaselt. Näiteks nupud “Esita”, "Kustuta", "Tühista" peab toimina veebi üleselt ühte moodi.

29 Kasutatud märksõnastus, sh nupu- ja vormiväljanimed, peab olema veebis ühtlustatud. Näiteks samasuguse tegevusega nupud on nimetatud ühtemoodi, samuti sisutekstide keeleline stiil peab olema sarnane.

30 Sama tööloogika alusel sooritatavad toimingud funktsioneerivad sarnaselt. Näiteks kõigis toimingutes „Salvesta” nupule vajutades kuvatakse teade, et vorm on salvestatud.

31 Erinevad toimingud peavad välja nägema erinevad. Näiteks peavad lingid, nupud, edasi liikumine, tagasi liikumine jms üksteisest erinema.

32 Kasutajaliidese teenusedisaini ja graafilise disaini etappides tuleb lähtuda minimalismi põhimõttest.

33 Kasutajaliides elementide paigutamisel peab olema lähtutud vertikaalsest ja horisontaalsest sümmeetriast.

34 Domeeninimi võiks võimalusel olla tähenduslik nii eesti kui ka inglise keeles. Näiteks võiks viia äriregistri lehele. Kui eesti keelt mitte valdav kasutaja soovib äriregistri businessregister.rik.ee  ENG  lehele minna, siis domeeninimi ei ütle talle sisuliselt midagi.ariregister.rik.ee

35 Domeeninimi peab töötama ka ilma “ “‘ta.www

36 Domeeninimi peab olema meeldejääv ja omama konteksti mõttes tähendust.

37 Veebilehel peavad olema kergesti leitavad viited kasutustingimustele ja privaatsuspoliitikale, kuid arvestada tuleb, et tegemist ei ole lehe mõttes esmase infoga.

38 Kasutajaliides peab andma kasutajale andmete laadimisest teada (loader), et kasutaja saaks aru, et leht ei ole hangunud vaid toimub andmetöötlus. Page loaderina on soovitav kuvada graafilist elementi, mitte tekstilist. Põhjus selles, et juhul, kui lehe laadimiskiirus on kiire, siis kasutajal on hetkeks näidatavat graafilist elementi lihtsam haarata, kui näiteks teksti “Laen, palun oodake”. Page loaderi puhul võib probleemiks osutuda olukord, kus page näidatakse iga kord, kuid tema kuvamise pikkus sõltub lehe laadimise kiirusest. Kui leht  loaderit  on kiire, siis sellisel juhul pageloader justkui “vilgub”/ilmub hetkeks ja kasutaja ei saa aru, millega tegu. Sellise olukorra lahendamiseks on soovitav kasutada praktikat, kus page loader ilmub (fadein, opacity 0-1) ühe sekundi vältel (0-1sek). Sellisel juhul, kui lehe laadimine on kiirem, kasutaja page loade

ei näe, kui lehe laadimine võtab rohkem aega, on page loader talle nähtav. Täpsemalt saab lehe laadimisest ja kolmest olulisemast tunnetuslikust limiidist lugeda .rit   Nielseni lehelt

39 Kasutaja peab saama kõiki enda poolt algatatud tegevusi katkestada. Näiteks sisselogimist, avalduse koostamist jms. Lisaks brauseri akna kinni panemise võimalusele peab kasutajal olema igas vaates katkestamise/väljumise võimalus.

40 Kasutajale peab olema lihtsasti leitav temaga seotud info, kuhu alla on kokku koondatud kõik, mida süsteem tema kohta teab ja mis võib olla kasutaja jaoks relevantne (minu asjad, profiil, konto seaded).

41 Kaaluda, millise sisu allkirjastmine on absoluutselt vajalik ja millise sisu puhul piisab kinnitusest. Näiteks tuludeklaratsiooni esitamisel ei ole vajalik deklaratsiooni allkirjastada, sest kasutaja on autenditud ja sellega on piisavalt tugev seos tekitatud kasutaja isiku ja tahteavalduse vahel.

42 Domeeninimedes ei tohi kasutada kirjavahemärke. Näiteks on kasutajatele keeruline sisestada aadressi reale , selle asemel peaks olema võimaldatud .www.e-toimik.ee www.etoimik.ee

43 Veebileht peab toetama enamlevinute veebilehitsejate ja operatsioonisüsteemide kolme viimast versiooni.

44 Veebilehel tuleb luua automaatselt genereeritav sisukaardi fail otsingumootoritele ( ).XML sitemap

45 Veebirakenduse kõik avalikud osad peavad olema otsingumootorite jaoks optimeeritud.

46 Kui on veebirakendusele on tellitud administreerimisliides, siis seal peab saama:

lisada ja hallata artiklite, uudiste ja kõikide muude lehe tüüpide sisu, pealkirju ning meta-kirjeldusi ( ’e).keyword määrata võimalikult kasutajasõbralikke, lihtsaid ja lühikesi -e kõikidele lehtedele (ka nendele mille sisu tuleb liideste kaudu). URL vaadata statistikat lehtede ja funktsionaalsuste, linkide, nuppude jms kasutaja poolt kasutatavate või tehtavate tegevuste jälgimiseks

Abiinfo

1 Kui vormivälja täitmisel tuleb kasutajal lähtuda kindlatest reeglitest, mis ei pruugi olla koheselt ilmselged, tuleb lisada abiinfo vastava vormivälja täitmisviisi kohta. Näiteks failide laadimisel, millised failiformaadid on lubatud.

2 Kõik erialased ja kasutajale arusaamatud terminid peavad olema lahti selgitatud. Selleks võib kasutada lehel kuvatavaid tekste või näiteks süsteemiülest sõnastikku.

3 Lehel peab olema viide, milliste õigusaktide alusel süsteem töötab.

4 Lehel peab olema viide, kes süsteemi haldab.

5 Abiinfo ikoonid koos avaneva lisainfoga tuleb paigutada kohtadesse, kus kasutaja võiks vajada täiendavat selgitust.

6 Kui abiinfo kuvamiseks on kasutatud tooltipe, siis tooltipi alast välja “klikkides” peab tooltip sulguma.

7 Lühikeste abitekstide korral on soovitatav kasutada tooltip lahendust, mis peab olema tekstiga sobivaks vormindatud nt ei tohi tooltip “venida” horisontaalselt ega vertikaalselt ebapraktiliselt suureks ning pikemate abitekstide korral tuleks infot kuvada modaalaknas. Lisaks modaalakna lahendusele võib kaaluda pikemate tekstide linkimist näiteks mõnele abiinfo portaalile või teisele süsteemi alamlehele, aga mõlemal juhul tuleb need avada uuele brauseri vahelehele. Lisaks abiinfo kuvamisele vormil konkreetsete osade juures on võimalik lisada ka nö “leheülene” abiinfo, kus on konkreetse lehe kohta käiv selgitus. Samas tuleks leheüleseid abisid pigem vältida, sest see on kasutajale koormav, kuna kasutaja tahab konkreetse tegevuse juures näha konkreetset infot. Üleüldiselt tuleks püüelda vähema abiinfo lisamisele ja intuitiivsema veebi poole.

8 Lisainfo ja abiinfo kuvamisel ei tohi jääda kasutajale muljet, et ta on süsteemist ära liikunud. See tähendab, et igal ajahetkel peab kasutajale näha jääma lehe üldraamistik – näiteks päis, jalus, navigatsioon jms.

Failid

1 Failile viitamisel/linkimisel peab olema linginime juurde lisatud failitüüp ja maht.

2 Failide süsteemi üleslaadimisel peavad olema välja toodud lubatud failiformaadid.

3 Failide süsteemi üleslaadimisel peab olema toodud failide lubatud maht (maht kokku ja üksiku faili maht).

4 Failide süsteemi üleslaadimise järel peab andma kasutajale ülevaate, millised failid süsteemi lisati.

5 Failide süsteemi üleslaadimise järel peab kasutajal olema võimalik neid sealt kustutada.

6 Kui on nõue failide digitaalseks allkirjastamiseks süsteemi sees, peab neid olema võimalik ühe toimingu raames allkirjastada korraga.

7 Kui vormil on failide üleslaadimise võimalus, siis kasutajale peab näitama, millise sisuga dokumente oodatakse. Näiteks loetelu dokumendi liikidest – riigilõivu kviitung, hagiavaldus jms.

Heli ja video

1 Heli (mis kestab kauem kui 3 sekundit), videot ja animatsiooni (kerimine, vilkumine, liikumine, mis kestab kauem kui 5 sekundit) peab saama katkestada, kinni panna (WCAG 2.2.2) ning heli tugevust muuta. (WCAG 1.4.2)

2 Veebilehel olevale helile ja videole peab lisama kirjeldava title=”...” atribuudi. (WCAG 1.1.1)

3 Ilma helita videole või animatsioonile tuleb nägemispuudega kasutajate jaoks lisada juurde tekstiline sisukirjeldus või helifail, kus räägitakse, mis videos toimub. Näiteks video, kuidas puhastada kohvimasinat, mille taustaks on küll muusika, kuid instruktsioonid ilmuvad ekraanile tekstina - sellisele videole tuleks lisada helifail või tekstiline versioon, kus selgitatakse sõnadega kohvimasina puhastamist sama detailselt kui videos. (WCAG 1.2.1)

4 Eellindistatud helisalvestusele tuleb lisada kuulmispuudega kasutajate jaoks transkribeeritud tekst, mis sisaldab ka helikirjeldusi nagu naer, aplaus, sammud jms. (WCAG 1.2.1)

5 Eellindistatud helisalvestusele ja heliga videole tuleb kuulmispuudega kasutajate jaoks lisada sünkroonsed subtiitrid, kus lisaks räägitavale tekstile on kirjeldatud ka teisi helisid nagu [lapsed naeravad] või [vali rokkmuusika]. Sellised subtiitrid on nähtaval kas alati või on antud võimalus kasutajale subtiitrid sisse lülitada, kui need on videole kaasa pandud, näiteks nagu YouTube'is. (WCAG 1.2.2)

6 Reaalajas edastatavale heliülekandele või heliga video ülekandele tuleb kuulmispuudega kasutajate jaoks lisada sünkroonsed subtiitrid, kus lisaks räägitavale tekstile on kirjeldatud ka teisi helisid nagu [lapsed naeravad] või [vali rokkmuusika]. Neid kirjutatakse ja edastatakse reaalajas. (WCAG 1.2.4)

7 Eellindistatud videofailile tuleb lisada nägemispuudega kasutajate jaoks sama infot edasi andev tekstiline sisukirjeldus, mis asub või millele viidatakse faili vahetus läheduses või versioon videost koos video kirjeldustega, kus dialoogi pauside ajal räägi jutustaja, mis videos toimub. (WCAG 1.2.3)

8 Eellindistatud videofailile tuleb nägemispuudega kasutajate jaoks lisada versioon video kirjeldustega, kus dialoogi pauside ajal räägi jutustaja, mis videos toimub. (WCAG 1.2.5)

Jalus

1 Veebi jaluses peab olema kuvatud rakenduse versiooni number.

2 Veebi jaluses peab olema lehe haldaja kontakt.

3 Jalusele tuleb määrata minimaalne kõrgus, et vältida olukorda, kus lühema sisulehe korral jääks jalus ekraani keskele. Jalusele fikseeritud positsiooni andmise tulemusel on eesmärgiks hoida jalus alati ekraani alumises osas.

Lingid

1 Lingid peavad olema muust tekstist visuaalselt eristatavad ning mitte ainult teist värvi, vaid näiteks alla joonitud, paksemad või suuremas kirjas. (WCAG 1.4.1)

2 Fokuseeritud link peab olema teistest visuaalselt eristatav. (WCAG 2.4.7)

3 Lingi tekstist (ning seda ümbritsevast kontekstist) peab saama selgelt aru, mis sellele vajutades juhtub. (WCAG 2.4.4) Lingi tekst peaks algama kõige tähtsama ja sisukama sõnaga. Lingi tekst ei tohiks olla lihtsalt “Kliki siia” või “Rohkem” ega lihtsalt URL, sest ekraanilugeja loeb selle ette täht haaval. Lingi tekst ei tohiks sisaldada sõna “link”, sest ekraanilugejad ütlevad, et tegu on lingiga.

4 Külastatud ja külastamata lingid peaksid olema visuaalselt eristatavad.

5 Sama tekstiga lingid ei tohi viia erinevatele lehtedele.

6 Ebavajalikke ja kordavaid linke tuleb vältida - näiteks pilt ja “Loe rohkem” tekst, mis viivad samale lehele kui link ise, tuleb panna kõik ühte  märgendisse.a

7 Lehel ei tohi olla katkiseid linke, mis ei vii kasutajat õigesse kohta.

8 Kui linke on väga palju, võiks need grupeerida nimekirja või  märgendiga.ul ol

9 Lingid ei tohi paikneda üksteisele liiga lähedal ega ka liiga kaugel.

10 Link, mis laeb alla faili: Teavitus, et algab faili allalaadimine, peab olema lingi tekstis näha. Ära tuleks märkida ka faili suurus ning formaat, et aeglase või piiratud mahuga interneti kasutajad saaksid vältida aja- ja rahakulu.

11 Peab olema üheselt arusaadav, mis on lingi eesmärk, mida ta teeb või kuhu ta viib. Link peab paiknema sisu suhtes õigesti (vastava sisu läheduses) ja lingi nimi peab olema sisukas.

12 Lingid, mis viitavad sama veebilehe teisele lehele ei tohiks ette hoiatamata avaneda uues aknas või uuel vahelehel. Kasutaja ei pruugi aru saada, et on sattunud uuele lehele ning võib proovida tulutult veebilehitseja “Tagasi” nuppu kasutada. Mobiilseadmes pole tavaliselt näha, mitu akent on avatud ning nende vahel navigeerimine on ebamugav. Üks võimalus on lisada lingile informatiivne ikoon, peita see ekraanilugejate eest atribuudiga aria-hidden=”true” ning lisada sama infot edasi andev tekstiline kirjeldus, mida visuaalselt pole näha, aga mida ekraanilugejad saavad lugeda. Ikoon tuleb alati paigutada peale linki, et lugemisjärjekord oleks loogiline.

Teine võimalus on esitada lisainformatsioon lingi atribuudis aria-label title=“…” ning dubleerida lingi tekst atribuudis    =“…”, et kõik ekraanilugejad loeksid välja kogu vajaliku informatsiooni.

13 Lingid peavad olema tavatekstist eristatud (ikoon, stiil, värv).

14 Link, mis viib sama lehe teise kohta: Soovitatav on kasutada ülehüppamislingi tekstis nt “Liigu sisuni: …” või lisada lisainformatsioon atribuudis aria-label=“…” ning dubleerida lingi tekst atribuudis title=”...”.

15 Veebist välja viitavad lingid peavad avanema veebilehitsejas uuel vahelehel.

16 Lingipealkirja kõrval kuvatav ja sellega seotud pisipilt peab olema samuti lingiks muudetud. Ehk kasutaja peab saama edasi liikuda ka pildil klikkides.

17 Menüüpunkt ja sellega seotud ikoonike peavad linkima mõlemad samale sisule.

18 Loeteludes, sh menüüdes peavad linginimed üksteisest visuaalselt hästi eristatud (vahed, jooned jms).

19 Linkide pealkirjad ei tohi paikneda menüüdes rohkemal kui kahel tekstireal.

20 Kasutada ei tohi pikemaid kui 4 sõnalisi linginimesid.

21 Linginimedest peavad olema eemaldatud mõttetud kordused.

Modaalaknad

1 Modaalakendest väljapoole ei tohi tekkida elementidel fockus olekut.

2 Kui modaalaken on avatud, siis modaalakna all oleval lehel ei tohi kasutaja saada kerimist (scroll) kasutada.

3 Modaalakna avades peab olema selle taha jääv taust tumendatud, et aken oleks lihtsasti eristatav ja taustal olev sisu ei tõmbaks tähelepanu.

4 Modaalakna sulgemiseks peab sellel olema vastav nupp, lisaks peab saama akent sulgeda klahviga ja vajutades hiirega modaalakna alast välja poole jäävale alale. Esc 

5 Modaalaknas tuleb vältida sisu jagamist lehtedele ( ) ja vahelehtedele ( ) ning modaalaknasse tekkivat .paging tabs  scrolli

Navigeerimine

1 Navigatsioon peab olema lihtne ja ühtne üle terve veebilehe. Navigatsioon peab lehele minnes olema kohe näha ja see tuleb paigutada see lehe ülaserva või vasakule. Menüüpunktide järjekord ei tohi erinevatel alamlehtedel erinev olla. (WCAG 3.2.3)

2 Igal lehel peal olema informatiivne ja lehte kirjeldav tiitel märgendina. (WCAG 2.4.2)title

3 Konkreetse lehe leidmiseks peab olema vähemalt kaks võimalust: lisaks menüüle näiteks otsing, sisukaart (mis töötab ilma JavaScriptita) või jäljerada (breadcrumbs). Erandiks on leht, mis on mingi protsessi samm või tulemus. (WCAG 2.4.5)

4 Menüüpunktid peavad olema sõnastatud nii, et oleks selge, mis nende all leidub. (WCAG 2.4.4, 2.4.6)

5 Kui megamenüü avaneb hiirega menüüpunkti kohal hõljudes (hover), peab see avanema ka tab-iga menüüpunktile liikudes. Kasutajal peab olema võimalik megamenüü kinni panna ilma hiirt või fookust liigutamata (nt vajutades ESC klahvi). Kasutajal peab olema võimalus liikuda megamenüü peale, ilma et see kinni läheks. Parem variant on panna megamenüü avanema menüüpunktile vajutades. (WCAG 1.4.13)

6 Lehe kõige esimene element peab olema link “Liigu põhisisu juurde”, mis teeb tabuleerivate kasutajate jaoks infoni jõudmise lihtsamaks. Sisu, mis kordub mitmel leheküljel, peab saama vahele jätta kasutades mugavaid ülehüppamislinke, näiteks “Jäta … vahele”. Kuigi need lingid võiksid olla alati nähtavad (nägijate jaoks, kellel on raske klaviatuuri kasutada), võib need ka visuaalselt peita. (WCAG 2.4.1)

7 Tihedamini külastatavad lehed tuleb teha kiiresti kättesaadavaks, kuid harvem kasutatavate lehtedeni jõudmiseks võib minna rohkem aega (nt kiirlingid).

8 Otsingukasti juures peab olema selgelt arusaadav, kuidas otsingut käivitada, lisaks peab otsing käivituma enter klahvi vajutusega.

9 Otsing peab leidma vasteid ka lähedastele otsingusõnadele. Näiteks vaste “nina-kõrva-kurguarst” peab leidma ka kasutades otsingusõna “kurgu-nina-kõrvaarst”.

10 Juurdepääsetavaim viis navigatsioon esitamiseks on nav role=“navigation” aria-label=“...” märgendiga, mille sees on märgendiga esitatud nimekiri. Alammenüüga elemendile võiks lisada aria-ul haspopup=“true” atribuudi.

11 Vältida tuleb mitme tasemelisi menüüsid – jääda ühe või kahe taseme juurde.

12 Veebi keelt vahetades peab kasutaja navigatsiooni mõttes jääma samale vaatele, millelt ta keelt vahetas.

13 Kui kasutajal on võimalik liikuda ühest süsteemist teise, peab ta igal ajahetkel aru saama, millises süsteemis ta parasjagu on. Arusaadavust toetab vastava lehe päis, logo, lehe pealkiri jms.

14 Hetkel avatud menüüpunkt peab olema teistest menüüpunktidest koheselt eristatav.

15 Igal veebi lehel peab olema logo, mis lingib avalehele.

16 Igal veebi lehel peab olema link avalehele.

17 Avalehel peab olema link “avalehele” peidetud.

18 Keerulisemates veebides peab olema kasutusel sisukaart.

19 Sisukaart peab kajastama veebi sisukorda menüüstruktuuri põhiselt.

20 Veebis peab olema kasutusel üks menüü. See tähendab, et sama menüü ei tohi olla kuvatud topelt, näiteks vasaku menüüna ja ülemise menüüna korraga.

21 Menüüs peab olema kasutatud erinevaid pealkirju st erinevad menüüpunktid ei tohi olla sama nimetusega.

22 Tagasitee tähised ( ) peab olema kasutajale kuvatud, kui kasutajal on võimalik navigeerida sügavamale, kui kaks taset.breadcrumbs

23 Tagasitee tähised peavad olema kuvatud iga veebilehe ülemises osas.

24 Tagasitee tähised peavad kajastama korrektselt veebi menüüstruktuuri st samme ei tohi vahelt ära jätta.

25 Tagasitee tähistes peavad olema menüüpunktid arusaadavalt eraldatud st tagasitee tähised ei tohi olla kuvatud sellise stiiliga, et neid võiks segi ajada menüüga.

26 Samalt lehelt samale lehele viitavaid linke olla ei tohi.

27 Tagasitee tähised peavad olema linkidena, mis viivad lehel vastava sisuni.

28 Veebilehitseja “back” nupuga peab saama veebis navigeerida.

29 Kui lehe sisuosa on väga pikk, siis peab veebi menüü (nii ülemise menüü korral, kui vasaku menüü korral) lehe kerimisega kaasa liikuma.

30 Kui lehe sisuosa on väga pikk, siis peab lehe kerimisel ilmuma “tagasi üles” nupp (lehe paremal allosas), millega kasutaja saab mugavalt suunduda lehe algusesse tagasi.

Nupud

1 Nupud ja muud funktsionaalsed elemendid peavad kogu lehe ulatuses olema sarnased ja äratuntavad. (WCAG 3.2.4)

2 Nupud peavad olema vähemalt 44 x 44 CSS piksli suurused ja piisavalt suurte vahedega, et neid oleks puutetundlikul ekraanil mugav vajutada.

3 Nupu peal olev tekst ja koodis olev nimi peavad olema identsed või vähemalt algama samamoodi. Nt kui nupu tekst on “Saada” ja “name” atribuut on “Saada_vorm”, siis helilist sisendit kasutav inimene saab öelda “Saada” ja nupp aktiveerub. (WCAG 2.5.3)

4 Nupul peavad olema selgelt visuaalselt eristatavad fokuseeritud (WCAG 2.4.7) ja aktiivne olek.

5 ui nupu sees on teksti asemel ikoon, pilt või üksik täht, tuleb nupule anda atribuut aria-label=“…”, et nupu funktsioon oleks ekraanilugejat kasutavale inimesele mõistetav. (WCAG 1.3.3)

6 Nupud tuleb esitada või input type=“button” märgendiga. Mitte kasutada a =“button” märgendit nupu esitamiseks, sest ekraanilugejaga kasutaja võib nupu vajutamiseks kasutada space button role klahvi, mis linki aga ei aktiveeri. Nuppu ei tohi esitada või  märgendiga, sest tugitehnoloogiad ei pruugi selliseid nuppe ära tunda.div span

7 Nupp peab olema vajutatav kogu oma ulatuses, mitte ainult nupul olev tekst.

8 Veebis peavad olema ainult nupud kujundatud nupu moodi. See tähendab, et kõik elemendid, mis ei ole nupud peavad nuppudest eristuma (näiteks lingid, menüü, teetähised ( )).breadcrumbs

9 Nupunimed peavad olema tegevust kirjeldavad. Näiteks “Edasi”, “Salvesta”, “Tühista”, “Allkirjasta”, “Esita” jne.

10 Ühe toimingu piires erinevate vormivaadete vahel liikudes peab kasutajal olema võimalus liikuda edasi ja tagasi, mida üldjuhul lahendatakse vastavate nuppude kuvamisega. Vormi esimeses vaates peaks olema “tagasi” nupu asemel “tühista” ja vormi viimasel vaatel “edasi” asemel näiteks “esita”.

11 Pikemaid, kui 1-2 sõnalisi nupunimesid ei tohi kasutada.

12 Nupud peavad olema klikkimiseks piisavalt suured ja terve nupp peab olema klikitav (mitte ainult tekst).

13 Nupunimedest peavad olema eemaldatud mõttetud kordused. Näiteks “Esita avaldus” asemel tuleb kasutada “Esita”.

Otsing

1 Leitud otsingutulemuste pealkirjad ja sisu kokkuvõtted peavad olema üksteisest piisavalt hästi eristatud st pealkiri ja sisu eelvaade ei tohi olla samas stiilis.

2 Leitud tulemuste pealkirjad peavad linkima leitud sisule.

3 Leitud failide kohta käiv info – failitüübid ja -mahud peavad olema välja toodud.

4 Iga tulemuse juures peab olema leitud sisu lühikokkuvõte/eelvaade. Kehtib artiklite puhul.

5 Otsingutulemuste kuvamisel on eelistatud „näita rohkem“ valik ja lehe kerimist ( ) kui tulemuste jaotamist erinevatele lehtedele ( ).scroll paging

6 Leheülene otsing peab olema kasutajale koheselt leitav st otsing ei tohi olla menüüsse peidetud.

7 Tavaotsing ja detailne otsing peavad olema eraldatud st kasutajal peab olema võimalus valida lihtsa otsingule lisaks ka detailset otsingut.

8 Otsinguväli peab olema otsingutingimuste sisestamiseks piisava suurusega (vähemalt 25 tähemärki).

9 Otsingutulemuste vaates peavad olema kuvatud otsitud parameetrid, et kasutaja näeks, mille järgi otsing teostati.

10 Otsingutulemuste vaates peab saama otsitud parameetreid kohe muuta ja uusi sisestada.

11 Otsingu sooritamise järel peab olema kuvatatud leitud tulemuste arv.

12 Otsingutulemuste mitte leidmisel peab olema kasutajale kuvatatud sellekohane teade.

13 Otsingu tegemine peab olema võimalikult lihtne ja selge. Otsinguvälju ei tohi olla palju, sest muidu võib kasutajale tekkida küsimus, kas otsingu sooritamiseks pean täitma maksimaalselt või minimaalselt otsinguvälju.

14 Võõrkeelse sisuga lehtedel peab otsing töötama sarnase kvaliteeditasemega nagu eestikeelsel versioonil, kuid otsingute puhul tuleb lisada selgitav info, et otsingu tulemused on valdavalt eestikeelsed, aga otsingu väljanimetused ja abitekstid on vastavalt valitud keelele.

Pildid ja ikoonid

1 Kui kasutatakse animeeritud galeriid (nt karusell), peab kasutajal olema võimalik animatsiooni peatada. (WCAG 2.2.2) Galerii peab olema kasutatav klaviatuuri abil. (WCAG 2.1.1) Aktiivne galerii element peab olema eristatav ka tugitehnoloogiatega – sellele võib lisada visuaalselt peidetud teksti. (WCAG 1.3.3)

2 Kui tegu on illustreeriva pildiga, mida informatsiooni kätte saamiseks näha pole vaja, tuleb lisada pildile tühi alt=“” atribuut, sest siis jätavad ekraanilugejad selle pildi vahele. Kui alt atribuuti ei lisata, loeb ekraanilugeja ette pildi faili nime. Illustreerivate piltide puhul tuleks kasutada CSS-i background, :before või :after reegleid HTML-i märgendite asemel. (WCAG 1.1.1)img

3 Igal pildil peab olema märgitud tekstiline alternatiiv alt=“…” atribuudiga. Tekstiline alternatiiv peab kandma edasi sama informatsiooni kui pilt ise. Tekstiline alternatiiv ei tohi olla lihtsalt “Pilt” või “Tabel”. Tekstilisse alternatiivi pole vaja kirjutada “Pildi peal on…”, sest ekraanilugeja ütleb, et tegu on pildiga. (WCAG 1.1.1)

4 Ikoon lingi teksti asemel: Kui ikooniga on tähistatud linki, tuleks lingile lisada atribuut aria-label=“…”. Antud atribuut võimaldab ekraanilugejatel kasutajale lisainformatsiooni lugeda. Ikoonile võib lisada ka atribuudi title=“…”, mis annab nägijatele lisainformatsiooni, kui kursoriga elemendi peale liikuda. (WCAG 1.3.3). Ikoon näitab, kuhu link viib.

5 Kui ikoon annab edasi tähtsat informatsiooni, mida tekstiliselt kirja ei taheta panna, tuleks see ekraanilugejate eest peita atribuudiga aria-hidden=”true” ning lisada sama infot edasi andev tekstiline kirjeldus, mida visuaalselt pole näha, aga mida ekraanilugejad saavad lugeda. Ikoonile võib lisada ka atribuudi title=“…”, mis annab nägijatele lisainformatsiooni, kui kursoriga elemendi peale liikuda. (WCAG 1.3.3) Infot annab edasi ainult ikoon.

6 Vältida tuleb hüperpilte (image map), mille eri osadele vajutades avanevad erinevad lingid.

7 Taustapiltide kasutamisel tuleb kindlaks teha, et tekst on pildi pealt loetav. Sisu peab loetavaks jääma ka taustapildi eemaldamisel. Taustapildi fail peab olema võimalikult väikesemahuline, et lehe laadimisaeg oleks võimalikult lühike.

8 Pildile tuleb lisada allkiri  märgendiga. Pildi tekstiline alternatiiv ei tohi korrata pildi allkirja, vaid andma lisainfot.figcaption

9 Ikoonid peavad olema lihtsad, selged, äratuntavad ja üheselt mõistetavad.

10 Kui ikoon on pelgalt illustreeriv ega kanna endas lisainformatsiooni, tuleks see ekraanilugejate eest peita atribuudiga aria-hidden=”true”. Antud atribuut ei mõjuta elemendi visuaalset nähtavust, vaid võimaldab ekraanilugejatel antud elemendi vahele jätta. Lisaks ikoonile on olemas sama infot edasi andev tekst.

Printimine ja salvestamine

1 Sisulehtede, mille sisu kasutaja sooviks tõenäoliselt printida või oma arvutisse salvestada, päisesse peab olema lisatud toimingule vastav tegevus (nupp, link, ikoon).

2 Sisulehed tuleb printida või salvestada järgides minimaalsuse printsiipi st ilmselt ei ole mõistlik print vaatesse kaasa panna menüüd jms.

3 Printimisel ja salvestamisel tuleb lisada lehele/lehtedele väljavõtte aeg, koht (veebi aadress) ja vajadusel isiku nimi (väljavõtte tegija).

4 Lisaks printimisele ja salvestamisele kaaluda sisu saatmise võimalust ka e-postile. Näiteks kinnistusraamatu väljavõte saatmine oma e-postile.

Tabelid ja andmeplokid

1 Tabel tuleks esitada kasutades , (päiselahtrite grupeerimiseks), (sisuosa eraldamiseks), (kokkuvõtvate lahtrite grupeerimiseks), märgendeid. (WCAG 1.3.1)table thead tbody tfoot tr, td, th

2 Tabelil peab olema päis. Horisontaalse päise lahtrid tuleb märkida th scope=“col” ja vertikaalse päise lahtrid th scope=“row”. (WCAG 1.3.1)

3 Tabelile peab andma pealkirja märgendiga. caption (WCAG)

4 Tabeleid ei tohi kasutada lehe sisu paigutamiseks ja kujundamiseks.

5 Keerulisele tabelile tuleb lisada pikem kirjeldus aria-describedby=”…” atribuudiga.

6 Tabeleid ei tohi infoga üle koormata, sest sellisel juhul muutuvad nad loetamatuks. Peab olema tehtud valik, milline info on kõige olulisem, mis koheselt tabelis kuvatakse ja vähemoluline info tuleb lisada detailinfo alla või järgnevatesse vaadetesse.

7 Tegevusnupud tuleb tabeli rea lõppu lisada. Kui on võimalik, siis tegevuste nimetuste tekstid tuleb kuvada koos ikooniga.

8 Lehe sisuosasse, kus kasutaja soovib tõenäoliselt andmeid filtreerida ja sorteerida, tuleb lisada vastavad tegevused. Näiteks tuleks nimetatud võimalused luua andmetabelite, nimekirjade ja otsingutulemuste juurde.

9 Tühje andmetabeleid ja andmeplokke ei tohi kuvada.

10 Kui tühi andmeplokk tuleb ärireeglitest tulenevalt kuvada, siis ei tohi näidata tabeli päiseid, vaid selle asemel tuleb kuvada teade, et andmed puuduvad.

11 Lehe sisu, andmeplokid ja tabelid peavad olema loogiliselt grupeeritud, sarnane sisu on koos ja erinevad plokid peavad olema visuaalselt eristatud.

12 Pikemate andmetabelite paremaks lugemiseks võiks kaaluda tabeli ridade “triibutamist”.

13 Andmetabelite ridade kõrgused peavad olema fondi suurus korda 1,6-1,8px.

14 Tabeli tulpade vahel peab olema piisavalt, kuid mitte raiskavalt ruumi.

15 Tabelis pikemate väärtuste kuvamisel on kaks võimalust: kas mitmel real või osa andmetest läheb “peitu” ja lõppu kuvatakse kolm punkti. See, kumb variant valitakse sõltub sellest, kui olulised on konkreetsed andmed konteksti vaatest.

16 Sõltuvalt tabelis kuvatavate andmete iseloomust ja sellest, kas tabelis kuvatava infoga saab tegevusi teha (avada detailsem infovaade, salvestada vms) tuleks kaaluda lisaks rea lõpus olevatele tegevustele, muuta terve tabeli rida “klikitavaks”. Sellisel juhul peab jääma vastava tegevuse viide ka rea lõppu. Selline lahendus muudaks andmete kasutamise mugavamaks. Tähelepanu tuleks pöörata kahele asjaolule: kui terve rida on “klikitav”, siis reas olevaid andmeid ei ole enam mugav hiire kursoriga selekteerida (kas seda üldse tehakse selles tabelis?) ja kui tabeli reaga on võimalik teha mitut tegevust nagu salvestada ja avada, siis milline tegevus tehakse real “klikkimise” tulemusel (kas on intuitiivne?).

17 Kui lehel kuvatavad tabelid on pikad, peab lehe kerimisel tabeli päis sisuga kaasa liikuma.

18 Ära on vaja määratleda, milline on tabeli ridade maksimaalne arv, mille ületamisel jaotuvad ülejäänud andmed "lehtedele" ( )pagination

Teated

1 Vigaselt täidetud väljad või täitmata jäetud kohutuslikud väljad peavad olema visuaalselt eristatavad. (WCAG 3.3.1) Vigaseid välju ei tohi eristada ainult värviga. (WCAG 1.4.1)

2 Olekumuudatused (nagu veateated või “Otsin...”, “Leiti 12 vastet”, “Vasteid ei leitud”), tuleb lisada koodi nii, et tugitehnoloogiad saaksid neid ette kanda ilma elemendile fookuse viimist. (WCAG 4.1.3) Näiteks veateatele võiks lisada aria-live=“assertive” atribuudi, sest siis katkestab ekraanilugeja oma töö ning loeb koheselt ette veateate.

3 Vigaselt täidetud välja juures peab olema tekstiline veateade. (WCAG 3.3.1) Veateatest peab olema selgelt arusaadav, miks viga tekkis ja kuidas seda parandada. Peab olema kirjas, kas probleem on ajutine või püsiv ning kas kasutaja saab probleemi ise lahendada või tegeleb sellega teenusepakkuja (sellisel juhul peaks lisama teenusepakkuja või kasutajatoe kontakti). (WCAG 3.3.3)

4 Veateade tuleb kuvada võimalikult lähedal kohale, kus viga tekkis. (WCAG 1.3.1) Vormiväljade puhu kuvatakse veateade vastava sisestuskasti juures.

5 Kasutajat tuleb teavitada, kui tekkis viga ning ka siis, kui kõik õnnestus.

6 Kui veateade kuvatakse eraldi lehel, peab seal olema vähemalt üks järgmistest: “Tagasi” link eelmisele lehele (käitub nagu veebilehitseja “Tagasi” nupp), “Proovi uuesti” link (käitub nagu veebilehitseja “Värskenda” nupp) või link avalehele saamiseks.

7 Vormiväljad, mille täitmine sõltub mõne eelneva vormivälja täitmisest, peavad olema eristatud või algselt peidetud. Näiteks, kui tellimuste valimiseks peab olema e-post sisestatud, siis tellimused peavad olema algselt peidetud või mitteaktiivsed.

8 Seosed vormiväljade vahel, mille täitmine on seotud mõne eelneva vormivälja täitmisest, peavad olema kasutajale esitatud üheselt arusaadavalt. Näiteks, kui tellimuste valimine sõltub e-posti välja täidetusest, siis peab olema kahe vormivälja vaheline seos kasutajale arusaadavaks tehtud.

9 Peab olema tagatud, et kasutaja saaks kohe aru, kui valitud toimingut ei saa või pole hetkel võimalik sooritada. Näiteks ei lubata kasutajal täita avaldust, mille esitamise aeg on möödunud.

10 Vormi täitmisel peab olema kasutusel abistavad tehnoloogiad (nt AJAX), mis annavad reaalajas tagasiside valikute võimalikkusest ja sisestatud andmete sobivusest. Näiteks kas e-post vastab formaadile, parooli valimisel tugevuse aste, postiaadresside ennustus jms.

11 Toimingute valikud, mida kasutaja ei tohi teostada, peavad olema piiratud. Näiteks võimaldatakse otsida andmeid ja tulemused kuvatakse, aga tulemuse avamisel ilmub teade, mis ütleb, et kasutajal puuduvad õigused sisu vaatamiseks. Sel juhul peaks olema kohe piiratud otsingu teostamine, sest tulemusi ei saa niikuinii vaadata.

12 Valesti sisestatud andmete puhul tuleb kuvada sellekohane teade.

13 Veateade peab piisavalt eristuma ülejäänud sisust ja tekitama piisavalt liikumist, et kasutaja märkaks seda. Inimese silm märkab ja reageerib liikumisele.

14 Veateade peab olema kuvatud silmatorkavas kirjas, see ei tähenda, et kiri peab olema punane.

15 Süsteemi lehtedele peab olema planeeritud olulise info (nt süsteemi tõrked ja hooldustööd vms) kuvamise koht. Teadete asukoht peab olema kergesti märgatav.

16 Vormis peab olema küsitud vaid sellist infot, mille küsimata jätmine takistaks toimingu sooritamist. Näiteks ei ole üldjuhul vajalik kohtusse avalduse esitamisel küsida kasutaja käest tema sugu.

17 Kasutajale peab olema arusaadav, mis eesmärgil andmeid küsitakse. Kui küsitakse andmeid, mis ei ole koheselt seostatav eesmärgiga, tuleb kasutajale selgitada, miks neid andmeid küsitakse.

18 Peab olema läbi mõeldud kas vormis on küsitud vaid neid andmeid, mille sisestamine on jõukohane kõikidele kasutajatele. Näiteks, kas kõigil süsteemi kasutajatel on olemas e-post või kas kõik kasutajad oskavad valida õiget dokumendi liiki.

19 Veebil peavad olemas olema nii 404 kui 500 lehed.

Tekstid, sisu ja fondid

1 Pealkirjad tuleb eristada märgenditega kuni , mitte ainult kujundusega. Pealkirjadena kuni  ei tohi esitada teksti, mis pole tegelikult pealkiri. (WCAG 1.3.1, 2.4.6)h1 h6 h1 h6

2 Pealkiri peab olema lühike, kuid sisukas ning kirjeldama sellele pealkirjale järgnevat sisu. (WCAG 2.4.6) Pealkiri peab algama kõige tähtsama ja sisukama sõnaga.

3 Igal lehel peaks olema vähemalt üks . (WCAG)h1

4 Pealkirjad peavad järgnema üksteisele hierarhiliselt korrektses järjekorras. Järjekorra korrektsust saab kontrollida näiteks WAVE tööriistaga. (WCAG 4.1.1)

5 Sisu kordamist ühe lehe ulatuses tuleb vältida, sest see võib olla ekraanilugejaga kasutajale olla segadusse ajav ja tüütu. Korduvat sisu peab saama ülehüppamislinkidega vahele jätta. (WCAG 2.4.1)

6 Tabuleerimisjärjekord peab ühtima sisu loogilise järjekorraga: kasutaja võib olla sunnitud navigeerima klaviatuuriga ning vales järjekorras sisu kaotab oma mõtte. (WCAG 2.4.3)

7 Teksti suurused tuleb määrata rem ühikutes, et veebilehitseja seadetes teksti suurust muutes muutuks vastavalt ka veebilehe teksti suurused. Teksti (v.a subtiitreid) peab saama suurendada 200% ilma, et sisu ekraanilt kaoks või kattuks. (WCAG 1.4.4) Reavahe tuleb määrata ilma ühikuta. Soovituslik universaalne reavahe on 1.5. Kui kasutaja muudab ise teksti reavahe 1.5-ks, ei tohi tekst või funktsionaalsus kaduma minna. (WCAG 1.4.12)

8 Lõikude vahe tuleb määrata rem ühikutes. Soovituslik universaalne lõikude vahe on võrdne fondi suurusega. Kui kasutaja muudab ise teksti reavahe 2 x fondi suuruseks, ei tohi tekst või funktsionaalsus kaduma minna. (WCAG 1.4.12)

9 Kui kasutaja muudab ise teksti sõnade vahe 0.16 x fondi suuruseks või tähtede vahe 0.12 x fondi suuruseks, ei tohi tekst või funktsionaalsus kaduma minna. (WCAG 1.4.12)

10 Teksti peab olema võimalik korrektses järjekorras aktiveerida ning kopeerida. (WCAG 1.3.2)

11 Teksti asemel ei tohiks kasutada pilti, millel on tekst, sest seda ei saa kopeerida ega lugeda ekraanilugejaga. Erandiks on logod, millele tuleb lihtsalt lisada alt=”…”. Erand tehakse ka olukorras, kus teksti esitamine pildina on mõtte edasi andmiseks ainus võimalus ning olukorras, kus kasutaja saab pildil oleva teksti suurust ja värvi muuta. (WCAG 1.4.5)

12 Kui osa tekstist on lehe üldisest keelest erinevas keeles, peab see olema märgitud näiteks ISO 639-1 koodiga lang=“…” atribuudis. (WCAG 3.1.2)

13 Pealkirjad peavad olema visuaalselt hästi eristatavad - suured ja selged.

14 Kasutaja peab lehelt leidma selle ja ainult selle sisu, mida ta sealt ootas.

15 Prioriteetne info peab asuma lehe keskel ning olema visuaalselt esile tõstetud.

16 Lehe sisu tuleb jagada mõistlike suurustega alamlehtedeks, et näidata kasutajale vaid seda, mille järgi ta on tulnud. Liiga pikad lehed võtavad kaua aega laadimiseks, liiga lühikesed lehed nõuavad kasutajalt edasi-tagasi navigeerimist.

17 Kasutada tuleb lihtsat ja selget keelt, sest veebi kasutavad erineva kultuurilise ja haridusliku taustaga inimesed.

18 Märkide (näiteks “-“) asemel tuleb kasutada sõnu (näiteks “kuni”), sest tugitehnoloogiad võivad neid valesti lugeda (näiteks “miinus”).

19 Lühendite kasutamisel tuleb nende seletus esimesel korral välja kirjutada.

20 Ühes reas tohib olla kuni 90 tähemärki, mobiilis kuni 70 tähemärki.

21 Tuleb kasutada seriifideta fonti, sest seda on nägemisraskustega inimestel üldiselt lihtsam lugeda.

22 Kaldkirjas ja paksu alla joonitud kirja tuleb vältida, sest neid on raske lugeda.

23 Tuleb vältida sõnades läbivaid suurtähti, sest selliseid sõnu on raskem lugeda. Kui aga läbivaid suurtähti siiski kasutatakse, tuleb seda teha CSS-is text-transform: uppercase reegli abil, sest caps- lock’iga kirjutatud sõnu loevad ekraanilugejad täht haaval mitte tervikuna.

24 Sisutekst peab olema minimaalselt 12px-16px suur.

25 Kui lehele on sisseehitatud teksti suurendamise võimalus, peaks see asuma päise keskosas, et see lehe suurendamisel ekraanilt ära ei kaoks.

26 Tekst ei tohi lehel liikuda (olla animeeritud), sest seda võib olla raske lugeda.

27 Kui osa tekstist on märgistatud tärni või mõne muu sümboliga, peab sümboli seletus asuma enne teksti. Seletuses peab sisalduma “[sümbol] tähistab …”.

28 Lehe üleselt peavad kõik elemendid, mis avavad või peidavad sisu, olema klikitaval põhimõttel, mitte ülelibisemise (hover) põhimõttel. Nõue tagab, et sisu oleks kasutatav ka puutetundlikel ekraanidel. Näiteks lisainfo avamiseks tuleb elemendil klikkida, mitte sellest üle libiseda.

29 Tekstide rööp joondusele peab olema eelistatud vasakjoondust. Nõue tuleneb inimese silma liikumise ja teksti töötlemise võimekusest.

30 Tekstide maht peab olema viidud miinimumini, sest kasutaja on valmis veebis lugema minimaalselt.

31 Tekstilõigud peavad olema liigendatud.

32 Sisutekstid ei tohi olla liiga pikad ja laialivalguvad.

33 Avalehel peab olema toodud lühikirjeldus, et oleks võimalik mõista, millisesse veebi kasutaja on jõudnud.

34 Lühikirjeldus peab olema silmatorkavalt nähtavas asukohas.

35 Lühikirjeldus tuleb esitada nii, et selle nägemiseks ei pea ekraanivaate kerimisriba kasutama.

36 Loetelude kirjed peavad olema järjestatud nii, et kõige olulisemad kirjed kuvatakse eespool.

37 Sarnastes veebitoimingutes peab kasutatama ühtlustatud märksõnu, sh nupunimetusi.

38 Igale veebilehele peab olema lisatud eraldi tiitelpealkiri.

39 Veebilehe pealkiri peab olema vastava menüüpunkti pealkirjaga sarnases sõnastuses.

40 Uudiste ja teadete juures peab olema selle lisamise kuupäev koos aastanumbriga.

41 Kasutatud pildid ja ikoonid peavad aitama sisu paremini kirjeldada, kui nad sisule midagi juurde ei anna, tuleb need veebist välja jätta. Arvestama peab ka sellega, et pildid muudavad lehe aeglasemaks.

42 Süsteemi või lehe nimi peab olema alati päises nähtav.

43 Veebis peab olema läbivalt kasutatud vabavaralisi veebifonte nagu näiteks Google Fonts.

44 Tuleks kaaluda, kas on mõistlik süsteemis kuvada erinevat sisu tulenevalt kasutajate gruppidest ja nende teadmistest. Näiteks ametnikule kuvatakse ühe sisuga veeb, tavakodanikule teise sisuga.

45 Tuleks kaaluda, kas on mõistlik süsteemis kuvada erinevat sisu tulenevalt kasutajate gruppidest ja nende teadmistest. Näiteks ametnikule kuvatakse ühe sisuga veeb, tavakodanikule teise sisuga.

46 Olulisemat sisu peab saama vaadata ilma kerimisriba kasutamata.

47 Hiire kursor (pointer/cursor) peab muutuma vastavalt sellele, missugune on tema käitumine: tekstikursor, lingi kursor jms. Millises olukorras millist kursori stiili kasutada leiab lehelt. MSDN 

48 Kirillitsa tugi peab olema tagatud venekeelse versiooni kõigil kuvadel, kirillitsas loodud sisu peab olema kuvatud korrektselt ja kujundus säilima tervikuna.

49 Pikema sisutekstiga lehtedel, mis sisaldavad vähemalt 6000 tähemärki ja mitut alapealkirja, peab olema eraldi sisukord (nt kasutustingimused, KKK jms lehed).

Tuvastus

1 Kui lehel on ajalimiit (lühem kui 20 tundi), peab kasutajat sellest hoiatama, lubama limiidi välja lülitamist või pikendamist (selleks peab andma vähemalt 20 sekundit aega). (WCAG 2.2.1)

2 Ettevaatlik tuleb olla robotilõksude kasutamises, sest CAPTCHA pildid on ekraanilugejaga loetamatud ning nupud ja lohistamisribad ei luba tihti turvakaalutlustel hiireklõpsu simuleerimist olles seega samuti ekraanilugejaga kasutamatud. Lisaks visuaalsele testile tuleb kindlasti ka pakkuda  testi. (WCAG 1.1.1) Robotite eemale hoidmiseks tuleks kasutada teisi vahendeid näiteks IP piirangud, päringute arv sekundi kohta jms.

3 Kasutaja ei pea samas süsteemis erinevate teenuste kasutamiseks end korduvalt tuvastama.

4 Kasutaja autentimise sessiooni peab pikenema kasutaja poolt tehtud tegevuste korral. Tegevused, mille korral sessiooni pikendatakse, tuleb valida konkreetses veebis tehtavate põhitegevuste järgi, et sessiooni pikendamise sagedus oleks piisav.

5 Sessiooni peatsest aegumisest peab kasutajat teavitama (tavaliselt 5 min enne lõppu).

6 Kasutajale peab teada andma kui palju aega tal on veel sessiooni aegumiseni jäänud, soovitav on kasutada lahendust, kus aja vähenedes seda kasutajale ka kuvatakse ( ).counter

7 Kasutajal peab olema võimalik pikendada sessiooni.

8 Kasutajal peab olema võimalik loobuda sessiooni pikendamisest.

9 Sessiooni vaikimisi pikkus peab olema optimaalne võrreldes süsteemis tehtavate tegevuste eesmärgi ja kestvusega.

10 Peale sessiooni aegumist peab võimaldama kasutajal jätkata sealt, kus ta pooleli jäi. See tähendab, et kui kasutajale kuvatakse teade, et sessioon on aegunud, siis peab tal olema võimalus end uuesti autentida ja jätkata pooleli jäänud kohast.

11 Peale autentimist tuleb kuvada kasutajale erinevate sisselogimise rollide valimiseks rollivalik, kui rolle on rohkem, kui üks. Näiteks juhul, kui kasutajal on lisaks oma eraisiku rollile ka ettevõtte esindaja või asutuse esindaja rollid olemas.

12 Kui autenditud kasutajal on võimalik siseneda süsteemi vaid ühe rolliga, siis rollivalikut kuvada ei tohi.

13 Sisse loginud kasutaja roll peab olema minimaalsuse printsiipi arvestades süsteemi päises kuvatud. Näiteks ei ole kasutajale vajalik kuvada korraga nii tema eesnime, perenime kui ka isikukoodi, sest ta teab seda juba ise ka. Küll aga peab olema võimalik eristada, kas kasutaja on eraisikuna või ametnikuna süsteemis.

14 Veebi sisenemiseks ja sealt väljumiseks peab olema üks koht. Tavapäraselt asub selleks vastav nupp päises.

15 Kasutajale ei pea kogu aeg olema kuvatud sessiooni aegumiseni jäänud aeg. Kuna sessiooni pikendatakse üldjuhul teatud tegevuste peale, siis pidevalt kuvatav sessiooni aeg ei pruugi muutuda sujuvalt ja võib seetõttu pigem tekitada küsimusi ja segadust.

Vormid

1 Igal vormiväljal peab olema täpselt üks pealkirja , mis on temaga seotud id=“…” ja for=“…” atribuutide kaudu. Pealkiri peab visuaalselt paiknema vormivälja suhtes nii, et nende kokkukuuluvus label oleks selge. (WCAG 1.3.1, 4.1.2) Pealkiri peab selgitama, millist infot on vaja sisestada. (WCAG 3.3.2)

2 Väljad peavad olema märgistatud nii, et autofill oskaks neid korrektselt täita. Kasutajalt ei tohi nõuda sisestatud andmete meelde jätmist, vaid tuleb näidata tema eelmisi valikuid ja varem sisestatud andmeid. (WCAG 1.3.5)

3 Vormielementi fokuseerides või klikkides ei tohi juhtuda midagi ettearvamatut ega muutuda lehe kontekst, välja arvatud juhul, kui kasutajat on sellest eelnevalt teavitatud. (WCAG 3.2.1, 3.2.2)

4 Kui vormi ära saatmisel on õiguslikud või finantsilised tagajärjed, peab kasutajal olema võimalik sisestatud info üle vaadata, seda parandada ning vajadusel vormi ärasaatmine tagasi võtta. (WCAG 3.3.4)

5 Kui info tuleb sisestada mingil kindlal kujul, tuleb seda kuju kirjeldada sisestuskastiga seotud märgendis. Soovitud kuju võib kirjutada ka sisestuskasti placeholder=“…” atribuuti, kuid see ei tohi label asendada märgendit. Placeholder=“…” atribuuti ei loe välja paljud ekraanilugejad ning enamus veebilehitsejaid kuvavad seda madala kontrastsusega värvides, mida vaegnägijad ei pruugi näha. label (WCAG 1.4.3)

6 Kui sisestuskasti funktsioon on visuaalselt piisavalt arusaadav, et ei vaja elementi, tuleb kasutada aria-label=“…” atribuuti, et selgitust saaksid lugeda ainult ekraanilugejad. label (WCAG)

7 Kokku kuuluvatele raadionuppudele tuleb anda ühine name=“…” atribuut, et korraga saaks valida ainult ühe raadionupu. (WCAG 4.1.2)

8 Kohustuslikud väljad peavad olema visuaalselt eristatavad mittekohustuslikest väljadest, kuid mitte ainult värvi abil. (WCAG 1.4.1)

9 Kui kohustuslikku välja tähistatakse tärniga, peab sellekohane selgitus asuma enne esimest vormivälja. Näiteks “* tähistab kohustuslikku välja”. (WCAG 3.3.2)

10 Vajalike vajutuste hulk tuleb hoida minimaalsena. Sisestuskastide asemel eelistada kasutada valikukaste, raadionuppe või märkeruute, sest need on mugavamad, eriti mobiilseadmel.

11 Kokku kuuluvad vormiväljad nagu raadionupud, märkeruudud ja sisestuskastid tuleb grupeerida elemendi sisse ning anda grupile üldine pealkiri elemendi abil.fieldset legend

12 Pikemate toimingute sooritamise protsess peab olema jagatud mitme ekraanivaate vahel.

13 Toimingusammude järjestus peab olema kasutajale hästi nähtav ja jälgitav.

14 Kui vorm on jaotatud sammudeks, mis asuvad mitmel lehel, tuleb kirjutada lehe  märgendisse, mitmenda sammu juures ollakse.title

15 Tuleb kasutada sisestuskasti tüüpe search, email, url, number, tel, range, date või time, et valideerida sisestatud infot automaatselt ning vältida vigu. Mobiilseadmes kuvatakse sisestuskasti tüübi olemasolul ka vastav klaviatuur, mis teeb sisestamise mugavamaks. Sisestuskasti tüübid pole hetkel veel kõigis veebilehitsejates toetatud.

1.

16 Sisendile võib seada piiranguid min=“…”, max=“…”, maxlength=“…” ja steps=“…” atribuutidega. Veelgi täpsema piirangu saab seada mustrikontrolli ehk pattern=“…” atribuudiga, mis võimaldab kontrollida kasutaja sisendi vastavust regulaaravaldisele ning vältida vigu.

17 Parim võimalus on paigutada pealkirjad sisestuskastide kohale, sest selline paigutus töötab hästi nii arvutis kui ka mobiilis.

18 Kasutajale ei tohi näidata korraga liiga palju valikuid ja võimalusi, sest see võib olla segadusse ajav ja frustreeriv. Valikud tuleb jagada väiksemateks gruppideks. Pikast valikute nimekirjast võiks pakkuda otsimisvõimalust.

19 Kokku kuuluvad valikud tuleb grupeerida  märgendi abil, et soovitud valiku leidmine oleks kiirem.optgroup

20 Kohustuslikud väljad peavad olema esitatud märgendiga. Soovituslik on lisada ka atribuut aria-required=“true”, sest kõik tugitehnoloogiad ei pruugi arvestada required atribuuti. input required

21 Eelmisesse vaatesse tagasi liikudes peavad alles jääma kõik kasutaja poolt eelnevalt sisestatud andmed.

22 Ekraanivaadet uuendades ( ) peavad alles jääma kõik sisestatud andmed.refresh

23 Sisestusvea avastamisel peavad alles jääma kõik kasutaja poolt sisestatud andmed.

24 Vormi avades peab olema esimene sisestusväli vaikimisi aktiivne.

25 Vormi iga sisestusvälja juures peab olema välja pealkiri ( ), mis peab olema joondatud vasakule.label

26 Vormipealkirjad peavad olema vormiväljade juurde paigutatud nii, et need on hetkega omavahel seostatavad.

27 Vormipealkiri peab alles jääma ka peale seda, kui vormiväli on aktiivne ehk kasutaja on alustanud sellesse väärtuse sisestamist.

28 Sisestusvälja vihje ( ) ei tohi jätta muljet, et tegemist on sisestatud andmetega.hint, placeholder

29 Vormides peab saama ühelt vormiväljalt teisele liikuda tabulaatorklahvi kasutades.

30 Tabulaatorklahviga edasi liikumise järjestus peab vastama vormi andmete tavapärasele sisestusjärjestusele.

31 Tabulaatorklahviga peab saama liikuda ka toimingu sooritamise nupule, nagu näiteks “esita”, “edasi” jms.

32 Enter nuppu vajutamine peab olema võrdsustatud aktiivse vormivälja juurde kuuluva tegevuse ( )/ toimingu sooritamise nupu vajutusega.call to action

33 Valikute kastid ( ) peavad olema valitavad tühiku klahviga.radiobuttonid, checkboxid

34 Vormidel ei tohi küsida korduvalt samu andmeid.

35 Varasemalt sisestatud andmeid tuleb kasutada toimingute sooritamiseks korduvalt (nt e-post, isikukood jms), st samu andmeid samas süsteemis kuid erinevates vaadetes ei tohi kasutaja käest küsida. Andmeid tuleb taaskasutada.

36 Pikemate tekstide sisestamiseks mõeldud vormiväljad peavad arvestama sisestatava sisu mahuga/pikkusega.

37 Kasutaja peab saama mugavalt üle lugeda teksti, mida ta vormiväljadesse on sisestanud.

38 Vabateksti välja juures peab olema näidatud järelejäänud tähemärkide arv.

39 Ei tohi olla vormivälju, mis jätavad mulje, et on aktiivsed, aga ei ole käsitsi muudetavad. Näiteks kuupäeva väli, mida käsitsi muuta ei saa, vaid tuleb vajutada kalendri ikooni ja kuupäev valida kalendrist.

40 Täidetud vormivälju peab olema võimalik tühjendada ühe toiminguga.

41 Kindlate ja piiritletud valikutega andmete lisamiseks peab olema välja toodud valikuvariandid. See vähendab eksimuste arvu. Näiteks tuleb vabateksti asemel pakkuda kasutajale valikuid.

42 Enim kasutatud valikud peavad vaikimisi olema valitud.

43 Kasutajal peab olema võimalik valikuid lisada, kui ei ole veendutud valikute ammendatuses.

44 Kuupäeva sisestamisel peab olema võimalus valida kuupäev kalendrist.

45 Kalendrist peab olema võimalik valida eraldi nii päeva, kuud kui ka aastat.

46 Kalendri avanedes peab olema vaikimisi avatud optimaalseim kuupäev. Näiteks avalduse koostaja sünniaja sisestamisel ei ole mõistlik avada vaikimisi 2019 aasta kalendrit.

47 Kasutajal peab olema võimalik kõiki enda poolt sisestatud andmeid muuta ja kustutada.

48 Kui andmete sisestamiseks on vormid jaotatud erinevatele vahelehtedele ( ), siis peavad olema eristatud vahelehed, millel mõni kohustuslik väli on veel täitmata.tabid

49 Kasutajale peavad olema näha kõik tema poolt sisestatud andmed. Näiteks, kui andmete sisestamiseks avaneb vormil modal ja kasutaja kinnitab andmete sisestuse ning sisestatud andmed ilmuvad vormile, tuleb kasutajale näidata kõiki tema poolt sisestatud andmeid.

Värvid ja mustrid

1 Elemendid ja nende olekud ei tohi olla eristatud ainult värviga. Info, mida antakse edasi värvidega, peab olema kättesaadav ka ilma värvideta. (WCAG 1.3.3, 1.4.1)

2 Fookuses olev element peab olema selgelt visuaalselt eristatav, et klaviatuuriga navigeerijatel oleks selge, mille juures nad lehel asuvad. (WCAG 2.4.7)

3 Aktiivne element (näiteks menüüpunkt, mis viitab lehele, kus hetkel asutakse) peab olema selgelt eristatav ka värve nägemata. (WCAG 1.4.1)

4 Teksti ja tema tausta värvid peavad olema piisavalt erinevad, et nende kontrastsus oleks minimaalselt: kui font on kuni 18pt ja regular - 4,5:1 ning kui font on vähemalt 18pt ja regular või vähemalt 14pt ja bold - 3:1. Erandiks on kiri logol ja dekoratsioonina kasutatav kiri. Värvide kontrastsust saab kontrollida nende HEX koodide järgi näiteks WebAIMi kontrolltööriistaga. (WCAG 1.4.3)

5 Kasutajaliidese elemendi (nt nupp) või graafilise elemendi (nt ikoon) ja tema tausta värvid peavad olema piisavalt erinevad, et nende kontrastsus oleks vähemalt 3:1. Värvide kontrastsust saab kontrollida nende HEX koodide järgi näiteks WebAIMi kontrolltööriistaga. (WCAG 1.4.11)

6 Kui lehele on sisseehitatud kontrastsuse muutmise võimalus, peaks see asuma päise ülemises vasakus nurgas, et see lehe suurendamisel ekraanilt ära ei kaoks.

7 Veebis tuleb kasutada tagasihoidlike värve ja mustreid, mis toetavad teenuse sisu, mitte ei tõmba tähelepanu oluliselt ära. Lähtuma peab minimalismist ja lihtsusest.

8 Tekst peab olema taustaga võrreldes piisavalt kontrastne, et see oleks loetav. Kontrastsuse kontrollimiseks saab kasutada vastavat tööriista. 

9 Vältima peab intensiivseid taustamustreid.

10 Läbipaistvate taustade pealt peab tekst piisavalt välja paistma.

Front-End nõuded versioon 1, jaanuar 2019

https://dok.rik.ee/x/viWcAg

Sisukord

Sissejuhatus Mõisted HTML

Nõuded CSS

Nõuded Responsiivsus Javascript

Nõuded Veebi sisu juurdepääsetavussuunised (WCAG) ja üleüldised kasutajakogemust puudutavad nõuded

Nõuded Meediumite kasutamine veebilehel (veebilehe laadimiskiirus) Koodibaasi kvaliteedi tagamine Muud nõuded

Nõuded

Sissejuhatus Tehnoloogia areng on tekitanud olukorra, kus pakutavate tehnoloogiate virr-varrist on raske leida asjakohaseid suunised, mille järgi juhinduda. Eriti peegeldub see Front-End tehnoloogiate rakendamisel, kus loodavate lahenduste kvaliteet on seinast-seina. Ühest küljest on sellise olukorra tekkimist võimaldanud asjaolu, et veebilehe arendamisel kasutatavad tehnoloogiad on vigade tolerantsed. See tähendab seda, et HTML-is või CSS-is esinevate vigade kohta ei anna veebilehitsejad vaikimisi arendajatele tagasisidet. Kui programmeerimiskeele interpreteerimisel tekib viga, siis veasituatsiooni põhjustatud kohas tegevus lõpetatakse ja selle katkestamise põhjus kirjutatakse kas ekraanile või mõnda faili. Siis HTML/CSS-i korral see nii ei ole. HTML/CSS-is esinevad vead saab tuvastada vaid kaudselt, kuna veebilehitseja tootjad on loonud enda poolt loodud veebilehitsejasse tööriistad, mis parendavad või ignoreerivad vigast koodi. Seega on võimalik kirjutada vigadega koodi, aga kasutaja neid vigu veebilehel ei näe.  Käesolev dokument käsitleb endas juhiseid ja suuniseid, mida tuleb järgida veebilehtede programmeerimisel. Käsitlevateks tehnoloogiateks on HTML5, CSS3 ja Javascript ehk see osa, mis toimub veebilehitsejas (browseris). Oluline osa sellest dokumendist keskendub ka sellele, kuidas tagada veebilehtede arendamise järjepidevus ja kvaliteet, mis vastaks tänapäeva veebilahenduste arendamise nõuetele ja WCAG suunistele. Lisaks eelnimetatule tuuakse käesolevas dokumendis välja ka parimad praktikad, mis aitavad meeskonnal paremini luua ja hallata pikaajalisi projekte.

Enne projekti tegelikku algust lepitakse kokku kõik erisused - millised nõuded konkreetses projektis ei rakendu (nt pole võimalik või vajalik).

Mõisted Grid-system – reeglistik, mis pakub ühtset süsteemi kasutajaliidese komponentide laiuste ja kauguste kirjeldamiseks. Tänapäeval on see, mis kirjeldab ka veebilehe responsiivsuse. grid-system Ehk reegleid, mis kirjeldavad, kuidas veebileht erineva suurusega ekraanidel välja näeb.

Javascript – skriptikeel, mille abil luuakse veebilehele erinevaid interaktsioone. Tuvastades kasutaja tekitatud sündmuseid võimaldab keel lisada, muuta või kustutada veebilehe sisu. Üks osa Javascriptist on ka peidetud andmevahetuse võimaldamine.

HTML5 (Hyper Text Markup Language)  – struktureeritud markeerimise keel. Viies põhiredaktsioon. Keel, mille abil kirjeldatakse veebilehe andmeid ja struktuuri.

CSS (Cascading Style Sheets) – keel, mille abil kirjeldatakse veebilehe välimust.

WCAG (Web Content Accessibility Guidelines) – dokument, mis pakub suuniseid, kuidas veebilehe sisu juurdepääsetavust parendada.

HTML Veebilehe valmistamisel on HTML-i roll kirjeldada lehe struktuuri ja seda, mis andmed sellel lehel olemas on. Semantiline HTML tähendab seda, et HTML-li kirjutamisel on eelistatud esmajärjekorras semantilisi (tähendustega) elemente. Semantilised elemendid annavad olulist teavet nii otsingumootoritele kui ka lehe külastaja abitarkvaradele. Teave puudutab just seda, mis andmed on veebilehel ja kuidas need omavahel seotud on.

Semantilise HTML-i teine oluline eelis seisneb selles, et tagab kindluse tuleviku suhtes (future proofing) või kasutuskõlblikuse / väljanägemise browseris ilma CSS'ita. Koodi loetakse arendajate poolt ja tõlgendatakse arvutite poolt.

Nõuded

Nr Nõude sisu Nõude seletused

F E H1

Lehe kirjeldamisel on kasutatud semantilisi elemente.

Semantiliste elementide kohta saab täpsemat infot leheküljelt: http://html5doctor.com Nimetatud lehekülg koondab informatsiooni W3C Working Groupi dokumentide refereeringut. Leht annab esmase ülevaate võimalikest elementidest ja nende kasutamiskohtadest. Täpsema info saamiseks viidatakse algmaterjalile.

Halb näide Hea näide

F E H2

Lehe sisupuu peegeldab lehe tegelikku hierarhiat.

Pealkirjad ja mõned HTML5 elemendid ( kirjeldavad veebilehe sisupuud. Puudulike pealkirjade või Sections and Outlines of an HTML5 Document)  ebakorrektse HTML5 elementide kasutamine moonutab lehe tegelikku sisupuud. Testimiseks sobivad rakendused, mis oskavad välja joonistada HTML5 dokumendi sisupuu. Näiteks  või WAVE Toolbar  .HTML5 Outliner

Loe lähemat WCAG suunistest käesoleva dokumendi vastavast peatükist.

F E H3

Koodis puuduvad elemendid, mida on kasutatud selleks, et näidata ekraanil mõnda kujunduselementi. Näiteks ikoonid või muu graafika.

Kuna HTML on mõeldud sisu struktureerimiseks, siis ei tohiks kasutada HTML-is elemente, mille eesmärk on vaid mõne kujunduselemendi ekraanile joonistamine. Näiteks ei ole korrektsuse huvides kohane lisada HTML-i elemente, mis on tühjad (ilma väärtuseta) ja on seal vaid selleks, et näiteks kuvada ikooni. Graafika eraldamine HTML-ist pakub võimalust juhtida kujundust ühest kohast. Ühtlasi võimaldab selline meetod muudatusi teha nii, et ei peaks sekkuma rakenduse äriloogikasse.

Halb näide

Hea näide

Märkus. Siin pole mõeldud elemente, mille sisu täidetakse Javascripti abil. Näiteks Google Maps jmt. Küll aga peavad sellised elemendid sisaldama informatsiooni juhuks kui Javascript ei rakendu.  Või juhtudeks, kui kasutaja veebilehitsejas on Javascripti kasutamine keelatud. Samuti ei kehti see kriteerium nn Backdrop jmt komponentidel, mida kasutatakse kujunduses komponentide nähtavuse parendamiseks. Selliste komponentide jaoks tuleks kasutada vastavaid ARIA parameetreid.

F E H4

HTML-is kirjeldatud lehe komponendid on eristatavad.

Veebileht koosneb komponentidest ja komponendile kuuluvatest elementidest. Komponendipõhine lähenemine veebilehe arendamisel tähendab seda, et lehe loomisel on selgelt defineeritud lehe erinevad väiksemad osad (ehk komponendid/elemendid). Neid väiksemaid osasid kasutatakse erinevates sisulehtedes. Ehk lehe komponendid on korduvkasutatavad ja on sõltumatud neid ümbritsevast HTML-ist. HTML-ist on võimalik selgelt eristada, milline osa koodist on sisu ja milline on see osa, mille abil hoitakse koos lehe paigutust ( ). Eemaldades või grid-system lisades komponente ei muuda see tegevus lehe elementide paigutust.

Alljärgnevas näites on kasutatud kahte komponenti:   ja  . Esimese abil kirjeldatakse veebilehe sisu paigutust horisontaalsel teljel (teda ennast pole layout card lehe külastajale näha), see hoiab veebilehte koos. Teine on aga sisu komponent, mis on lehe külastajale näha ja mille laius sõltub sellest, palju on talle ruumi antud   komponendi vahendusel. Mõlemad on eraldiseisvad osad, millel on täita oma roll. Seega pole asjakohane märkida  -ile, milline layout layout card  tema sees välja näeb. See, milline üks või teine komponent välja näeb, seda kirjeldatakse vaid selle komponendi juures. Sellest siis alljärgnev halb ja hea näide.

Halb näide Hea näide

F E H5

Lehel on teade, kui kasutajal puudub Javascripti tugi.

Javascript on tänapäeval  veebi osa. Lisades lehele interaktsioone ja kulissidetagust andmevahetust, pakub see lehe külastajale paremat de facto  kasutajakogemust kui seda teeks vaid HTML ja CSS-i kasutamine. Kuna Javascripti osakaal lehe vajaliku funktsionaalsuse tekitamiseks on suur, siis on hädavajalik külastajale teada anda, kui tema veebilehitsejal Javascript ei ole toetatud. 

F E H6

Lehel on teade, kui kasutaja külastab veebilehte iganenud veebilehitsejaga.

Kui külastada lehte iganenud veebilehitsejaga, siis kuvatakse külastajale selle kohta teade. Teade sisaldab viiteid, kuidas uuendada või asendada oma veebilehitsejat.

Märkus.  all peetakse silmas neid veebilehitsejaid, mille toetamine on tootja poolt lõpetatud. Kuna veebilehitsejate uuenduste Iganenud veebilehitseja tsükkel on kaasaegsetes veebilehitsejatel 6-12 nädala tagant, siis need veebilehitsejad tagavad parima kasutajakogemuse ja turvalisuse. Kasutajaid tuleks suunata kasutama just neid veebilehitsejaid. Vt ka nõuet FEU3.

F E H7

Kood on W3C valideeruv.

Validaatorite eesmärk on pakkuda esmast teavet testitava koodi kohta. Valideerimise raportit ei saa käsitleda kui põhjust väita, et loodud kood on kasutuskõlbmatu. Igat raporti rida tuleb käsitleda eraldi ja võrrelda seda kokku lepitud nõuetega. Tarkvaraprojekti planeerimisel tuleb arvestada valitud tehnoloogiatega. Näiteks kui on kasutuses tehnoloogia, mis baseerub mitmetel kolmanda osapoole rakendustel, siis projekti teostajal ei ole võimalik tagada seda, et kõikide osapoolte genereeritud kood oleks täismahus valideeruv. Sellegi poolest tuleks eelistada neid teeke, mille väljund vastaks WCAG

õimalikest mööndustest tuleb projekti alustamisel informeerida tellijat. Mööndused peavad olema põhjendatud, näiteks kolmanda osapoole suunistele ja v tarkvara kasutamisel ja paremate alternatiivide puudumine. See muidugi ei tähenda seda, et valideerimisel avastatud vead (ehk “ ”) tuleb aktsepteerida. Koodis esinevad vead tuleb parandada. Muud errors valideerimisel saadud tulemustele tuleb anda hinnang eraldi. 

F E H8

Graafika, mida on võimalik realiseerida CS S-iga, tuleb ka realiseerida CSS-iga.

Erinevad kujunduselemendid, mis ei ole lehe sisu osa, tuleks realiseerida kasutades CSS-i võimalusi. Näiteks varjud, kumerad ääred, gradiendid jmt. CSS-is kirjeldatud kujunduselemendid võimaldavad eraldada sisu visuaalist. See pakub väga head paindlikkust kujunduse muutmiseks, täienduste tegemiseks jmt. Ühtlasi CSS-i abil loodud graafikat on kerge kohandada vastavalt ekraanile, millel teda kuvatakse. Veebilehitseja suudab CSS-i abil loodud graafikat vastavalt külastaja ekraani võimekusele kohandada. 

F E H9

Vormi sisestusväljadel on kasutatud asjakohast tüüpi.

HTML võimaldab ära märkida, millist   väärtust sisestusväli eeldab (lisaks eeldamisele on võimalik ka lisada valideerimisreeglid, mis ka kontrollivad, kas tüüpi sisestatud väärtus vastab reeglitele). Eriti oluline on see aina rohkem levima hakkanud puutetundlikele ekraanidele, milledes andmete sisestamisel kuvatavale klaviatuurile saab ette öelda, millist tüüpi sisu on vaja sisestada ja seade automaatselt optimeerib klaviatuuri just selle jaoks.

Halb näide Hea näide

CSS

Veebilehe valmistamisel on CSS-i roll kirjeldada, milline see veebileht välja näeb. Ehk see, millisena oleme tänapäeval harjunud veebilehti nägema, on kirjeldatud kasutades CSS-i keelt. Kui veebilehel puudub viide CSS failile, siis veebilehe väljanägemise kirjeldab HTML elementide vaikeväärtused, mille on ära kirjeldanud veebilehitseja tootja.

Keskmiste ja suuremate veebilehtede loomisel ja selle CSS-i koodibaasi haldamiseks on soovitav veebilehe komponendid jagada erinevateks failideks. Siinkohal mängivad olulist rolli erinevad nn CSS-i preprotsessorid, mis võimaldavad luua CSS-i läbi struktureeritud lähenemise. Preprotsessorid on tööriistad, mis pakuvad tarkvaraloojale võimaluse jagada oma CSS pisemateks osadeks. Võimaldavad luua CSS-i arhitektuuri, kus suured komponendid toetuvad pisematele.

Tänapäeval ühed levinumad CSS-i preprotsessorid on: ja . RIK kasutab SCSS-i.LESS SASS/SCSS

CSS-i koodistandardi paika panemiseks ja kontrollimiseks oleks soovitav kasutada ka SCSS Linterit. Linter on tööriist, mis aitab valideerida SCSS-i koodi vastavalt kokkulepitud reeglitele. Tänapäeval on olemas abivahendid, mis kontrollivad koodi korrektsust töö käigus automaatselt.

Nõuded

Nr Nõude sisu Nõude seletused

F E C1

Kasutatud on mõnda levinumat CSS-i raamistikku (eelistatult Twi

).tter Bootstrap

Arendusprotsessi kiirendamiseks ja jätkusuutlikuse tagamiseks on hea aluseks võtta valmis Front-End komponentide teek, mis pakub ühtset ökosüsteemi ja dokumentatsiooni veebilehe valmistamiseks. .RIK kasutab 'i ja seda tuleks uutes projektides ka eelistada, kui ei ole kokku lepitud teisitiTwitter Bootstrap Kuna valmis teek pakub juba hulganisti komponente ja elemente, mida veebilehe valmistamisel saab kasutada, siis nende kombineerimine võimaldab luua pidevalt juurde uusi vaateid, ilma et protsessi peaks sekkuma kujundaja.   Teegi valimisel peab peale kvaliteetse dokumentatsiooni ja populaarsusele olema oluliseks kriteeriumiks ka asjaolu, et see oleks modulaarne ja võimaldaks muuta sisendväärtuseid (on kasutatud SCSS CSS-i preprotsessorit). Igal projektil on oma nõuded ja vajadused.  Teek peab võimaldama sisse-välja lülitada oma funktsionaalsust. Modulaarsus ja sisendväärtuste muutmine võimaldab kokku panna just sellise koodibaasi, mida konkreetne projekt vajab. Projektis raames peab on sisse lülitatud olema ainult vajalik funktsionaalsus (kasutaja browser ei tõmba alla staatilisi ressursse, mida ei kasutata).

F E C2

CSS-i lähtekood sisaldab vaid standardseid atribuute.

Veebilehitsejate tootjad on loonud võimaluse eksperimentaalseid ja/või mitte standardseid atribuute kasutada lisades atribuudi algusesse veebilehitseja tootja eesliidese. Kuna neid eesliiteid on vaja vaid ajal, mil kasutatav tehnoloogia pole veel standardiks saanud või nimetatud funktsionaalsus pole  veel tootja poolt täies mahus implementeeritud, siis lähtekoodis neid sisaldada ei tohi. Lähtekood peab sisaldama ainult standardile vastavaid atribuute.

Veebilehitsejate tootjate eesliidesed lisab eraldi rakendus ( . Selle jaoks on olemas erinevad nn   tööriistad, mis pakuvad võimaluse juhtida, post-production) autoprefixer milliste veebilehitsejate ja milliste versioonidele eesliidest tuleb suunata ( ).PostCSS

Halb näide Hea näide

Antud kriteerium puudutab ka tänaseks juba iganenud meetodeid, mille abil püütakse sihtida mõne konkreetse veebilehitseja spetsiifilisi vigu, mis võimaldab just selle veebilehitseja jaoks kirjutada eraldi CSS-i kirjeid. Selle asemel tuleb välja selgitada mitte konkreetse veebilehitseja ja selle versioon, vaid selle võimekus. Selle jaoks on olemas nii CSS-is kui ka Javascriptis vastavad tööriistad.

CSS-is on selle jaoks näiteks @support tingimus, mis võimaldab tuvastada CSS-i abil veebilehitseja võimekust. Näiteks:

F E C3

CSS-i selektorina on eelistatud peamiselt CSS klasse.

Visuaali kirjeldamiseks on kasutatud CSS-i klassi selektorit. See tähendab seda, et visuaali rakendamiseks kasutatakse CSS klasse ja/või HTML elemente. Eelistada tuleb visuaali sidumist CSS klassi ja vältida ID selektorit.

Nõuet ei kohaldata tüpograafia kirjeldamiseks. Tüpograafia puudutab lehekülje sisu autoreid, kes sisestavad sisu mõne tekstiredaktori kaudu. Nendeks tekstiredaktoriteks on peamiselt nn WYSIWYG tüüpi tööriistad, mis võimaldavad sisu sisestada nagu seda tehakse näiteks Microsoft Wordis. Need tööriistad kirjutavad HTML-i koodi taustas ise ja nemad oskavad tähistada teksti osasid peamiselt HTML elementidega (p, h1-h6, table jne).

Märkus. CSS-i klassi eelistamise soovitus tuleneb sellest, kuidas toimub CSS-i selektori reeglite täitmine. Kui CSS-is on sarnaseid reegleid, siis mille põhjal otsustab veebilehitseja, millist reeglit rakendada? Et otsus oleks võimalik teha, antakse igale selektorile kaal. Suurema kaaluga selektorite reeglid rakenduvad. ID-ga ja pikad selektorid omavad märkimisväärset kaalu. Kui erinevate arendajate poolt mingi konkreetse komponendi visuaali muutmisel on igaüks kirjutanud enda selektori, siis on ilmselge, et iga arendaja koodi lisandumisel on konkreetse visuaali kirjeldamist puudutav CSS omandanud märkimisväärset kaalu. Selle tulemusel tekib olukord, kus hilisemate muudatuste tegemine võib osutuda võimatuks. Ühtlasi selline lähenemine läheb vastuollu levinumate CSS-i klassi nimetamise põhimõtetega.

Halb näide Hea näide

F E C4

CSS selektorite pikkus on mõistlik.

Mida pikem on CSS-i selektor, seda kauem võtab veebilehitsejal aega selle täitmine, samuti väheneb koodi jälgitavus ja loetavus. Seepärast on soovitav, et CSS-i selektor ei oleks pikem kui kolm-neli sammu.  Kuna CSS-i selektori täitmist alustatakse vasakult paremale, siis need kolm-neli sammu peaks eelistatuna olema lähimad struktuurid. Tuleb ka arvestada, et pikem selektor omab märkimisväärset suuremat kaalu reeglite rakendumisel  . Kui erand on põhjendatud, siis on erandid lubatud. Aga läbivalt (loe eelmise punkti märkust) tuleb siiski kasutada kuni kolme-nelja sammu pikkusi selektoreid.

Halb näide Hea näide

Veebilehitseja tootjad pidevalt optimeerivad oma algoritme, et CSS-is kirjeldatud reeglite täitmine oleks võimalikult kiire. Kiirust mõõdetakse küll millisekundites, kuid mahukamate projektide korral võib tekkida olukord, kus mahukate selektorite täitmine võtab põhjendamatult palju ressurssi.

F E C5

On kasutatud mõnda levinumat CSS klassi nimetamise põ himõtet.

CSS-i klasside nimetamine peab olema läbi rakenduse ühesugune. Tänapäeval kõige levinum CSS klasside nimetamise põhimõte on BEM (block-element-modifier).   Nõue tagab selle, et kui koodi kirjutavad erinevad arendajad, siis klasside nimetamise loogika on läbivalt sama. See muudab koodi ühtsemaks ja lihtsamini jälgitavamaks. Ühtlasi pakub BEM kahele kõige suuremale veebilehtede arendamise murekohale lahendust. Esiteks nõuab see seda, et kood oleks semantiline ja modulaarne. Teiseks vähendab võimalust, et erinevate arendajate poolt koostatud kood tekitab konflikte (ehk kirjutatakse teineteise vormingud üle).

BEM kohta leiab täpsemat infot siit: https://en.bem.info

Halb näide Hea näide

F E C6

SCSS-i lähtekood on struktureeritu d komponendip õhiselt.

Senised praktikad on näidanud, et veebilehe arendamisel ja ülesehitamisel on kõige paremaid tulemusi andnud komponendipõhine lähenemine: SCSS-i lähtekood on struktureeritud nii, et iga komponent on kirjeldatud oma failis. Sealjuures üldised ehk globaalsed parameetrid on koondatud ühte faili. See tähendab seda, et leht koosneb erinevastest plokkidest ja plokid elementidest. Iga komponendi muutmine/parendamine on võimaldatud nii, et see ei vajaks teiste komponentide samaaegset muutmist (st ei segaks teiste komponentide arendajaid). Selleks tuleb jagada SCSS koodibaas väiksemateks loogilisteks osadeks, milleks on näiteks navigatsioon, vormi komponendid, modaalaknad jmt.

F E C7

CSS klasse kasutatakse vaid visuaali kirjeldamiseks.

Ei ole hea praktika siduda Javascripti funktsionaalsust HTML elemendiga CSS klassi abi. Kasuta selleks data-* atribuute. Nõnda tekitatakse Javascripti ja HTML-i sidumiseks universaalne põhimõtte, mis ei mõjuta lehe semantikat ega sega visuaali ja Javascripti funktsionaalsust.

Responsiivsus Responsiivsete veebilehtede arendamine sai hoo sisse, kui oli vaja hakata veebilehte muutma kasutatavaks ka väiksematel ekraanidel: nutitelefonidel, tahvlitel. Nüüd aga me ei saa enam lähtuda kolmest ekraanist: mobiil, tahvel ja arvuti. Ekraani mõõte, millega veebilehti tänapäeval külastatakse, on väga palju. Selleks, et igas suuruses oleks veebileht tarbitav, tuleb muuta kogu veebileht sõltuvaks ekraani mõõdust. Ühest küljest aitab meil seda teha juba süsteemi rakendamine, kuid määrab ära vaid komponentide laiused. Et oleks võimalik juhtida ka komponentide ja grid grid nende elementide propotsioone (teksti suurus, jne) lähtuvalt ekraani suurusest, siis seda aitab meil saavutada juba mõnda aega CSS-is kasutatav ühik „rem“.padding-marging

Mida ühik „rem“ tähendab? Kõige lihtsam on seda seletada nõnda, et selle väärtus sõltub HTML-i juurelemendi ( teksti suurusest. HTML-i juurelement on element „html“. Vaikimisi on root element) selle elemendi teksti suurus 16px. See ütleb meile, et 1rem = 16px. Mida me saame selle teadmisega peale hakata? Me saame kogu veebilehel kasutatava disaini panna sõltuma juurelemendi teksti suurusest. Vaatame alljärgnevat näidet:

Pikslites kirjutades oleks:

Kui aga muudame juurelemendi teksti suuruse sõltuvaks ekraani suurusest (ühtlasi määrame ära minimaalse ja maksimaalse teksti suuruse), siis saame luua olukorra, kus veebilehe komponentide ja elementide propotsioonid muutuvad vastavalt sellele, kui suur on lehe külastaja veebilehitseja aken. Nõnda ei teki enam olukord, kus suurel ekraanil on tekst ja elemendid liiga pisikesed ja väiksel ekraanil aga vastupidi. Meil on olemas nüüd keskne koht, mille kaudu saame muuta kogu veebilahenduse kujunduse propotsioone.

 Loe täpsemalt Fluid Typegraphy.

Lisaks

CSS-i rakendamisel on mõistlik kaaluda varianti luua täiendavaid tööriistu ( ), mis hõlbustavad teha kasutajaliidese kujunduses parendusi nõnda, et selle jaoks ei pea muutma komponenti või Utilities selle elemente. Näiteks pakub selliseid tööriistu Responsiivsete lahenduste maailmas osutuvad need tööriistad hädavajalikuks, kuna Bootstrap https://getbootstrap.com/docs/4.1/utilities/borders/ arenduse käigus on vajadus veebilahenduse propotsioone juhtida vastavalt tekkinud olukorrale (näiteks lähtuvalt ekraani suurusest).

Javascript Tänapäeval kuulub iga veebilahenduse juurde. on see osa veebilehest, mis annab sellele dünaamilisuse ja võime reageerida kasutaja toimingutele. Ühtlasi aitab luua ka nn Javascript Javascript pol

-e, mille abil saab arendaja kasutada veebilehitsejas API-sid, mis on vaikimisi arendaja poolt toetatud veebilehitsejas puudu. See võimaldab kasutada tehnoloogiaid, mis on muidu kasutatavad yfill vaid uuemates veebilehitsejates.

Dokumendiobjektide mudel (DOM, Document Object Model)

DOM on platvormist ja keelest sõltumatu poolt standardiseeritud HTML dokumentidega suhtlemise liides. See liides võimaldab näiteks lugeda ja muuta veebilehte. Selle liidesega W3C Javascriptil suhtlemine on ka põhjus, miks osad veebilahendused tunduvad kasutaja jaoks aeglased või lihtsalt ei toimi ootuspäraselt. Kuna DOM sisaldab kogu informatsiooni kuvatava veebilehe kohta, siis on tegemist väga suure objektiga. Selles mingite muudatuste tegemine nõuab veebilehitsejal erinevaid tegevusi. Ja need tegevused, mida veebilehitseja mingi toimingu tulemusel peab täiendavalt tegema, on need, mida me soovime arendamise käigus hoida minimaalsena. Oluline on siinkohal ka meeles pidada, et on andmeid, mida DOM-is ei sisaldu. Näiteks kui me küsime Javascripti vahendusel elemendi kõrgust-laiust, siis veebilehitseja peab selle väärtuse küsimise hetkel välja uurima. Kui seda küsimist aga tehakse korduvalt ja erinevates skriptiosades erinevatel põhjustel, siis see on üks nendest põhjustest, mis võib muuta rakenduse aegalseks.

Selles, et neid probleeme vältida, on veebilehitseja tootjad loonud erinevaid täiendavaid API-sid, mille abil oleks võimalik DOM liidesega efektiivsemalt suhelda. Näiteks väga tihti on veebilahendustes vaja teada saada, kas üks või teine element on kasutaja jaoks nähtav. Ajalooliselt on seda probleemi erinevalt lahendatud, kuid kõik need nõuavad veebilehitsejalt liigset tööd. Selle jaoks on nüüd aga olemas eraldi , mis võimaldab seda funktsionaalsust paremini oma arendustest rakendada. Arendajal võib tekkida ka vajadus teada saada, kas Intersection Observer API DOM-is on midagi muutunud. Kas mingi osa skriptist on teinud HTML-is mingeid muudatusi. Varasemalt tuli selleks kirjutada eraldi skript, mis käib DOM-ist perioodiliselt muudatusi otsimas /kontrollimas. Skripti kirjutamise asemel on nüüd olemas efektiivsem muudatuste jälgimise võimalus - kasutada  .MutationObserver API

DOM-iga suhtlemise meetodites on toimunud viimastel aastatel oluline nihe. Kui eelnevalt tuli arendajal kirjutada kood, mis mingi reegli alusel küsib DOM-ilt infot, siis nüüd on pigem vastupidi. DOM ütleb ise, kui jälgitav tunnus on muutunud.

Kui eelnimetatud DOM-i puudutavad API-d on midagi, mida pakuvad veebilehitsejad, siis nendele lisaks on erinevad arendajad loonud veel täiendavaid liideseid, mis on veebilehitsejast sõltumatud. Üks populaarsem liides on . Internetist võib selle kohta leida väga palju materjali, aga lihtsamalt öeldes on tegemist DOM-i abstraktsiooniga ehk lihtsustatud ja eraldiseisva versiooniga Virtual DOM kuvatavast veebilehest. Kuna veebilehitseja enda DOM on väga mahukas ja sellega suhtlemine võib osutuda ressursinõudlikuks, siis pakub võimalust teha muudatusi veebilehes Virtual DOM nõnda, et ise vastutab selle eest, millised muudatused tuleb saata veebilehitseja DOM-i, et kasutaja saaks neid ka näha. Sellisel viisil muudetakse veebilehitseja DOM-i vaid siis, kui Virtual DOM seda tõesti on vaja teha ja seda püütakse teha võimalikult ressursisäästlikult.

Virtual DOM-i kasutavad näiteks sellised tehnoloogiad nagu React, Vue, Angular jne. Eelnimetatud tehnoloogiad on pigem raamistikud, mille üks osa on i rakendaine. Internetist võib Virtual DOM- leida ka vaid -i liidese jaoks mõeldud  teeke.Virtual DOM Javascripti

Nõuded

Nr Nõude sisu Nõude seletused

FEJ1 JS-i lähtekood on komponendipõhine

JS kirjutamisele tuleb läheneda modulaarselt. Koodibaas tuleb jagada väiksemateks loogilisteks komponentideks. Eelistada tuleb ES6 mooduleid (import/export).

See parandab:

funktsionaalsuse selget eraldatust koodi uuesti kasutamist koodi testimist isolatsioonis koodi hoomatavust arendaja poolt

FEJ2 Vorming, linter ja build protsess Projekt sisaldab käske koodi lintimiseks, testimiskes ja vajadusel kompileerimiskes.

Projekti raames peab kood jälgima ühtset stiili ja standardit. Ühtne stiil ja standard tagatakse läbi konfigureeritud style guide (mõne laialt levinud) ja linteri.

Linter aitab:

välja tuua potentsiaalseid vigu koodis parandada koodi loetavust hoida koodi kvaliteeti keskenduda probleemi lahendamisele

-        https://eslint.org/ -        https://standardjs.com/ -        https://github.com/airbnb/javascript/

-        https://gulpjs.com/ -        https://webpack.js.org/ -        https://docs.npmjs.com/misc/scripts

FEJ3 Kommentaarid Koodi kommenteerimiseks/dokumenteerimiseks eelista JSDoc formaati - .http://usejsdoc.org/index.html

kasuta järgneva koodi rea kommenteerimiseks//

kasuta et välja tuua probleeme// FIXME:

kasuta et välja tuua lahendusi probleemidele// TODO:

See annab:

võimaluse genereerida dokumentatsiooni funktsioonide, meetodite, konstruktorite kohta ühtne kommenteerimise stiil koodi editorid võivad kuvada lisa informatsiooni kasutatava funktsionaaluse osas

Veebi sisu juurdepääsetavussuunised (WCAG) ja üleüldised kasutajakogemust puudutavad nõuded Veebi sisu juurdepääsetavussuunised hõlmavad mitmeid soovitusi veebi sisu juurdepääsetavuse parandamiseks. Eesti keeles on võimalik tutvuda suuniste täisdokumendiga siin: http://www.w3.org

. /Translations/WCAG20-et/ Arendusprojektis tuleb kasutada raamistikke, mille väljund HTML peab vastama WCAG suunistele. 

Kuid peamised põhimõtted on:

Veebileht on struktureeritud korrektselt. Siin on mõeldud just seda, millest oli juttu ka juba HTML-i peatükis. Tuleb eelistada tähendustega elemente. Kui veebilehel on loetelu, siis tuleb kasutada ka vastavat HTML elementi. Täiendavat semantikat võimaldab lisada WAI-ARIA rollide mudel ( ) Rolle saab kasutada ka sellistes https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics olukordades, kus semantiliste elementide kasutamine pole mingil põhjusel võimalik. Veebilehel esinevatele ajas muutuvatele meediumitele saab WAI-ARIA mooduli States and Properties abil lisada täiendavat informatsiooni. Kasuta tekstilist vastet kui visuaalselt on näha vaid ikoon, video, audio jmt. Kui lehel on kasutatud nupuna ikooni, siis lisa nupule ka info, mida see ikoon tähendab. Seda on kõige lihtsam teha kasutades HTML-is või atribuuti. Vormi elementidel tuleks title alt kasutada elementi.label Ära keskendu ainult visuaalile. Lehe sisu peab olema arusaadav ka siis, kui lülitame välja näiteks CSS või kui lehte loeb ette kasutajale tarkvara. Oluline on silmas pidada, et ikooniga või värviga tähistatud kujunduselemendid oleks ka vaegnägijale tarbitavad ( , ).https://www.w3.org/TR/WCAG20-TECHS/G95.html https://www.w3.org/TR/WCAG20-TECHS/G18.html Veebileht on kasutatav ka klaviatuuriga. Komponentide loomisel tuleks arvestada kasutaja harjumustega. Kui kasutajal on harjumus teha tühik klahviga aktiivseks, siis see peaks toimima ka siis, kui see on checkbox checkbox loodud kasutades Javascripti abi.

Täiendavad kasutajaliidese komponentide nõuded leiad RIKi UIG lehelt

Nõuded

Nr Nõude sisu Nõude seletused

F E W1

Meediumitel, mis võimaldavad külastajale interaktsiooni, on kirjeldatud nn  olek.hover 

Igal elemendil, millega kasutaja saab midagi teha (lingid, vormi väljad, nupud jmt), on kirjeldatud  olek.  olek on see, kui kasutaja liigub hiirega hover  Hover  selle elemendi peale.  Erandiks on puutetundlikud ekraanid, kus  olek võrdub  . See tähendab, et funktsionaalsused, mis sõltuvad  tulebhover  klikiga hover-ist,  puutetundlikel ekraanidel ümber teha  . Siit ka soovitus otsutada, milline on primaarne funktsionaalsus. Üldiselt liigub maailm selles suunas, et klikipõhiseks funktsionaalsus, mis toob kasutajale midagi nähtavale  abil, ehitatakse siiski  peale, kuna tõusev trend on see, et veebilehti külastatakse pigem hover-i  kliki  puutetundlike ekraanidega.

F E W2

Vormi elementidel on kirjeldatud  olek.focus 

Focus olek aitab kasutajal eristada aktiivset vormi elementi teistest.

 selleks, et hinnata, kas focus on normaalselt nähtav, tuleb lähtuda WCAG poolsest soovitusest teksti värvi ja teksti taustavärvi vaheline kontrasti Märkus: määrast. Tööriist testimiseks: https://webaim.org/resources/contrastchecker/

F E W3

Elementidel on kirjeldatud  olek.active 

Active oleks aitab kasutajal eristada aktiivset elementi. Näiteks klaviatuuri abil lehel ringi liikudes saab aktiivne interaktsiooni võimaldav element teda eristava vormingu. 

F E W4

Elementidel on kirjeldatud  olek.visited 

Mahukate veebilehtede korral on hea anda lehe külastajale tagasisidet viidete kohta, mida ta on juba külastanud. Sedasi lehe korduval külastamisel on tema persionaalne ajalugu näha.

F E W5

Veasituatsioonid on sõnastatud asjakohaselt ja omavad vastavalt situatsioonile korrektset visuaali.

Veasituatsioonide tekkimisel antakse kasutajale asjakohast tagasisidet. Teade on tähistatud nii värvi kui ka vastava ikooniga. Kehtib reegel, et süsteemi tõrked, mis ei tulene kasutaja tegevusest, tähistatakse punase värviga. Muud tõrked, mis on põhjustatud kasutaja käitumisest, pigem oranziga (ehk hoiatava, informatiivse tooniga).

F E W6

Situatsioonid, kus informatsioon on mõnes komponendis puudu või on alles saabumas, on selgelt tähistatud.

Veebilehel on arvestatud olukordadega, kus näiteks tabel on tühi. Sellistel olukordades tuleb kasutajale anda infot, miks see on tühi ja vajadusel lisada juurde, mida ta peaks tegema, et see infoga saaks täidetud. Sama kehtib ka ajas muutuvate meediumite kohta. Kui mingi informatsiooni laadimine nõuab rohkem aega, siis selle laadimise kohta tuleb anda kasutajale tagasidet.

F E W7

Veebilehel kasutatud animatsioonid parendavad kasutajakogemust.

Nii nagu päris maailmas, nõnda ka veebis, peavad animatsioonid peegeldama objektide kergust, raskust, suurust jmt. Animatsioonid peavad olema kasutajat toetavad ja kirjeldama animeeritava elemendi suhet ülejäänud lehega. Et animatsioonid ei hakkaks liialt riistvara koormama ega kasutajat ärritama, tuleb animatsioonide kirjeldamisel lähtuda animatsiooni optimeerimise põhimõtetest. Nendeks on:

-        animatsioonid ei tohi nõuda veebilehitsejalt põhjendamatuid kordusi; -        animeerida tuleb CSS-i atribuute, mis on veebilehitsejate poolt optimeeritud; -        animatsioonid tuleb käivitada komplektina ja ajastatult veebilehitsejale kõige paremal hetkel (requestAnimationFrame).

Mida ühe või teise CSS-i atribuudi muutmine veebilehitsejalt nõuab, saab tutvuda lehel CSS Triggers

: Animatsioonid peavad olema põhjendatud, kui animatsioon on põhjendamata ja/või näiteks epileptikutele isegi ohtlik, siis see kriteerium ei ole Märkus täidetud .

Meediumite kasutamine veebilehel (veebilehe laadimiskiirus)

Mitmekesise meediumi kasutamine veebilehel avaldab otsest mõju lehe laadimiskiirusele ja sellele, kui kiiresti veebilehitseja suudab lehe külastajale valmis meisterdada. Mida suurem on veebilehe toimimiseks vaja erinevate ressursside osakaal, seda kauem läheb aega, mil leht on kasutamiseks valmis.   Jättes korraks kõrvale CSS ja Javascript failid, siis kõige suuremateks veebilehe kuvamise blokeerijateks on pildid ja videod. Piltide kasutamisel tuleb pöörata tähelepanu nende mahule. Ei ole sobilik lisada veebilehele pilte, mille maht on põhjendamatult suur. Kui on alust arvata, et kasutavate piltide mahud on liiga suured, siis alljärgnevad tööriistad võimaldavad nende mahtusid vähendada:

-        http://www.jpegmini.com -        https://pngquant.org -        https://imageoptim.com -        https://github.com/google/guetzli

Videode kasutamisel tuleb arvestada sellega, et videode vaatamiseks on vaja selle mängijat. Igasuguse mängija visualiseerimine ja käivitamine võtab aega, kuna mängija jaoks on vaja alla laadida selle käivitamiseks vajalikke ressursse. Kui lehel on mitu sellist mängijat, siis iga mängija jaoks tuleb veebilehitsejal tööd teha. Iga täiendav liigutus aga nõuab aega ja see avaldab märkimisväärset mõju lehe kiirusele.

Mis puudutab aga CSS-i ja Javacripti faile, siis nende kasutamisel tuleb tekitada olukord, kus:

-        kõik lehel kasutusel olevad CSS-i failid oleksid liidetud üheks failiks ja faili sisu oleks minimeeritud; -        kõik lehel kasutusel olevad Javascripti failid oleksid liidetud üheks ja faili sisu oleks minimeeritud.

Veebilehe kiiruse optimeerimise ja selle mõjude kohta  saab täiendavalt lugeda lehelt:  ja https://kinsta.com/learn/page-speed/ https://developers.google.com/web/fundamentals/performance/critical- rendering-path/

Pildigraafika optimeerimine

Tänapäeval on võimalik kasutada erinevaid tööriistu, mis võimaldavad juba töö käigus pildigraafikat optimeerida. Selle jaoks tuleb vaid seadistada taustateenus, mis jälgib kataloogides toimunuid muudatusi ja vastavalt etteantud mustritele käivitavad optimeerimist teostavad skriptid.  Kõige levinumad taustateenuste skriptide jooksutajad on:

-        Gulp -        Grunt -        Webpack

Kuna kõik kolm nimetatud kasutavad mooduleid, mis on kirjutatud kasutades Javascripti, siis on võimalik ilma suurema vaevata luua lähtuvalt vajadusest projektile omane skript pildigraafika optimeerimiseks. Seda siis eeldusel, et mõni juba olemasolevatest ei sobi. Küll aga juba vabalt kättesaadavad skriptid sisaldavad enimlevinud algoritme erinevate pildigraafika optimeerimiseks. Tasulistest tarkvaradest tooks välja -i. Tegemist on suurepärase tööriistaga just JPG piltide optimeerimiseks. Tihti saavutab see pea 3x mahu vähenemise ilma et pilt kaotaks JPEGmin silmnähtavalt kvaliteedist. Tutvu pildigraafika erinevate optimeerimise meetoditega .siin

Responsiivsed pildid

Tehnoloogi aitab lehe autoril lisada veebilehele piltmaterjali sellisel kujul, mis võimaldab neid tarbida erinevate suurutel ekraanidel. Siinkohal tuleks silmas pidada peale pildi kõrguse ja laiusele ka selle mahtu ja fookuspunkti. Fookuspunktist tuleb kinni pidada, et olukordi, kus pildil kujutatud oluline element oleks ebanormaalselt lõigatud või muul viisil rikutud.välitda

HTML-i elementile img on võimalik lisada juurde täiendav parameeter, mis sisaldab informatsiooni võimalike alternatiivsete pildi variatsioonide kohta: https://developer.mozilla.org/en-US/docs/Learn /HTML/Multimedia_and_embedding/Responsive_images

Koodibaasi kvaliteedi tagamine

CSS-i kirjutamisel on suureks abiks erinevad nn CSS-i preprotsessorid. Need on tööriistad, mille abil on võimalik läheneda CSS-i kirjutamisele struktueeritult. Preprotsessorid muudavad CSS-i skriptikeeleks, mis kompileeritakse tavaliseks CSS-iks, mida veebilehitsejad oskavad lugeda. Skriptikeelelaadne kirjutamine võimaldab korduvaid tegevusi hoida ühes kohas.

CSS-i preprotsessorid

Tänapäeval levinumad CSS-i preprotsessorid on ja . Kuna viimasel ajal on populaarsust kogumas pigem SASS/SCSS, siis võiks täna alustavates projektides pigem eelistada LESS SASS/SCSS SASS/SCSS preprotsessorit. Seda põhjusel, et nimetatud preprotsessori kompetentsi on tööturul lihtsalt rohkem.

CSS-i postprotsessorid (PostCSS)

Tänapäeval täiendava võimalusena on loodud , mille abil on võimalik olemasolevat CSS-i järeltöödelda. Need tööriistad pakuvad võimaluse CSS-i lähtuvalt sisendparameetritele või tehnoloogia teatavatele mustritele muuta selliseks nagu vaja. Näitena võib tuua olukorra, kus ühe rakenduse jaoks tehtud CSS oleks vaja muuta teise rakenduse jaoks sobilikuks nõnda, et see hakkaks vastama uue rakenduse stiilinõuetele (näiteks vaja muuta kasutatavat fonti, värve jmt).

Üks levinum põhjusi kasutada -i on aga vajadus  ( ) tagada uuemate tehnoloogiate tagasiühilduvat tuge ammutades andmeid andmebaasist.PostCSS Autoprefixer Can I Use

Tagasiühilduvat tuge vajavad:

-        eksperimentaalses staatuses olev funktsionaalsus

See on funktsionaalsus, mis on küll veebilehitsejal olemas, aga tootja poolt on märgitud eksperimentaalseks. Eksperimentaalsete funktsionaalsuste eristamiseks kasutavad veebilehitsejad eesliiteid ( Näiteks prefix).

(spetsifikatsioon näeb ette aga ) Igal tootjal on oma.-webkit-box-shadow box-shadow .

-        varasema (kehtetuks tunnistatud) funktsionaalsust kirjeldava spetsifikatsiooni toetamine

Uute veebitehnoloogiate lisamine veebilehitsejatesse on modulaarne. Iga tootja otsustab ise, millal millist moodulit oma tootesse lisab. Tulemuseks on see, et osa veebilehitsejaid toetavad funktsionaalsuse varasemat spetsifikatsiooni, teised aga uuemat. Sellest tulenevalt kasutavad veebilehitsejad erinevat süntaksit funktsionaalsuse rakendamiseks.

Autoprefixed on PostCSS-i moodul, mis on loodud selleks, et lahendada eelnimetatud tagasiühilduva toega seotud küsimusi, lisab vajadusel eesliitega juurde puuduvad atribuudid ja teeb süntaksi parendusi seal kus vaja.

PostCSS pakub lahendusi erinevatele probleemidele. Vabalt kättesaadavatest moodulitest saab ülevaate siit:  .https://www.postcss.parts Kuna moodulid on kirjutatud kasutades , siis on lihtne neid mooduleid ise lähtuvalt projekti spetsiifikast juurde luua.Javascripti

Linter (lint, linter, linting) Linter on tööriist, mis otsib koodist võimalikke vigu. Front-End arenduses saab sellist tööriista kasutada automaatse validaatorina, mis testib iga arendaja koodi vastavalt ette antud standardile. Selline tööriist pakub võimalust defineerida koodistandard iga projekti jaoks eraldi (ehk saab panna sõltuma projekti spetsiifikast). Selliselt saab tagada, et kõikidel projektis osalevatel arendajatel on kood kirjutatud järgides samu põhimõtteid.

Muud nõuded

Nõuded

Nr Nõude sisu Nõude seletused

F E U1

Rakendus peab olema graafiliselt eskaleeruv.

Nii avalikuks kui ka sisemiseks kasutamiseks tehtav rakendus peab olema graafiliselt eskaleeruv (responsive web design) ja mugavalt kasutatav kõigi enamlevinud seadmete resolutsioonidega vahemikus 320x568px kuni 3840x2160px. Ühegi nimetatud resolutsiooni korral ei tohi tekkida horisontaalset kerimisriba. Implementatsioon peab jälgima “Mobile first” kontseptsiooni.

F E U2

Vaikimisi veebilehitseja poolt blokeeritavaid hüpikaknaid ei tohi kasutada.

Kõik aknad, mis avanevad peavad olema sellised, mida üksi brauser oma vaikimisi konfiguratsioonis ei blokeeri. St ei tohi tekkida olukorda, kus veebilehitseja blokeerib vaikimisi avatava akna ning kasutaja peab selle avamise eraldi veebilehitsejas lubama.

Veebilehitseja poolt võidakse blokeerida avatav aken olukorras, kus rakendus üritab seda avada automaatselt, st mitte kasutaja vahetu tegevuse peale. Näited:

Veebilehitseja blokeerib avaneva akna, sest see avaneb läbi Javascripti automaatselt.

Veebilehitseja blokeerib avaneva akna, sest see avaneb läbi Javascripti automaatselt.

Veebilehitseja ei blokeeri avanevat akent, sest see avaneb kasutaja vahetu tegevuse peale.

F E U3

Veebipõhine kasutajaliides peab olema kasutatav enamlevinud veebibrauseritega. Minimaalselt Mozilla Firefox, Safari, Chrome ja Edge arenduse testimise hetkel 2 viimast (major) versiooni ning Internet Explorer 11.

Operating system Browser

Windows Internet Explorer 11

Windows Edge (2 viimast versiooni)

Windows Google Chrome (2 viimast versiooni)

Windows Mozilla Firefox ( )2 viimast versiooni

macOS Safari ( )2 viimast versiooni

macOS Google Chrome ( )2 viimast versiooni

macOS Mozilla Firefox ( )2 viimast versiooni

iOS Safari ( )2 viimast versiooni

iOS Google Chrome ( )2 viimast versiooni

Android Google Chrome ( )2 viimast versiooni

Arenduse tavad ja töökorraldus

Tellija jätab endale õiguse muuta raamlepingu alusel sõlmitavate hankelepingute tehnilises kirjelduses

kirjeldatud nõudeid. Pakkuja peab lähtuma hankelepingute täitmisel järgnevatest nõuetest, v.a juhul kui tellija on

hankelepingu tehnilises kirjelduses märkinud teisti.

Arendustööde teostamisel kohustub pakkuja lähtuma mittefunktsionaalsetest nõuetest.

1. Nõuded arenduste üleandmisele

Loodavad hanke tulemid antakse üle RIK-i koodirepositooriumi kaudu. Partneri meeskonnaliikmetele luuakse

RIK-i poolt ligipääs koodirepositooriumile lähtekoodide, andmebaasimuudatuste ning muude tulemite või nende

muudatuste üleandmiseks.

2. Commit

Arendamisel lisada commitide (lähtekoodi repositooriumisse lisamine) juurde kindlasti töökäsu 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 ning kindlasti lisada info selle kohta, et kes antud commiti

teeb (isiku nimi).

Vigade parandamisel tuleb alati committimisel lisada ticketi number märkusena.

Muudatusi tuleb commitida vähemalt kord päevas.

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

1) Iseendaga kooskõlas (pole vastuolusid, katkiseid mooduleid, iseendaga vastuolus funktsionaalsust);

2) Üldharu/muu haru tulemiga kooskõlas (üldharus olemasolev pole peale commiti katki);

3) 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.

Commititav kood/teostatud töö/tulem peab olema piisavalt testitud ja pakkuja poolt testidega kaetud, kasutades

selleks:

a) Unittest’e,

b) Systemtest’e

c) Manuaalseid teste

3. Tagimine

Versiooni üleandmiseks tuleb sellest koostada tag. Tagi number peab ühtima versiooni numbriga, mida üle

antakse, kuid tagi nimi peab alati algama projekti lühendiga. Tagi alla tuleb siduda kõikide arhitektuuriliste

komponentide (rakendus, andmebaasiscriptid, x-tee adapter jne) ning muudetud või loodud dokumentatsiooni

commitid.

Versiooni numbrid peavad olema vähemalt kolmekohalised (X.Y.Z, milles X- põhiversioon, Y - üleantav versioon,

Z paranduse number). Vajadusel võib kokku leppida teistsuguses numeratsioonis.

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html#tsvn-dug-branch-1

Iga tagiga (uue versiooniga) peab kaasnema versiooni kirjeldus (mis taskid, mis ticketid, mis baasiscriptid, mis

juhendeid täiendati jne), mis tuleb paigutada dokumentatsiooni alla.

4. Dokumentatsioon

Dokumentatsiooni tuleb hoida trunk/doc/ kaustas. Alampuud lepitakse eraldi kokku.

5. Baasiscriptid

Andmebaas ning selle muudatused tuleb alati üle anda loovate, muutvate, täiendavate jne skriptidena ning neid

tuleb alati hoida trunk/baas/ kaustas.

Andmebaasiscriptide failinimed peavad olema kujul:

YYYYMMDDHHMM_prefiks+Järjekorranr.sql ehk 201105131430_KR0003.sql kus prefiks on süsteemi

lühend.

6. Pakkuja poolne testimine

Partner peab lisaks kasutuslugude funktsionaalsele testimisele teostatava arenduse/töö/tulemi commitimisel ja

üleandmisel ise tõestatavalt veendunud olema, et nende arendus/töö/tulem teeb seda, mis on nõutud ning

samaaegselt ei riku/lõhu juba olemasolevat muud arendust/tööd/tulemit.

Iga kirjutatud koodiüksuse kohta peaks olemas olema ka vastav test, mis kindlustab, et loodu toimib ja seda ka

eriolukordades. Samuti on testid abiks juba olemasolevate komponentide muutmisel, indikeerides koheselt

võimaliku probleemolukorra.

Arendatav funktsionaalsus peab olema kaetud:

1. Unittestidega

2. Süsteemitestidega

3. Manuaalsete testidega

Igal commitimisel ning üleandmisega peab edukalt:

1. käivitama kõik Unittestid ning selle dokumenteerima.

2. käivitama kõik süsteemitestid ning selle dokumenteerima

3. käivitama kõik manuaalsed testid ning selle dokumenteerima

4. dokumenteerima, mis test data't kasutati, mis keskkondi kasutati, jne.

6.1 Unit-testid e. Moodultestid

Moodultestid testivad ÜHTE klassi isoleeritult teistest klassidest ja ressurssidest (andmebaas).

Ideaalis peaks igal iseseival klassil olema oma moodultest, mis kataks selle funktsionaalust täielikult.

Kuna klassid kasutavad teineteist, moodustuvad niiöelda kobarad, siis moodultesti ideoloogiaga see hästi kokku

ei sobi. Selleks, et saaks testida tõesti vaid konkreetse ühe klassi funktsionaalsust, on kasutusel mock-

objektid(väline komponent Rhino Mocks).

6.2 Süsteemitestid

Süsteemitestid testivad süsteemi kasutaja vaatenurgast, eesmärgiks on kontrollida süsteemi vastavust kasutaja

nõudmistele.

Süsteemitestid jagunevad omakorda kaheks:

1. Funktsionaalsuse testid - üldjuhul koostatakse konkreetse teenuse klassi süsteemitestid sellises mahus, et

kaetud oleksid selle kõik erinevad meetodid ning lisaks äriloogiliselt olulisemad stsenaariumid.

2. Mittefunktsionaalsete aspektide testid - näiteks jõudluse testimiseks.

6.3 Üldised nõuded testide kirjutamisel

Nagu eelnevalt sai kirjeldatud, on testid liigendatud oma olemuse järgi. Testi sisu ja iseloom varieerub olenevalt

selle kategooriale (nt. [Test, Category("Bug")] – testis kirjeldatakse kindel veaolukord ning kontrollitakse selle

põhjal vea olemasolu. testi andmed on antud veaolukorra järgi koostatud ja spetsiifilised). Küll aga on kujunenud

kindlad head tavad, mida tuleb kõigi testide kirjutamisel järgida – koodieetikat, testide liigendamist, testide

automatiseeritust (st. teste peab saama käivitada skriptidega projektiväliselt nt. kategooria alusel iga-öiselt) ning

testide autonoomsust (testid peavad võimalikult hästi taluma ET muudatusi).

6.4 Koodieetika ja struktuur testide kirjutamisel

Testkood peaks olema liigendatud ja selgelt loetav:

1. Defineerida testis projekti erinevate osade kasutus (nt. using System;);

2. Iga testklass tuleb deklareerida [TestFixture]-raamistikus ning olenevalt testi iseloomust nimetada kujul

Bug1234Test (kindlat viga #1234 kirjeldav Bug-test), Ticket1234Test (uuendust #1234 kontrolliv test)

või TestiKirjutajaEesnimi_TeenuseNimiTest (teenuse spetsiifiline süvatest);

3. Testis olevad privaatsed klassimuutujad on tava kohaselt kujul _muutujaNimi, näiteks

private Menetlus _menetlus;

4. Kaitstud ja avalikud muutujad on kujul muutujaNimi või MuutujaNimi;

5. Vajalik uute klassiobjektide initsialiseerimine (nt. liidesed) toimub meetodis SetUp(). Näiteks:

[SetUp]

public void SetUp()

{

_liides = new Liides();

}

6. Iga uus testcase tuleb kirjutada raamistiku sisse kujul

[Test, Category("Kategooria")]

ning testi enda nimetus tuleneb testi tüübist:

a) Bug-testide ja uuendusi kontrollivate testide korral nimetus, mis kirjeldab võimalikult hästi ja

konkreetselt kontrollitavat objekti/olukorda .

b) Teenusepõhiste süvatestide puhul esiteks test, mis kontrollib, et teenust saaks nii minimaalsete

kui ka maksimaalsete andmetega kinnitada, nimetusega A_SetUp()

7. Testandmed võiksid olla võimalikult reaalse elu lähedased ja loogilised, st. ei tohiks tekitada uut objekti

klassist Helikopter kujul _a, vaid kujul _helikopter.

8. Iga äridokumendis olev nõue või tingimus tuleb testida eraldi testcase’i all, olenemata sellest kas

kontrolliks on üks või rohkem ridu koodi. Kui teha äriloogiline kontroll vaid ühe testi all, siis ei kajasta

see teenuse tervist – st. kui esimene kontroll annab veateate, siis ülejäänuteni test ei jõua. Selle

vältimiseks on testid ärinõuete kaupa eraldi kirjutatud.

6.5 Autonoomsus

Testid peavad taluma pisemaid koodi muudatusi (neid, millega ei kaasne DTO või andmemudeli muutused).

6.6 Automatiseeritus

Kõiki teste peab saama käivitada näiteks projektiväliselt skripti abil. Selleks peavad testid olema õigesti

kategoriseeritud.

Riigihanke „Kohtute infosüsteemi arendustööd" (296052)

hankedokumentide juurde

RAAMLEPING NR ..

Raamlepingu sõlmimise

alus

Raamleping sõlmitakse riigihanke „Kohtute infosüsteemi arendustööd"

(viitenumber296052) (edaspidi nimetatud riigihange) tulemusena.

Pooled Raamleping sõlmitakse Registrite ja Infosüsteemide Keskuse (edaspidi

tellija) ning kuni kolme riigihankes edukaks osutunud pakkuja (edaspidi

eraldi täitja või täitjad) vahel, keda nimetatakse edaspidi eraldi pool või koos

pooled. Raamleping sõlmitakse kaskaadmeetodil, milles lähtutakse täitjate

poolt riigihankes esitatud paremusjärjestusest.

Raamlepingu eesmärk

Raamlepingu eesmärgiks on:

- kehtestada raamlepingu kehtivusaja vältel selle alusel sõlmitavaid

hankelepinguid reguleerivad tingimused;

- määratleda pooltevahelised õigused, kohustused ning vastutus

hankelepingute sõlmimisel;

- kehtestada ühtsed tingimused hankelepingute tõlgendamiseks.

Tellija Registrite ja Infosüsteemide Keskus

Registrikood 70000310

Aadress Lubja 4, Tallinn, 19081

Tellija esindaja Rivo Reitmann

Esinduse alus Põhimäärus

Täitja 1

Registrikood

Aadress

Täitja esindaja

Esinduse alus

Täitja 2

Registrikood

Aadress

Täitja esindaja

Esinduse alus

Täitja 3

Registrikood

Aadress

Täitja esindaja

Esinduse alus

1. Raamlepingu ese ja dokumendid

1.1. Raamlepingu esemeks on Kohtute infosüsteemi (KIS) arendustööde tellimine vastavalt

hankedokumentides toodud tingimustele.

1.2. Raamleping koosneb lepingu põhiosast ja selle lisadest. Raamlepinguga samaaegselt

allkirjastatavad lisad on:

1.2.1. Lisa 1 – Raamlepingu tehniline kirjeldus;

1.2.2. Lisa 2 – Hankelepingu projekt;

1.2.3. Lisa 3 – Pakkumus /allkirjastatakse koos lepinguga juhul, kui raamleping sõlmitakse ühe

pakkujaga/.

1.2.4. Lisa 4 – Poolte volitatud esindajad ja kontaktandmed.

1.3. Raamlepingu lahutamatuks osaks on ka riigihanke dokumentatsioon.

2. Kinnitused

2.1. Pooled kinnitavad, et:

2.1.1. raamlepingu sõlmimisega ei ole nad rikkunud ühegi enda suhetes kehtiva seaduse,

põhikirja või muu normatiivakti sätet ega varem sõlmitud lepingu või kokkuleppega

endale võetud kohustust;

2.1.2. nad on oma majandustegevuses iseseisvad ja kumbki pool ei vastuta teise poole poolt

endale kolmandate isikute ees raamlepingu või hankelepinguga võetud kohustuste

täitmise eest;

2.1.3. neil on seaduses ettenähtud piisav õigus- ja teovõime raamlepingu ja hankelepingu

sõlmimiseks ning nendest tulenevate kohustuste täitmiseks ja õiguste realiseerimiseks;

2.1.4. nende poolt raamlepingu allkirjastanud isikutele on antud piisavad volitused selle

sõlmimiseks kooskõlas seaduste, põhikirjade või muude normatiivaktidega.

2.2. Poolte esindajad kinnitavad, et neil on kõik õigused ja volitused sõlmida raamleping esindatava

nimel ning nad ei tea ühtegi takistust raamlepinguga võetud kohustuste täitmiseks.

3. Raam- ja hankelepingute tõlgendamine

3.1. Pooled järgivad raamlepingu ja hankelepingu (antud punkti kontekstis ühiselt nimetatud ka kui

leping) täitmisel ja tõlgendamisel järgmisi põhimõtteid:

3.1.1. lepingu jaotiste pealkirjad ei määra nende mõistete ega sätete tähendusi;

3.1.2. lepingus, kui kontekst seda nõuab, võivad ainsuses olevad sõnad tähendada mitmust ja

vastupidi.

3.1.3. pooled käituvad teineteise suhtes heas usus ja mõistlikkuse põhimõttest lähtuvalt;

3.1.4. pooled peavad mõistlikuks seda, mida samas olukorras heas usus tegutsevad isikud

loeksid mõistlikuks;

3.1.5. mõistlikkuse hindamisel arvestatakse lepingulise suhte olemust ja lepingu eesmärki ning

vastava tegevusala praktikat, samuti muid asjaolusid;

3.1.6. kahtluse korral tuleb väljendeid, millel võib olla rohkem kui üks tähendus, mõista viisil, mis

sobib kõige rohkem lepingu olemuse ja eesmärkidega;

3.1.7. lepingu tingimust tuleb tõlgendada koos lepingu teiste tingimustega, andes igaühele neist

tähenduse, mis lähtub lepingu kui terviku tähendusest ning poolte omavahelisest

praktikast;

3.1.8. lepingu tingimuste tõlgendamisel eelistatakse tõlgendust, mis muudab lepingu tingimuse

seaduslikuks või kehtivaks;

3.1.9. kui esineb vastuolu lepingu ja selle lisa vahel, siis lähtutakse tõlgendamisel lepingu lisast;

3.1.10. vastuolu korral lepingu ja / või selle lisade erinevate sätete vahel tühistab hilisem säte

varasema ning üld- ja erisätte vastuolu korral kohaldatakse erisätet;

3.1.11. pooled juhinduvad omavaheliste suhete reguleerimisel lepingust ning lepinguga

reguleerimata küsimustes Eesti Vabariigis kehtivatest õigusaktidest;

3.1.12. kui mõni lepingu säte osutub vastuolus olevaks Eesti Vabariigi seadustega või muude

kehtivate õigusaktidega, ei mõjuta see lepingu ülejäänud sätete kehtivust;

3.1.13. lepingu tõlgendamisel lähtutakse poolte ühisest tegelikust tahtest, isegi kui see erineb

sõnade tavapärasest tähendusest;

3.1.14. kui poolte ühist tegelikku tahet ei õnnestu kindlaks teha, tuleb lepingut tõlgendada nii,

nagu teise poolega samasugune mõistlik isik pidi lepingut samade asjaolude esinemise

korral mõistma;

3.1.15. ühegi poole mistahes viivitus, hoolimatus või keeldumine teist poolt lepingutingimuste

täitma sundimisel või muude nõuete esitamisel ei kujuta endast selle poole mistahes

lepingujärgsetest õigustest loobumist või nende tühistamist.

4. Raam- ja hankelepingute ulatus ja maht

4.1. Raamleping kehtib 48 kuud alates selle sõlmimisest või kuni raamlepingu eeldatava maksumuse

täitmiseni.

4.2. Raamlepingu eeldatav maksumus on 4 000 000 eurot (km-ta).

4.3. Raamlepingu alusel sõlmitud hankelepingu(te) kehtivus ei ole piiratud raamlepingu kehtivuse

lõpptähtpäevaga.

5. Raamlepingu täitmine

Juhul, kui raamleping sõlmitakse mitme täitjaga

5.1. Raamlepingu alusel tehakse tellimusi lähtudes raamlepingu täitjate poolt riigihankes esitatud

paremusjärjestusest. Raamlepingus on riigihankes paremusjärjestus esimene täitja 1, teine täitja 2

ning kolmas täitja 3.

5.2. Hankelepingute sõlmimiseks esitab Tellija kontaktisik riigihankes parima pakkumuse teinud

raamlepingu täitja kontaktisikule kirjalikku taasesitamist võimaldavas vormis (nt e-posti teel)

tellimuse esialgse raamlepingu sõlmimiseks esitatud pakkumuse täpsustamiseks. Tellimus

sisaldab pakkumuse täpsustamiseks vajaminevaid tingimusi:

5.2.1. kõiki sisulisi andmeid, mis on vajalikud tellimuse täitmiseks (tehniline kirjeldus; tööde

teostamise soovitav ajaperiood; eeldatav maksumus; juhul kui on tegemist

välisrahastusega, siis välja tuua nimetatu allikas. Kui tellimuses nõutud, esitab täitja

lähteülesandes kirjeldatud funktsionaalsuse/tööde detailseks analüüsiks,

realiseerimiseks, testimiseks ning dokumenteerimiseks kuluvat aega arendustundides;

infosüsteemiga seotud infosüsteemide tööks vajalike tarkvarakomponentide täienduste

kirjelduse; ajahinnangu kalendripäevades hinnapakkumuse aktsepteerimisest tellijale

tööde üleandmiseni; projektiplaani);

5.2.2. pakkumuse täpsustuse esitamise tähtaega;

5.2.3. pakkumuse täpsustuse jõusoleku minimaalset tähtaega;

5.2.4. pakkumuse täpsustuse esitamise kontakt e-posti aadressi.

5.3. Raamlepingu täitja esitab omapoolse pakkumuse täpsustuse vastavalt punktis 5.2 nimetatud

tellimuse saamisel lähtudes vastavas tellimuses märgitud andmetest või põhjenduse tellimuse

täitmise võimatuse kohta.

5.4. Tellija määratud tähtaeg pakkumuse täpsustuse esitamiseks ei tohi olla lühem kui 3 (kolm)

tööpäeva. Tähtaega hakatakse lugema tellimuse esitamisest järgmisest tööpäevast. Täitja on

pakkumuse täpsustuse esitanud tähtaegselt kui see on laekunud tellija kontakt e-posti aadressile

pakkumuse täpsustuse esitamise tähtpäeval.

5.5. Kui raamlepingu täitja pakkumuse täpsustust ei esita, teatab tellimuse täitmise võimatusest,

pakkumuse täpsustus ületab eeldatavat maksumust või pakkumuse täpsustus ei vasta tellimuses

kehtestatud tingimustele, esitab tellija tellimuse paremusjärjestuselt järgmisele pakkumuse teinud

raamlepingu täitjale.

5.6. Tellijal on õigus kõrvale kalduda tellimuse esitamise korrast ja pöörduda kohe paremusjärjestuselt

järgmise pakkumuse teinud raamlepingu täitja poole, kui:

5.6.1. Esimeses järjekorras raamlepingu täitja(d) on oluliselt rikkunud varasemat antud

raamlepingu alusel sõlmitud hankelepingu tingimust.

5.6.2. Esimeses järjekorras raamlepingu täitja(d) ei ole teostanud töid tähtaegselt ning tellimuse

esitamise hetkel on ta viivituses eelmiste tööde teostamisega

5.6.3. Esimeses järjekorras raamlepingu täitja(d) on teavitanud Tellijat, et täidab teisi tellimusi

mahus, mis ei võimalda tal uut tellimust täita.

5.7. Pakkumuse täpsustus aktsepteeritakse tellija poolt kui see vastab tellimuses kehtestatud tingimustele.

5.8. Tellijal on õigus jätta kirjalik hankeleping sõlmimata kuni 19 999,99 euro (ilma käibemaksuta) suuruste

tehingute korral.

5.9. Kirjaliku hankelepingu sõlmimata jätmisel loetakse hankelepinguks tellimus, aktsepteeritud

pakkumuse täpsustus ning hankelepingu projektides sisalduvad üldtingimused kogumina.

Hankelepingu lahutamatuteks osadeks on riigihanke alusdokumendid, raamleping koos lisadega,

üleandmise-vastuvõtmise aktid, pooltevahelised kirjalikud teated ning lepingu muudatused ja lisad.

5.10. Kirjalik hankeleping sõlmitakse alati 20 000 euro (ilma käibemaksuta) või suuremate tehingute korral.

Kirjalik hankeleping koosneb hankelepingu eritingimuste projektis toodud lisadest ja hankelepingu

lahutamatuks osaks nimetatud dokumentidest.

5.11. Pakkumise täpsustamiseks kulunud aega ei tasustata.

Juhul, kui raamleping sõlmitakse ühe täitjaga

5.1. Hankelepingute sõlmimiseks esitab tellija kontaktisik täitja kontaktisikule kirjalikku taasesitamist

võimaldavas vormis (nt e-posti teel) tellimuse esialgse raamlepingu sõlmimiseks esitatud pakkumuse

täpsustamiseks. Tellimus sisaldab pakkumuse täpsustamiseks vajaminevaid tingimusi:

5.1.1. kõiki sisulisi andmeid, mis on vajalikud tellimuse täitmiseks (tehniline kirjeldus; tööde

teostamise soovitav ajaperiood; eeldatav maksumus; juhul kui on tegemist

välisrahastusega, siis välja tuua nimetatu allikas. Kui tellimuses nõutud, esitab täitja

lähteülesandes kirjeldatud funktsionaalsuse/tööde detailseks analüüsiks,

realiseerimiseks, testimiseks ning dokumenteerimiseks kuluvat aega arendustundides;

infosüsteemiga seotud infosüsteemide tööks vajalike tarkvarakomponentide täienduste

kirjelduse; ajahinnangu kalendripäevades hinnapakkumuse aktsepteerimisest Tellijale

tööde üleandmiseni; projektiplaani);

5.1.2. pakkumuse täpsustuse esitamise tähtaega;

5.1.3. pakkumuse täpsustuse jõusoleku minimaalset tähtaega;

5.1.4. pakkumuse täpsustuse esitamise kontakt e-posti aadressi.

5.2. Täitja esitab omapoolse pakkumuse täpsustuse vastavalt punktis 5.1 nimetatud tellimuse saamisel

lähtudes vastavas tellimuses märgitud andmetest või põhjenduse tellimuse täitmise võimatuse kohta.

5.3. Pakkumuse täpsustus aktsepteeritakse tellija poolt kui see vastab tellimuses kehtestatud tingimustele

5.4. Tellijal on õigus jätta kirjalik hankeleping sõlmimata kuni 19 999,99 euro (ilma käibemaksuta) suuruste

tehingute korral.

5.5. Kirjaliku hankelepingu sõlmimata jätmisel loetakse hankelepinguks tellimus, aktsepteeritud pakkumuse

täpsustus ning hankelepingu projektides sisalduvad üldtingimused kogumina. Hankelepingu

lahutamatuteks osadeks on riigihanke alusdokumendid, raamleping koos lisadega, üleandmise-

vastuvõtmise aktid, pooltevahelised kirjalikud teated ning lepingu muudatused ja lisad.

5.6. Kirjalik hankeleping sõlmitakse alati 20 000 euro (ilma käibemaksuta) või suuremate tehingute korral.

Kirjalik hankeleping koosneb hankelepingu eritingimuste projektis toodud lisadest ja hankelepingu

lahutamatuks osaks nimetatud dokumentidest.

5.7. Pakkumise täpsustamiseks kulunud aega ei tasustata.

6. Muutumatud tingimused

6.1. Raamlepingu kehtivuse ajal kehtivad muutumatult raamlepingus ja hankelepingus sätestatud

tingimused. Muutumatult kehtivad ka raamlepingu sõlmimiseks esitatud pakkumuses märgitud

hankelepingu eseme ühikumaksumused.

6.2. Hankelepingu tingimused võivad erineda raamlepingu tingimustest ainult juhul, kui hankelepingu

tingimused on tellija jaoks raamlepingus sätestatud tingimustest soodsamad.

7. Raamlepingu rikkumine ja vastutus

7.1. Pooled vastutavad oma raamlepingust tulenevate kohustuste rikkumise eest iseseisvalt, välja

arvatud, kui rikkumine on vabandatav. Eeldatakse, et rikkumine ei ole vabandatav.

7.2. Kohustuse rikkumine on vabandatav, kui pool rikkus kohustust vääramatu jõu tõttu.

7.3. Pooled ei või oma lepingujärgseid kohustusi üle anda kolmandale isikule. 7.4. Täitja vastutab kõikide isikute eest, keda ta kasutab oma lepingujärgsete kohustuste täitmisel.

8. Raamlepingu ülesütlemine

8.1. Pooltel on õigus raamleping korraliselt üles öelda, järgides etteteatamistähtaega 60 (kuuskümmend)

kalendripäeva.

8.2. Registrite ja Infosüsteemide Keskusel on õigus raamleping erakorraliselt üles öelda ilma

etteteatamistähtajata järgmistel juhtudel:

8.2.1. täitja on oluliselt rikkunud raamlepingu alusel sõlmitud hankelepingut;

8.2.2. täitja on oma lepingujärgsed kohustused üle andnud kolmandale isikule.

8.3. Raamlepingu ülesütlemine ei mõjuta sõlmitud hankelepingute kehtivust. Täitjal ei teki tellija vastu

raamlepingu korralisest ülesütlemisest tekkinud kahju hüvitamise nõude esitamise õigust, nt

saamata jäänud tulu.

9. Lõppsätted

9.1. Raamlepingu tingimused on avalikud.

9.2. Raamlepingu muudatused vormistatakse kirjalikult raamlepingu lisana. Kontaktandmete

muutumisel teavitatakse teist poolt viivitamatult kirjalikku taasesitamist võimaldavas vormis.

9.3. Raamlepingu muutmine ei mõjuta sõlmitud hankelepingute tingimusi.

9.4. Raam- ja hankelepingute täitmise keel on eesti keel.

9.5. Raamlepinguga seotud vaidlused lahendatakse läbirääkimiste teel. Läbirääkimiste tulemusel

kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.

9.6. Leping allkirjastatakse digitaalselt.

Tellija Täitja

/digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/

Raamleping nr ..

Lisa nr 4

POOLTE VOLITATUD ESINDAJAD JA KONTAKTANDMED

Poolte volitatud esindajateks raamlepingu täitmisel on:

Pool Volitatud

esindaja nimi

Volitatud esindaja

ametikoht

Volitatud

esindaja

kontakttelefon Volitatud esindaja email

Tellija

Täitja

Täitja kontaktandmed tellimuste esitamiseks:

Täitja Kontaktisik, e-mail

Riigihanke „Kohtute infosüsteemi arendustööd“ (296052)

hankedokumentide juurde

Arendusleping nr ...

Arenduslepingu eritingimused

Tallinnas

Kaldkirjas tekst lisatakse juhul, kui leping on seotud Euroopa Liidu vahenditest rahastatava projektiga.

(punktiiri asemele viide konkreetsele rahastusallikale, SF projekti puhul kirja projekti täpne nimi).

Võttes arvesse perioodi 2021–2027 Euroopa Liidu ühtekuuluvus- ja siseturvalisuspoliitika fondide meetme

“Digiriik“ projekti „Kasutajakeskse Ametlike teadaannete süsteemi loomine“, mille kohaselt on vastava

projekti elluviija Justiitsministeerium ja partner Registrite ja Infosüsteemide Keskus:

Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310) asukohaga Lubja 4, 19081 Tallinn,

mida esindab põhimääruse alusel direktor Rivo Reitmann, edaspidi Tellija,

ja

………………. (registrikoodiga…………) asukohaga …………….., ……., mida esindab …………alusel

………, edaspidi Täitja,

keda nimetatakse edaspidi pool või koos pooled, sõlmisid käesoleva arenduslepingu (edaspidi nimetatud

Leping) alljärgnevas:

1. Lepingu sõlmimise alus ja ese

1.1. Kooskõlas riigihankega „Kohtute infosüsteemi arendustööd“ (viitenumber 296052) tulemusel

sõlmitud raamlepinguga nr …….. esitatud pakkumuse täpsustusele teostab täitja Lepingu lisas 3

kirjeldatud tööd ning täidab kõik muud Lepingust tulenevad kohustused (edaspidi ka Töö).

1.2. Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus,

seonduvates õigusaktides ning Perioodi 2021–2027 Euroopa Liidu ühtekuuluvus- ja

siseturvalisuspoliitika fondide rakendamise seaduses, Vabariigi Valitsuse määruses „Perioodi

2021–2027 Euroopa Liidu ühtekuuluvus- ja siseturvalisuspoliitika fondide rakenduskavade

vahendite andmise ja kasutamise üldised tingimused“ ja juhtrühma otsustes sätestatud tingimustel

ja mahus.

2. Hind ja maksetingimused

2.1. Lepingu hind on …………. eurot (netosumma), arvestusega, et arendustööde tunnihind on .....

eurot (netosumma).

2.2. Leping on …….. euro (netosumma) ulatuses rahastatud välisvahenditest ja …….. euro

(netosumma) ulatuses riigieelarvest. Muutes lepingut riigihangete seaduse § 123 alusel

täpsustatakse rahastuse allikas lepingu muudatuses.

2.3. Tellija tasub lepingu alusel teostatud tööde eest lepingu üldtingimustes sätestatud korras.

3. Lepingu jõustumine ja Töö teostamise tähtaeg

3.1. Leping jõustub allkirjastamise hetkest ja kehtib kuni lepingujärgsete kohustuste nõuetekohase

täitmiseni.

3.2. Töö teostamise tähtaeg on ……… arvates Lepingu jõustumise ajahetkest. /Märgitakse

etapiviisilise üleandmise korral viimase etapi üleandmise tähtaeg/.

4. Lepingu dokumendid

4.1. Lepingu dokumendid koosnevad Lepingu tekstist, Lepingu lisadest, mis on lisatud Lepingu

allkirjastamisel ja lisadest, millistes võidakse kokku leppida pärast Lepingu allkirjastamist.

Lepingu allkirjastamisel on Lepingu lisad järgmised:

4.1.1. Arenduslepingu üldtingimused Lisa nr 1;

4.1.2. Personal ja kontaktandmed Lisa nr 2;

4.1.3. Tehniline kirjeldus (Tellimus) Lisa nr 3;

4.1.4. Pakkumus (Pakkumuse täpsustus) Lisa nr 4;

4.1.5. Maksegraafik Lisa nr 5. /antud lisa eksisteerib juhul kui Töö eest tasumine toimub

mitmes osas/.

4.2. Kui Lepingu dokumendid on oma sisult vastuolulised ja/või nendes antud informatsioon erinevalt

tõlgendatav, siis dokumentide pädevusjärjekord (ülimuslik lepingu dokument on nimetatud

eespool allolevas loetelus) on järgmine:

4.2.1. Eritingimused;

4.2.2. Arenduslepingu üldtingimused;

4.2.3. Tehniline kirjeldus;

4.2.4. Muud riigihanke alusdokumendid;

4.2.5. Pakkumus.

Käesoleva Lepingu allakirjutamisega tõendavad pooled, et on tutvunud ja on nõus Lepinguga ja selle

lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende tagajärgi.

Tellija: Täitja:

/ allkirjastatud digitaalselt /

/ allkirjastatud digitaalselt /

Rivo Reitmann

Direktor

Registrite ja Infosüsteemide Keskus

Arendusleping nr. …………

Lisa nr 2

PERSONAL JA KONTAKTANDMED

1. Tellija esindaja ja kontaktisikud

1.1. Tellija esindajaks tööde vastuvõtmise aktide, teadete jms lepinguga seonduvate dokumentide

allkirjastamisel on Registrite ja Infosüsteemide Keskuse …………………. (tel ………….; e-post

…………….).

1.2. Tellija kontaktisikuks tööde teostamise juhendamisel ning Täitjale vajaliku lähteinformatsiooni ja

tööülesannete täpsustamisel jmt. on Registrite ja Infosüsteemide Keskuse ………… (tel …; e-post

…………………).

2. Täitja esindaja ja kontaktisikud

2.1 Täitja esindajaks on ………… (tel …………..; e-post………….).

2.2 Täitja kontaktisikuks on ………… (tel …………..; e-post………….).

3. Personali nimekiri

3.1. Tellija personal

Nr. Nimi Ametinimetus Kontaktandmed

3.2. Täitja personal

Nr. Nimi Ametinimetus Kontaktandmed

4. Kontaktandmed

4.1. Tellija kontaktandmed on: 4.2. Täitja kontaktandmed on:

Registrite ja Infosüsteemide Keskus …………….

Reg. nr. 70000310 Registrikood

Lubja tn 4 ……………

19081 TALLINN ……………

Telefon: 663 6300 Telefon: …………….

Arendusleping nr ……

Lisa nr 3

TEHNILINE KIRJELDUS KOOS LISADEGA

Tehniline kirjeldus asub arenduslepingu asice konteineris eraldi faili(de)na.

Arendusleping nr ………

Lisa nr 4

PAKKUMUS

Pakkumus asub arenduslepingu asice konteineris eraldi konteinerina.

Riigihanke „Kohtute infosüsteemi arendustööd“ (296052)

hankedokumentide juurde

ARENDUSLEPINGU ÜLDTINGIMUSED

Kui eritingimustes on sätestatud teisiti kui üldtingimustes, siis kehtib eritingimustes toodu.

1. Definitsioonid

Järgnevad definitsioonid laienevad nii lepingule kui ka selle osaks olevatele dokumentidele.

1.1 Tarkvara

Tarkvara tähendab põhiliselt arvutiprogramme, telekommunikatsioone, andmebaasi-, rakendus- ja

muud tarkvara objektikoodis, lähtekoodis või nende mistahes muid vorme või adaptsioone koos

sellega seonduva dokumentatsiooniga. Spetsiaalselt tellijale tema funktsioonide täitmiseks loodud

tarkvara käsitletakse lepingu raames spetsiaaltarkvarana.

1.2 Seadmed

Seadmed tähendavad lepingus kirjeldatud tooteid, hõlmates nendega otseselt seotud tarkvara, mis on

vajalik seadmete funktsioneerimiseks.

1.3 Telekommunikatsioonid

Telekommunikatsioonid tähendavad sisemise ja välise telekommunikatsiooni seadmeid, tarkvara ja

teenuseid ning vajalikke vahendeid, teenuseid ja protseduure.

1.4 Asukoht

Asukoht tähendab kohta või kohti, välja arvatud täitja asukoht, kuhu seadmeid, telekommunikatsioone

või tarkvara tarnitakse või installeeritakse või teenuseid osutatakse (nt tellija test- arendus-ja

toodangukeskkond).

1.5 Puudus ja viga

Puuduse või veaga on tegemist juhul, kui seade, telekommunikatsioon või tarkvara ei täida lepingus

sätestatud funktsioone, annab valesid tulemusi, kui tema nõuetekohane toimimine katkeb või on (muul

viisil) häiritud, nii et seadme, telekommunikatsiooni või tarkvara otstarbekohane kasutamine on

takistatud või oluliselt häiritud. Vigu liigitatakse järgnevalt:

1.5.1 Kriitiline/Blocker – viga, mille tõttu süsteemi tervikuna või mistahes süsteemi osa ei ole

võimalik kasutada ja/või see piirab sama süsteemi mistahes teise osa kasutamist.

1.5.2 Kõrge – viga, mille tõttu pole võimalik mingit süsteemi osa kasutada, kuid see ei sega

mõne teist sama süsteemi osa kasutamast.

1.5.3 Keskmine – viga, mille tõttu süsteemi või selle süsteemi mõnda osa on võimalik kasutada

piirangutega ja/või kasutajad peavad tegema mitte ettenähtud tegevusi eesmärgi

saavutamiseks (nt. funktsionaalsus lubab vigadega toiminguid lõpetada).

1.5.4 Madal – viga, mille tõttu süsteemis esineb kõrvalekaldeid ettenähtust, kuid üldprotsessi

need ei häiri või häirivad vähesel määral.

1.5.5 Väheoluline - viga, mille tõttu otseseid kõrvalekaldeid ei teki kuid vajavad

muutmist/parandamist.

1.6 Hooldus

Hooldus tähendab töid, mis tagavad seadmete, telekommunikatsioonide ja tarkvara (kaasa arvatud

nende juurde kuuluvate andmete ja andmebaaside) toimivuse (korrasoleku, terviklikkuse, jõudluse

jms). Hooldus sisaldab kaugtuge, vigade ennetamist ja parandamist, uute redaktsioonide ja

versioonide ning nendega seotud dokumentatsiooni üleandmist. Samuti hõlmab hooldus lepingus

sätestatud tingimustel seadmete, telekommunikatsioonide ja tarkvara kohandamist tellija vajadustele,

eeldusel, et see ei nõua olulist ümberprogrammeerimist ega uue toote loomist.

1.7 Arendustööd

Arendustööd tähendavad tarkvara funktsionaalsuse parandamise ja täiendamise ning teenuse

arendamisega seonduvaid töid. Arendustööd sisaldavad endas tehnilist konsultatsiooni, disainitööde

teostamist, süsteemi- ja detailanalüüsi läbiviimist, programmeerimistöid, testimist (sh automaattestid),

dokumentatsiooni koostamist ja vajadusel koolitusi.

1.8 Toodangukeskkond

Reaalseks andmevahetuseks mõeldud keskkond, mis ei ole test- või arenduskeskkond.

2. Hind

2.1 Lepingu hind sisaldab kõiki tolli- ja muid makse, kaasa arvatud käibemaks. Lepingu

eritingimustes märgitakse lepingu hind käibemaksuta (netosummas).

2.2 Lepingu hind väljendatakse eurodes.

2.3 Lepingu hind on täitja ainuke tasu seoses lepinguga ja täitja ise ega tema töötajad ei võta

päevarahasid, kaudset tasu ega muud lepingus toodud kohustustega seotud tasu. Samuti ei

ole täitjal ega tema töötajal õigust täiendavale autori- või muule sarnasele tasule seoses

lepingu täitmisel kasutatud patenteeritud või muul viisil kaitstud eseme või protsessiga.

3. Maksmine

3.1 Täitja esitab tellijale arve masinloetaval kujul e-arvena. Arve esitamise õigus tekib täitjal pärast

töö vastuvõtmist tellija poolt.

3.2 Arve peab sisaldama vähemalt alljärgnevaid andmeid:

3.2.1 info arve esitaja kohta;

3.2.2 info maksja kohta;

3.2.3 viide Lepingule;

3.2.4 käibemaksukohustuslase number;

3.2.5 vastuvõetud Töö nimetus ja kirjeldus;

3.2.6 käibemaks;

3.2.7 kogusumma;

3.3 Tellija tasub lepingu hinna täitja poolt esitatud arvel märgitud kuupäevaks. Maksetähtaeg ei tohi

olla lühem kui 30 kalendripäeva, va juhul kui tellija on nimetatut tehnilises kirjelduses (tellimuses)

ette näinud.

3.4 Ettemakseid tellija ei teosta.

3.5 Lõpparve maksmine eeldab täitja kõigi lepingu järgsete kohustuste täitmist ning tellija poolt

vastuvõtmist.

3.6 Tellijal on õigus lepingu rikkumise korral arvestatud leppetrahvid ja kahju hüvitised maha arvata

lepingu alusel täitjale tasumisele kuuluvatest summadest.

3.7 Tellija poolt makstud mistahes summa, mis ületab täitjale lepingus ettenähtu, maksab täitja

tellijale tagasi 30 kalendripäeva jooksul pärast vastava teate saamist.

3.8 Lepingujärgse hinna tasumisega viivitamisel on täitjal õigus nõuda viivist iga maksmisega

viivitatud kalendripäeva eest 0,15 (null koma viisteist) % maksmata summast päevas.

4. Informatsioon ja aruanded

4.1 Täitja loetakse asukohaga ja lepingu tingimustega tutvunuks. Eelkõige ei rahuldata täitja nõuet

lisamakseteks või ajapikenduseks, kui ta oleks saanud vajaliku informatsiooni hankida

visiidiga asukohta, konsulteerides tellijaga või muul sobilikul viisil.

4.2 Tellija varustab täitjat tema käsutuses oleva mistahes informatsiooni ja dokumentatsiooniga,

mis võib olla lepingu täitmisel oluline, niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva

jooksul vastava nõude saamisest.

4.3 Tellija abistab täitjat niipalju kui võimalik lepingusse puutuva informatsiooni saamisel, mida

täitja mõistlikkuse piirides lepingu täitmiseks nõuab.

4.4 Täitja annab tellijale niipea kui võimalik, kuid mitte hiljem kui 2 tööpäeva jooksul vastava

nõude saamisest, lepingu täitmist (sealhulgas seadmeid, telekommunikatsioone, tarkvara,

projekti kulgemist ja teenuseid) puudutavat informatsiooni.

4.5 Täitja kohustub vastavalt perioodi 2021–2027 Euroopa Liidu ühtekuuluvus- ja

siseturvalisuspoliitika fondide rakendamise seaduse § 25 lg-le 3 esitama kontrollija nõudel

projektiga seotud teavet ja dokumente, mis on vajalikud seaduse § 23 lõikes 1 nimetatud

asjaolude kontrollimiseks.

5. Teated ja kirjavahetus

5.1 Pooltevaheline suhtlus toimub selleks otstarbeks määratud poolte kontaktandmetel ja

aadressidel. Pooled on kohustatud kontaktandmete ja aadresside muutusest teineteist

teavitama viivitamatult, aga mitte hiljem kui 2 tööpäeva jooksul.

5.2 Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem

kui 2 tööpäeva jooksul.

5.3 Pooltevahelised lepinguga seotud teated peavad olema kirjalikku taasesitamist võimaldavas

vormis, välja arvatud juhtudel, kui teated on informatsioonilise iseloomuga, mille edastamisel

teisele poolele ei ole õiguslikke tagajärgi. Teade loetakse kättesaaduks, kui:

5.3.1 teade on üle antud allkirja vastu;

5.3.2 teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud

5 (viis) kalendripäeva;

5.3.3 e-posti või telefoni teel on teade edastatud lepingus märgitud kontaktisikule või esindajale.

6. Asukoht

6.1 Täitja peab andma lepingutäitmise käigus piisavalt informatsiooni korrektselt kirjalikku

taasesitamist võimaldavas vormis koostatud kasutusjuhendi näol, et võimaldada tellijal

asukoht lepingujärgsete kohustuste täitmiseks kohaselt ette valmistada. Juhend peab olema

antud sellise sisendiga, et objektiivselt keskmise võimekusega programmeerija oleks suuteline

asukoha töö vastuvõtmiseks vajalike testide teostamiseks ette valmistada. Juhend peab

olema esitatud piisava ajavaruga selleks, et tellijal oleks võimalik töö üleandmisel alustada

koheselt vastuvõtmiseks vajalike testide teostamist. Juhul, kui töö üleandmise hetkeks ei ole

juhendit edastatud või kui edastamisest hoolimata ei ole tellija asukohta ette valmistada

jõudnud, algab töö vastuvõtmiseks ette nähtud tähtaeg kulgema pärast asukoha ette

valmistamist. Kui täitja ei ole ette näinud erilisi keskkonnatingimusi, võib tellija eeldada, et neid

ei nõuta.

6.2 Tellija teeb vastavad ettevalmistused ja loob tingimused omal kulul.

6.3 Kui tellija ettevalmistused või loodud tingimused ei vasta lepingus sätestatule, esitab täitja

viivitamatult puuduste loetelu. Kui tellija ei muuda olukorda selliselt, et täitjal oleks võimalik

ajagraafikust kinni pidada, on täitjal õigus saada lepingujärgsete kohustuste täitmiseks

vajalikku ajapikendust.

6.4 Täitjal on õigus taotleda juurdepääsu asukohale tellija tavalisel tööajal.

6.5 Täitja kulud, mis on seotud lepingus sätestatud juurdepääsupiirangutega ja turvaprotseduuridega,

sisalduvad lepingu hinnas ning neid ei hüvitata.

6.6 Tellija võib igal ajal lepingu kehtivuse vältel muuta või kehtestada juurdepääsupiiranguid ja

turvaprotseduure. Kui täitja tõendab, et selline muudatuste tegemine või piirangute või

protseduuride kehtestamine põhjustas lisakulusid, on tal õigus nende hüvitamisele.

7. Lepingu muutmine

7.1 Lepingut võib muuta poolte kirjalikul kokkuleppel. Muudatused jõustuvad pärast nende

allkirjastamist mõlema poole poolt või poolte poolt määratud tähtajal. Kirjaliku vormi

mittejärgimisel on muudatused tühised.

7.2 Riigihangete seaduse § 123 lg 1 p 1 kirjeldatud muudatused lepitakse kokku tellija ja täitja

esindajate poolt kirjalikku taasesitamist võimaldavas vormis.

8. Poolte õiguskaitsevahendid

8.1 Lepingu see peatükk fikseerib Lepingu olulised rikkumised, menetluse rikkumisest teatamisel ning

poolte vastutuse. See peatükk ei välista ega piira poole õigust kasutada muude lepingu

rikkumiste korral muid õigusaktidest tulenevaid õiguskaitsevahendeid, samuti kasutada

täiendavaid õiguskaitsevahendeid lisaks selles peatükis kokkulepitule.

8.2 Lepingust või seadusest tuleneva õiguse või õiguskaitsevahendi mittekasutamine või selle

kasutamisega viivitamine ei tähenda nimetatud õigusest või õiguskaitsevahendist või muudest

õigustest või õiguskaitsevahenditest loobumist. Lepinguga seotud mis tahes loobumised on

kehtivad ainult siis, kui need on selgesõnaliselt ja kirjalikult väljendatud.

8.3 Pooled vastutavad lepinguga võetud kohustuste täitmata jätmise või mittekohase täitmise eest

Eesti Vabariigi õigusaktides ning lepingus ettenähtud korras.

8.4 Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi:

8.4.1 pool ei täida mis tahes lepingust tulenevat kohustust teise poole poolt lepingust tuleneva

vastava kohustuse täitmiseks antud täiendava tähtaja jooksul;

8.4.2 täitja ei täida garantiiperioodil lepingust tulenevaid kohustusi;

8.4.3 täitja ei ole esitanud tellijale asukoha keskkonnatingimusi, millest tulenevalt on häiritud

tellija seadmete, telekommunikatsioonide või tarkvara kohane funktsioneerimine ning

mistõttu tellija kaotab täitja lepingu järgsete kohustuste täitmise vastu huvi;

8.4.4 täitja rikkus kohustust tahtlikult või raske hooletuse tõttu;

8.4.5 täitja rikub personaliga seonduvaid tingimusi;

8.4.6 poolel või tema poolt kaasatud kolmandal isikul puuduvad lepingu täitmiseks vajalikud

õigused (sealhulgas load, litsentsid, Intellektuaalse omandi õigused);

8.4.7 täitja suhtes on algatatud pankrotimenetlus, pankrot on välja kuulutatud, täitja varad

arestitakse või täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see

halvenemine muudab vähetõenäoliseks lepingu nõuetekohase täitmise;

8.4.8 pool on rikkunud Intellektuaalse omandi õigusi ja nende kasutamise tingimusi;

8.4.9 pool on rikkunud konfidentsiaalsuskohustust ja/või isikuandmete töötlemisega seonduvaid

kohustusi;

8.4.10 pool on rikkunud avalikustamise keelu kohustust;

8.4.11 pool on rikkunud kolmandate isikutega seonduvaid kohustusi;

8.4.12 tellija on viivituses lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend (30)

kalendripäeva;

8.5 Poolel on õigus nõuda lepingu olulise rikkumise korral leppetrahvi tasumist kuni 30% Lepingu

hinnast iga vastava juhtumi korral. Juhul, kui leppetrahvi nõue on seotud töö etapi puuduliku

teostamisega ja puudus ei sea ohtu lepingujärgse töö tervikuna nõuetekohast üleandmist ei

tohi leppetrahvi nõue ületada 30% teostatud või töös oleva etapi maksumusest.

8.6 Poolte rahaline koguvastutus on piiratud lepingu maksumusega, välja arvatud juhul, kui pool

rikkus kohustust tahtlikult või raske hooletuse tõttu.

8.7 Pool peab teavitama teist poolt leppetrahvi nõudest mõistliku aja jooksul arvates ajast, mil ta sai

teada leppetrahvi nõudmise õiguse tekkimisest. Leppetrahvi nõude esitamisel on pool

kohustatud märkima mõistliku tähtaja leppetrahvi tasumiseks, tähtaeg ei tohi olla lühem kui 30

kalendripäeva. Pool on kohustatud leppetrahvi tasuma nõudes märgitud tähtaja jooksul. Kui

poole hinnangul on leppetrahvi nõue alusetu, on pool kohustatud esitama oma vastuväited

enne leppetrahvi tasumise tähtaega. Leppetrahvi nõudmine ei mõjuta poole õigust nõuda

poolelt nõuetekohase töö või selle osa teostamist ning kahju hüvitamist või kasutada muid

seadusest tulenevaid õiguskaitsevahendeid. Tellija käsitleb kahjuna ka projekti „......“

rakendamiseks antud toetuse tagasimakse hüvitamist olukorras, mil tagasimakse on tingitud

täitja tegevusest/ tegevusetusest.

8.8 Lisaks leppetrahvi nõudele ja / või leppetrahvi asemel on tellijal õigus nõuda täitjalt lepingu

mittenõuetekohasel täitmisel, et:

8.8.1 täitja kõrvaldaks puudused, sealhulgas nõuda, et täitja hangiks parema teenuse

osutamiseks vajalikud lisa- või asendusseadmed, -telekommunikatsioonid, -tarkvara ja

teenused;

8.8.2 oluliste puuduste, samuti puuduste kõrvaldamise ebaõnnestumise korral nõuda, et täitja

teeks uue töö ja tarniks uued seadmed, telekommunikatsioonid ja tarkvara või keelduda

vastuvõtmisest ning leping lõpetada;

8.8.3 võtta täitja pakutud töö vastu ning alandada vastavalt hinda;

8.9 Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta

lepingut rikkunud poolt Lepingujärgsete kohustuste täitmisest.

9. Standardid, liidesed ja ühilduvus

9.1 Täitja lepingujärgsete kohustuste täitmine ei tohi tekitada häireid tellija mistahes teiste liidestatud

süsteemide talitluses.

9.2 Täitja garanteerib, et kõik seadmed, telekommunikatsioonid, tarkvara ja teenused on vastastikku

ühilduvad, funktsioneerivad ja töötavad standardite ja/või liideste vahendusel rahuldavalt koos

mistahes teiste lepingus sätestatud seadmete, telekommunikatsioonide, tarkvara ja

teenustega ning lepingus sätestatud keskkonnas.

9.3 Täitja ei muuda ilma tellija eelneva kirjaliku nõusolekuta mistahes standardeid, liideseid,

sideprotokolle jms.

10. Dokumentatsioon

10.1 Lepingu täitmisel kaasneva dokumentatsiooni loomisel toetutakse dokumentatsiooniplaanile.

10.2 Täitja varustab tellijat piisava ja adekvaatse dokumentatsiooniga, kaasa arvatud informatsioon

seadmete, telekommunikatsioonide ja tarkvara projekteerimise ja funktsioneerimise kohta, mis

on vajalik, et tellija saaks seadmeid, telekommunikatsioone, tarkvara ja teenuseid efektiivselt

kasutada, hooldada, kohandada ja neile lisaseadmeid lisada.

10.3 Kõik juhendid ja muud dokumendid esitatakse eesti keeles, kui ei ole kokku lepitud teisiti.

10.4 Dokumentatsioon peab vastama tootele, sisaldama muudatusi ja olema terminoloogiliselt üheselt

mõistetav.

10.5 Dokumentide valmistamiseks ja levitamiseks kasutatakse paberkandjat või elektroonilist

infokandjat.

11. Üleandmine ja vastuvõtmine

11.1 Töö või töö etapi valmimise järgselt annab täitja selle tellijale üle vastuvõtmiseks.

11.2 Täitja peab tellijat töö või töö etapi üle andmise viivitusest või viivitusse sattumise ohust ja

põhjustest koheselt kirjalikku taasesitamist võimaldavas vormis informeerima. Kui täitja

viivituse põhjustab tellija, on täitjal õigus nõuda mõistlikku ajapikendust ja põhjendatud

lisakulude hüvitamist.

11.3 Töö või töö etapi üleandmise kohta koostab täitja üleandmise akti, milles näidatakse muuhulgas

ära üleandmise kuupäev, teostatud töö, osutatud teenuste, hoolduse ja tarnitud seadmete,

telekommunikatsioonide ja tarkvara detailiseeritud nimekiri ning vajaduse korral neis esinevad

puudused. Iga töö etapi üleandmisel koostab ja esitab täitja antud etapi kohta koostatud

dokumentatsiooni, vastavalt dokumentatsiooniplaanile või tellija poolt tehnilises kirjelduses

esitatud nõudmistele.

11.4 Töö või töö etapi üleandmine tellijale ei ole käsitatav selle vastuvõtmisena tellija poolt.

11.5 Täitjal on õigus nõuda ja tellijal kohustus töö vatsu võtta kui töös on täitja poolt kõrvaldatud kõik

järgmise prioriteediga vead: kriitiline/blocker, kõrge ja keskmine. Taolisel juhul lasub täitjal

kohustus vaegtöödena madala ja väheolulise tähtsusega vead parandada töö vastuvõtmise

aktis toodud ajaperioodiks.

11.6 Pärast töö etapi üleandmist on tellijal õigus töö üle vaadata 10 tööpäeva jooksul. Pärast töö

üleandmist on tellijal õigus töö üle vaadata 20 tööpäeva jooksul. Tellija võib tehnilises

kirjelduses (tellimuses) ette näha töö üle vaatamisele käesolevast erinevad tähtajad.

11.7 Juhul, kui tellija leiab, et töö ei vasta lepingu tingimustele, on tellija kohustatud teavitama täitjat

töös avastatud puudustest, keeldumisest tööd enne puuduste kõrvaldamist vastu võtta ja

kirjeldama töö puudused. Täitja on kohustatud puudused kõrvaldama 5 tööpäeva jooksul, kui

pooled ei ole kokku leppinud mõnda muud tähtaega. Kui tellija näeb töö üle vaatamisel ette

käesolevatest üldtingimustest erineva tähtaja, täpsustab tellija tehnilises kirjelduses

(tellimuses) puuduste kõrvaldamiseks antava tähtaja. Töö puuduste kõrvaldamise kulud

kannab Täitja.

11.8 Enne töö üleandmist viib täitja töö nõuetelevastavuse kindlakstegemiseks läbi testid.

11.9 Täitja esitab tellijale kõik tema poolt läbiviidud testide tulemusena valminud dokumentide

koopiad.

11.10 Enne töö vastuvõtmist viib tellija töö nõuetelevastavuse kindlakstegemiseks läbi testid.

11.11 Kui töö või mistahes töö osa ei läbi teste, viiakse otsekohe pärast seda, kui täitja on teinud

vajalikud korrektuurid testide edukaks läbiviimiseks, läbi kordustestid samadel tingimustel.

11.12 Tellija nõudmisel viib kordustestid läbi täitja.

11.13 Parandatud töö üleandmine toimub nagu esmakordsel üleandmiselgi.

11.14 Puudustega üle antud tööd ei loeta tähtaegselt üleantuks ning tellijal on õigus nõuda sellise

lepingurikkumise korral täitjalt leppetrahvi lepingus sätestatud korras ja määrades või

rakendada muid õiguskaitsevahendeid.

11.15 Vastuvõtmiseks valmis töö peab vastama lepingus sätestatud tingimustele. Töö etapi

vastuvõtmine tellija poolt ei tingi ega kohusta töö kui terviku vastuvõtmist tellija poolt juhul, kui

töö ei vasta tingimustele. Töö vastuvõtmise kohta koostab tellija vastuvõtuakti, milles

näidatakse muuhulgas ära vastuvõtmise kuupäev, teostatud töö, osutatud teenuste, hoolduse

ja tarnitud seadmete, telekommunikatsioonide ja tarkvara detailiseeritud nimekiri.

11.16 Töö või töö etapp loetakse vastuvõetuks vastuvõtuakti allkirjastamisest või

toodangukeskkonnas kasutusele võtmisest. Juhul, kui tellija on võtnud puuduseid sisaldava

töö või töö etapi toodangukeskkonnas kasutusele, loetakse vastuvõetuks ainult

nõuetekohaselt teostatud tööd ja täitjal on õigus nimetatute osas esitada arve. Taolises

olukorras esitab tellija täitjale töös või töö etapis esinevate puuduste nimekirja ning puuduste

kõrvaldamise tähtaja, kas enne töö või töö etapi toodangukeskkonnas kasutusele võtmist või

vahetult pärast selle toimumist.

11.17 Mistahes seadmete, telekommunikatsioonide, tarkvara ja teenuste osa valmimisel võib tellija

anda välja vastuvõtuakti vastava osa kohta. Selline vastuvõtmine ei mõjuta täitja kohustust

täita kõiki Lepingus ettenähtud kohustusi.

11.18 Täitja vastutab töö juhusliku hävimise või kahjustumise eest kuni töö vastuvõtmiseni tellija

poolt.

Lisatakse vajadusel:

11.19 Täitja kohustub tellija juhendamisel märgistama töö enne selle üleandmist vastavalt

õigusaktides kehtestatud nõuetele (hankelepingu sõlmimisel märgitakse konkreetne viide, nt

Vabariigi Valitsuse 12.05.2022. a määrusele nr 54 „Perioodi 2021–2027 ühtekuuluvus- ja

siseturvalisuspoliitika fondide vahendite andmisest avalikkuse teavitamine“).

ja

11.20. Tellija kinnitab, et ta on teadlik asjaolust, et projekti „……….“ rakendamiseks antud toetuse

saamiseks peab töö vastuvõtmine olema fikseeritud vastuvõtmisaktis ning kinnitatud juhtrühma poolt.

12. Koolitus

12.1 Täitja tagab tellija personalile adekvaatse väljaõppe, kindlustamaks seadmete,

telekommunikatsioonide, tarkvara ja teenuste rahuldava ja efektiivse toimimise, vastavalt

lepingus kokkulepitule.

12.2 Koolituse toimumise aeg, koht ja maht kooskõlastatakse eelnevalt tellija kontaktisikuga.

13. Garantii

13.1 Täitja annab tööle …….. kuulise töövõtugarantii. Garantiiperiood algab tööde kogumina

vastuvõtmisest.

13.2 Garantiiperioodil ilmnevad puudused kõrvaldab täitja omal kulul, v.a punktis 13.6 toodud

juhtumitel. Kui ilmnenud puudused ei ole garantii korras kõrvaldatavad, esitab täitja tellijale

põhjendused kirjalikku taasesitamist võimaldavas vormis, kuid mitte hiljem kui järgmisel

tööpäeval pärast sellest asjaolust teada saamist.

13.3 Kui ei ole kokku lepitud teisiti, toimub garantiiliste puuduste üleandmine ja vastuvõtmine lepingu

punktis 11 toodud regulatsiooni kohaselt.

13.4 Juhul kui garantiiperioodil ilmnenud puudused muudavad osa või kõik seadmed,

telekommunikatsioonid ja/või tarkvara kasutamiskõlbmatuks, varustab täitja tellijat nõutud

tasemel toimimise garanteerivate lisa- või asendusosade ja muu vajalikuga omal kulul.

13.5 Tellija informeerib täitjat puuduse iseloomust ja ulatusest otsekohe selle ilmnemisel. Täitja on

kohustatud eemaldama ilmnenud puudused vastavalt lepingus toodule või tellija poolt

määratud ajal.

13.6 Garantiiga ei ole hõlmatud:

13.6.1 puudused, mille tekkimise eest vastutab tellija;

13.6.2 diagnostikaks kulunud aeg, juhul kui algselt garantii juhtumine registreeritud juhtumi

raames tuvastatakse, et tegu ei ole garantiilise juhtumiga. Vastav töö kuulub eraldi

tasustamisele lepingu tunnihinna alusel.

13.7 Garantii kaotab kehtivuse kui täitjaga kooskõlastamata on muudetud või muudetakse lähtekoodi,

v.a juhul kui tellija suudab eristada lähtekoodis tehtavaid muudatusi.

14. Load ja litsentsid

14.1 Täitja vastutab ainuisikuliselt lepingu täitmiseks vajalike lubade ja litsentside saamise eest. Tellija

teeb täitjaga mõistliku koostööd, hoidmaks ära selliste lubade või litsentside väljaandmise

asjatut viivitamist või väljaandmisest keeldumist.

14.2 Tellija võib ilma ette teatamata lepingu lõpetada, kui täitja ei saa lepingu täitmiseks vajalikku luba

või litsentsi.

14.3 Täitja garanteerib, et tal on õigus anda tellijale lepingu objektiks oleva tarkvara ja teiste autori- või

muude sarnaste õigustega kaitstavate esemete kasutamisõigus.

14.4 Täitja garanteerib, et nimetatud kasutusõiguse üleandmisega ei rikuta kolmandate isikute õigusi.

Juhul kui kolmas isik esitab oma õiguste rikkumise tõttu tellija vastu hagi ning see

rahuldatakse, tasub täitja võimalikud kahjuhüvitusnõuded, samuti õigusabikulud ja muud

seonduvad kulud.

15. Riski üleminek

15.1 Juhusliku hävimise või kahjustumise risk läheb tellijale üle töö vastuvõtmisel, samuti hetkel, mil

tellija satub viivitusse toimingu tegemisega, millega ta töö üleandmisele peab kaasa aitama.

16. Intellektuaalne vara

16.1 Lepingu allkirjastamisega kinnitab täitja tellijale, et talle kuuluvad lepingu täitmiseks vajalikud

varalised autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on tarvilikud

lepingu järgse töö täielikuks teostamiseks ja loovutamiseks ning, et nende suhtes ei ole

kolmandatel isikutel nõudeid.

16.2 Täitja kinnitab, et ta on võtnud tarvitusele kõik meetmed autori isiklike õiguste realiseerimiseks

viisil, mis ei takista ega raskenda teose kasutamist ja autori varaliste õiguste teostamist tellija

poolt.

16.3 Täitja annab spetsiaaltarkvarale Euroopa Liidu tarkvara vaba kasutuse litsentsi v.1.1 (EUPL).

Juhul, kui töö üleandmine toimub etapiviisiliselt, siis loetakse litsents antuks iga etapi (teose)

vastuvõtmisel tellija poolt.

16.4 Tellijal on muuhulgas õigus spetsiaaltarkvara (teose) autoriõiguste kehtivusaja jooksul:

16.4.1 teost kasutada mis tahes eesmärgil ja mis tahes viisil;

16.4.2 teost reprodutseerida;

16.4.3 originaalteost muuta ja luua teosel põhinevaid tuletatud teoseid;

16.4.4 teost või selle koopiaid üldsusele edastada, sealhulgas neid kättesaadavaks teha või

eksponeerida, samuti avalikult esitada;

16.4.5 teost või selle koopiaid levitada;

16.4.6 teost või selle koopiaid laenutada ja rentida;

16.4.7 anda all-litsentse teose või selle koopiate suhtes kehtivate õiguste kohta.

16.5 Täitja annab tellijale spetsiaaltarkvara lähtekoodi, täitmiskoodi ja dokumentatsiooni kujul, mis

võimaldab tellijal sellest aru saada.

16.6 Tellija võib levitada lähtekoodi ja täitmiskoodi ning dokumentatsiooni ja selle muudatusi mistahes

kolmandatele isikutele ja asutustele.

16.7 Kõik täitja poolt lepingu täitmise käigus koostatud dokumendid ja andmed kuuluvad tellijale. Täitja

annab kõik nimetatud dokumendid ja andmed tellijale üle.

16.8 Tellija võib spetsiaaltarkvara autoriõigusi teostada mistahes olemasolevas või hiljem loodud

keskkonnas, toel või formaadis.

16.9 Täitja tagab, et tema töötajad on loobunud Eesti seadusega lubatud ulatuses oma õigusest

teostada isiklikke õigusi, et tellijale oleks võimalik vajalikke varalisi õigusi litsentsida.

16.10 Lepingujärgse tarkvarasüsteemi loomiseks kolmandatele isikutele kuuluvate komponentide

(tarkvara) kasutamise osas juhinduvad pooled nende kasutamise litsentsitingimustest. Täitja

kinnitab, et eelistab tarkvara loomisel selliseid kolmandatele isikutele kuuluvaid komponente,

mille kasutamisega ei kaasne täiendavaid litsentsitasusid ega piiranguid tarkvara kasutamisel

või alllitsentside andmisel. Täitja on kohustatud tellijat teavitama juhul, kui täitja plaanib

tarkvara loomisel kasutada selliseid kolmandatele isikutele kuuluvaid komponente, mille

kasutamine toob tellijale kaasa täiendavaid litsentsitasusid või piiranguid tarkvara kasutamisel.

Ilma tellija kirjaliku nõusolekuta ei tohi täitja tarkvara loomisel nimetatud komponente

kasutada.

16.11 Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende kehtivuse

territooriumiks on kogu maailm.

17 Personal

17.1 Lepingus kirjeldatud teenuseid osutavad lepingus nimetatud isikud vastavalt lepingus

sätestatud ülesannetele. Muudatusi tohib teha vaid tellija kirjalikku taasesitamist võimaldavas

vormis antud nõusolekul.

17.2 Täitja asendab töid teostava isiku viivitamatult lepingu objekti täitmise seisukohast võrdväärse

kvalifikatsiooni ja kogemustega ning tellijale vastuvõetava isikuga, kui:

17.2.1 töid teostav isik ei ole võimeline teenuste osutamist jätkama haiguse, õnnetusjuhtumi või

muu temast tuleneva põhjuse tõttu;

17.2.2 lepingus 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 lepingu korrektset ja õigeaegset

täitmist.

17.2.3 isikul on kuriteo toimepanemise eest määratud kehtiv karistus.

17.3 Täitja kannab kõik punktis 17.2 nimetatud asendusest tulenevad või sellega kaasnevad kulud.

17.4 Töid teostavatel isikutel ei tohi olla kuriteo toimepanemise eest määratud kehtivat karistust.

17.5 Töid teostavad isikud ei tohi olla tellija töötajad ega tellija töötajaga seotud juriidilised isikud.

Seotud juriidiline isik tähendab käesoleva lepingu mõistes juriidilist isikut, mille juhtumis- või

kontrollorgani liige tellija töötaja on või juriidiline isik, milles vähemalt 1/10 osalusest kuulub

tellija töötajale.

18 Kolmandad isikud

18.1 Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled

on kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima.

18.2 Pooled ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma

lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma teise poole sellekohase

selgesõnalise kirjaliku nõusolekuta.Tellijal on õigus edastada või suunata täitja poolt esitatud

arve tasumisele tellijast erinevale hankijale nendevahelise koostöökokkuleppest tuleneval

alusel juhul kui vastavasisuline teavitus on tellija poolt pakkumuse esitamise ettepanekus

kajastatud.

18.3 Pooled vastutavad kõigi isikute eest, keda nad kasutavad oma lepingujärgsete kohustuste

täitmisel.

19 Auditeerimine

19.1 Mõlemal poolel on õigus kaasata auditeerimiseks sõltumatu audiitor. Audiitori kaasamiseks ei

ole vajalik teise poole luba.

19.2 Audiitori isik ja muu auditeerimisega seotud asjaolud sätestatakse eraldi kokkuleppes.

Auditeerimise käigus avastatud probleemid tuleb registreerida ja vajaduse korral sisestada

probleemide lahendamise protsessi.

19.3 Täitja peab täpset arvestust lepingu täitmisel töötatud kalendripäevade ja –kuude

kompenseerimisele kuuluvate kulude kohta. Audiitorile võimaldatakse piiramatu ligipääs

nimetatud andmetele.

19.4 Audiitorit kaasanud pool tagab, et audiitor käsitleb saadud informatsiooni konfidentsiaalsena.

Vastutus jääb audiitorit kaasanud poolele.

19.5 Pärast andmete auditeerimist ja kontrollimist teeb audiitor järeldusotsuse, mis on lõplik.

19.6 Auditi kulud kannab auditi tellinud pool.

20 Õigustest loobumine

20.1 Kummagi poole mistahes viivitus, hoolimatus või keeldumine teist poolt lepingutingimuste

täitmise nõudmisel või muude nõuete esitamisel ei kujuta endast selle poole mistahes

lepingujärgsetest õigustest loobumist või nende tühistamist.

21 Konfidentsiaalsus ja isikuandmed

21.1 Täitja ei või oma lepingujärgseid kohustusi anda üle kolmandale isikule ega kaasata oma

lepingujärgsete kohustuste täitmiseks kolmandat isikut ilma tellija sellekohase selgesõnalise

kirjaliku nõusolekuta.

21.2 Täitja on kohustatud:

21.2.1 tagama lepingu täitmise käigus tellijalt ükskõik mis vormis saadud teabe (andmed,

tehingudokumentatsioonis ja lepingutes sisalduvad tellija esindajate isikuandmed, know-

how) konfidentsiaalsuse ning ei edasta ega võimalda sellele teabele juurdepääsu

kolmandale isikule ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta;

21.2.2 tagama lepingueelsete läbirääkimiste, lepingujärgsete kohustuste ja lepingu täitmise käigus

ükskõik mis vormis teatavaks saanud isikuandmete (v.a. tehingudokumentatsioonis ja

lepingutes sisalduvate Tellija esindajate isikuandmete) konfidentsiaalsuse ning ei edasta

ega võimalda nendele juurdepääsu ühelegi kolmandale isikule ilma tellija sellekohase

selgesõnalise kirjaliku nõusolekuta;

21.2.3 ei edasta punktis 21.2.2 nimetatud isikuandmeid väljapoole Euroopa Liidu liikmesriikide ja

Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma tellija sellekohase

selgesõnalise kirjaliku nõusolekuta;

21.2.4 kasutama ja töötlema punktis 21.2.2. nimetatud isikuandmeid üksnes lepingu täitmiseks ja

tellija dokumenteeritud juhiste alusel, välja arvatud juhul, kui täitja on kohustatud teavet

töötlema täitja suhtes kohalduva õiguse alusel. Viimati nimetatud juhul teavitab täitja tellijat

vastava kohustuse olemasolust enne teabe töötlemist, kui selline teavitamine ei ole olulise

avaliku huvi tõttu täitja suhtes kohalduva õigusega keelatud;

21.2.5 võimaldab juurdepääsu punktis 21.2.2. nimetatud isikuandmetele ainult nendele isikutele,

kellel on selleks oma tööülesannete täitmiseks vajadus ning tagab, et need isikud on

teadlikud ning järgivad isikuandmete töötlemisalaseid nõudeid ja õigusakte, nad on saanud

asjakohase koolituse eelmainitud nõuete kohta, on võtnud endale

konfidentsiaalsuskohustuse või neile kehtib asjakohane seadusest tulenev

konfidentsiaalsuskohustus. Vastav konfidentsiaalsuskohustus jääb kehtima pärast

käesoleva lepingu lõppemist;

21.2.6 kohustub täitma kõiki kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust

puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte ja

muid eeskirju.

21.2.7 kohustub rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid

punktis 21.2.2. nimetatud isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise;

juhusliku hävimise ja tahtliku hävitamise eest ning õigustatud isikule andmete

kättesaadavuse takistamise eest, volitamata töötlemise s.h. avalikustamise eest:

a) vältima kõrvaliste isikute ligipääsu isikuandmete töötlemiseks kasutatavatele

seadmetele;

b) ära hoidma andmete omavolilist lugemist, kopeerimist ja muutmist

andmetöötlussüsteemis, samuti andmekandjate omavolilist teisaldamist;

c) ära hoidma isikuandmete omavolilist salvestamist, muutmist ja kustutamist ning

tagama, et tagantjärele oleks võimalik kindlaks teha, millal, kelle poolt ja milliseid

isikuandmeid salvestati, muudeti või kustutati või millal, kelle poolt ja millistele

isikuandmetele andmetöötlussüsteemis juurdepääs saadi;

d) tagama, et igal andmetöötlussüsteemi kasutajal oleks juurdepääs ainult temale

töötlemiseks lubatud isikuandmetele ja temale lubatud andmetöötluseks;

e) tagama andmete olemasolu isikuandmete edastamise kohta: millal, kellele ja millised

isikuandmed edastati, samuti selliste andmete muutusteta säilimise;

f) tagama, et isikuandmete edastamisel andmesidevahenditega ja andmekandjate

transportimisel ei toimuks isikuandmete omavolilist lugemist, kopeerimist, muutmist või

kustutamist;

g) pidama arvestust isikuandmete töötlemisel kasutatavate tema kontrolli all olevate

seadmete ja tarkvara üle, dokumenteerides järgmised andmed:

i. seadme nimetus, tüüp ja asukoht ning seadme valmistaja nimi;

ii. tarkvara nimetus, versioon, valmistaja nimi ja kontaktandmed.

21.2.8 teavitama tellijat toimunud või põhjendatult kahtlustatavast käesoleva lepingu punktis

21.2.1 ja/või 21.2.2 sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 21.2.7. ja

selle alapunktides a-g sätestatud turvameetmete rikkumisest, mis põhjustab, on

põhjustanud või võib põhjustada edastatavate, salvestatud või muul viisil töödeldavate

isikuandmete juhusliku või ebaseadusliku hävitamise, kaotsimineku, muutmise või loata

avalikustamise või neile juurdepääsu, kirjalikult viivitamata aga mitte hiljem kui

kakskümmend neli (24) tundi pärast sellest teada saamist. Teates tuleb vähemalt:

a) kirjeldada (Isikuandmetega seotud) rikkumise laadi, sealhulgas puudutatud

andmesubjektide liike ja arvu ning puudutatud kirjete liike ja arvu;

b) teatada andmekaitse töötaja ja tema kontaktandmed või muu kontaktpunkt, kust saab

lisateavet;

c) soovitada meetmeid (Isikuandmetega seotud) rikkumise võimalike negatiivsete

mõjude leevendamiseks;

d) kirjeldada (Isikuandmetega seotud) rikkumise tõttu andmesubjektidele tekkivaid

tagajärgi ja potentsiaalseid ohte;

e) kirjeldada täitja/või kolmandast isikust alltöötleja poolt välja pakutud või võetud

meetmeid (Isikuandmetega seotud) rikkumisega tegelemiseks ja

f) esitada muud teavet, mis on mõistlikult nõutav, et tellija saaks täita kohaldatavaid

andmekaitse õigusakte, sealhulgas riigiasutustega seotud teavitamise ja avaldamise

kohustusi, näiteks teavet, mis on nõutav andmesubjekti tuvastamiseks.

21.2.9 tellija eelnevalt kirjalikul heakskiidul lõpetama käesoleva lepingu punktis 21.2.8.nimetatud

rikkumise ning kohaldama meetmeid (isikuandmetega seotud) rikkumise lahendamiseks,

sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja

leevendamiseks;

21.2.10 kohustub lepingu lõppemisel kustutama kõik punktis 21.2.2. nimetatud isikuandmed ja

nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti;

21.2.11 teeb tellijale kättesaadavaks kogu teabe, mida tellija peab vajalikuks lepingus sätestatud

kohustuste täitmise tõendamiseks;

21.2.12 võimaldab tellijal või tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning panustab

nendesse;

21.2.13 kohustub võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil punktis

21.2.2. nimetatud isikuandmete osas tellijal täita tellija kohustust vastata taotlustele

andmesubjekti õiguste teostamiseks ning teostada nende õiguste teostamisest tulenevaid

toiminguid (andmete parandamine, sulgemine, kustutamine).

21.3 Käesoleva lepingu punktis 21.2.1. sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni

avaldamisele täitja audiitorile ja advokaadile.

21.4 Käesoleva lepingu punktides 21.2.1. ja 21.2.2. sätestatud konfidentsiaalsuskohustuse nõue on

tähtajatu ning kehtib nii lepingu täitmise ajal kui ka pärast lepingu lõppemist.

21.5 Tulenevalt konfidentsiaalse informatsiooni laadist on tellijal õigus seada täiendavaid nõuded

ja/või juhised isikuandmete töötlemiseks.

21.6 Kõik käesoleva lepingu punktides 21.2.1. – 21.4 kohustused kehtestab täitja kõikidele

kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. Kolmas isik

on füüsiline või juriidiline isik või riigi- või kohaliku omavalitsuse asutus, kes ei ole ei tellija ega

ka täitja.

22 Avalikud suhted

22.1 Pooled ei tegele seoses lepinguga avalike suhetega ega anna teateid pressile, elektroonilisele

meediale, üldsusele või teistele auditooriumidele, välja arvatud teise poole eelneval kirjalikul

nõusolekul. Avaldada võib vaid teateid, mis on teise poolega eelnevalt kooskõlastatud.

22.2 Kõik eelnimetatud kohustused kehtestab pool ka kõigile kolmandatele isikutele, keda ta

kasutab oma lepingujärgsete kohustuste täitmisel.

23 Lepingu täitmise peatamine ja lepingu lõpetamine

23.1 Tellija võib peatada täitjale lepingujärgselt makstavate summade maksmise kas osaliselt või

täielikult, kui:

23.1.1 täitja ei täida lepingut;

23.1.2 vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid täitja

poolseid kohustuste rikkumisi;

23.1.3 tellija lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab

segada muu asjaolu, mille eest vastutab täitja.

23.2 Täitja võib peatada tellijale teenuse osutamise kas osaliselt või täielikult, kui:

23.2.1 tellija ei täida lepingut;

23.2.2 täitja lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab

segada muu asjaolu, mille eest vastutab tellija.

23.3 Tellija võib igal ajal lepingu üles öelda, teatades sellest 1 (üks) kuu ette. Sellisel juhul on täitjal

õigus nõuda tasu täidetud kohustuste eest.

23.4 Tellijal on õigus leping erakorraliselt etteteatamata lõpetada täitjapoolse olulise lepingu

rikkumise korral. Lepingu lõpetamisel punktides 8.4 nimetatud juhtudel täitja tehtud tööd ei

tasustata. Täitja poolt tarnitud seadmed, telekommunikatsioonid ja tarkvara tagastatakse, selle

võimatuse korral või muul juhul, kui tagastamine on saadu olemuse tõttu välistatud, makstakse

hüvitust võlaõigusseaduses sätestatud korras.

23.5 Täitja võib lepingu üles öelda tellijapoolse olulise lepingu rikkumise korral pärast vastava

hoiatuse saatmist, kui rikkumist ei ole kõrvaldatud 10 (kümne) tööpäeva jooksul peale

hoiatuse esitamist. Sellise lepingu lõpetamise korral maksab tellija täitjale tasu täidetud

kohustuste eest.

23.6 Lepingu lõppemisel on täitja kohustatud tellijale tagastama kõik lepingu täitmiseks üleantu.

24 Vääramatu jõud

24.1 Lepingust tulenevate kohustuste mittetäitmist või mittenõuetekohast täitmist ei loeta lepingu

rikkumiseks, kui selle põhjuseks oli vääramatu jõud. Vääramatu jõuna käsitlevad pooled

võlaõigusseaduse §-s 103 lg 2 nimetatud asjaolusid.

24.2 Pool, kelle tegevus lepingujärgsete kohustuste täitmisel on takistatud vääramatu jõu asjaolude

tõttu, on kohustatud sellest koheselt kirjalikult teatama teisele poolele, esitades teavitusega

ühes tõendid kõigi järgnevate asjaolude esinemise kohta:

24.2.1 takistava asjaolu esinemine, mis takistab kohustuse kohast täitmist;

24.2.2 takistava asjaolu asetsemine väljaspool võlgniku mõjusfääri;

24.2.3 asjaolu ettenägematus;

24.2.4 asjaolu vältimatus ja ületamatus.

24.3 Vääramatu jõu asjaolude ilmnemisel pikeneb lepingu lõpptähtaeg nimetatud asjaolude

esinemise perioodi võrra. Pool peab vääramatu jõu asjaolude äralangemisel lepingut täitma

asuma. Kui vääramatu jõu asjaolude tõttu on poole lepingust tulenevate kohustuste täitmine

takistatud enam kui 60ne kalendripäeva võrra võib teine pool öelda lepingu üles.

25 Kehtiv seadusandlus

Lepingule ning kõikidele lepingu osaks olevatele dokumentidele kohaldatakse Eesti Vabariigi

õigusakte.

26 Vaidluste lahendamine

26.1 Käesoleva lepingu allkirjastamisega kinnitavad pooled, et on tutvunud ja on nõus lepinguga ja

selle lisadega ning mõistavad täielikult enesele võetavate kohustuste sisu ning nende

tagajärgi.

26.2 Lepinguga seotud või sellest tulenevate arusaamatuste või vaidluste puhul püüavad pooled

leida lahenduse heal tahtel põhinevate läbirääkimiste teel.

26.3 Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.

DIREKTOR

KÄSKKIRI 04.07.2025. a nr 44

Tallinn

Justiitsministri 18.04.2007. a määruse nr 20 „Registrite ja Infosüsteemide Keskuse põhimäärus“ § 11 lõike

1 punkti 9 alusel ning kooskõlas direktori 04.06.2025 käskkirjaga nr 35 ja 20.06.2025 käskkirjaga nr 40

kinnitan käesoleva käskkirja lisad.

/allkirjastatud digitaalselt/

Rivo Reitmann

Hanke alusdokumentide kinnitamine riigihankes „Kohtute infosüsteemi arendustööd" (296052)

Lisad: 1. hanketeade „Kohtute infosüsteemi arendustööd" (296052) (vormistatud digitaalselt),

2. hankedokumendid „Kohtute infosüsteemi arendustööd" (296052) koos lisadega (vormistatud

digitaalselt).

Eesti: Tarkvara programmeerimis­ ja nõustamisteenused Kohtute infosüsteemi arendustööd

Hanketeade või kontsessiooniteade – üldkord

1 Hankija

1.1 Hankija Ametlik nimi: Registrite ja Infosüsteemide Keskus Hankija õiguslik vorm: Keskvalitsusasutus Hankija tegevus: Üldised avalikud teenused

2 Menetlus

2.1 Menetlus Pealkiri: Kohtute infosüsteemi arendustööd Kirjeldus: Riigihanke eesmärgiks on raamlepingu sõlmimine ühe edukaks tunnistatud pakkujaga, kes hakkab  teostama kohtute infosüsteemi (KIS) arendustöid pakkumuses fikseeritud tunnihinna alusel. KIS arendustööde  eesmärk on KIS infosüsteemi täiustamine ja parendamine, sealhulgas protsesside automatiseerimise, tehisaru  kasutuselevõtu jms kaudu, et tagada õiguskindlus ja võimalusel lühendada menetluste aegu. / Kõrvaldamise alused ja  kvalifitseerimistingimused: Vaata hanke alusdokumentidest Menetluse tunnus: 924ac2fa­7531­4329­8f13­035a60276fea Sisemine tunnus: 296052­0000 Menetluse liik: Avatud Kiirendatud menetlus: ei Menetluskorra kirjeldus: Avatud hankemenetlus

2.1.1 Eesmärk Lepingu olemus: Teenused Peamine liigitus (cpv): 72200000 Tarkvara programmeerimis­ ja nõustamisteenused

2.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Põhja­Eesti (EE001) Riik: Eesti Lisateave: Eesti

2.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Lõuna­Eesti (EE008) Riik: Eesti Lisateave: Eesti

2.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Lääne­Eesti (EE004) Riik: Eesti Lisateave: Eesti

2.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Kirde­Eesti (EE00A) Riik: Eesti

https://ted.europa.eu/TED Page 1/6

Lisateave: Eesti

2.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Kesk­Eesti (EE009) Riik: Eesti Lisateave: Eesti

2.1.3 Maksumus Eeldatav maksumus käibemaksuta: 4 000 000 Euro

2.1.4 Üldine teave Lisateave: Riigihange ei ole osadeks jaotatud, sest raamlepingu esemeks on kohtute infosüsteemi arendustööd  ja hooldustööd ning muud sama eesmärgi saavutamiseks vajalikud teenused. Teenuse osutamiseks sõlmitakse  raamleping ühe pakkujaga. Teenuse osutamine ühe pakkuja poolt tagab hankija rahaliste vahendite otstarbeka ja  säästliku kasutamise, muu hulgas läbi töödesse sisse elamiseks või sellega tutvumiseks kuluva tööaja vähendamise.  Hankija soovib sõlmida raamlepingu tervikteenust pakkuva ettevõttega, kes teostab arendustöid (analüüsi, arendust,  testimist jms) ning vajadusel pakub ka konsultatsiooni. Raamlepingu algusaeg on hanke üldandmetes märgitud  eeldatava algusajana, sest lepingu täitmise alguskuupäeva nõuab RHR­i tehniline lahendus. Hankija ei seo  end nimetatud kuupäevaga, s.t lepingu täitmist alustatakse alates lepingu sõlmimisest. Kõrvaldamise alused ja  kvalifitseerimistingimused: Vaata hanke alusdokumentidest. Õiguslik alus: Direktiiv 2014/24/EL

5 Osa

5.1 Osa tehniline tunnus: LOT­0000 Pealkiri: Kohtute infosüsteemi arendustööd Kirjeldus: Riigihanke eesmärgiks on raamlepingu sõlmimine ühe edukaks tunnistatud pakkujaga, kes hakkab  teostama kohtute infosüsteemi (KIS) arendustöid pakkumuses fikseeritud tunnihinna alusel. KIS arendustööde  eesmärk on KIS infosüsteemi täiustamine ja parendamine, sealhulgas protsesside automatiseerimise, tehisaru  kasutuselevõtu jms kaudu, et tagada õiguskindlus ja võimalusel lühendada menetluste aegu. / Kõrvaldamise alused ja  kvalifitseerimistingimused: Vaata hanke alusdokumentidest Sisemine tunnus: 296052­0000

5.1.1 Eesmärk Lepingu olemus: Teenused Peamine liigitus (cpv): 72200000 Tarkvara programmeerimis­ ja nõustamisteenused

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Põhja­Eesti (EE001) Riik: Eesti Lisateave: Eesti

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Lõuna­Eesti (EE008) Riik: Eesti Lisateave: Eesti

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Lääne­Eesti (EE004) Riik: Eesti

https://ted.europa.eu/TED Page 2/6

Lisateave: Eesti

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Kirde­Eesti (EE00A) Riik: Eesti Lisateave: Eesti

5.1.2 Lepingu täitmise koht Riik – jaotus (NUTS): Kesk­Eesti (EE009) Riik: Eesti Lisateave: Eesti

5.1.3 Eeldatav kestus Alguskuupäev: 22/09/2025 Kestus: 48 Kuu

5.1.5 Maksumus Eeldatav maksumus käibemaksuta: 4 000 000 Euro

5.1.6 Üldine teave Reserveeritud osalemine: Osalemine ei ole reserveeritud. Tuleb esitada lepingu täitmiseks määratud töötajate nimed ja nende kutsekvalifikatsioonid: Ei ole nõutud Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah Lisateave: Riigihange ei ole osadeks jaotatud, sest raamlepingu esemeks on kohtute infosüsteemi arendustööd  ja hooldustööd ning muud sama eesmärgi saavutamiseks vajalikud teenused. Teenuse osutamiseks sõlmitakse  raamleping ühe pakkujaga. Teenuse osutamine ühe pakkuja poolt tagab hankija rahaliste vahendite otstarbeka ja  säästliku kasutamise, muu hulgas läbi töödesse sisse elamiseks või sellega tutvumiseks kuluva tööaja vähendamise.  Hankija soovib sõlmida raamlepingu tervikteenust pakkuva ettevõttega, kes teostab arendustöid (analüüsi, arendust,  testimist jms) ning vajadusel pakub ka konsultatsiooni. Raamlepingu algusaeg on hanke üldandmetes märgitud  eeldatava algusajana, sest lepingu täitmise alguskuupäeva nõuab RHR­i tehniline lahendus. Hankija ei seo  end nimetatud kuupäevaga, s.t lepingu täitmist alustatakse alates lepingu sõlmimisest. Kõrvaldamise alused ja  kvalifitseerimistingimused: Vaata hanke alusdokumentidest.

5.1.7 Strateegilised hanked Strateegilise hanke eesmärk: Sotsiaalsete eesmärkide täitmine

Kirjeldus: Hindamiskriteeriumites on kasutatud sotsiaalselt vastutustundlikku aspekti. Strateegilise hanke eesmärk: Keskkonnamõju vähendamine

Kirjeldus: Keskkonnahoidlikud tingimused lisatud riigihanke vastavustingimustesse. Strateegilise hanke eesmärk: Innovaatiline hange

Kirjeldus: Tarkvara arendustööd saab pidada innovatsiooni toetavaks, arvestades, et iga arendus võimaldab  infosüsteemide kasutajamugavuse parandamist, teenuse täiustamist ning protsesside täiustamist/ lihtsustamist.

Keskkonnamõju vähendamist käsitlev lähenemisviis: Muu Uuenduslik eesmärk: Hanke alusel tellitud tööd, asjad või teenused toovad endaga kaasa protsessiinnovatsiooni.

5.1.8 Ligipääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume ei ole lisatud järgmise põhjendusega Põhjendus: Eraldi ligipääsetavuse nõudeid riigihankes kehtestatud ei ole ning infosüsteemi arendamisel järgitakse  ettevõtlus­ ja infotehnoloogiaministri 28.02.2019 määrusega nr 20 „Veebilehe ja mobiilirakenduse ligipääsetavuse  nõuded ning ligipääsetavust kirjeldava teabe avaldamise kord“ nõudeid.

5.1.10 Pakkumuste hindamise kriteeriumid

https://ted.europa.eu/TED Page 3/6

Kriteerium: Liik: Hind Kirjeldus: Vaata hanke alusdokumentidest Hindamise lävendikriteeriumi kategooria: Kaal (punktid, täpne)

Hindamiskriteerium – arv: 20 Kriteerium:

Liik: Kvaliteet Kirjeldus: Vaata hanke alusdokumentidest Hindamise lävendikriteeriumi kategooria: Kaal (punktid, täpne)

Hindamiskriteerium – arv: 5 Kriteerium:

Liik: Kulu Kirjeldus: Vaata hanke alusdokumentidest Hindamise lävendikriteeriumi kategooria: Kaal (punktid, täpne)

Hindamiskriteerium – arv: 30 Kriteerium:

Liik: Kvaliteet Kirjeldus: Vaata hanke alusdokumentidest Hindamise lävendikriteeriumi kategooria: Kaal (punktid, täpne)

Hindamiskriteerium – arv: 25 Kriteerium:

Liik: Kvaliteet Kirjeldus: Vaata hanke alusdokumentidest Hindamise lävendikriteeriumi kategooria: Kaal (punktid, täpne)

Hindamiskriteerium – arv: 20

5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr­web/#/procurement/8912744/documents?group=B

5.1.12 Hanke tingimused Esitamise tingimused:

Elektrooniline esitamine: Nõutav Esitamise aadress: https://riigihanked.riik.ee/rhr­web/#/procurement/8912744/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Pakkumuste esitamise tähtaeg: 18/08/2025 12:00 +03:00 Pakkumuse jõusoleku tähtaeg: 3 Kuu

Teave avaliku avamise kohta: Avamise kuupäev: 18/08/2025 13:00 +03:00 Koht: https://riigihanked.riik.ee/rhr­web/#/

Lepingutingimused: Lepingu täitmine peab toimuma kaitstud tööhõive programmide raames: Ei E­arveldamine: Nõutav Kasutatakse elektroonilisi tellimusi: ei Kasutatakse elektroonilisi makseid: jah

5.1.15 Vahendid Raamleping:

Raamleping ilmaminikonkursita

https://ted.europa.eu/TED Page 4/6

Osalejate maksimaalne arv: 1 Teave dünaamilise hankesüsteemi kohta:

Ei kohaldata dünaamilist hankesüsteemi

5.1.16 Lisateave, lepitus ja vaidlustus Lepitusorganisatsioon: Riigihangete vaidlustuskomisjon Vaidlustusorgan: Riigihangete vaidlustuskomisjon Teave vaidlustamise tähtaegade kohta: https://fin.ee/riigihanked­riigiabi­osalused/riigihanked/vaidlustusmenetlus Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus

8 Organisatsioonid

8.1 ORG­0001 Ametlik nimi: Registrite ja Infosüsteemide Keskus Registreerimisnumber: 70000310 Postiaadress: Lubja tn 4   Linn: Tallinn Sihtnumber: 19081 Riik – jaotus (NUTS): Extra­Regio NUTS 3 (EEZZZ) Riik: Eesti Kontaktpunkt: Teele Nässi E­posti aadress: [email protected] Telefon: +372 58505692 Internetiaadress: http://www.rik.ee/ Hankija profiil: http://www.rik.ee/ Selle organisatsiooni rollid:

Hankija Organisatsioon, mis annab lisateavet hankemenetluse kohta Organisatsioon, millele laekuvad osalemistaotlused

8.1 ORG­0002 Ametlik nimi: Riigihangete vaidlustuskomisjon Registreerimisnumber: 1000123 Postiaadress: Tartu mnt 85   Linn: Tallinn Sihtnumber: 10115 Riik – jaotus (NUTS): Extra­Regio NUTS 3 (EEZZZ) Riik: Eesti E­posti aadress: [email protected] Telefon: +3726113713 Selle organisatsiooni rollid:

Vaidlustusorgan Lepitusorganisatsioon

8.1 ORG­0003 Ametlik nimi: Riigihangete register Registreerimisnumber: TED64 Postiaadress: Lõkke tn 4  

https://ted.europa.eu/TED Page 5/6

Linn: Tallinn Sihtnumber: 10122 Riik – jaotus (NUTS): Extra­Regio NUTS 3 (EEZZZ) Riik: Eesti E­posti aadress: [email protected] Telefon: +3726113693 Selle organisatsiooni rollid:

TED eSender

Teave teate kohta

Teate tunnus/versioon: 9eee2a16­b4f3­4387­ab8a­f6f9672dc094 ­ 01 Vormi liik: Hange Teate liik: Hanketeade või kontsessiooniteade – üldkord Teate saatmise kuupäev: 27/06/2025 13:21 +03:00 Teate saatmise kuupäev (eSender): 27/06/2025 13:21 +03:00 Keeled, milles käesolev teade on ametlikult kättesaadav: eesti keel 

https://ted.europa.eu/TED Page 6/6