Alusdokumentide kinnitamine dünaamilises hankesüsteemis „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks" (278726)

1 / 12 ALLTÖÖVÕTJATE KONTROLLIMISE TINGIMUSED LEPINGU TÄITMISE ETAPIS Viitenumber: 278726 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressurssi soetamiseks Esimese ringi alltöövõtjaid kontrollitakse:Jah Teise ja järgmiste ringide alltöövõtjaid kontrollitakse: Ei Alltöövõtjad peavad esitama hankepassi: Jah Selgitus alltöövõtjate kontrollimise kohta: ELi ühtekuuluvus- ja siseturvalisuspoliitika fondide rakenduskavade vahendite kasutamisel 2021–27 tuleb edukal pakkujal nende riigihangete puhul, mille maksumus ületab rahvusvahelist piirmäära, esitada pärast lepingu sõlmimist lepingu töölehel "Alltöövõtjad" järgmine info: • alltöövõtja nimi ja registrikood • alltöövõtulepingu nimetus, kuupäev, number ja lepingu summa. See info tuleb esitada hankelepingu täitmisel iga oma alltöövõtja kohta, kellega on sõlmitud alltöövõtuleping maksumusega üle 50 000 euro (käibemaksuta). Vt VV 12.05.2022 määrus nr 55. Tuginetavate isikute, sh tuginetavate alltöövõtjate, hankepassid esitab pakkuja koos taotluse/ pakkumusega registrisse integreeritud hankepassi rakendusega. Lepingu käigus planeeritavate alltöövõtjate kinnitused kõrvaldamise aluste puudumise kohta saab peatöövõtja esitada lepingu töölehel "Alltöövõtjad". ALLTÖÖVÕTJA ESIMESE RINGI KÕRVALDAMISE ALUSED A: Kõrvalejätmise alused seoses kriminaalasjas tehtud süüdimõistva otsusega 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 Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  2 / 12 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 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)) 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 Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  3 / 12 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 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 Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  4 / 12 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)) B: Kõrvalejätmise alused seoses maksude või sotsiaalkindlustusmaksete tasumisega 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 Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  5 / 12 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)) 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 Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  6 / 12 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 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)) Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  7 / 12 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 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)) Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  8 / 12 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 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)) Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  9 / 12 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 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)) Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  10 / 12 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 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)) Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  11 / 12 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)) 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 Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  12 / 12 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 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)) Koostatud 27.06.2024 13:19:30 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  1 / 31 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: 278726 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] Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  2 / 31 Teave hankemenetluse kohta Hanke menetlusliik: Dünaamilise hankesüsteemi piiratud hankemenetlus Pealkiri: Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressurssi soetamiseks Lühikirjeldus: Dünaamilise hankesüsteemi esemeks on tarkvaraarenduste soetamine ja arendusressursi soetamine dokumendihaldussüsteemi arendamiseks. Täpne lepingu ese ning hankija vajadused määratletakse igakordselt dünaamilise hankesüsteemi alusel korraldatud hanke alusdokumentides. Dünaamilise hankesüsteemi alusel võib RIK teostada hankeid sh vabatahtliku keskse hankimise raames teiste hankijate nimel. Avaliku sektori hankija või võrgustiku sektori hankija poolt toimikule antud viitenumber (kui on asjakohane): 278726 Hanke liik: Asjad Hanke CPV-d: 48900000-7 Mitmesugused tarkvarapaketid ja arvutisüsteemid 72200000-7 Tarkvara programmeerimis- ja nõustamisteenused Hanke osad Hanke osade kohta kehtivad järgnevad nõuded: Tingimuse kirjeldus: Pakkumusi võib esitada: Maksimaalne osade arv Maksimaalne osade arv, mille kohta võib pakkumusi esitada: 5 Maksimaalne osade arv, mille kohta võidakse sõlmida leping ühe pakkujaga: Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  3 / 31 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: Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  4 / 31 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 Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  5 / 31 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, ...): Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  6 / 31 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. 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. 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  7 / 31 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. 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? Viide seadusele: Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  8 / 31 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 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. 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)) 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 "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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  9 / 31 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? Viide seadusele: RHS § 95 lg 1 p 3 "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. 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)) 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 Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  10 / 31 maksukorralduse seaduse tähenduses või maksuvõlg /…/ tema asukohariigi õigusaktide kohaselt“ 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)) 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 Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  11 / 31 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  12 / 31 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. 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? 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  13 / 31 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. 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)) 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  14 / 31 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. 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? 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  15 / 31 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. 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? 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  16 / 31 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. 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)) 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  17 / 31 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. 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? 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. Kehtib: Kõik osad Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  18 / 31 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. 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? Viide seadusele: Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  19 / 31 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“; 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. 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)) D: Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused 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? Viide seadusele: RHS § 95 lg 1 p 5. Alates 14.08.2022 kontrollib hankija kõrvaldamise aluse puudumist 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). 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: 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: Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  20 / 31 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. 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? 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. 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: 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. Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  21 / 31 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? Viide seadusele: RHS § 95 lg 4.1 „Hankija võib riigihanke alusdokumentides sätestada, et tal on õigus kõrvaldada riigihanke menetlusest pakkuja või taotleja, kellel on hankija asukoha järgse, ühishanke puhul iga ühishankija asukoha järgse, või kui hankijaks on kohaliku omavalitsuse üksuste ühendus, iga ühendusse kuuluva hankija asukoha järgse kohaliku maksu maksuvõlg maksukorralduse seaduse tähenduses.“. Vabatahtlik kõrvaldamise alus. RHR-i kaudu saab päringuid teha vaid Tallinnas registreeritud hankija (MTA maksuvõlapäring + tänavate sulgemise maks). 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)) IV OSA: KVALIFITSEERIMISTINGIMUSED A: Sobivus KUULUMINE ÄRIREGISTRISSE Ettevõtja on kantud mõnda tema asukohaliikmesriigi äriregistrisse kooskõlas direktiivi 2014/24/ EL lisaga XI; teatavate liikmesriikide ettevõtjatelt võidakse nõuda muude kõnealuses lisas sätestatud nõuete täitmist. Viide seadusele: RHS § 99 lg 1 „pakkuja või taotleja asukohariigi õigusaktide kohaselt tuleb ettevõtja kanda äriregistrisse“ RHS § 99 lg 2 „hankija võib nõuda registreeringut tõendava asjakohase tõendi esitamist“ Tingimuse selgitus: Taotleja peab olema registreeritud oma asukohariigi äriregiregistris või peab olema talle väljastatud vastav tegevusluba või peab ta kuuluma vastavasse organisatsiooni, kui see on nõutud tema asukohariigi õigusaktide kohaselt. Taotleja, kelle asukohariigiks on Eesti Vabariik, peab olema registreeritud Eesti äriregistris. Taotleja esitab kinnituse hankepassis. RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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 Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  22 / 31 alusel hankija nõutud täiendavad dokumendid esitamata. Hankepassi esitamine on kohustuslik kõigile taotlejatele, kaasa arvatud ühistaotlejad ning alltöövõtjad, kelle majandus-ja/või finantsnäitajatele ja/või kutsealasele suutlikkusele tuginetakse. Kehtib: Ainult järgmiste osade kohta: Osa 1 - Tarkvaraarendus eeldatava maksumusega kuni 199 999 EUR (km-ta) Osa 2 - Tarkvaraarendus eeldatava maksumusega alates 200 000 EUR (km-ta) Osa 3 - Arendusressursi soetamine eeldatava maksumusega kuni 149 999 EUR (km-ta) Osa 4 - Arendusressursi soetamine eeldatava maksumusega alates 150 000 kuni 449 999 EUR (km-ta) Osa 5 - Arendusressursi soetamine eeldatava maksumusega alates 450 000 EUR (km-ta) Tingimuse kirjeldus: Registri nimi: Äriregister Veebiaadress (URL): https://ariregister.rik.ee/ Ettevõtjalt oodatavad vastused: 1. Mis on Teie vastus? (Raadionupp valikutega "Jah/Ei") 2. Registreerimise number (Sisestusväli (max pikkus 250 tähemärki)) 3. Põhjused, miks ei kuulu nõutud registrisse (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)) 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: Taotleja viimase kolme riigihanke algamise ajaks lõppenud majandusaasta netokäive peab olema kokku vähemalt 400 000 EUR. Taotleja esitab hankepassis kinnituse ja andmed, et tema kolme viimase lõppenud majandusaasta summeeritud netokäive on olnud vähemalt 400 000 EUR. 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 taotleja hankija nõudmisel esitama täiendavad selgitused, andmed või dokumendid kuni 5 (viie) tööpäeva jooksul alates päringu saamisest. Taotleja esitab hankepassis vastavad andmed. Kui taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, kes on esitanud valeandmeid käesolevas paragrahvis sätestatud või käesoleva seaduse §-des 98–101 sätestatu alusel hankija Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  23 / 31 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 ühistaotlejatale. Kehtib: Ainult järgmiste osade kohta: Osa 2 - Tarkvaraarendus eeldatava maksumusega alates 200 000 EUR (km-ta) Tingimuse kirjeldus: Miinimumnõue: 400000 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)) Ü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: Taotleja viimase kolme riigihanke algamise ajaks lõppenud majandusaasta netokäive peab olema kokku vähemalt 300 000 EUR. Taotleja esitab hankepassis kinnituse ja andmed, et tema kolme viimase lõppenud majandusaasta summeeritud netokäive on olnud vähemalt 300 000 EUR. 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 taotleja hankija nõudmisel esitama täiendavad selgitused, andmed või dokumendid kuni 5 (viie) tööpäeva jooksul alates päringu saamisest. Taotleja esitab hankepassis vastavad andmed. Kui taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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 ühistaotlejatale. Kehtib: Ainult järgmiste osade kohta: Osa 4 - Arendusressursi soetamine eeldatava maksumusega alates 150 000 kuni 449 999 EUR (km-ta) Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  24 / 31 Tingimuse kirjeldus: Miinimumnõue: 300000 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)) Ü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: Taotleja viimase kolme riigihanke algamise ajaks lõppenud majandusaasta netokäive peab olema kokku vähemalt 600 000 EUR. Taotleja esitab hankepassis kinnituse ja andmed, et tema kolme viimase lõppenud majandusaasta summeeritud netokäive on olnud vähemalt 600 000 EUR. 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 taotleja hankija nõudmisel esitama täiendavad selgitused, andmed või dokumendid kuni 5 (viie) tööpäeva jooksul alates päringu saamisest. Taotleja esitab hankepassis vastavad andmed. Kui taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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 ühistaotlejatale. Kehtib: Ainult järgmiste osade kohta: Osa 5 - Arendusressursi soetamine eeldatava maksumusega alates 450 000 EUR (km-ta) Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  25 / 31 Tingimuse kirjeldus: Miinimumnõue: 600000 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 ASJADE HANKELEPINGUTE PUHUL: TÄPSUSTATUD LIIKI TARNETE TEOSTAMINE Ainult asjade riigihankelepingute puhul: nimekiri hankija kindlaksmääratud tunnustele vastavate asjade müügi või 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 lepinguid. Viide seadusele: RHS § 101 lg 1 p 2 „nimekiri hankija kindlaks määratud tunnustele vastavate asjade müügi 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 asjade müügi lepingute kohta“ Tingimuse selgitus: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 2 (kaks) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 200 000 (kakssada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendustöö leping. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud, sh ka seda kus tööd antakse üle etapiviisiliselt (tellija on nõutud ulatuses töid saanud ja vastu võtnud)). Taotleja peab hankepassi korrektselt sisestama referentslepingu(te) maksumuse(d), lepingu(te) kuupäeva(d) 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 taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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. Kehtib: Ainult järgmiste osade kohta: Osa 1 - Tarkvaraarendus eeldatava maksumusega kuni 199 999 EUR (km-ta) Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  26 / 31 Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 2 Kirjeldus: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 2 (kaks) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 200 000 (kakssada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendustöö leping. 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)) ASJADE HANKELEPINGUTE PUHUL: TÄPSUSTATUD LIIKI TARNETE TEOSTAMINE Ainult asjade riigihankelepingute puhul: nimekiri hankija kindlaksmääratud tunnustele vastavate asjade müügi või 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 lepinguid. Viide seadusele: RHS § 101 lg 1 p 2 „nimekiri hankija kindlaks määratud tunnustele vastavate asjade müügi 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 asjade müügi lepingute kohta“ Tingimuse selgitus: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 300 000 (kolmsada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendustöö leping. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud, sh ka seda kus tööd antakse üle etapiviisiliselt (tellija on nõutud ulatuses töid saanud ja vastu võtnud)). Taotleja peab hankepassi korrektselt sisestama referentslepingu(te) maksumuse(d), lepingu(te) kuupäeva(d) 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 taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, kes on esitanud valeandmeid Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  27 / 31 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. Kehtib: Ainult järgmiste osade kohta: Osa 2 - Tarkvaraarendus eeldatava maksumusega alates 200 000 EUR (km-ta) Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 3 Kirjeldus: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 300 000 (kolmsada tuhat) EUR. 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)) 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: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 2 (kaks) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 200 000 (kakssada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendusressursi või arendustöö leping. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud, sh ka seda kus tööd antakse üle etapiviisiliselt (tellija on nõutud ulatuses töid saanud ja vastu võtnud)). Taotleja peab hankepassi korrektselt sisestama referentslepingu(te) maksumuse(d), lepingu(te) kuupäeva(d) 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 Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  28 / 31 küsida teise lepingu poole käest kinnitusi ja/tõendeid. Kui taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1).RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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. Kehtib: Ainult järgmiste osade kohta: Osa 3 - Arendusressursi soetamine eeldatava maksumusega kuni 149 999 EUR (km-ta) Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 2 Kirjeldus: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 2 (kaks) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 200 000 (kakssada tuhat) EUR. 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)) 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: Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  29 / 31 Taotleja viimase 3 (kolme) riigihange algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 300 000 (kolmsada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendusressursi või arendustöö leping. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud, sh ka seda kus tööd antakse üle etapiviisiliselt (tellija on nõutud ulatuses töid saanud ja vastu võtnud)). Taotleja peab hankepassi korrektselt sisestama referentslepingu(te) maksumuse(d), lepingu(te) kuupäeva(d) 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 taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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. Kehtib: Ainult järgmiste osade kohta: Osa 4 - Arendusressursi soetamine eeldatava maksumusega alates 150 000 kuni 449 999 EUR (km-ta) Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 3 Kirjeldus: Taotleja viimase 3 (kolme) riigihange algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 300 000 (kolmsada tuhat) EUR. 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)) 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. Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  30 / 31 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: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 600 000 (kuussada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendusressursi või arendustöö leping. Lepingud peavad olema täidetud (täitmine on põhikohustuste ulatuses lõppenud, sh ka seda kus tööd antakse üle etapiviisiliselt (tellija on nõutud ulatuses töid saanud ja vastu võtnud)). Taotleja peab hankepassi korrektselt sisestama referentslepingu(te) maksumuse(d), lepingu(te) kuupäeva(d) 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 taotleja 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 taotleja täitma hankepassi ka selle isiku kohta, kelle vahenditele ta tugineb. Lisaks peab taotleja 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 taotleja kasutab neid lepingu täitmisel (RHS § 103 lg 1). RHS § 95 lg 4 p 9: Hankija võib kõrvaldada hankemenetlusest taotleja, 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. Kehtib: Ainult järgmiste osade kohta: Osa 5 - Arendusressursi soetamine eeldatava maksumusega alates 450 000 EUR (km-ta) Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  31 / 31 Tingimuse kirjeldus: Minimaalne teostatud tööde arv: 3 Kirjeldus: Taotleja viimase 3 (kolme) riigihanke algamisele eelneva aasta jooksul täidetud lepingute hulgas peab olema vähemalt 3 (kolm) dünaamilise hankesüsteemi objektiga samaväärset lepingut ning esitatavate lepingute kogumaksumus ilma käibemaksuta on kokku vähemalt 600 000 (kuussada tuhat) EUR. Samaväärne leping on igasugune tarkvara arendusressursi või arendustöö leping. 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)) Koostatud 26.06.2024 14:55:57 https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info  HINDAMISKRITEERIUMID JA HINNATAVAD NÄITAJAD Viitenumber: 278726 Hankija: Registrite ja Infosüsteemide Keskus (70000310) Hange: Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressurssi soetamiseks OSA 1 – TARKVARAARENDUS EELDATAVA MAKSUMUSEGA KUNI 199 999 EUR (KM-TA) Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Maksimaalne osakaalude vahemik Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Vahemiku Kogus Ühik Pakkuja nr hindamismeetod keskmine täidetav 1 Kogumaksumus või töötunni maksumus Dünaamilise hankesüsteemi hangetes Maksumus - 65 rakendatakse alljärgnevalt: hankija hinnatav 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus ja/või projektiplaan. Kogumaksumuse ja töötunni maksumuse küsimise üle otsustab hankija vastavalt hanke esemele, täpsustades hindamiskriteeriumid seotud hanke alusdokumentides. Kui seotud hankes on võimalik määratleda hankelepingu eseme skoop täpselt, siis küsib hankija kogumaksumust. Kui seotud hanke eset ei ole võimalik täpselt määratleda, siis küsib hankija ühe töötunni maksumust, piiritledes hankelepingu mahu ajaliselt, rahaliselt, töötundide arvuga või muul moel. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda Koostatud 27.06.2024 13:14:47 1 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  vahemikus 51-80 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 51-80 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Pakkumuse maksumuse hindamiskriteeriumi minimaalne väärtus on 51. 2 Meeskonnaliikmete töökogemus ja/või Dünaamilise hankesüsteemi hangetes Kvaliteet - hankija 35 projektiplaan rakendatakse alljärgnevalt: hinnatav 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus ja/või projektiplaan. Meeskonnaliikmete töökogemuse ja/ või projektiplaani küsimise ning hindamiskriteeriumite üle otsustab hankija vastavalt hanke esemele. Hankija hindab meeskonnaliikmete töökogemust ja kompetentsi kas osaletud projektide arvu, töökogemuse aastate või projektis osalemise mahu järgi, täpsustades konkreetsed hindamiskriteeriumid seotud hanke alusdokumentides. Töökogemuse või projektide perioodide ajalise kattumise puhul arvestatakse kattuvaid perioode ühekordselt. Projektiplaani hindamisel hinnatakse projektiplaani vastavust tehnilisele kirjelduses esitatud nõuetele, konkreetsed hindamiskriteeriumid täpsustatakse seotud hanke alusdokumentides. Koostatud 27.06.2024 13:14:47 2 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 20-49 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 20-49 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Meeskonnaliikme töökogemuse, kompetentsi ja/või osalemine varasemates tarkvara projektides ja /või projektiplaani hindamiskriteeriumi maksimaalne väärtus on 49. Kokku: Hindamismetoodika kirjeldus 1. Kogumaksumus või töötunni maksumus Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". 2. Meeskonnaliikmete töökogemus ja/või projektiplaan Pakutud meeskonnaliikmete töökogemus ja/ või projektiplaan - hinnatakse vastavust tehnilises kirjelduses esitatud nõuetele. Täpsemad kriteeriumid sätestatakse iga vastava seotud piiratud hankemenetluse raames. OSA 2 – TARKVARAARENDUS EELDATAVA MAKSUMUSEGA ALATES 200 000 EUR (KM-TA) Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Maksimaalne osakaalude vahemik Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Vahemiku Kogus Ühik Pakkuja nr hindamismeetod keskmine täidetav 1 Kogumaksumus või töötunni maksumus Dünaamilise hankesüsteemi hangetes Maksumus - 65 rakendatakse alljärgnevalt: hankija hinnatav 1. kohal maksumus kokku või töötunni Koostatud 27.06.2024 13:14:47 3 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  maksumus, 2. kohal meeskonnaliikmete töökogemus ja/või projektiplaan. Kogumaksumuse ja töötunni maksumuse küsimise üle otsustab hankija vastavalt hanke esemele, täpsustades hindamiskriteeriumid seotud hanke alusdokumentides. Kui seotud hankes on võimalik määratleda hankelepingu eseme skoop täpselt, siis küsib hankija kogumaksumust. Kui seotud hanke eset ei ole võimalik täpselt määratleda, siis küsib hankija ühe töötunni maksumust, piiritledes hankelepingu mahu ajaliselt, rahaliselt, töötundide arvuga või muul moel. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 51-80 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 51-80 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Pakkumuse maksumuse hindamiskriteeriumi minimaalne väärtus on 51. 2 Meeskonnaliikmete töökogemus ja/või Dünaamilise hankesüsteemi hangetes Kvaliteet - hankija 35 projektiplaan rakendatakse alljärgnevalt: hinnatav 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus ja/või projektiplaan. Meeskonnaliikmete töökogemuse ja/ või Koostatud 27.06.2024 13:14:47 4 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  projektiplaani küsimise ning hindamiskriteeriumite üle otsustab hankija vastavalt hanke esemele. Hankija hindab meeskonnaliikmete töökogemust ja kompetentsi kas osaletud projektide arvu, töökogemuse aastate või projektis osalemise mahu järgi, täpsustades konkreetsed hindamiskriteeriumid seotud hanke alusdokumentides. Töökogemuse või projektide perioodide ajalise kattumise puhul arvestatakse kattuvaid perioode ühekordselt. Projektiplaani hindamisel hinnatakse projektiplaani vastavust tehnilisele kirjelduses esitatud nõuetele, konkreetsed hindamiskriteeriumid täpsustatakse seotud hanke alusdokumentides. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 20-49 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 20-49 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Meeskonnaliikme töökogemuse, kompetentsi ja/või osalemine varasemates tarkvara projektides ja /või projektiplaani hindamiskriteeriumi maksimaalne väärtus on 49. Kokku: Koostatud 27.06.2024 13:14:47 5 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info Hindamismetoodika kirjeldus 1. Kogumaksumus või töötunni maksumus Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". 2. Meeskonnaliikmete töökogemus ja/või projektiplaan Pakutud meeskonnaliikmete töökogemus ja/ või projektiplaan - hinnatakse vastavust tehnilises kirjelduses esitatud nõuetele. Täpsemad kriteeriumid sätestatakse iga vastava seotud piiratud hankemenetluse raames. OSA 3 – ARENDUSRESSURSI SOETAMINE EELDATAVA MAKSUMUSEGA KUNI 149 999 EUR (KM-TA) Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Maksimaalne osakaalude vahemik Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Vahemiku Kogus Ühik Pakkuja nr hindamismeetod keskmine täidetav 1 Kogumaksumus või töötunni maksumus Dünaamilise hankesüsteemi hangetes Maksumus - 65 rakendatakse alljärgnevalt: hankija hinnatav 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides. Kogumaksumuse ja töötunni maksumuse küsimise üle otsustab hankija vastavalt hanke esemele, täpsustades hindamiskriteeriumid seotud hanke alusdokumentides. Seotud hankes küsitakse iga konkreetse meeskonnaliikme töötunni maksumust. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda Koostatud 27.06.2024 13:14:47 6 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  vahemikus 51-80 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 51-80 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Pakkumuse maksumuse hindamiskriteeriumi minimaalne väärtus on 51. 2 Meeskonnaliikmete töökogemus, Dünaamilise hankesüsteemi hangetes Kvaliteet - hankija 35 kompetents ja/või osalemine rakendatakse alljärgnevalt: hinnatav varasemates tarkvara projektides 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides Meeskonnaliikmete töökogemuse kompetents ja/või osalemise varasemates tarkvara projektides küsimise ning hindamiskriteeriumite üle otsustab hankija vastavalt hanke esemele. Hankija hindab meeskonnaliikmete töökogemust ja kompetentsi kas osaletud projektide arvu, töökogemuse aastate või projektis osalemise mahu järgi, täpsustades konkreetsed hindamiskriteeriumid seotud hanke alusdokumentides. Töökogemuse või projektide perioodide ajalise kattumise puhul arvestatakse kattuvaid perioode ühekordselt. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 20-49 väärtuspunkti 100 Koostatud 27.06.2024 13:14:47 7 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 20-49 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Meeskonnaliikme töökogemuse, kompetentsi ja/või osalemine varasemates tarkvara projektides hindamiskriteeriumi maksimaalne väärtus on 49. Kokku: Hindamismetoodika kirjeldus 1. Kogumaksumus või töötunni maksumus Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". 2. Meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides Pakutud meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides - hinnatakse vastavust tehnilises kirjelduses esitatud nõuetele. Täpsemad kriteeriumid sätestatakse iga vastava seotud piiratud hankemenetluse raames. OSA 4 – ARENDUSRESSURSI SOETAMINE EELDATAVA MAKSUMUSEGA ALATES 150 000 KUNI 449 999 EUR (KM-TA) Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Maksimaalne osakaalude vahemik Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Vahemiku Kogus Ühik Pakkuja nr hindamismeetod keskmine täidetav 1 Kogumaksumus või töötunni maksumus Dünaamilise hankesüsteemi hangetes Maksumus - 65 rakendatakse alljärgnevalt: hankija hinnatav 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus, kompetents ja/või Koostatud 27.06.2024 13:14:47 8 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  osalemine varasemates tarkvara projektides. Kogumaksumuse ja töötunni maksumuse küsimise üle otsustab hankija vastavalt hanke esemele, täpsustades hindamiskriteeriumid seotud hanke alusdokumentides. Seotud hankes küsitakse iga konkreetse meeskonnaliikme töötunni maksumust. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 51-80 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 51-80 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Pakkumuse maksumuse hindamiskriteeriumi minimaalne väärtus on 51. 2 Meeskonnaliikmete töökogemus, Dünaamilise hankesüsteemi hangetes Kvaliteet - hankija 35 kompetents ja/või osalemine rakendatakse alljärgnevalt: hinnatav varasemates tarkvara projektides 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides Meeskonnaliikmete töökogemuse kompetents ja/või osalemise varasemates tarkvara projektides küsimise ning hindamiskriteeriumite üle otsustab hankija vastavalt hanke esemele. Hankija hindab meeskonnaliikmete Koostatud 27.06.2024 13:14:47 9 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  töökogemust ja kompetentsi kas osaletud projektide arvu, töökogemuse aastate või projektis osalemise mahu järgi, täpsustades konkreetsed hindamiskriteeriumid seotud hanke alusdokumentides. Töökogemuse või projektide perioodide ajalise kattumise puhul arvestatakse kattuvaid perioode ühekordselt. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 20-49 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 20-49 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Meeskonnaliikme töökogemuse, kompetentsi ja/või osalemine varasemates tarkvara projektides hindamiskriteeriumi maksimaalne väärtus on 49. Kokku: Hindamismetoodika kirjeldus 1. Kogumaksumus või töötunni maksumus Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". 2. Meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides Pakutud meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides - hinnatakse vastavust tehnilises kirjelduses esitatud nõuetele. Täpsemad kriteeriumid sätestatakse iga vastava seotud piiratud hankemenetluse raames. Koostatud 27.06.2024 13:14:47 10 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info OSA 5 – ARENDUSRESSURSI SOETAMINE EELDATAVA MAKSUMUSEGA ALATES 450 000 EUR (KM-TA) Pakkumuse maksumust hinnatakse - Ilma maksudeta Kriteeriumi kaalumise meetod - Maksimaalne osakaalude vahemik Elektroonilist oksjoni kasutatakse: ei Jrk Nimetus Kirjeldus Tüüp / Vahemiku Kogus Ühik Pakkuja nr hindamismeetod keskmine täidetav 1 Kogumaksumus või töötunni maksumus Dünaamilise hankesüsteemi hangetes Maksumus - 65 rakendatakse alljärgnevalt: hankija hinnatav 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides. Kogumaksumuse ja töötunni maksumuse küsimise üle otsustab hankija vastavalt hanke esemele, täpsustades hindamiskriteeriumid seotud hanke alusdokumentides. Seotud hankes küsitakse iga konkreetse meeskonnaliikme töötunni maksumust. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 51-80 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 51-80 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Pakkumuse maksumuse hindamiskriteeriumi minimaalne väärtus on 51. Koostatud 27.06.2024 13:14:47 11 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  2 Meeskonnaliikmete töökogemus, Dünaamilise hankesüsteemi hangetes Kvaliteet - hankija 35 kompetents ja/või osalemine rakendatakse alljärgnevalt: hinnatav varasemates tarkvara projektides 1. kohal maksumus kokku või töötunni maksumus, 2. kohal meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides Meeskonnaliikmete töökogemuse kompetents ja/või osalemise varasemates tarkvara projektides küsimise ning hindamiskriteeriumite üle otsustab hankija vastavalt hanke esemele. Hankija hindab meeskonnaliikmete töökogemust ja kompetentsi kas osaletud projektide arvu, töökogemuse aastate või projektis osalemise mahu järgi, täpsustades konkreetsed hindamiskriteeriumid seotud hanke alusdokumentides. Töökogemuse või projektide perioodide ajalise kattumise puhul arvestatakse kattuvaid perioode ühekordselt. Kriteeriumi väärtuspunktide osakaal võib seotud hangetes varieeruda vahemikus 20-49 väärtuspunkti 100 väärtuspunkti skaalal. Kriteeriumi punktide vahemik võib muutuda 20-49 väärtuspunkti vahemikus iga seotud hanke osas niivõrd, kui see ei too kaasa kriteeriumite tähtsuse järjekorra muutust. Meeskonnaliikme töökogemuse, kompetentsi ja/või osalemine varasemates tarkvara projektides hindamiskriteeriumi Koostatud 27.06.2024 13:14:47 12 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  maksimaalne väärtus on 49. Kokku: Hindamismetoodika kirjeldus 1. Kogumaksumus või töötunni maksumus Madalaima väärtusega pakkumus saab maksimaalse arvu punkte. Teised pakkumused saavad punkte proportsionaalselt vähem ja arvutatakse valemiga: "madalaim väärtus" / "pakkumuse väärtus" * "osakaal". 2. Meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides Pakutud meeskonnaliikmete töökogemus, kompetents ja/või osalemine varasemates tarkvara projektides - hinnatakse vastavust tehnilises kirjelduses esitatud nõuetele. Täpsemad kriteeriumid sätestatakse iga vastava seotud piiratud hankemenetluse raames. Koostatud 27.06.2024 13:14:47 13 / 13 https://riigihanked.riik.ee/rhr-web/#/procurement/ 7251864/general-info  EESTI: MITMESUGUSED TARKVARAPAKETID JA ARVUTISÜSTEEMID DÜNAAMILINE HANKESÜSTEEM DOKUMENDIHALDUSSÜSTEEMI TARKVARAARENDUSTE JA ARENDUSRESSURSI SOETAMISEKS Hanketeade või kontsessiooniteade – üldkord 1 Hankija 1.1 Hankija Ametlik nimi: Registrite ja Infosüsteemide Keskus Ostja õiguslik vorm: Keskvalitsusasutus Hankija tegevus: Üldised avalikud teenused 2 Menetlus 2.1 Menetlus Pealkiri: Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks Kirjeldus: Dünaamilise hankesüsteemi esemeks on tarkvaraarenduste soetamine ja arendusressursi soetamine dokumendihaldussüsteemi arendamiseks. Täpne lepingu ese ning hankija vajadused määratletakse igakordselt dünaamilise hankesüsteemi alusel korraldatud hanke alusdokumentides. Dünaamilise hankesüsteemi alusel võib RIK teostada hankeid sh vabatahtliku keskse hankimise raames teiste hankijate nimel. Menetluse tunnus: bbf86bd7-c4dc-4cfa-9507-4da255f88dbd Sisemine tunnus: 278726 Menetluse liik: Piiratud Kiirendatud menetluse põhjendus: Menetluskorra kirjeldus: Dünaamilise hankesüsteemi piiratud hankemenetlus 2.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48900000 Mitmesugused tarkvarapaketid ja arvutisüsteemid 2.1.3 Väärtus Eeldatav maksumus käibemaksuta: 4 000 000 Euro 2.1.4 Üldine teave Õiguslik alus: Direktiiv 2014/24/EL 2.1.5 Hanke tingimused Esitamise tingimused: Hanke osade maksimaalne arv, mille kohta üks pakkuja võib pakkumusi esitada: 5 2.1.6 Kõrvalejätmise alused Ainult siseriiklikest õigusaktidest tulenevad kõrvalejätmise alused: https://riigihanked.riik.ee/rhr-web/#/ procurement/7251864/procurement-passport 5 Osa https://ted.europa.eu/TED Page 1/14  5.1 Partii tehniline ID: LOT-0001 Pealkiri: Tarkvaraarendus eeldatava maksumusega kuni 199 999 EUR (km-ta) Kirjeldus: Antud osa alt soovib RIK soetada dokumendihaldussüsteemile tarkvaraarendust ja -hooldust. Sisemine tunnus: 278726 5.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48900000 Mitmesugused tarkvarapaketid ja arvutisüsteemid 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kesk-Eesti (EE009) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kirde-Eesti (EE00A) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lääne-Eesti (EE004) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lõuna-Eesti (EE008) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Põhja-Eesti (EE001) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.3 Eeldatav kestus Alguskuupäev: 01/09/2024 Kestus: 48 Kuu 5.1.4 Uuendamine Hankija jätab endale õiguse teha töövõtjalt täiendavaid oste, nagu on kirjeldatud siin: Kui konkreetse hanke pakkumuse esitamise ettepanekus ja/või selle lisades on vastavalt sätestatud, on hankijal õigus lepingut pikendada ja/ või selle mahtu ja maksumust muuta, kooskõlas RHS-i ja konkreetses hankes sätestatud tingimustega. 5.1.5 Väärtus Eeldatav maksumus käibemaksuta: 500 000 Euro 5.1.6 Üldine teave Reserveeritud osalemine: Osalemine ei ole reserveeritud. Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Teave Euroopa Liidu vahendite kohta ELi vahendite täiendavad üksikasjad: Võidakse rahastada erinevate projektide raames. Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah https://ted.europa.eu/TED Page 2/14  Lisateave: Tulenevalt RHS § 34 lõikest 3 pikendab RIK dünaamilise hankesüsteemiga liitumise taotluste läbivaatamise tähtaega kuni 40 tööpäevani alates nende kättesaamisest arvates (kehtib taotlustele, mis esitatakse 30 päeva jooksul hanketeate avaldamisest arvates). 5.1.7 Strateegilised hanked 5.1.8 Juurdepääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume pole lisatud, sest hange ei ole mõeldud kasutamiseks füüsilistele isikutele 5.1.9 Valikukriteeriumid Kriteerium: Liik: Sobivus tegeleda kutsealase tööga Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Majanduslik ja finantsseisund Selle kriteeriumi kasutamine: Ei kasutata Kriteerium: Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Teave kaheetapilise menetluse teise etapi kohta: Menetluse teise etappi kutsutavate kandidaatide miinimumarv: 5 5.1.10 Pakkumuste hindamise kriteeriumid Kriteerium: Liik: Hind Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 65 Kriteerium: Liik: Kvaliteet Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 35 Selle meetodi kirjeldus, mida kasutatakse juhul, kui hindamist ei ole võimalik kriteeriumide abil teostada: Pakkumuste hindamise kriteeriumide osakaalu märkimata jätmise põhjendus: 5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info 5.1.12 Hanke tingimused Esitamise tingimused: Elektrooniline esitamine: Lubatud Avalduse esitamise aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Osalemistaotluste esitamise tähtaeg: 02/08/2024 12:00 +03:00 Tähtaeg, mille jooksul pakkumus peab kehtima: 3 Kuu Lepingutingimused: https://ted.europa.eu/TED Page 3/14  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 Meetodid Raamleping: Ei kohaldata raamlepingut Teave dünaamilise hankesüsteemi kohta: Dünaamiline hankesüsteem, mida saavad kasutada ainult käesolevas teates loetletud hankijad Elektrooniline oksjon: ei 5.1.16 Lisateave, vahendamine ja läbivaatamine Vahendusorganisatsioon: Riigihangete vaidlustuskomisjon Läbivaatav organisatsioon: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus TED eSender: Riigihangete register 5.1 Partii tehniline ID: LOT-0002 Pealkiri: Tarkvaraarendus eeldatava maksumusega alates 200 000 EUR (km-ta) Kirjeldus: Antud osa alt soovib RIK soetada dokumendihaldussüsteemile tarkvaraarendust ja -hooldust. Sisemine tunnus: 278726 5.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48900000 Mitmesugused tarkvarapaketid ja arvutisüsteemid 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kesk-Eesti (EE009) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kirde-Eesti (EE00A) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lääne-Eesti (EE004) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lõuna-Eesti (EE008) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Põhja-Eesti (EE001) Riik: Eesti Lisateave: Täpne piirkond määramata https://ted.europa.eu/TED Page 4/14  5.1.3 Eeldatav kestus Alguskuupäev: 01/09/2024 Kestus: 48 Kuu 5.1.4 Uuendamine Hankija jätab endale õiguse teha töövõtjalt täiendavaid oste, nagu on kirjeldatud siin: Kui konkreetse hanke pakkumuse esitamise ettepanekus ja/või selle lisades on vastavalt sätestatud, on hankijal õigus lepingut pikendada ja/ või selle mahtu ja maksumust muuta, kooskõlas RHS-i ja konkreetses hankes sätestatud tingimustega. 5.1.5 Väärtus Eeldatav maksumus käibemaksuta: 1 000 000 Euro 5.1.6 Üldine teave Reserveeritud osalemine: Osalemine ei ole reserveeritud. Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Teave Euroopa Liidu vahendite kohta ELi vahendite täiendavad üksikasjad: Võidakse rahastada erinevate projektide raames. Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah Lisateave: Tulenevalt RHS § 34 lõikest 3 pikendab RIK dünaamilise hankesüsteemiga liitumise taotluste läbivaatamise tähtaega kuni 40 tööpäevani alates nende kättesaamisest arvates (kehtib taotlustele, mis esitatakse 30 päeva jooksul hanketeate avaldamisest arvates). 5.1.7 Strateegilised hanked 5.1.8 Juurdepääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume pole lisatud, sest hange ei ole mõeldud kasutamiseks füüsilistele isikutele 5.1.9 Valikukriteeriumid Kriteerium: Liik: Sobivus tegeleda kutsealase tööga Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Majanduslik ja finantsseisund Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Teave kaheetapilise menetluse teise etapi kohta: Menetluse teise etappi kutsutavate kandidaatide miinimumarv: 5 5.1.10 Pakkumuste hindamise kriteeriumid Kriteerium: Liik: Hind Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 65 Kriteerium: Liik: Kvaliteet Nimi: https://ted.europa.eu/TED Page 5/14  Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 35 Selle meetodi kirjeldus, mida kasutatakse juhul, kui hindamist ei ole võimalik kriteeriumide abil teostada: Pakkumuste hindamise kriteeriumide osakaalu märkimata jätmise põhjendus: 5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info 5.1.12 Hanke tingimused Esitamise tingimused: Elektrooniline esitamine: Lubatud Avalduse esitamise aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Osalemistaotluste esitamise tähtaeg: 02/08/2024 12:00 +03:00 Tähtaeg, mille jooksul pakkumus peab kehtima: 3 Kuu 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 Meetodid Raamleping: Ei kohaldata raamlepingut Teave dünaamilise hankesüsteemi kohta: Dünaamiline hankesüsteem, mida saavad kasutada ainult käesolevas teates loetletud hankijad Elektrooniline oksjon: ei 5.1.16 Lisateave, vahendamine ja läbivaatamine Vahendusorganisatsioon: Riigihangete vaidlustuskomisjon Läbivaatav organisatsioon: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus TED eSender: Riigihangete register 5.1 Partii tehniline ID: LOT-0003 Pealkiri: Arendusressursi soetamine eeldatava maksumusega kuni 149 999 EUR (km-ta) Kirjeldus: Antud osa alt soovib RIK teostada hankeid dokumendihaldussüsteemi arendusressursi soetamiseks, küsides ühte või mitut kindlaksmääratud rolli või meeskonda. Sisemine tunnus: 278726 5.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48900000 Mitmesugused tarkvarapaketid ja arvutisüsteemid 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kesk-Eesti (EE009) Riik: Eesti Lisateave: Täpne piirkond määramata https://ted.europa.eu/TED Page 6/14  5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kirde-Eesti (EE00A) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lääne-Eesti (EE004) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lõuna-Eesti (EE008) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Põhja-Eesti (EE001) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.3 Eeldatav kestus Alguskuupäev: 01/09/2024 Kestus: 48 Kuu 5.1.4 Uuendamine Hankija jätab endale õiguse teha töövõtjalt täiendavaid oste, nagu on kirjeldatud siin: Kui konkreetse hanke pakkumuse esitamise ettepanekus ja/või selle lisades on vastavalt sätestatud, on hankijal õigus lepingut pikendada ja/ või selle mahtu ja maksumust muuta, kooskõlas RHS-i ja konkreetses hankes sätestatud tingimustega. 5.1.5 Väärtus Eeldatav maksumus käibemaksuta: 500 000 Euro 5.1.6 Üldine teave Reserveeritud osalemine: Osalemine ei ole reserveeritud. Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Teave Euroopa Liidu vahendite kohta ELi vahendite täiendavad üksikasjad: Võidakse rahastada erinevate projektide raames. Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah Lisateave: Tulenevalt RHS § 34 lõikest 3 pikendab RIK dünaamilise hankesüsteemiga liitumise taotluste läbivaatamise tähtaega kuni 40 tööpäevani alates nende kättesaamisest arvates (kehtib taotlustele, mis esitatakse 30 päeva jooksul hanketeate avaldamisest arvates). 5.1.7 Strateegilised hanked 5.1.8 Juurdepääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume pole lisatud, sest hange ei ole mõeldud kasutamiseks füüsilistele isikutele 5.1.9 Valikukriteeriumid Kriteerium: Liik: Sobivus tegeleda kutsealase tööga Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse https://ted.europa.eu/TED Page 7/14  Kriteerium: Liik: Majanduslik ja finantsseisund Selle kriteeriumi kasutamine: Ei kasutata Kriteerium: Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Teave kaheetapilise menetluse teise etapi kohta: Menetluse teise etappi kutsutavate kandidaatide miinimumarv: 5 5.1.10 Pakkumuste hindamise kriteeriumid Kriteerium: Liik: Hind Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 65 Kriteerium: Liik: Kvaliteet Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 35 Selle meetodi kirjeldus, mida kasutatakse juhul, kui hindamist ei ole võimalik kriteeriumide abil teostada: Pakkumuste hindamise kriteeriumide osakaalu märkimata jätmise põhjendus: 5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info 5.1.12 Hanke tingimused Esitamise tingimused: Elektrooniline esitamine: Lubatud Avalduse esitamise aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Osalemistaotluste esitamise tähtaeg: 02/08/2024 12:00 +03:00 Tähtaeg, mille jooksul pakkumus peab kehtima: 3 Kuu 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 Meetodid Raamleping: Ei kohaldata raamlepingut Teave dünaamilise hankesüsteemi kohta: Dünaamiline hankesüsteem, mida saavad kasutada ainult käesolevas teates loetletud hankijad Elektrooniline oksjon: ei 5.1.16 Lisateave, vahendamine ja läbivaatamine Vahendusorganisatsioon: Riigihangete vaidlustuskomisjon https://ted.europa.eu/TED Page 8/14  Läbivaatav organisatsioon: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus TED eSender: Riigihangete register 5.1 Partii tehniline ID: LOT-0004 Pealkiri: Arendusressursi soetamine eeldatava maksumusega alates 150 000 kuni 449 999 EUR (km-ta) Kirjeldus: Antud osa alt soovib RIK teostada hankeid dokumendihaldussüsteemi arendusressursi soetamiseks, küsides ühte või mitut kindlaksmääratud rolli või meeskonda. Sisemine tunnus: 278726 5.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48900000 Mitmesugused tarkvarapaketid ja arvutisüsteemid 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kesk-Eesti (EE009) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kirde-Eesti (EE00A) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lääne-Eesti (EE004) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lõuna-Eesti (EE008) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Põhja-Eesti (EE001) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.3 Eeldatav kestus Alguskuupäev: 01/09/2024 Kestus: 48 Kuu 5.1.4 Uuendamine Hankija jätab endale õiguse teha töövõtjalt täiendavaid oste, nagu on kirjeldatud siin: Kui konkreetse hanke pakkumuse esitamise ettepanekus ja/või selle lisades on vastavalt sätestatud, on hankijal õigus lepingut pikendada ja/ või selle mahtu ja maksumust muuta, kooskõlas RHS-i ja konkreetses hankes sätestatud tingimustega. 5.1.5 Väärtus Eeldatav maksumus käibemaksuta: 1 000 000 Euro 5.1.6 Üldine teave https://ted.europa.eu/TED Page 9/14  Reserveeritud osalemine: Osalemine ei ole reserveeritud. Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Teave Euroopa Liidu vahendite kohta ELi vahendite täiendavad üksikasjad: Võidakse rahastada erinevate projektide raames. Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah Lisateave: Tulenevalt RHS § 34 lõikest 3 pikendab RIK dünaamilise hankesüsteemiga liitumise taotluste läbivaatamise tähtaega kuni 40 tööpäevani alates nende kättesaamisest arvates (kehtib taotlustele, mis esitatakse 30 päeva jooksul hanketeate avaldamisest arvates). 5.1.7 Strateegilised hanked 5.1.8 Juurdepääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume pole lisatud, sest hange ei ole mõeldud kasutamiseks füüsilistele isikutele 5.1.9 Valikukriteeriumid Kriteerium: Liik: Sobivus tegeleda kutsealase tööga Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Majanduslik ja finantsseisund Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Teave kaheetapilise menetluse teise etapi kohta: Menetluse teise etappi kutsutavate kandidaatide miinimumarv: 5 5.1.10 Pakkumuste hindamise kriteeriumid Kriteerium: Liik: Hind Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 65 Kriteerium: Liik: Kvaliteet Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 35 Selle meetodi kirjeldus, mida kasutatakse juhul, kui hindamist ei ole võimalik kriteeriumide abil teostada: Pakkumuste hindamise kriteeriumide osakaalu märkimata jätmise põhjendus: 5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info 5.1.12 Hanke tingimused Esitamise tingimused: Elektrooniline esitamine: Lubatud Avalduse esitamise aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/tenders https://ted.europa.eu/TED Page 10/14  Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Osalemistaotluste esitamise tähtaeg: 02/08/2024 12:00 +03:00 Tähtaeg, mille jooksul pakkumus peab kehtima: 3 Kuu 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 Meetodid Raamleping: Ei kohaldata raamlepingut Teave dünaamilise hankesüsteemi kohta: Dünaamiline hankesüsteem, mida saavad kasutada ainult käesolevas teates loetletud hankijad Elektrooniline oksjon: ei 5.1.16 Lisateave, vahendamine ja läbivaatamine Vahendusorganisatsioon: Riigihangete vaidlustuskomisjon Läbivaatav organisatsioon: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus TED eSender: Riigihangete register 5.1 Partii tehniline ID: LOT-0005 Pealkiri: Arendusressursi soetamine eeldatava maksumusega alates 450 000 EUR (km-ta) Kirjeldus: Antud osa alt soovib RIK teostada hankeid dokumendihaldussüsteemi arendusressursi soetamiseks, küsides ühte või mitut kindlaksmääratud rolli või meeskonda. Sisemine tunnus: 278726 5.1.1 Eesmärk Lepingu olemus: Tarned Peamine liigitus (cpv): 48900000 Mitmesugused tarkvarapaketid ja arvutisüsteemid 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kesk-Eesti (EE009) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Kirde-Eesti (EE00A) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lääne-Eesti (EE004) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Lõuna-Eesti (EE008) https://ted.europa.eu/TED Page 11/14  Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.2 Lepingu täitmise asukoht Riik – jaotus (NUTS): Põhja-Eesti (EE001) Riik: Eesti Lisateave: Täpne piirkond määramata 5.1.3 Eeldatav kestus Alguskuupäev: 01/09/2024 Kestus: 48 Kuu 5.1.4 Uuendamine Hankija jätab endale õiguse teha töövõtjalt täiendavaid oste, nagu on kirjeldatud siin: Kui konkreetse hanke pakkumuse esitamise ettepanekus ja/või selle lisades on vastavalt sätestatud, on hankijal õigus lepingut pikendada ja/ või selle mahtu ja maksumust muuta, kooskõlas RHS-i ja konkreetses hankes sätestatud tingimustega. 5.1.5 Väärtus Eeldatav maksumus käibemaksuta: 1 500 000 Euro 5.1.6 Üldine teave Reserveeritud osalemine: Osalemine ei ole reserveeritud. Hankeprojekt, mida rahastatakse täielikult või osaliselt ELi vahenditest Teave Euroopa Liidu vahendite kohta ELi vahendite täiendavad üksikasjad: Võidakse rahastada erinevate projektide raames. Hanke suhtes kohaldatakse riigihankelepingut (GPA): jah Lisateave: Tulenevalt RHS § 34 lõikest 3 pikendab RIK dünaamilise hankesüsteemiga liitumise taotluste läbivaatamise tähtaega kuni 40 tööpäevani alates nende kättesaamisest arvates (kehtib taotlustele, mis esitatakse 30 päeva jooksul hanketeate avaldamisest arvates). 5.1.7 Strateegilised hanked 5.1.8 Juurdepääsetavuse kriteeriumid Puuetega inimeste juurdepääsukriteeriume pole lisatud, sest hange ei ole mõeldud kasutamiseks füüsilistele isikutele 5.1.9 Valikukriteeriumid Kriteerium: Liik: Sobivus tegeleda kutsealase tööga Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Majanduslik ja finantsseisund Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Kriteerium: Liik: Tehniline ja kutsealane suutlikkus Kirjeldus: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/procurement-passport Selle kriteeriumi kasutamine: Kasutatakse Teave kaheetapilise menetluse teise etapi kohta: Menetluse teise etappi kutsutavate kandidaatide miinimumarv: 5 5.1.10 Pakkumuste hindamise kriteeriumid https://ted.europa.eu/TED Page 12/14  Kriteerium: Liik: Hind Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 65 Kriteerium: Liik: Kvaliteet Nimi: Kirjeldus: Vaata hanke alusdokumentidest Kaal (punktid, vahemiku keskmine): 35 Selle meetodi kirjeldus, mida kasutatakse juhul, kui hindamist ei ole võimalik kriteeriumide abil teostada: Pakkumuste hindamise kriteeriumide osakaalu märkimata jätmise põhjendus: 5.1.11 Hankedokumendid Hankedokumentide aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/general-info 5.1.12 Hanke tingimused Esitamise tingimused: Elektrooniline esitamine: Lubatud Avalduse esitamise aadress: https://riigihanked.riik.ee/rhr-web/#/procurement/7251864/tenders Keeled, milles võib pakkumusi või osalemistaotlusi esitada: eesti keel Elektrooniline kataloog: Ei ole lubatud Variandid: Ei ole lubatud Osalemistaotluste esitamise tähtaeg: 02/08/2024 12:00 +03:00 Tähtaeg, mille jooksul pakkumus peab kehtima: 3 Kuu 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 Meetodid Raamleping: Ei kohaldata raamlepingut Teave dünaamilise hankesüsteemi kohta: Dünaamiline hankesüsteem, mida saavad kasutada ainult käesolevas teates loetletud hankijad Elektrooniline oksjon: ei 5.1.16 Lisateave, vahendamine ja läbivaatamine Vahendusorganisatsioon: Riigihangete vaidlustuskomisjon Läbivaatav organisatsioon: Riigihangete vaidlustuskomisjon Organisatsioon, mis annab lisateavet hankemenetluse kohta: Registrite ja Infosüsteemide Keskus Organisatsioon, millele laekuvad osalemistaotlused: Registrite ja Infosüsteemide Keskus TED eSender: Riigihangete register 8 Organisatsioonid 8.1 ORG-0001 Ametlik nimi: Registrite ja Infosüsteemide Keskus Registreerimisnumber: 70000310 https://ted.europa.eu/TED Page 13/14  Postiaadress: Lubja tn 4 Linn: Tallinn Sihtnumber: 19081 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: Eesti E-posti aadress: [email protected] Telefon: +3726113713 Selle organisatsiooni rollid: Läbivaatav organisatsioon Vahendusorganisatsioon 8.1 ORG-0003 Ametlik nimi: Riigihangete register Registreerimisnumber: TED64 Linn: Tallinn Riik: Eesti E-posti aadress: [email protected] Telefon: +3726113693 Selle organisatsiooni rollid: TED eSender 11 Teave teate kohta 11.1 Teave teate kohta Teate tunnus/versioon: 2100b88d-4d2d-4542-a9d2-37c5c86f6cbe - 01 Vormi liik: Hange Teate liik: Hanketeade või kontsessiooniteade – üldkord Teate saatmise kuupäev: 27/06/2024 14:17 +03:00 E-saatja teate saatmise kuupäev: 27/06/2024 14:17 +03:00 Keeled, milles käesolev teade on ametlikult kättesaadav: eesti keel 11.2 Avaldamisteave https://ted.europa.eu/TED Page 14/14  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.  Dokumentatsiooniplaan v2 versioon 2.0 Täitja poolt Tellijale üle antavad dokumendid Arenduste kirjeldus Arhitektuuri kirjeldus Seadmete ja tarkvara kasutusjuhendid Testplaan ja testimise tulemusena valminud dokumendid Varundus/taasteplaan Versiooni kirjeldus Nõuded arendustele vastavustabel Front-end nõuete vastavustabel Kasutajaliideste ja WCAG nõuete vastavustabel Andmekogude semantiline kirjeldus ja koosseis Dokumendid peavad vastama vähemalt alljärgnevatele tingimustele Tehnilise dokumentatsiooni võiks võimaluse korral hoida git’is koodi juures .md failides. Ärilised dokumendid peavad olema RIK Confluence keskkonnas Dokumendi nimi hankelepingus Dokumendi sisu vastavalt arenduslepingule Sihtgrupp 1 Arenduste kirjeldus Dokumendi/dokumentide eesmärgiks on anda selge ja konkreetne ülevaade süsteemi sisust ja realiseeritud arendustest. Tellija Eraldiseisvaid dokumente üle ei anta vaid RIK Confluence keskkonda kirjutatakse analüüsi jooksvalt projekti käigus. äriprotsesse valdavad Kirjeldused peavad olema kinnitatud Tellija poolt enne arendustöö algust. kontaktisikud: ärianalüü Üle antavad dokumendid peavad sisaldama: tikud süsteemi Infosüsteemi terviku kirjeldus – olemasoleva süsteemi täiendamisel lisatud/muudetud osade kirjeldus. Tegemist on süsteemi ärisisul põhinevate analüütik baaskomponentidega, millele toetuvad kasutaja tegevused, ekraanivormid, kasutuslood/protsessid, teenused, jms; ud Vormide (ekraanivormide) kirjeldused; Täitjast Kasutuslugude / vormide kasutamise protsesside / tegevuste kirjeldused; sõltumatud Infosüsteemi teenuste kirjeldused. tarkvara hooldajad arendaja d ja edasiare ndajad testijad arhitektid projektiju hid 2 Arhitektuuri kirjeldus Dokumendi eesmärgiks on kirjeldada loodava süsteemi tehnilist ülesehitust. Kirjeldatakse rakenduse loogilist struktuuri, näidates ära selle kihtideks jagunemise. Kirjeldatakse ka füüsilist arhitektuuri, antakse ülevaade kasutatavatest tehnoloogiatest ning vahenditest. arhitekt administraator Dokument peab rahuldama vähemalt alljärgnevaid sisunõudeid: turvaspetsialist topoloogia, süsteemi füüsiline arhitektuur (süsteemi komponendid andmebaasiserver, rakendusserver, meiliserver jms): süsteemi soovituslikud näitajad komponentide kaupa, näiteks andmesidekiirused, andmemahud, protsessori kiirus, mälumaht, komponentide arv süsteemi osade kaupa, kettasüsteemi jõudlus jms; liidesed teiste süsteemidega (x-tee, meilisüsteemid) ja sõltuvused teistest süsteemidest; süsteemi tehnilised (sh automaatsed) protsessid ehk töövoog – komponentide omavahelised suhtlusstsenaariumid ja koostoimimine (näiteks, mis komponent ja millal pöördub RR teenuse poole); kolmandate osapoolte poolt toodetud kasutatavad tarkvarad/riistvarad, mis on vajalikud süsteemi toimimiseks; süsteemi krüpto-, allkirjastamise, digitemebeldamise lahendused ja algoritmid. Esmane kirjeldus esitatakse enne arendustööde algust. Täiendatud kirjeldus antakse üle koos vaheetapi üleandmise aktiga. Lõplik (täielik) kirjeldus esitatakse lõppaktiga 3 Seadmete ja tarkvara Süsteem tuleb ehitada selliselt, et see ei vajaks täiendavaid selgitusi (oleks intuitiivne). tarkvara kasutusjuhendid Siiski võib teatud hetkedel kasutaja vajada täiendavat infot, mis aitaks kasutajatel mõista, kuidas oma ülesandeid täita, sellisel juhul peab info sisu olema hõlpsasti kasutajad leitav ja keskenduma kasutaja ülesandele. Seega tuleks alati eelistada kasutajale kontekstipõhist abiinfo andmist, mis on realiseeritud UI vaates, milles kasutaja haldurid parasjagu oma ülesandeid täidab. Abiinfo peab olema lühike ja sisaldama konkreetsete sammude kirjeldusi, mis tuleb läbi viia. Kasutusjuhendi materjali eraldiseisvalt üle ei anta, vaid need kuuluvad üle antava rakenduse juurde. 4 Administreerimisjuhend, paigal Juhend on aluseks süsteemi administreerimisele, paigaldamisele ja seadistamisele. dusjuhend haldurid Juhend peab rahuldama vähemalt alljärgnevaid sisunõudeid: projektijuht adminitraator süsteemi parameetrite (seadistuste) kirjeldus ning nende muutmiste mõjud ja protseduurid (näiteks .net rakenduste puhul konfiguratsiooniparameetrite arhitekt kirjeldused/selgitused ja näidisväärtused); logimise realisatsiooni kirjeldused (kuhu ja mida, kas kasutatakse roteerimist või katalogiseerimist jms); rutiinsete hooldusprotseduuride kirjeldus; paigalduspaketi koostamise protseduurid; paigaldusprotseduurid; süsteemi halvamist võimaldavad riskid ja nende esinemise võimalikkus. Paigaldusjuhendis kirjeldatakse iga realiseeritud osa rakendamine (deployment) koos spetsiifiliste seadistustega. Paigaldusprotseduurid peavad olema kirjutatud selliselt, et RIK-i administraator suudab rakenduse paigaldada ja seadistada ilma kõrvalise abita. Etapi juhendid antakse üle koos vaheetapi üleandmise aktiga. Lõplikud (täielikud) juhendid esitatakse lõppaktiga. 5 Testplaan ja testimise Annab detailse ülevaate teostatud arenduste testimisest ning testimise tulemustest. projektijuht tulemusena valminud Kesksel kohal on testplaan, mis kirjeldab testimise strateegia, skoobi, vahendid, tegevused, tulemid jne. Vastavalt kokkuleppele koostatakse testlood, mis vastuvõtu dokumendid võivad olla laiendatud kasutuslood. testijad Vastavalt kokkuleppele teostatud funktsionaalsuse-, jõudluse-, koormuse-, integratsiooni-, kasutatavuse-, turvalisuse- jm. testimise dokumendid (plaan, lood, juhendid, puudused, puuduste kõrvaldamise info, tulemid). Testimisel ilmnenud vead ning paranduste info (versiooniinfo, vajadusel sisu). Testimise otstarbel loodud kood, skriptid, kasutusjuhendid. Testimise dokumentatsioon ei pea olema üks dokument, dokumendid võib grupeerida loogilisteks osadeks: Testplaan Nõuetele vastavus Testlood Etapi juhendid antakse üle koos vaheetapi üleandmise aktiga. Lõplikud (täielikud) juhendid esitatakse lõppaktiga. 6 Varundus/taasteplaan Tagada süsteemi hävingujärgne kiire ja tõrgeteta taastamine. administraator Taasteplaan on aluseks süsteemi taastamisele peale suuremat hävingut. Taasteplaan peab rahuldama vähemalt alljärgnevaid sisulisi nõudeid: 1. Süsteemi backup’id, varundamisele kuuluvate komponentide ja asukohtade loetelu (nt rakenduse konfiguratsioonifailid, rakenduse failid failiserveril paiknevad failid ja andmebaas jne), nende kirjeldused ja kasutuselevõtu protseduurid (Näiteks: tuua kataloogi (vajadusel faili) tasemel välja list failidest, mida peab varundama; varunduse järjekord (kui see on oluline); 2. Taastamise sammud kasutades installatsiooni juhendit ja varundatud andmeid; 3. Süsteemi komponentide asendusvõimalused, nende alternatiivkomponentide spetsifikatsioonid. Miinimumis peab vastama küsimusele: milline riistvara/tarkvara on sobiv arendaja arvates (tehtud nt jõudlustestid) seda süsteemi käitama. Esmane dokument esitatakse enne arendustööde algust. Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga. Lõplik (täielik) dokument esitatakse lõppaktiga. 7 Versiooni kirjeldus Vajalik ülevaate saamiseks infosüsteemi versioonide sisust. projektijuht Detailne info iga versiooniuuenduse kohta: avaldamise kuupäev versiooni number versiooni tüüp (peamine, vaheversioon, parandus, erakorraline) versiooni sisu - milliseid teostatud arendusi sisaldab (töökasu numbrid, näiteks Jira taskide numbrid ja/või lingid taskile) leitud, kuid parandamata vead Versioni kirjeldus võib põhineda tarnitud Jira piletitel. Esitatakse koos iga üleantava versiooniga ja iga versiooni kohta. 8 Nõuded arendustele Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud arenduse nõuetega. arhitekt vastavustabel Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud mittefunktsionaalsed nõuded ning täitmismärge. administraator turvajuht Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused. Esmane dokument esitatakse enne arendustööde algust. Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga. Lõplik (täielik) dokument esitatakse lõppaktiga. 9 Front-end nõuete Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud front-end nõuetega. arhitekt vastavustabel Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud front-end nõuded ning täitmismärge. Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused. Esmane dokument esitatakse enne arendustööde algust. Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga. Lõplik (täielik) dokument esitatakse lõppaktiga. 10 Kasutajaliideste ja Kontrolltabel nii Täitjale kui ka Tellijale veendumaks, et arvestatud on hankes nõutud kasutajaliideste ja WCAG nõuetega. haldurid WCAG nõuete Kõik raamlepingus, lähteülesandes või tehnilises kirjelduses kirjeldatud kasutajaliideste ja WCAG nõuded ning täitmismärge. vastavustabel Täitmismärke tegemise aluseks peab olema testimine. Vajadusel lisatakse selgitused. Esmane dokument esitatakse enne arendustööde algust. Täiendatud dokument antakse üle koos vaheetapi üleandmise aktiga. Lõplik (täielik) dokument esitatakse lõppaktiga. 11 Andmekogude Vajalik ülevaate saamiseks, mis andmed andmekogus on ja mida need tähendavad. tellija semantiline kirjeldus ja Andmekogus töödeldavate andmete koosseisu kirjeldus sisaldab: tellija poolne koosseis projektijuht vanemandmeobjekti nimetus (tabeli nimetus); andmeobjekti nimetus (veeru nimetus); märge, kas tegemist on isikuandmetega; märge, kas tegemist on eriliigiliste isikuandmetega; märge, kas tegemist on andmekogu põhiandmetega; märge, kas tegemist on arhiiviväärtuslike andmetega; viide andmekogule, kust mittepõhiandmed pärinevad; andmeobjekti semantiline kirjeldus (selgitus, mis andmeobjektiga on tegemist). (Kõik märked formaadis jah/ei.) Dokument (fail) esitatakse lõppaktiga.  KINNITATUD Direktori 10.02.2020 Käskkiri nr 11 Lisa 1 Muudetud: 30.05.2023. a nr 42 Nõuded arendustele v6.0 Võti Nõude liik Kokkuvõte Kirjeldus Loodavate lahenduste X-tee Vastavus teenused peavad vastama RIA x- NA-1 üldistele tee juhendis toodud nõuetele. standarditele Aluseks tuleb võtta hanke välja kuulutamise hetkel kehtiv versioon. Kui hankes ei spetsifitseerita tarkvaralist lahendust tuleb kasutada vastaval konkreetsele vajadusel allpool toodud tarkvarade viimaseid stabiilseid versioone. Serverite operatsioonisüsteemina: 1) Linux RedHat Enterprise/Centos 2) Windows Andmebaasidena: 1) Microsoft SQL 2) Postgre SQL Vastavus Lahendusega koos tarnitav Veebiserverina: NA-2 üldistele standardtarkvara peab vastama 1) Nginx standarditele RIK nõuetele 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 Rakendus peab olema loodud vastavalt Eesti Infoturbestandardi Vastavus nõuetele. NA-3 üldistele Aluseks tuleb võtta hanke standarditele väljakuulutamise hetkel kehtiva versiooni meetmeid. [30.05.2023 DK nr 42 - muudetud]  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. Valik sõltub vajadustest ja kohustustest. 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 (EUPL © Euroopa Liit 2007, 2016, mille järel on märge „Litsentsitud EUPL alusel“); 2) lähtekoodi avalikustamine Euroopa Liidu joinup virtuaalses varamus. GNU GPL puhul on nõutav mh: RIK põhimõte on arendada 1) autoriõiguse märge päises tarkvara avatult ja avaldada (Copyright © <aasta> <autori Vastavus tarkvara vaba litsentsiga. Avaliku nimi>); NA-4 üldistele sektori kohustuseks on arendada 2) litsentsitingimustes ette nähtud standarditele tarkvara eelkõige avatult ja teavitus töö osas garantii avaldada tarkvara vaba litsentsiga välistamise kohta. vastavalt litsentsi nõuetele. 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.  Rakenduse, andmebaasi ja kolmanda osapoole komponentide platvorm(id)/versioon(id) peavad Kui on tuleb tellijaga paika panna ja NA-5 Arhitektuur olema sellised, mille eluea lõpp kokku leppida vahetuse strateegia. (EOL) pole teadaolevalt vähem kui 4 aasta pärast. Tulevase ja olemasolevate infosüsteemide platvormid (rakendusserver, andmebaas, Süsteemi jõudlus peab vastama kolmanda osapoole komponendid) kokkulepitud topoloogial eelanalüüsi NA-6 Arhitektuur ja topoloogia peab olema enne ja lähteülesande käigus välja toodud reaalse arenduse algust RIK jõudlusnäitajatele. Infrastruktuuride osakonnaga kooskõlastatud. Rakendusserver peab võimaldama NA-7 Arhitektuur töötamist andmebaasiserverist eraldi serveril. Rakendust peab saama ilma ümber programmeerimata liigutada Lahendus ei tohi olla sisse NA-8 Arhitektuur erinevate domeenide ja domeeni kompileeritud absoluutseid URL-e. saitide vahel Liideseid peab saama konfiguratsioonist välja lülitada. Väliste liidestatud süsteemide tõrke korral ei tohi süsteem hanguda, vaid peab väljastama mõistliku (võimalikult lühikese) aja jooksul Tõrkekindluse tagamiseks tuleb ajakohase veateate. Võimalusel väliseid liidestusi kasutada nii vähe tuleb töökindluse tõstmiseks NA-9 Arhitektuur kui võimalik. Kui need on vajalikud, kasutada asünkroonseid liideseid siis peavad nad olema võimalikult (ntäiteks Rahvastikuregistri, Maa- tõrkekindlad. ameti infosüsteemi või Google analythicsk´i töötamast lakkamisel peab süsteemi põhifunktsionaalsus,kui süsteemi äriloogika seda võimaldab, tööle jääma). Andmevahetus riigi infosüsteemi kuuluvate andmekogudega ja riigi infosüsteemi kuuluvate Kui X-tee päringut teostab inimene, NA-10 Arhitektuur andmekogude vahel toimub läbi siis peab olema päringu päises riigi infosüsteemi autentinud kasutaja andmed. andmevahetuskihi (x-tee). Avaliku teabe seaduse § 43 (9) lõige 5. Rakenduse testkeskkonnad peavad olema ühendatud test X- NA-11 Arhitektuur teega ja arenduskeskkonnad arendus X-teega. Rakenduse Rakendus peab neid sealt ka konfiguratsiooniparameetrid tuleb kasutama (mitte kopeerima ühte kohta kokku tuua nii, et nende parameetreid käivitamisel muutmisel ei peaks rakendust kolmandatesse kohtadesse). NA-12 Arhitektuur uuesti kokku kompileerima (nt ühte Logimise seaded võivad olla tekstipõhisesse rakenduse konfiguratsioonifailist konfiguratsioonifaili, andmebaasi eraldi ühes lisakonfiguratsioonifailis tabelisse). (näit Log4net).  Mõistlikuks ajaks loetakse Rakenduse kompileerimine (saidi maksimaalselt 30 sekundit. Kui taaskäivitas, konfiguratsiooni rakendus vajab indekseeritud sisu ja NA-13 Arhitektuur muutmine vms) peaks toimuma see pole kättesaadav, siis peab mõistliku aja jooksul. rakendus väljastama selle kohta selge teate. NA-14 Arhitektuur Rakendus peab olema 64-bitine. Andmebaas ja rakendus peavad Nõue kehtib Oracle ja Postgre NA-15 Arhitektuur kasutama UTF-8 kodeeringut. andmebaaside puhul. Failisüsteemi salvestamisel ei tohi ühte kausta tekkida üle 10000 objekti Failid peab katalogiseerima (kaust või fail). Failistruktuur peab NA-16 Arhitektuur kokkulepitud tunnuste alusel olema mõistlik (kaustu ei tohi olla (aasta, kuu, kuupäev). rohkem kui faile) ning ei tohi tekitada märgatavat jõudluskadu. Kasutatav programmeerimise NA-17 Arhitektuur paradigma on objekt-orienteeritud. Andmebaasis peab kasutama indekseid või muid meetmeid, et nõuded jõudlusele oleksid täidetud Kõik välised võtmed (Foreign Key) ka tulevikus (1, 3, 5 või 10 aasta NA-18 Arhitektuur peavad olema indekseeritud. pärast – vastavalt planeeritud kasutusajale). Väliseid võtmeid tuleb kasutada ka ühest andmebaasist teisele viitamisel. SQL päringute väljakutsumisel väljastpoolt andmebaasi, peab kasutama päringumuutujaid, et Tuleb kasutada päringumuutujaid vältida SQL vahemälu NA-19 Arhitektuur (Parameter Binding). fragmentseerumist (When calling SQL code from outside the database, Parameter Binding should be used to prevent SQL cache fragmentation). Kõigis andmebaasi tabelites peab olema defineeritud üks tehniline NA-20 Arhitektuur primaarvõti ja selle nimetus peab olema „ID“. Failide hoidmise asukoht lepitakse iga kord eraldi kokku. Failide Failid ja failide indeks peavad hoidmine klassikalises andmebaasis NA-21 Arhitektuur olema replikeeritavad teise on kulukas ja seab kõrgendatud serveriruumi. nõudmised ning piirangud andmebaasiserveritele. Rakendusel peab olema haldusliides, mille kaudu rakenduse Vajadus halduril teha otse baasis haldur saab teha tavapäraseid NA-22 Arhitektuur haldustoiminguid peab olema haldustoiminguid. Halduri viidud miinimumini. haldustoimingud lepitakse tellijaga kokku detailanalüüsi käigus. Andmebaas peab toetama nii külm- Ei tohi kasutada teenuseid, mis NA-23 Arhitektuur kui ka kuumvaru (peegeldamist) välistavad andmebaasi peegeldamist teise serveriruumi. (nt "failstream").  Tõusutundlikkus peab olema välja Sorteerimisreeglistik peab vastama lülitatud ning accent peab olema NA-24 Arhitektuur eesti keele tähestikule. sisse lülitatud. Näiteks: MS SQL puhul Estonian_CI_AS. Kirjade tekst peab olema haldurite poolt hallatav. Kirja saatmisel peab süsteem veenduma, et elektronposti server võttis meili vastu. Kui Kui süsteem saadab elektronkirju, elektronposti server millegi pärast NA-25 Arhitektuur peab kasutama süsteemivälist RIK- kirju vastu ei võta, tuleb kirjad ära i elektronposti serverit. saata pärast seda kui elektronposti server jälle vastab. Kirjad saatmist peab olema võimalik lihtsalt (näiteks muudatuse ajaks) rakenduse konfiguratsioonist kinni keerata. Konfiguratsiooniparameetrite Näiteks : X-tee Turvaserver, mitte nimed peavad olema sisulised. NA-26 Arhitektuur XTTS või viitenumber, mitte vk_seb Juhul kui see ei ole võimalik, peab jne. kõrval olema selgitus. Tagasüsteemide ülesanneteks on andmete haldamine ja võrguteenuste Infosüsteemides on eessüsteemid pakkumine. Tagasüsteemid ei tegele (front end) ja tagasüsteemid (back NA-27 Arhitektuur lõppkasutaja autentimise ja end) arhitektuuriliselt selgelt autoriseerimisega. Lõppkasutaja lahutatud. autoriseerimise tagavad eessüsteemid. Näiteks IIS: *.config , *.resources Konfiguratsioonifailid peavad Apache: *.conf, .htaccess. Kui neid NA-28 Arhitektuur olema vastavalt rakendusserveri on mitu, siis arendaja peab need tüübile vaikimisi kaitstud failid eraldi välja tooma konfiguratsioonifailide listis. Näiteks: IIS: Bin,App_Code, Rakenduse failid, mida kasutaja App_Data, App_Browsers, NA-29 Arhitektuur näha ei tohi, peavad olema App_GlobalResources, vaikimisi kaitstud kaustades. App_LocalResources, App_Themes, App_WebReferences Kõiki parameetreid tuleks Konfiguratsioonis ei tohi olla konfiguratsioonis kirjeldada vaid uhe NA-30 Arhitektuur erinevaid parameetreid, mis on korra (mitte nii, et mitmes lõigus sama sisuga. kirjeldatakse samu asju uuesti). Rakendustes tohib kasutada vaid masinapõhiseid teenuseid, mis lubavad kõrgkäideldavaid (klaster) lahendusi. Kõrgkäideldav Kõik rakendused peavad töötama lahendus peab olema selline, mida NA-31 Arhitektuur kõrgkäideldavalt. saab samaaegselt käitada erinevates masinates. Kasutajasessioon ei tohi olla ühe klastri üle põhine. Ei tohi kasutada sticky sessioneid. Klientrakendus ei tohi pöörduda otse NA-32 Arhitektuur Tuleb kasutada rakendusservereid. andmebaasi poole.  Keskkonnapõhiseid muutujad Näiteks WSDL ei tohi sisaldada NA-33 Arhitektuur peavad olema konfiguratsioonist viiteid arendusserveritele. seadistatavad. Kui kasutatakse Windows teenuseid peavad teenuste nimed NA-34 Arhitektuur olema serveri administraatori poolt konfigureeritavad. Andmebaas ei tohi sisaldada Rakenduse äriloogika tuleb äriloogikat, mis muudab NA-35 Arhitektuur realiseerida eraldi andmebaasist andmetabelites olevaid ja sinna sõltumatus rakenduskihis. kirjutatavaid andmeid. Erandiks on trigerid, mis tekitavad logi. Ei ole tohi kasutada selliseid platvormispetsiifilist lahendusi, mille Andmebaasis võib kasutada vaid üleviimine mõnele muule ISO/IEC 9075 standardiga kaetud andmebaasiplatvormile ei ole NA-36 Arhitektuur funktsionaalsusi. Kuid erandina ei võimalik. tohi kasutada sama standardi osas 13 kirjeldatud funktsionaalsusi. ISO/IEC 9075 osa 13 spetsifitseerib Javas kirjutatud programmimoodulite kasutamist andmebaasis. RIK kasutab keskset autentimislahendust (AUP). Kui kui mõni ärinõue välistab AUP kasutamise, esitab RIK arendajale lisanõuded autentimissüsteemile. Rakendus peab kasutama Kasutatavaid autentimisviise peab NA-37 Arhitektuur autentimiseks RIK olema rakenduse konfiguratsioonist autentimisportaali AUP. võimalik sisse ja välja lülitada. Samuti peab rakenduse konfiguratsioonist olema määratav kas ID-kaardiga autenimise korral kasutatakse OCSP või tühistusnimekirjade põhist autentimist. Uniform resource identifier (URI) pikkus ei tohi ületada ühegi IS poolt NA-38 Arhitektuur Max uri < 2000. toetatava brauseri maksimaalset lubatud väärtust. Rakenduse teenusekirjeldus (n: Näiteks: Alajaotis WSDL) peab olema üles ehitatud definitions/types/schem: NA-39 Arhitektuur nii, et see toetaks teenuse complexType defineerimisel tuleb versioneerimist. sellele lisada "any" element. Juhul kui äriprotsess seda võimaldab, tuleb suurte Rakenduse operatiivbaas peab NA-40 Arhitektuur andmemahtude korral kasutada olema võimalikult väike. andmete arhiveerimist põhibaasist väljapoole. Rakendusega tarnitavad litsentsid EU projektide korral tuleb kehtivusaja NA-41 Arhitektuur peavad olema vähemalt 5 aastase suhtes lähtuda EU või RIA nõuetest. kehtivusega.  Eraldatud peavad olema teenused, kuhu pöörduvad kasutajad ja need teenused, kuhu pöörduvad teised teenused ja serverid (näiteks saidid). Rakendus peab olema tehniliselt Avalikud liidesed tuleb selgelt osadeks jaotatud (tükeldatud) eristada muudest mitteavalikest, vastavalt loogilisele jaotusele. sisemistest, konfigureerimis jms NA-42 Arhitektuur Saadud osised peavad olema liidestest. Kui rakendusel on eraldi eraldi versioneeritavad ja turvatasemega liidesed ametnikule ja paigaldatavad. kodanikule, peab rakendus olema jaotatud kaheks eraldi liidesekomponendiks ning nende mõlema poolt kasutatavaks andmebaasiks. Kõik dokumentide konverteerimised ühest formaadist NA-43 Arhitektuur teise tuleb teha kasutades RIK keskseid dokumentide konverteerimise teenuseid. Süsteem ei tohi võimaldada kasutajale ligipääsu süsteemi NA-44 Arhitektuur toimimise informatsioonile, nagu failide täisnimed (path), kutsepinud (stack trace) jms. Rakendus peab olema võimeline SSL offload, vajalike NA-45 Arhitektuur töötama koormusjaoturitega kliendiparameetrite edasiandmine varustatud taristul. kasutades http headereid. Rakenduse failidele ei tohi olla NA-46 Arhitektuur rohkem ligipääsuvajadust, kui read- execute. Kui on planeeritud kasutada Windows servereid peavad kõik NA-47 Arhitektuur rakenduse osad (ka baas) olema võimelised töötama windows core serveritel. Näiteks, kui on tegemist Andmebaasis tuleb veerutüübiks kuupäevaga, siis date. Kasutada ei NA-48 Arhitektuur määrata selleks sisuliselt sobivaim tohi varchar(max) andmetüüpi, kui andmetüüp. see pole põhjendatud ja vajalik. Rakendus peab väljastama oma SOAP teenuste wsdl'e, REST NA-49 Arhitektuur masinliideste teenuste tehnilisi teenustele n:swaggeri v. openapi spetsifikatsioone. formaadis kirjeldusi. Active Directory (AD) autentimise kasutamisel peab rakendus kasutama SAML2.0 (Security Teiste standardite kasutus tuleb RIK- NA-50 Arhitektuur Assertion Markup Language) ja iga eelnevalt kooskõlastada. ADFS (Active Directory Federation Services) standardeid.  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 ID-kaardiga (kliendi sertifikaadiga) kohustuslikult nõutav: autentimist teostavad veebirakendused peavad (juhul, kui Apache: SSLVerifyClient require; NA-51 Arhitektuur sessiooni pole algatatud) suhtlema NGINX: ssl_verify_client on; kliendi veebirakendusega ainult Pulse TM: ssl.requireCert(); selleks, et saada veebirakendusest HAProxy: verify required; sisselogimiseks vajaliku koodi. 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 eesti keelse veateate. NB! Rakenduse javascrip-ti tuleb ID- kaardiga autentimise puhuks erand kirjutada! Tuleb kasutada vaid RIK poolt ette NA-52 Arhitektuur antud captcha lahendust. Rakendustevaheline suhtlus tuleb Sobivad liideste formaadid lepitakse NA-53 Arhitektuur realiseerida läbi rest- või soap-vms kokku projekti käigus. veebiteenuste või message queue. Serveris peab olema kirjeldatud, Mitte kirjeldatud meetoditele ei tohi NA-54 Arhitektuur millistele HTTP meetoditele vastata. vastatakse. Meiliaadress peab vastama RFC5322 ja/või RFC6854 standardile. Süsteem, kuhu on Vigastele meiliaadressidele ei tohi NA-55 Arhitektuur võimalik e-posti aadresse sisestada, kirju saata. peab kontrollima nende kehtivust. Kasutaja kontaktinfo tuleb alati valideerida. Rakendusel peab olema CSP Erandid tuleb kirjeldada NA-56 Arhitektuur header. Vaikeväärtus on "self". pigaldusjuhendis. Turvalisuse ja Tuleb arvestada tingimusega, et Kliendi ja serveri vaheline side terviklikkuse osad ühendused nõuavad NA-57 peab olema krüpteeritud SSL- tagamisega kahepoolset SSL autentimist (nt: protokolli kasutades. seotud nõuded suhtlus turvaserveriga).  Turvalisuse ja terviklikkuse Rakendus ei salvesta andmeid Erandiks on mitmekeelse süsteemi NA-58 tagamisega kliendi arvutisse (sh küpsiseid). puhul keelevalik. seotud nõuded Sessiooni lõpetamine Turvalisuse ja infosüsteemis (nt logi välja nupu terviklikkuse NA-59 vajutamine) peab serveri poolt tagamisega sessiooni tunnused kehtetuks seotud nõuded tunnistama (nt küpsised). Kõik andmemuudatused peavad baasis säilima. Andmete muutmisel andmeid ei kustutata, vaid tehakse uus kirje uute andmetega. Vana kirjed muudetakse kehtetuks. Iga uus kirje peab sisaldama vähemalt järgmist informatsiooni: Kui andmebaasis olevate andmete 1) viide kirjele, mille ta kehtetuks Turvalisuse ja turvaosaklass "terviklus" on 2 või 3, muutis (kui on); terviklikkuse tuleb kõik osaklassi 2 või 3 infot 2) kasutaja, kes kirje lõi; NA-60 3) kirje loomise aeg; tagamisega sisaldavad andmebaasi kirjed ja seotud nõuded tabelid versioneerida. [30.05.2023 4) sessiooni-ID (kui on olemas). DK nr 42 - muudetud] Iga kehtetuks tunnistatud kirje peab sisaldama lisaks vähemalt järgmist informatsiooni: 1) kasutaja, kes kirje kehtetuks tunnistas; 2) kirje kehtetuks tunnistamise aeg. Kui rakenduse poolt töödeldavate Testandmed peavad säilitama kõik andmete konfidentsiaalsusklass on toodangu andmete omadused Turvalisuse ja 2 või kõrgem, peab rakendusega (pikkuse, tüübi) ja omavahelised terviklikkuse NA-61 kaasas olema lahendus, mis suhted. Toodanguandmetest tagamisega suudab toota toodangu andmetest testandmete tegemise algoritmid ja seotud nõuded testandmed, mis ei sisalda põhimõtted tuleb eelnevalt konfidentsiaalset informatsiooni. kooskõlastada tellijaga. Schema muutmine ei ole rakenduse töö. Schema omanik ei tohi olla rakenduse tööks kasutatav baasi kasutaja. Turvalisuse ja Andmebaasis olevate rakenduse terviklikkuse kontod peavad omama ainult NA-62 tagamisega minimaalselt rakenduse tööks Nõude täitmiseks vajalikud vahendid seotud nõuded vajalikke õiguseid. (skriptid) peavad kuuluma rakenduse juurde ja nende sisu peab olema kontrollitav. Kontodele vajalikud õigused peavad olema kirjeldatud rakenduse installatsioonijuhendis. Turvalisuse ja Rakenduse lõppkasutajatele peab Rakendusepõhiseid kasutajarolle ei terviklikkuse NA-63 olema võimalik jagada õigusi läbi tohi defineerida ainult läbi AD OU'de tagamisega andmebaasis defineeritud rollide. ja gruppide. seotud nõuded Ligipääs rakendusse ja andmetele Turvalisuse ja tohib olla vaid dokumenteeritud terviklikkuse NA-64 ning tellimuses kirjeldatud teid tagamisega mööda ja dokumenteeritud seotud nõuded autentimisprotseduure kasutades.  Räsimine peab kasutama turvalist räsifunktsiooni (NA-74) ja soola (salt). Sool peab olema Turvalisuse ja Kõik paroolid ja salasõnad peab andmebaasiüleselt unikaalne, terviklikkuse rakendus alati salvestama vaid piisavalt suure bitiarvuga ja NA-65 tagamisega krüpteeritud või räsitud ja soolatud "random". Krüpteerimata kujul ei tohi seotud nõuded kujul. paroole salvestada (ka ajutiselt) ühelegi kettale. Krüpteering peab olema CBC, CRT vms režiimis. Kasutada ei tohi ECB režiimi. Kindlasti peab olema kasutusel ID- Rakendused, kuhu saavad ligi kaardi põhine autentimine. välised kasutajad, peavad Turvalisuse ja võimaldama autentimist vähemalt Kui on vajalik ka parooliga logimine, terviklikkuse NA-66 kahe erineva Eesti riigi poolt peavad välised kasutajad autentima tagamisega aktespteeritava kaheastmeilse ennast spetsiaalse väliskasutajate seotud nõuded isikutuvastsulahendusega. jaoks mõeldud AD pihta. Mingil juhul Parooliga autentimsit tuleb vältida. ei tohi väliskasutajaid teha RIK-i sisemisse AD-sse. Turvalisuse ja Kasutajaarvutitest otse x-tee terviklikkuse Rakendus ei tohi teostada X-tee NA-67 päringute tegemine on arvutivõrgu tagamisega päringut otse kasutajaarvutist. tasemel keelatud. seotud nõuded IIS puhul peab kasutama näiteks URL scan, apache puhul Veebipõhised välise veebilehega modsecurity või vastavat tööriista. Turvalisuse ja rakendused, mis on keskmise või Võimalikud piirangud tuleb kokku terviklikkuse NA-68 kõrgema ISKE klassiga peavad leppida tellijaga detailanalüüsi käigus tagamisega kasutama vahendeid kaitsmaks lähtuvalt tellija vajadustest ja seotud nõuded rakendust keelatud päringute eest. nõudmistest. Kasutama peab whitelisting põhimõtet, mitte blacklistingut. Sarnaselt õnnestunud sisselogimisega, tuleb ebaõnnestunud sisselogimise Kui rakenduse kaitsetarve on suur katsete korral kuvama millal need Turvalisuse ja või väga suur, peab rakendus toimusid ja mitu neid oli. Kasutaja terviklikkuse sisenemisel näitama pärast NA-69 peab saama soovi korral veenduda, tagamisega õnnestunud sisselogimist eelmise kas keegi pole tema nime all üritanud seotud nõuded õnnestunud sisselogimise aega. sisse logida. ID-kaardi, mobiil-ID ja [30.05.2023 DK nr 42 - muudetud] digi-ID-ga sisenemise ürituse ebaõnnestunud katseid näitama ei pea. Mõeldud on spetsiaalrakendusi Turvalisuse ja Rakenduse kasutajaliidesest peab (custom built). Nõue ei kehti terviklikkuse olema kasutajal avalehel ilma sisse veebitarkvara (apache, IIS jne), NA-70 tagamisega logimiseta võimalik näha andmebaaside jms kohta. Viimaste seotud nõuded rakenduse versiooni numbrit. versiooni numbrit tuleb pigem varjata. Aeg peab olema muudetav koos Sessioonide lõpetamine tuleb teiste Turvalisuse ja teostada serveri poolel ja kõigil konfiguratsiooniparameetritega. Kui terviklikkuse NA-71 rakendustel peab olema kliendilt pole etteantud aja jooksul tagamisega konfigureeritav kasutajasessiooni ühtegi päringut tulnud, tuleb seotud nõuded aegumise aeg. sessioon serveri enda algatusel lõpetada.  Veebipõhiste rakenduste Turvalisuse ja mitteautentinud kasutajate poolt Soovitatavalt tuleb seda teha enne terviklikkuse NA-72 saadetud vormid tuleb puhastada andmebaasi salvestamist, vajadusel tagamisega XSS-filtriga või eemaldada HTML- andmete väljakuvamisel. seotud nõuded tag´id. Veebipõhiste rakenduste poolt Turvalisuse ja saadetavad vormidel peab terviklikkuse NA-73 paiknema peidetud unikaalne räsi, Eesmärk on vältida CSRF rünnakuid. tagamisega mida kontrollitakse vormi seotud nõuded vastuvõtmisel. Valida tohib vaid neid, mille soovituslik kasutusaeg RIA krüptoprotokollide elutsükliuuringu uuringu kohaselt on üle 12 aasta. Kui räsimine ei pea tagama pikaajalist salastaatust ja tõestusväärtust võib tellijaga kokkuleppel kasutada algoritme, mille soovituslik kasutusaeg on krüptoprotokollide elutsükliuuringu uuringu kohaselt üle 5 aasta. Turvalisuse ja Krüpteerimise ja räside arvutamise Kui tehniliselt vähegi võimalik tuleb terviklikkuse NA-74 korral tuleb kasutada tugevaid sertifikaate hoida RIK HSM tagamisega algoritme. lahenduses. Ligipääs võtmetele ja seotud nõuded sertifikaatidele peab olema vaid teadmisvajaduse põhimõttel. Kirjandus: NIST SP-800- 57 Key Management Guidelinesja European Payments Council (2017) Guidelines on cryptographic algorithms usage and key management. Süsteemi kirjelduses tuleb välja tuua kõik krüptoalgoritmid, võtmepikkused ja kasutuskohad. Turvalisuse ja Autenditud sessiooni tunnust ei tohi Sessiooni ei tohi olla võimalik üle terviklikkuse ainult lihtsa küpsisega lahendada NA-75 võtta URLi kopeerimisega ühest tagamisega (kasutada OWASP parimaid arvutist teise. seotud nõuded praktikaid). Halduritel ei tohi olla võimalik Turvalisuse ja muuta rakenduseväliste liidestuste- Tagada tuleb rollide lahusus: terviklikkuse NA-76 ning nendega seotud äriloogiliste administraatoril ja halduril on tagamisega funktsionaalsuste tehnilisi erinevad tööülesanded. seotud nõuded konfiguratsioone. Turvalisuse ja ID-kaardiga autentimisel, peab terviklikkuse NA-77 rakendus suutma vastu võtta ID- Proxy tugi tagamisega kaardi sertifikaati ka HTTP päises. seotud nõuded Turvalisuse ja Kõik digitembeldamist vajavad terviklikkuse rakendused peavad kasutama RIK- NA-78 tagamisega i-keskset digitembeldamise seotud nõuded teenust.  Veebirakendus peab probleemideta läbima OWASP ASVS põhineva testi. Esmane väline turvatestimine Turvalisuse ja Rakenduse turvalisuse tagamiseks tellitakse tellija finantseeringul. Kui terviklikkuse (näiteks XSS, SQLInjection, jne) selle tulemusel leitakse arendaja NA-79 tagamisega tuleb järgida OWASP-i parimaid poolsest tegevusest või seotud nõuded praktikaid. tegevusetusest põhjustatud vigu, võib tellija nõuda OWASP järeltestide kompenseerimist arendajalt. Toodangukeskkonna rakendus ei tohi sisaldada osiseid, mis on Turvalisuse ja toodangu keskkonnas ebavajalikud terviklikkuse Arendus peab olema orienteeritud NA-80 või segavad (näiteks mõeldud tagamisega toodangukeskkonnas toimimiseks. testimiseks testkeskkonnas, seotud nõuded arendusabiks arenduskeskkonnas jne). Turvalisuse ja terviklikkuse Ajatemplite kasutamisel Ajatempli serveri URL peab olema NA-81 tagamisega eelistatakse Guardtime lahendust. konfigureeritav. seotud nõuded Turvalisuse ja Rakendus ei tohi lubada ühe terviklikkuse Nõue ei kehti, kui see tellija poolt NA-82 kasutajaga mitut samaaegset tagamisega eraldi ärinõuetes nõutud. sessiooni. seotud nõuded Konkreetne lahendus valitakse ja lepitakse tellijaga eraldi kokku. Käesoleva nõude täpsustuseks vt ISKE nõue HT.34. Ajatemplite, digitemplite ja digitaalallkirjade terviklust tuleb reaalajas ja hiljem perioodiliselt (muudetava perioodiga) valideerida. Valideerimise protsessi Kui rakenduse tervikluse tulemusena tuleb genereerima Turvalisuse ja turvaosaklass on T3, peavad automaatne raport, mis on vaadeldav terviklikkuse tõestusväärtust omavad andmed süsteemi halduri liidese kaudu ning NA-83 tagamisega olema digitaalallkirjastatud või mida on võimalik automaatselt seotud nõuded digitembeldatud. [30.05.2023 DK edastada ettenähtud e-posti nr 42 - muudetud] dressidele. Raport peab sisaldama infot valideerimise protsessi alguse ja lõpu aja kohta, infot selle kohta, kui mitut ajatemplit kontrolliti ja kas infot kõik ajatemplid olid korrektsed. Kui tembeldamises või allkirjastamises ilmneb viga, peab olema võimalik hiljem katkenud kohast tembeldamist või allkirjastamist jätkata.  Ahela moodustamiseks ei tohi kasutada andmetesse kirja pandud viiteid (n: id=2ja andmed="mingid andmed", eelmine_andmed=1 ). Krüptoahela koostamisel tuleb kasutada lahendust, kus järgmise ajatembeldatava kirje koosseisu fikseeritakse eelmise kirje mitte ajatembeldatud räsi. Uue ahela lüli Kui rakenduse tervikluse lisamisel tuleb kontrollida eelmise lüli turvaosaklass on T3, peavad korrektsust. Turvalisuse ja tõestusväärtust omavad andmed ja terviklikkuse logid olema krüptoaheldatud, et NA-84 tagamisega tagada, et tõestusväärtusega Tagatud peab olema ka nõue, et seotud nõuded andmeid ei saaks märkamatult kirjeid ei saaks märkamatult kustutada. [30.05.2023 DK nr 42 - kustutada ahela lõpust. Krüptoahela muudetud] terviklust peab saama perioodiliselt (muudetava perioodiga) kontrollida ja lahendus peab suutma vajadusel and häire (e-kiri) kui terviklus on kompromiteeritud. Krüptoaheldamis e ja selle kontrolli sisse ja väljalülitamine ning kontrolliperioodi muutumiine peab olema teostatav vaid rakenduse konfiguratsioonist rakenduse administraatori poolt, Sümmeetrilise võtme turvamiseks tuleb kasutada asümmeetrilisi algoritme. Sertifikaati tuleb hoida nii, Turvalisuse ja Kui rakenduses on S3 salastatuse et see oleks kättesaadav terviklikkuse astmega andmeid, peavad need nii rakendusele, kuid mitte NA-85 tagamisega transpordil kui ka salvestatult alati rakendusserveri administraatorile. seotud nõuded olema krüpteeritud kujul. Sertifikaat peab olema vahetatav, st krüptograafia edasi arenedes peab olema võimalik kasutusele võtta tugevam sertifikaat. Kui paks klient kasutab ajutisi faile, Paksu kliendi korral ei tohi tuleb tagada nende perioodiline rakendus kasutaja tööjaama jätta Turvalisuse ja kustutamine tagamaks, et ei maha krüpteerimata kujul ajutisi terviklikkuse koormata liigselt kasutaja arvutit. NA-86 faile, mis sisaldavad või võivad tagamisega Eesmärk on tagada, et rakenduse sisaldada konfidentsiaalset või seotud nõuded sulgemisel ei jääks kasutaja kõrget terviklust nõudvat arvutisse maha informatsiooni, mida informatsiooni. sinna jääda ei tohiks. Turvalisuse ja Rakendus peab serverist Kui kasutatakse ajutiste failide terviklikkuse NA-87 kustutama kõik ajutised failid kausta peab selle asukoht olema tagamisega koheselt, kui neid enam ei kasutata. konfiguratsioonist konfigureeritav. seotud nõuded Rakendus tohib aktsepteerida vaid Turvalisuse ja sessioonivõtmeid, mida ta ise on terviklikkuse väljastanud. Sisselogimisel peab NA-88 tagamisega kasutaja saama uue sessiooni seotud nõuded võtme ning endine võti tuleb kehtetuks tunnistada.  Faili nimes tuleb lubada vaid suur- ja Kui rakendusse laaditakse faile väiketähti, numbreid, "_" ja "-" ning Turvalisuse ja kasutaja poolt, peab need failid vaid ühte punkti järjest. Viirusetõrje terviklikkuse NA-89 valideerima (kontrollima faili tüüpi, lahenduse pakub välja RIK tagamisega suurust). Failid peavad läbima infrastruktuuride osakond. seotud nõuded viirusetõrje. Võimalusel tuleb teha tüübi ja faili laiendi vastavuse kontroll. Turvalisuse ja Kui rakendusse laetakse faile peab terviklikkuse faili nimi salvestamisel sisaldama NA-90 tagamisega random komponenti nii, et faili tee seotud nõuded ei ole lihtsalt ära arvatav. Turvalisuse ja Iframe-i kasutamine pole lubatud ja terviklikkuse Rakendus ei tohi lubada ennast NA-91 HTTP päringutele tuleb lisada "X- tagamisega kasutada iframe sees. Frame-Options: DENY" päis. seotud nõuded Turvalisuse ja Sessiooni küpsise korrala tuleb terviklikkuse Sessiooni küpsised peavad olema lisada lipud Secure, HttpOnly NA-92 tagamisega turvatud. ja SameSite. Küpsise nime prefiks seotud nõuded peab olema "__Host-". Testplaan ja testitulemused tuleb Logimine, Rakenduse kõik üleantavad edastada tellijale koos rakenduse NA-93 debuggimine, versioonid peavad enne tellijale üle üleandmisega. Nõuded testimisele testimine andmist olema testitud. RIK dokumendis "Arendamise tavad ja töökorraldus". Vastav logi peab asuma teistest logidest eraldi failis ja andmebaasis Turvalisuse seisukohalt kriitilised turvalogide tabelis. Väliste Logimine, sündmused, nagu sessiooni rakenduse puhul tuleb logida NA-94 debuggimine, algamine ja lõppemise, rolli võimalusel kasutaja IP. Sessiooni testimine muutumine jne tuleb logida. võtmete väärtuses, privaatvõtmeid ja kasutaja salasõnad võivad logisse jääda vaid räsitud kujul. 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. Logimine Rakendus peab suutma logida kõiki Logimine, peab olema võimalik nii andmebaasi väliste süsteemidega vahetatavaid NA-95 debuggimine, kui ka failisüsteemi (iga sõnum eraldi (ka X-tee teenuste kaudu liikuvaid) testimine faili, failid vähemalt päeva kaupa pöördumisi andmevahetuslogisse. eraldi kaustas) või mõlemasse korraga. Logifaili asukoht peab olema administraatori poolt ilma rakendust uuesti kompileerimata seadistatav.  Logi salvestatakse kasutaja tegevuse logisse. Logi peab sisaldama (toodud järjekorras) millal tehti, kasutaja ID ja isikukood (firma registrikood), kui võimalik kust tehti (seadme nimi, IP, sertifikaat), mis tegevused andmetega tehti ja kas tegevus õnnestus. Kui võimalik siis päringu SQL lause. Logida peab Kui rakenduse turvaosaklass olema võimalik ka konkreetseid "konfidentsiaalne" on 2 või 3, peab andmed, mida kasutaja serveri Logimine, tagama konfidentsiaalsuse arvates nägi. Viimane peab aga NA-96 debuggimine, osaklassiga 2 ja 3 andmete olema välja lülitatav või asendatav testimine vaatamise logimise. [30.05.2023 põhiobjektide ID-dega päringu liikide DK nr 42 - muudetud] kaupa. Logida tuleb ka kasutajate tegevuste ebaõnnestumised (näiteks õiguste puudumise tõttu). Vastav logi peab asuma tegevuslogi andmebaasi tabelis. Logimise konfiguratsioon peab olema muudetav vaid uue rakenduse paketiga (deploy). Näiteks IOC konteinerist konfigureeritav (late binding). Logi salvestatakse kasutaja tegevuse logisse. Logi peab sisaldama (toodud järjekorras) millal tehti, kasutaja ID ja isikukood (firma registrikood), kui võimalik kust tehti (seadme nimi, IP, sertifikaat), mis Kui rakenduse turvaosaklass tegevused andmetega tehti ja kas "terviklus" on 2 või 3, peab tagama tegevus õnnestus. Kui võimalik siis Logimine, tervikluse osaklassiga 2 ja 3 päringu SQL lause. Logida tuleb ka NA-97 debuggimine, andmete loomise, muutmise ja kasutajate tegevuste testimine kustutamise logimise. [30.05.2023 ebaõnnestumised (näiteks õiguste DK nr 42 - muudetud] puudumise tõttu). Vastav logi peab asuma tegevuslogi andmebaasi tabelis. Logimise konfiguratsioon peab olema muudetav vaid uue rakenduse paketiga (deploy). Näiteks IOC konteinerist konfigureeritav (late binding). Süsteemi logid peavad asuma teistest logidest eraldi failis ja andmebaasi süsteemi logide tabelis. Logi peab sisaldama minimaalselt (toodud järjekorras) vea tekkimise aega, veakoodi, veakirjeldust (stack Logimine, Rakendus peab logima kõiki trace, traceback vms), võimalusel NA-98 debuggimine, rakenduses tekkivaid tehnilisi vigu kasutaja andmeid (nimi, ID, IP ja testimine süsteemi logisse. URL), HTTP-, GET- ja POST- parameetrid ja nende väärtusi. Kas logitakse baasi või faili või mõlemasse peab olema rakendust uuesti kompileerimata administraatori poolt muudetav.  Peab olema võimalus logimist välise Failisüsteemi logimise korral süsteemi kaupa sisse-välja lülitada. peavad logid olema ka Ei tohi esinda olukorda, kus ühte katalogiseeritud (näiteks liigi järgi) Logimine, kausta tekib rohkem kui 10000 faili. ja tunnustatud faililaiendiga NA-99 debuggimine, Peab tagama, et iga rakendusserver (näiteks .log, .txt, .xml). Logi peab testimine saaks vajadusel kirjutada logid oma olema roteeruv, et ei tekiks liiga logifaili. Logifaili asukoht peab olema suuri faile või faile kus on vaid administraatori poolt ilma rakendust üksikuid logikirjeid. uuesti kompileerimata seadistatav. Logiväljad, mida lõppkasutaja saab manipuleerida (IP, useragent, URL) peavad salvestuma logisse kodeeritud kujul. Tuleb võimalusel vältida olukorda, kus ühe päringu tõttu tekib kirjeid mitmesse logisse. Igas logikirjes peab olema päringu unikaalne identifikaator, mis võimaldab logikirjet siduda teiste logikirjetega, mis tekkisid sama päringu tagajärjel. Seda nii ühe faili piires, kui ka juhul kui päringu tulemusel kirjutati mitmesse logi asukohta.. Kogu rakenduse logi peab olema Logimine, ühesuguse formaadiga, kergesti Sama infot sisaldavad väljad peavad NA-100 debuggimine, masinloetav ja täielik (kes, mis, (ka erinevates) logiasukohtades testimine mida, jms). Logis ei tohi kasutada olema sama nimega ja andmed klassifikaatoreid. samas formaadis. Failisüsteemis asuv logi peab olema XML, JSON või CSV formaadis. Kui parameetri väärtus on tühi, tuleb see logis märkida asendusväärtusega (nt “null”). Kui vähegi võimalik peab logi kuupäeva ja ajaformaat olema kujul "AAAA-KK- PP ja hh:mm:ss,nnnn“ lokaalne Eesti ajavöönd. "hh" järgib 24-tunnist kellaajaformaati. Kuupäev ja kellaaeg samas andmeväljas esitatakse kujul, kus kuupäevavormingu ja kellaajavorming vahele lisatakse täht T. Tabeli suurenedes peab olema võimalik hoida vanu kirjeid, näiteks Logimine, Logi tabelid peavad olema kuude või aastate kaupa, NA-101 debuggimine, arhiveeritavad operatiivbaasist iseseisvates tabelites või teises testimine välja. baasis. Mehhanism peab töötama ka krüptoaheldatud logi korral. Kui rakendus kasutab või pakub Näiteks kui palju on kasutatud kuus, Logimine, väliseid teenuseid (näiteks SK aastas jne digitembeldamist, ID- NA-102 debuggimine, teenuseid) peab ta suutma autentimist, autentimisportaali, testimine arvestust pidada vastavate pangalingi kasutamist jne. teenuste kasutamise mahu üle.  Jõudlustestide täpne kirjeldus tuleb kokku leppida detailanalüüsi käigus. Arendaja peab koos rakendusega tarnima skripti ja vajalikud Logimine, Rakendusega peab olema kaasas tarkvaralised vahendid kokkulepitud NA-103 debuggimine, skript jõudlustestide tegemiseks. jõudlustestide läbiviimiseks. testimine Jõudlustestide läbiviimine ei tohi nõuda tellijalt omapoolset tarkvara arendamist, skriptide kirjutamist või litsentside ostmist. Rakendusel peab olema Logimine, masinloetav XML-staatusleht, mille Staatuslehe nõuded sisalduvad NA-104 debuggimine, struktuur vastab tellija poolt ette käesoleva dokumendi lisas 1. testimine antud XML struktuurile. Nõuet ei arvestata arendustarkvara Lähtekoodi kommentaarid peavad poolt automaatselt genereeritavate Nõuded kõigis lahenduse kihtides koodilõikude puhul. Samuti ei NA-105 lähetkoodile ja (rakenduse enda kood, rakendata nõuet kolmandate paigaldamisele andmebaas, jne) olema kirjutatud osapoolte poolt toodetud eesti keeles. lähtekoodile – nt: erinevad lahtise koodiga kooditükid jne. Lähtekoodi kommentaarid peavad olema: 1. Põhjendatud. Kommenteerida ainult kommenteerimise pärast pole vaja. Kood peab olema kirjutatud selliselt, et see on loetav ka ilma kommentaarideta. Rakenduse kood peab olema Kommentaarid on mõeldud Nõuded piisavalt hästi kommenteeritud, et keeruliste ja/või kohendamist NA-106 lähetkoodile ja erialast haridust omav ja/või edasist tööd (viimaste paigaldamisele tarkvaraarendaja on võimeline juurde on tuleks märkida TODO) süsteemile jätkuarendusi teostama. 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. Muutujate, tüüpide ja funktsioonide Nõuded nimed peavad olema sisulised ja NA-107 lähetkoodile ja andma selget informatsiooni nende paigaldamisele otstarbest. Koodis kasutatavaid konstante ei Nõuded tohi väärtusena hardcodeda – need NA-108 lähetkoodile ja tuleb defineerida muutujatena ja paigaldamisele kasutada läbi nende. Koodis defineeritud andmetüübid Nõuded peavad olema nimetava käände Näiteks "Isik", "Menetlus" jne. NA-109 lähetkoodile ja ainsuses. Kõik andmemassiivid Andmebaasides ei tohi kasutada paigaldamisele tuleb nimetada nimetava mitmuses täpitähti. (näiteks collectionid, arrayd, jms).  Andmetabelites sisalduvad Nõuded Näiteks kui on tegu tabelitega ’Isikud’ võõrvõtmed peavad nime järgi NA-110 lähetkoodile ja ja ’Autod’, siis seos ’isiku autod’ seostuma tabeli ja väljaga millele paigaldamisele oleks: Isikud.ID=Autod.Isik_ID need viitavad. Nõuded Näiteks Oracle korral Andmebaasi väljade pikkused tuleb NA-111 lähetkoodile ja Nvarchar(2000) tähendab 2000 baiti kirjeldada tähemärkides. paigaldamisele mitte tähemärki. Kui kokku pole lepitud teisiti, siis Nõuded Valideerimiseks kasutatakse JAVA rakenduse kood peab olema NA-112 lähetkoodile ja 'checkstyle' vaikimisi kirjutatud vastavalt "SUN Java paigaldamisele konfiguratsiooni. Code convention" dokumendile. Kui kokku pole lepitud teisiti, siis Nõuded Python rakenduse kood peab http://www.python.org/dev/peps/pep NA-113 lähetkoodile ja olema kirjutatud vastavalt "Style -0008/ paigaldamisele Guide for Python Code " dokumendile. Kui kokku pole lepitud teisiti, siis .NET rakenduse kood peab olema http://msdn.microsoft.com/en- Nõuded kirjutatud vastavalt "NET us/library/ms229042.aspx. NA-114 lähetkoodile ja Framework Developer's Guide - Valideerimiseks kasutatakse paigaldamisele Design Guidelines for Developing 'StyleCop' vaikimisi konfiguratsiooni. Class Libraries". Näiteks PMD (http://pmd.sourceforge.net), Nõuded JAVA koodi valideerimiseks DocCheck NA-115 lähetkoodile kasutatakse validaatorit. (http://java.sun.com/j2se/javadoc/do ccheck/) või muud võrreldavat kokkulepitud validaatorit. Näiteks FxCop Nõuded .NET koodi valideerimiseks (http://msdn.microsoft.com/en- NA-116 lähetkoodile kasutatakse validaatorit. us/library/bb429476.aspx) või muud võrreldavat kokkulepitud validaatorit. Näiteks Pychecker Nõuded Pythoni koodi valideerimiseks (http://pychecker.sourceforge.net/) NA-117 lähetkoodile kasutatakse validaatorit. või muud võrreldavat kokkulepitud validaatorit. Kasutuses mitteolev kood tuleb Nõuded NA-118 rakenduse lähtekoodist lähetkoodile kõrvaldada. Andmebaasi tabelid ja väljad ning muu kood (stored procid, funktsioonid, triggerid, viewd, user Nõuded NA-119 defined data types ja sequencid) lähetkoodile peab olema kommenteeritud rakenduse koodiga samadel alustel.  Mitte Dossier vaid Toimik, mitte Person vaid Isik. Lähtekoodis defineeritud muutujate, klasside/tabelite, NB! Nõuet ei arvestata Nõuded meetodite jm. nimed peavad arendustarkvara poolt automaatselt NA-120 lähetkoodile lahenduse kõigis kihtides genereeritavate koodilõikude puhul, (rakenduse enda kood, andmebaas mida ei ole vaja tõlkida. Samuti ei jne) olema eesti keelsed. rakendata nõuet kolmandate osapoolte poolt toodetud lähtekoodile. Aadressiandmete sisestamisel, Liidestatakse maa-ameti X-tee Andmekvaliteet kuvamisel ja hoidmisel tuleb teenusega või RIK sisemise vastava NA-121 ja standardid lähtuda määrusest Maa-ameti andmeid vahendava "Aadressiandmete süsteem". süsteemiga. Muu hulgas peab kontrollima, kas sisestatav väärtus vastab välja tüübile ja/või etteantud valikväärtustele. Numbriväljale tohib sisestada vaid numbreid, kuupäeva väljale kuupäeva, elektronposti aadressi vilajale elektronposti aadressi, valikväärtuste korral vaid lubatud valikväärtused jne. Andmete sisestamisel (ka läbi Kontrollima peab sisendi suurust. masin-masin liideste või Olukorras, kus veebirakendus peab Andmekvaliteet veebiteenuste) peab rakendus alati NA-122 töötlema potentsiaalselt ohtlikke ja standardid andmed valideerime. Sobimatuid andmeid (nt tähemärke, millel on andmeid ei tohi olla võimalik rakendatava sisestada. interpretaatorprogrammi jaoks tähendus) ja filtreerimisfunktsiooni ei saa seega kasutada, tuleb need andmed ära maskeerida, st muuta nende kuvamisvormingut. Sisendi kontrolli ebaõnnestumise korral tuleb peatada sisendi kasutamine ja kasutajat sellest teavitada. Iga transaktsiooni juures tuleb Andmekvaliteet veenduda, et kasutajal on õigus NA-123 ja standardid neid vaadata või muuta (isiku õiguste, mitte rolli õiguste kontroll) Tegevusalade andmete sisestamisel, kuvamisel ja hoidmisel tuleb lähtuda Vabariigi Andmekvaliteet Valitsuse 10. Jaanuari 2008. a Liidestatakse RIK EMTAK NA-124 ja standardid määrusest nr 11 "Klassifikaatorite infosüsteemi teenusega. süsteem" ja kasutada EMTAK infosüsteemis kehtivat klassifikaatorit. Kasutaja poolt sisestatud andmed Andmekvaliteet Kasutada tuleks võimalusel NA-125 tuleb enne välja kuvamist ja standardid Blacklistingu asemel whitelistingut. filtreerida.  Kui rakendusel tekib päringu Andmekvaliteet töötlemisel tehniline viga, siis peab Näiteks: "Tekkis tehniline viga. NA-126 ja standardid vastama süsteemi-infot Päringu ID: XXXXX". mittesisaldava veateatega. Erandiks võivad olla tellijaga Dokumentatsioo Kogu rakenduse dokumentatsioon kokkuleppel kolmanda osapoole NA-127 n peab olema kirjutatud eesti keeles. komponentide (mis pole kirjutatud tellija jaoks) dokumentatsioon. Rakenduse dokumentatsioon peab Dokumentatsioo NA-128 vastama RIK n dokumentatsiooniplaani nõuetele. Iga uue versiooniga peab alati välja Release notes peab kajastama kõiki Dokumentatsioo NA-129 tooma versiooni muudatuse muudatusi eelmise ja uue versiooni n kirjeldused (release notes). vahel. Kõik rakenduse testimiseks, koolituseks või implementeerimiseks üle antavad Arendajale antakse selleks õigused tarkvarapaketid peavad olema NA-130 Versioonihaldus RIK-i koodihoidlas, kus ta peab versioneeritud vastavalt hoidma oma PMA versioone. dokumendile RIK Arendamise tavad ja töökorraldus. Kasutama peab RIK-i koodihoidlat. Paralleelse arendamise puhul Arendaja peab veenduma, et teeb NA-131 Versioonihaldus võetakse igal hommikul RIK muudatusi aktuaalsesse koodi. koodihoidlast viimane seis koodist. Kõik rakenduste tellijale Ka tagant järgi peab olema 100% lepingujärgsete üleantavate kindel, et üle anti õige arendaja NA-132 Versioonihaldus versioonide lähtekoodid peavad signeeritud, mitte kolmanda olema varustatud arendaja osapoole poolt kompromiteeritud esindaja digiallkirjaga. versioon. Nii arendamisel kui ka hoolduslepingute korral Kui ei ole tellijaga kokku lepitud NA-133 Versioonihaldus kasutatakse RIK vigadehalduse teisiti. keskkonda. Puhas link on inimloetav, tähendust Kui veebirakenduses või veebilehel omav, paraja pikkusega, tekstiline on linke, mida kasutajad näevad või (erandina lubatud numbrid ja märgid NA-134 Versioonihaldus millele nad saavad viidata, peavad „/“, „.“, „-“ ja „_“) ja ajas püsiv. need olema puhtad lingid. Veebisaidi igal kuval peab olema unikaalne link. Kooste kirjelduste alusel valmiv Näiteks: kompileeritavate keelte paigalduspakett tohib sisaldada Paigalduspaketi puhul ei tohi sisaldada lähtekoodi, kui NA-135 ainult minimaalse rakenduse kooste see pole vajalik rakenduse käitamiseks vajamineva käitamiseks. failikomplekti. Kooste kirjelduste alusel valmivat Eelkõige ei tohi tekitada olukorda, Paigalduspaketi paigalduspaketti peab olema kus rakenduse jooksutamiseks uues NA-136 kooste võimalik liigutada erinevate serveris, tuleb see tingimata just serverite vahel. sealsamas kokku kompileerida. Lähtekoodi kompileerimine peab Selle nõude täitmise võimaldamiseks Paigalduspaketi NA-137 olema teostatav ka Interneti on RIK-is kasutusel sisemised kooste ühenduse puudumise korral. tarkvarakomponentide repod.  Paigalduspaketi Andmebaasi paigalduse skriptid ei Administraator peab saama NA-138 kooste tohi olla kompileeritud. veenduda skriptide sisus. Lisad: Lisa 1 – Staatuslehe nõuded  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: SA-v 1.1 Loomise eesmärk/taust SA-v 1.2 Tekkimise aeg SA-v 1.3 Autor SA-v 1.4 Viimase muutmise põhjus SA-v 1.5 Viimase muutmise aeg SA-v 1.6 Muutja SA-v 1.7 Kui on tegemist nõuete komplektiga (või plokiga), siis peavad olema selgelt eristatavad pealkiri ja sisu SA-v 2. Oleku info: SA-v 2.1 Kinnitaja ja kooskõlastajad SA-v 2.2 Nõude/nõuete komplekti seis - kasutusel olevad olekunäitajad peavad olema kokkulepitud vastavalt antud projekti vajadustele. Näiteks võivad nõude/nõuete komplekti olekud olla: tegemisel kooskõlastamisel kinnitatud implementeeritud kehtetu SA-v 3. Identifitseerimise info: SA-v 3.1 Igal nõudel/reeglil ja nõete komplektil peab olema unikaalne identifikaator II. Sisu Alljärgnevalt on kirjeldatud nõuded süsteemianalüüsi sisule. SA-s 1. Loetavus ja mõistetavus. Süsteemianalüüs peab olema: SA-s 1.1 Loetav ja selge SA-s 1.2 Kindlas kõneviisis SA-s 1.3 Sisaldama üheselt defineeritud äri- ja süsteemi mõisteid SA-s 1.4 Sisaldama ainult täpseid andmeolemite/andmeväljade nimetusi SA-s 2. Infosüsteemi terviku kirjeldus Infosüsteemi terviku kirjelduses peavad olema: SA-s 2.1 Kõikide kasutatavate mõistete definitsioonid SA-s 2.2 Kõikide äriobjektide ja neile vastavate andmeolemite ning seoste kirjeldused ning üldised tööpõhimõtted SA-s 2.3 Andmeolemite kõik andmeväljad ja nende sisu vastastikune mõju üksteisele SA-s 2.4 Infosüsteemi erinevate kihtide kirjeldused: andmevahetus/kasutajaliides, domeen ja andmebaas. SA-s 2.5 Andmete käitlemine antud süsteemis: SA-s 2.5.1 versioneerimine SA-s 2.5.2 sünkroniseerimine SA-s 2.5.3 arhiveerimine SA-s 2.5.4 kustutamine SA-s 2.6 Kasutusel väljade ja kasutatavate andmeolemite täpsed nimetused SA-s 2.7 Õiguste kirjeldused: kasutajad, rollid, grupid SA-s 2.8 Süsteemi üldised valideerimised SA-s 3. Vormide kirjeldused SA-s 3.1 Kõik kasutajaliidesevormid ja vormide elemendid peavad olema nõuetega/reeglitega kaetud SA-s 3.2 Peab olema loodud prototüüp, mis kajastab kõike realiseeritavat. Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames. SA-s 3.3 Iga vormi/vormi osa eesmärk peab olema selge - lühike ja täpne kirjeldus, milleks seda vormi on vaja. SA-s 3.4 Iga vormi jaoks peavad olema välja toodud kõik vormiga seotud sisulised veateated. Märkus: Sõltuvalt projekti kokkulepetest võib seda osa teha ka UX inimene UX ja ärianalüüsi tööde raames.  SA-s 3.5 Iga vormi toimimise juures peavad olema välja toodud erandid, kui need on olemas, võrreldes selle konkreetse süsteemi üldiselt kehtivate reeglitega SA-s 3.6 Igal vormil peavad olema välja toodud kõik sellega seotud valideerimised ning nendega seotud süsteemi poolt tagastatavad veateated ja hoiatused SA-s 3.7 Vormi andmeväljade sisestamise ja muutmise kirjeldused; kes (süsteem, kasutaja, sidussüsteem, genereeritakse jooksvalt, ...), mis tingimustel, kuidas? SA-s 3.8 Millised andmeväljad on SA-s 3.8.1 kohustuslikud SA-s 3.8.2 valikulised SA-s 3.8.3 ainult kuvatavad SA-s 3.8.4 tingimuslikult kuvatavad vs alati kuvatavad SA-s 3.8.5 vaikeväärtustega täidetavad + millised need vaikeväärtused on SA-s 3.9 Lubatud väärtused väljadele (tekst, numbrid, e-mail, komakohad, jne) SA-s 3.10 Kuidas antud vormile saab - kui see ei tule välja punktis SA-s 4 nõutud kirjeldustest SA-s 4. Kasutuslugude/vormide kasutamise protsesside/tegevuste kirjeldused SA-s 4.1 Kuidas on erinevad vormid omavahel seotud SA-s 4.2 Kasutajate tegevuste ja tegevuste kogumite kirjeldused SA-s 4.3 Süsteemi terviklikud kasutamise protsessid/kasutuslood SA-s 4.4 Kriitiliste funktsionaalsuste jaoks testimise stsenaariumid 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: SA-s 5.1 Tarbitavad teiste süsteemide teenused (kui on) SA-s 5.1.1 Kõik edastatavad sisendid SA-s 5.1.2 Kõik tarbitavad väljundid - millised ja kus, kuhu edasi saadetakse/märgitakse/salvestatakse SA-s 5.2 Kõik infosüsteemi enda poolt pakutavad teenused (kui on) SA-s 5.2.1 Iga teenuse kohta detailne sisendite kirjeldus SA-s 5.2.2 Iga teenuse kohta detailne väljundite kirjeldus SA-s 5.2.3 Iga teenusega kaasnevad valideerimised ja sisulised veateated SA-s 5.2.4 Iga teenuse enda loogika ja funktisonaalsuse kirjeldus SA-s 6. Pildid, skeemid, diagrammid: Peavad: SA-s 6.1 toetama kirjeldatavat - olema tervikliku kirjelduse osa, mitte tühjalt genereeritud pildialbum SA-s 6.2 omama selget eesmärki - milleks see pilt/skeem/diagramm on, mida ta annab?  SA-s 6.3 olema intuitiivselt loetavad Lisaks: SA-s 6.4 Teenuste puhul on hea lisada ka XML 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- Kõikide üle antavate tarkvara versioonidega peavad kaasas olema vastavad testid, nendega seotud dokumentatsioon ning kirjelduse või raporti leitud ja parandatud vigadest. TE-Y-1 AO-N- Tarkvara vastuvõtmiseks vajalikud hankevõitja poolsed testimised ja skoop (osa testplaanist) lepitakse kokku projekti alguses ning seda muudetakse poolte kokkuleppel. TE-Y-2 AO-N- Vastavalt kokkuleppele tuleb koostada ning üle anda punktis AO-N-TE-Y-2 nimetatud testplaan ja testlood ning eraldi testprojekti ja -programmi puhul ka vajaminev dokumentatsioon ja TE-Y-3 kirjeldus. AO-N- 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. TE-Y-4 AO-N- Üle antud testides või vastuvõtutestimisel esinenud probleemid tuleb parandada sarnaselt põhiarendusega. TE-Y-5 AO-N- 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 TE-Y-6 vm.). AO-N- Ü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 TE-Y-7 Gattling'us. Kokkuleppel Java+JUnit, Cypress või muu. 2. Dokumentatsioon AO-N-TE-D Nõue Sisu AO-N-TE-D- Dokumentatsiooni eesmärgiks on edasi anda kogu vajalik informatsioon testide kohta (testplaanid, testlood, testide käivitamiseks, jooksutamiseks ja valideerimiseks vajalik informatsioon 1 jne). AO-N-TE-D- Dokumentatsioon peab olema versioneeritud ning iga punkti (Näiteks Testlugu) juures peab olema tekkimise aeg, viimase muudatuse aeg, autor, muutja. 2 3. Testplaan ja -lood AO-N-TE-T Nõue Sisu AO-N- Testplaanile ja –lugudele rakendub peatükk AO-N-TE-D-2 . TE-T-1 AO-N- Testplaan kirjeldab ning selgitab kogu tarkvaraga seotud testimist, kui ei ole kokku lepitud teisiti. TE-T-2 AO-N- Testlood tulenevad kasutuslugudest ja/või süsteemianalüüsi nõuetest, nende kattumisel piisab testimise kirjeldusest, et vältida dokumentatsiooni dubleerimist. TE-T-3 AO-N- Testloos peab minimaalselt olema: testi kirjeldus, viide nõudele või kasutusloole, etapid, oodatud tulemus, tegelik tulemus. TE-T-4 AO-N- 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 TE-T-5 nimetamisloogika ja kommentaarid teevad kergelt selgeks tegevuste ahela). 4. Logimine, raporteerimine AO-N-TE-R Nõue Sisu AO-N- Raportitele rakendub peatükk AO-N-TE-D-2 . Eraldi raporteid pole tingimata vaja kui kasutatakse ühist JIRA + Confluence keskkonda. TE-R-1 AO-N- Testraportis kajastatud vigade juures peab olema märgitud tarne versioon, milles viga leiti ning milles see on kõrvaldatud. TE-R-2 AO-N- Automaatsete testide puhul peab automaatselt genereeruma testraport või statistika tegemiseks vajalik logi (Näiteks NUnit genereerib ise raporti, JMeteris Summary Report+ Aggregate Report TE-R-3 või eraldi .csv fail jne.).  AO-N- Koormus- ja stressitestide puhul peab raport kajastama, millise koormuse juures hakkasid testid negatiivseid tulemusi saama ning millised vead esinesid. TE-R-4 AO-N- 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 TE-R-5 (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- 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. N-1 AO-N-TE- 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.). N-2 AO-N-TE- 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). N-3 AO-N-TE- Iga teenuse kohta peab olema Smoke test, mis kontrollib lihtsaima sisendiga teenuse töökorda. N-4 AO-N-TE- 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 N-5 integratsioonitestide jaoks). AO-N-TE- Testsessioonid ning omavahel mitte seotud testid ei tohi üksteist mõjutada. N-6 6. Lähtekood ja spetsiaalsed tööriistad AO-N-TE-I Nõue Sisu AO-N-TE-I- Spetsiaalselt arendatud testprojektile ja -programmile rakenduvad „Nõuded arendustele –Nõuded rakenduse koodile" . 1 AO-N-TE-I- Spetsiaalselt arendatud testprojektid peavad kasutama üldtuntud raamistikke Näiteks NUnit, JUnit. 2 AO-N-TE-I- 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 3 kirjutata käsitsi).  AO-N-TE-I- Punktis AO-N-TE-I-3 mainitud tööriistad ja nende parandused tuleb tarnida koos testidega. 4 7. Alusandmed AO-N-TE-A Nõue Sisu AO-N-TE- Alusandmete genereerimiseks vajalik peab olema vastavate testidega kaasas. A-1 AO-N-TE- Kui testimiseks on vajalikud andmed teistest süsteemidest, siis nende saamine lepitakse eelnevalt kokku. A-2 AO-N-TE- Alusandmed peavad töötama erinevates keskkondades, kaasa arvatud andmed, mida päritakse teistest süsteemidest. A-3 AO-N-TE- Peab vältima teiste süsteemide andmete rikkumist, selle vältimiseks vt. punkt AO-N-TE-A-2 . A-4 AO-N-TE- 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 A-5 eraldi testandmete alamprojektist). AO-N-TE- 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 A-6 (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.).  Front-End nõuded v1.0 KINNITATUD Direktori 05.06.2019. a Käskkirjaga nr 77 Lisa 4 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 grid-system see, mis kirjeldab ka veebilehe responsiivsuse. 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 FEH1 Lehe kirjeldamisel on kasutatud Semantiliste elementide kohta saab semantilisi elemente. 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 FEH2 Lehe sisupuu peegeldab lehe tegelikku Pealkirjad ja mõned HTML5 elemendid (Sect hierarhiat. ions and Outlines of an HTML5 Document) ki rjeldavad veebilehe sisupuud. Puudulike pealkirjade või ebakorrektse HTML5 elementide kasutamine moonutab lehe tegelikku sisupuud. Testimiseks sobivad rakendused, mis oskavad välja joonistada HTML5 dokumendi sisupuu. Näiteks WAVE Toolbar või HTML5 Outliner. Loe lähemat WCAG suunistest käesoleva dokumendi vastavast peatükist. FEH3 Koodis puuduvad elemendid, mida on Kuna HTML on mõeldud sisu kasutatud selleks, et näidata ekraanil struktureerimiseks, siis ei tohiks kasutada mõnda kujunduselementi. Näiteks HTML-is elemente, mille eesmärk on vaid ikoonid või muu graafika. 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. FEH4 HTML-is kirjeldatud lehe komponendid Veebileht koosneb komponentidest ja on eristatavad. 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 (grid- system). Eemaldades või lisades komponente ei muuda see tegevus lehe elementide paigutust. Alljärgnevas näites on kasutatud kahte komponenti: layout ja card. Esimese abil kirjeldatakse veebilehe sisu paigutust horisontaalsel teljel (teda ennast pole 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 layout kom ponendi vahendusel. Mõlemad on eraldiseisvad osad, millel on täita oma roll. Seega pole asjakohane märkida layout-ile, milline 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 FEH5 Lehel on teade, kui kasutajal puudub Javascript on tänapäeval de facto veebi Javascripti tugi. osa. Lisades lehele interaktsioone ja kulissidetagust andmevahetust, pakub see lehe külastajale paremat 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. FEH6 Lehel on teade, kui kasutaja külastab Kui külastada lehte iganenud veebilehte iganenud veebilehitsejaga. veebilehitsejaga, siis kuvatakse külastajale selle kohta teade. Teade sisaldab viiteid, kuidas uuendada või asendada oma veebilehitsejat. Märkus. Iganenud veebilehitseja all peetakse silmas neid veebilehitsejaid, mille toetamine on tootja poolt lõpetatud. Kuna veebilehitsejate uuenduste 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.  FEH7 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 suunistele ja võimalik est mööndustest tuleb projekti alustamisel informeerida tellijat. Mööndused peavad olema põhjendatud, näiteks kolmanda osapoole tarkvara kasutamisel ja paremate alternatiivide puudumine. See muidugi ei tähenda seda, et valideerimisel avastatud vead (ehk “errors”) tuleb aktsepteerida. Koodis esinevad vead tuleb parandada. Muud valideerimisel saadud tulemustele tuleb anda hinnang eraldi. FEH8 Graafika, mida on Erinevad kujunduselemendid, mis ei ole võimalik realiseerida CSS-iga, tuleb ka lehe sisu osa, tuleks realiseerida kasutades realiseerida CSS-iga. 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. FEH9 Vormi sisestusväljadel on kasutatud HTML võimaldab ära märkida, millist tüüpi vä asjakohast tüüpi. ärtust sisestusväli eeldab (lisaks eeldamisele on võimalik ka lisada valideerimisreeglid, mis ka kontrollivad, kas 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 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: LESS ja SASS/SCSS. RIK kasutab SCSS-i. 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 FEC1 Kasutatud on mõnda levinumat CSS-i Arendusprotsessi kiirendamiseks ja raamistikku (eelistatult Twitter Bootstrap). jätkusuutlikuse tagamiseks on hea aluseks võtta valmis Front-End komponentide teek, mis pakub ühtset ökosüsteemi ja dokumentatsiooni veebilehe valmistamiseks. RIK kasutab Twitter Bootstrap'i ja seda tuleks uutes projektides ka eelistada, kui ei ole kokku lepitud teisiti. 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 o n peab sisse lülitatud olema ainult vajalik funktsionaalsus (kasutaja browser ei tõmba alla staatilisi ressursse, mida ei kasutata). FEC2 CSS-i lähtekood sisaldab vaid Veebilehitsejate tootjad on loonud standardseid atribuute. 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 (post-production). Selle jaoks on olemas erinevad nn autoprefixer töö riistad, mis pakuvad võimaluse juhtida, milliste veebilehitsejate ja milliste versioonidele eesliidest tuleb suunata (PostC SS). Halb 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: FEC3 CSS-i selektorina on eelistatud peamiselt Visuaali kirjeldamiseks on kasutatud CSS-i CSS klasse. 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 FEC4 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 (loe eelmise punkti märkust). Kui erand on põhjendatud, siis on erandid lubatud. Aga läbivalt tuleb siiski kasutada kuni kolme-nelja sammu pikkusi selektoreid. Halb 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. FEC5 On kasutatud mõnda levinumat CSS CSS-i klasside nimetamine peab olema läbi klassi nimetamise põhimõtet. 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://e n.bem.info Halb näide FEC6 SCSS-i lähtekood on struktureeritud Senised praktikad on näidanud, et veebilehe komponendipõhiselt. 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.  FEC7 CSS klasse kasutatakse vaid visuaali Ei ole hea praktika siduda Javascripti kirjeldamiseks. 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 grid süsteemi rakendamine, kuid grid määrab ära vaid komponentide laiused. Et oleks võimalik juhtida ka komponentide ja nende elementide propotsioone (teksti suurus, padding-marging jne) lähtuvalt ekraani suurusest, siis seda aitab meil saavutada juba mõnda aega CSS-is kasutatav ühik „rem“. Mida ühik „rem“ tähendab? Kõige lihtsam on seda seletada nõnda, et selle väärtus sõltub HTML-i juurelemendi (root element) teksti suurusest. HTML-i juurelement on element „html“. Vaikimisi on 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 (Utilities), mis hõlbustavad teha kasutajaliidese kujunduses parendusi nõnda, et selle jaoks ei pea muutma komponenti või selle elemente. Näiteks Bootstrap pakub selliseid tööriistu https://getbootstrap.com/docs/4.1 /utilities/borders/ Responsiivsete lahenduste maailmas osutuvad need tööriistad hädavajalikuks, kuna arenduse käigus on vajadus veebilahenduse propotsioone juhtida vastavalt tekkinud olukorrale (näiteks lähtuvalt ekraani suurusest). Javascript Tänapäeval kuulub Javascript iga veebilahenduse juurde. Javascript on see osa veebilehest, mis annab sellele dünaamilisuse ja võime reageerida kasutaja toimingutele. Ühtlasi aitab luua ka nn polyfill-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 vaid uuemates veebilehitsejates. Dokumendiobjektide mudel (DOM, Document Object Model) DOM on platvormist ja keelest sõltumatu W3C poolt standardiseeritud HTML dokumentidega suhtlemise liides. See liides võimaldab näiteks Java scriptil lugeda ja muuta veebilehte. Selle liidesega 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 Intersection Observer API, mis võimaldab seda funktsionaalsust paremini oma arendustest rakendada. Arendajal võib tekkida ka vajadus teada saada, kas 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 Virtual DOM. Internetist võib selle kohta leida väga palju materjali, aga lihtsamalt öeldes on tegemist DOM-i abstraktsiooniga ehk lihtsustatud ja eraldiseisva versiooniga kuvatavast veebilehest. Kuna veebilehitseja enda DOM on väga mahukas ja sellega suhtlemine võib osutuda ressursinõudlikuks, siis Virtual DOM pakub võimalust teha muudatusi veebilehes nõnda, et Virtual DOM 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 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 Virtual DOM-i rakendaine. Internetist võib leida ka vaid Virtual DOM-i liidese jaoks mõeldud Javascripti teeke. 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 // FIXME: et välja tuua probleeme  kasuta // TODO: et välja tuua lahendusi probleemidele 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 (https://developer. mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics ) Rolle saab kasutada ka sellistes olukordades, kus semantiliste elementide kasutamine pole mingil põhjusel võimalik. Veebilehel esinevatele ajas muutuvatele meediumitele saab WAI-ARIA States and Properties mooduli 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 ti tle või alt atribuuti. Vormi elementidel tuleks kasutada label elementi. Ä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 checkbox teha tühik klahviga aktiivseks, siis see peaks toimima ka siis, kui see checkbox on loodud kasutades Javascripti abi. Täiendavad kasutajaliidese komponentide nõuded leiad RIKi UIG lehelt Nõuded Nr Nõude sisu Nõude seletused FEW1 Meediumitel, mis võimaldavad Igal elemendil, millega kasutaja saab midagi külastajale interaktsiooni, on kirjeldatud teha (lingid, vormi väljad, nupud jmt), on nn hover olek. kirjeldatud hover olek. Hover olek on see, kui kasutaja liigub hiirega selle elemendi peale. Erandiks on puutetundlikud ekraanid, kus hover olek võrdub klikiga. See tähendab, et funktsionaalsused, mis sõltuvad hover-ist, tuleb puutetundlikel ekraanidel ümber teha klikipõhiseks. Siit ka soovitus otsutada, milline on primaarne funktsionaalsus. Üldiselt liigub maailm selles suunas, et funktsionaalsus, mis toob kasutajale midagi nähtavale hover-i abil, ehitatakse siiski kliki peale, kuna tõusev trend on see, et veebilehti külastatakse pigem puutetundlike ekraanidega. FEW2 Vormi elementidel on kirjeldatud focus ol Focus olek aitab kasutajal eristada aktiivset ek. vormi elementi teistest.  Märkus: 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äärast. Tööriist testimiseks: https://webaim.org /resources/contrastchecker/ FEW3 Elementidel on kirjeldatud active olek. Active oleks aitab kasutajal eristada aktiivset elementi. Näiteks klaviatuuri abil lehel ringi liikudes saab aktiivne interaktsiooni võimaldav element teda eristava vormingu. FEW4 Elementidel on kirjeldatud visited olek. 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. FEW5 Veasituatsioonid on sõnastatud Veasituatsioonide tekkimisel antakse asjakohaselt ja omavad vastavalt kasutajale asjakohast tagasisidet. Teade on situatsioonile korrektset visuaali. 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). FEW6 Situatsioonid, kus informatsioon on Veebilehel on arvestatud olukordadega, kus mõnes komponendis puudu või on alles näiteks tabel on tühi. Sellistel olukordades saabumas, on selgelt tähistatud. 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. FEW7 Veebilehel kasutatud animatsioonid Nii nagu päris maailmas, nõnda ka veebis, parendavad kasutajakogemust. 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 Märkus: Animatsioonid peavad olema põhjendatud, kui animatsioon on põhjendamata ja/või näiteks epileptikutele isegi ohtlik, siis see kriteerium ei ole 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: https://kinsta.com/learn/page-speed/ ja 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 JPEGmin-i. Tegemist on suurepärase tööriistaga just JPG piltide optimeerimiseks. Tihti saavutab see pea 3x mahu vähenemise ilma et pilt kaotaks 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 välitda olukordi, kus pildil kujutatud oluline element oleks ebanormaalselt lõigatud või muul viisil rikutud. 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 LESS ja SASS/SCSS. Kuna viimasel ajal on populaarsust kogumas pigem SASS/SCSS, siis võiks täna alustavates projektides pigem eelistada 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 tehnoloogia, mille abil on võimalik olemasolevat CSS-i järeltöödelda. Need tööriistad pakuvad võimaluse CSS-i lähtuvalt sisendparameetritele või 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 PostCSS-i on aga vajadus (Autoprefixer) tagada uuemate tehnoloogiate tagasiühilduvat tuge ammutades andmeid Can I Use andmebaasist. 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 (prefix). Näiteks -webkit-box-shadow (spetsifikatsioon näeb ette aga box-shadow). Igal tootjal on oma. - 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 Javascripti, siis on lihtne neid mooduleid ise lähtuvalt projekti spetsiifikast juurde luua. 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 FEU1 Rakendus peab olema graafiliselt Nii avalikuks kui ka sisemiseks eskaleeruv. 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. FEU2 Vaikimisi veebilehitseja poolt Kõik aknad, mis avanevad peavad olema blokeeritavaid hüpikaknaid ei tohi sellised, mida üksi brauser oma vaikimisi kasutada. 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 Veebilehitseja ei blokeerib avaneva blokeeri avanevat akna, sest see akent, sest see avaneb läbi avaneb Javascripti kasutaja vahetu automaatselt. tegevuse peale. FEU3 Veebipõhine kasutajaliides peab olema kasutatav enamlevinud Operating Browser veebibrauseritega. Minimaalselt Mozilla system Firefox, Safari, Chrome ja Edge arenduse testimise hetkel 2 viimast (major) Windows Internet Explorer 11 versiooni ning 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)  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 2.1 AA nõuded. WCAG nõuetele vastamist reguleerib 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 meta märgendi user-scalable=”no” atribuuti. (WCAG 1.4.4) 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 frameset või ifram, sest paljud mobiilseadmed ei toeta neid ning nad on üldiselt vananenud ja problemaatilised. Kui siiski kui kasutatakse raame, tuleb neile anda 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 html elemendi lang=“…” atribuudis. (WCAG 3.1.1) 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 businessregister.rik.ee võiks viia äriregistri ENG lehele. Kui eesti keelt mitte valdav kasutaja soovib äriregistri lehele minna, siis domeeninimi ariregister.rik.ee ei ütle talle sisuliselt midagi. 35 Domeeninimi peab töötama ka ilma “www“‘ta. 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 loaderit näidatakse iga kord, kuid tema kuvamise pikkus sõltub lehe laadimise kiirusest. Kui leht 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 rit 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 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 www.e-toimik.ee, selle asemel peaks olema võimaldatud 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 (keyword’e). määrata võimalikult kasutajasõbralikke, lihtsaid ja lühikesi URL-e kõikidele lehtedele (ka nendele mille sisu tuleb liideste kaudu). 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 a märgendisse. 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 ul või ol märgendiga. 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=“…” ning dubleerida lingi tekst atribuudis title=“…”, 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 Esc klahviga ja vajutades hiirega modaalakna alast välja poole jäävale alale. 5 Modaalaknas tuleb vältida sisu jagamist lehtedele (paging) ja vahelehtedele (tabs) ning modaalaknasse tekkivat 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 title märgendina. (WCAG 2.4.2) 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 ul märgendiga esitatud nimekiri. Alammenüüga elemendile võiks lisada aria- 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 (breadcrumbs) peab olema kasutajale kuvatud, kui kasutajal on võimalik navigeerida sügavamale, kui kaks taset. 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 button või input type=“button” märgendiga. Mitte kasutada a role=“button” märgendit nupu esitamiseks, sest ekraanilugejaga kasutaja võib nupu vajutamiseks kasutada space klahvi, mis linki aga ei aktiveeri. Nuppu ei tohi esitada div või span märgendiga, sest tugitehnoloogiad ei pruugi selliseid nuppe ära tunda. 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 (scroll) kui tulemuste jaotamist erinevatele lehtedele (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 img märgendite asemel. (WCAG 1.1.1) 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 figcaption märgendiga. Pildi tekstiline alternatiiv ei tohi korrata pildi allkirja, vaid andma lisainfot. 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 table, thead (päiselahtrite grupeerimiseks), tbody (sisuosa eraldamiseks), tfoot (kokkuvõtvate lahtrite grupeerimiseks), tr, td, th märgendeid. (WCAG 1.3.1) 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 caption märgendiga. (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 h1 kuni h6, mitte ainult kujundusega. Pealkirjadena h1 kuni h6 ei tohi esitada teksti, mis pole tegelikult pealkiri. (WCAG 1.3.1, 2.4.6) 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 h1. (WCAG) 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 MSDN lehelt. 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 label, mis on temaga seotud id=“…” ja for=“…” atribuutide kaudu. Pealkiri peab visuaalselt paiknema vormivälja suhtes nii, et nende kokkukuuluvus 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 label märgendis. Soovitud kuju võib kirjutada ka sisestuskasti placeholder=“…” atribuuti, kuid see ei tohi asendada labelmä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. (WCAG 1.4.3) 6 Kui sisestuskasti funktsioon on visuaalselt piisavalt arusaadav, et ei vaja label elementi, tuleb kasutada aria-label=“…” atribuuti, et selgitust saaksid lugeda ainult ekraanilugejad. (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 fieldset elemendi sisse ning anda grupile üldine pealkiri legend elemendi abil. 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 title märgendisse, mitmenda sammu juures ollakse. 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. 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 optgroup märgendi abil, et soovitud valiku leidmine oleks kiirem. 20 Kohustuslikud väljad peavad olema esitatud input required märgendiga. Soovituslik on lisada ka atribuut aria-required=“true”, sest kõik tugitehnoloogiad ei pruugi arvestada required atribuuti. 21 1. Eelmisesse vaatesse tagasi liikudes peavad alles jääma kõik kasutaja poolt eelnevalt sisestatud andmed. 22 Ekraanivaadet uuendades (refresh) peavad alles jääma kõik sisestatud andmed. 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 (label), mis peab olema joondatud vasakule. 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 (hint, placeholder) ei tohi jätta muljet, et tegemist on sisestatud andmetega. 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 (call to action)/ toimingu sooritamise nupu vajutusega. 33 Valikute kastid (radiobuttonid, checkboxid) peavad olema valitavad tühiku klahviga. 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 (tabid), siis peavad olema eristatud vahelehed, millel mõni kohustuslik väli on veel täitmata. 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.  Nõuded projektiplaanile versioon 1.0 Pakkumuse osana esitatakse projektiplaan, mis sisaldab ajakava kõikide funktsionaalsuste loomise ja selle pakkumuse alustamiseks vajalike tööde läbiviimiseks. Pakkumuses esitatavalt projektiplaanilt eeldatakse vastavust järgmistele tingimustele: PP 1.1 Projektiplaanis kirjeldatud tööde läbiviimise tulemusena peab olema saavutatud projekti eesmärk ja soovitud funktsionaalsus. PP 1.2 Iga projektiplaani töö kohta peab olema kirjeldatud töö nimetus, töö tegija(te) sh vastutaja roll/nimi, ajaline kestus inimtundides ja tähtaeg. PP 1.3 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. PP 1.4 Kõik projektiplaanis kirjeldatud tööd peavad olema omavahel loogiliselt seotud ja jaotatud iteratsioonidena. PP 1.5 Projektiplaan peab sisaldama varuaega (puhvrit) ja selles peab arvestama riiklike pühade, puhkepäevade ja projektimeeskonna puhkustega. PP 1.6 Projektiplaan peab olema ajakohastatud kogu projekti teostamise vältel. PP 1.7 Lisaks projektiplaanile tuleb kirjeldada, kuidas projektijuhtimise riske maandada kavatsetakse (pakkumuse eraldi dokument). Majasiseselt: RIKi projektijuht lisab projektiplaani arenduste kasutuselevõtuga seotud õigusloomelise tegevuse, kasutajate koolitamise, kasutusjuhendite jms koostamise kava võttes arvesse, et need tegevused oleks arenduste kasutuselevõtu hetkeks teostatud. Vajalikud tegevuste tähtajad annab tellija ja sisuosakond. Samuti lisab projektijuht projektiplaani ajakava arenduste registreerimiseks ja kooskõlastamiseks RIHA-s vastavalt RIHA põhimäärusele, arvestades ametlikule kooskõlastamisele kuluva maksimaalse aja kuluga (registreerida tuleb nii projekti kavatsus kui kasutuselevõtmine). Vajaliku d tegevuste tähtajad annab tellija ja sisuosakond.  „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ (278726) Tehniline kirjeldus 1. Hanke üldinfo ja eesmärk 1.1. Registrite ja Infosüsteemide Keskus loob riigihangete seaduse (edaspidi RHS) § 33 lõike 1 alusel dünaamilise hankesüsteemi „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“. 1.2. Dünaamiline hankesüsteem on jagatud kategooriateks vastavalt hanke eeldatavale maksumusele või vastavalt tellitavate tööde või teenuste eripäradele, st hankija võib dünaamilise hankesüsteemi alt teostada hankeid nii tervikteenuse (lõpptulemus arendustööna) kui ka tunnipõhise arendusteenuse soetamiseks (arendusressurss). 1.3. Dünaamilise hankesüsteemi hangete teostamisel kohaldatakse RHS-i piiratud hankemenetluse sätteid, võttes arvesse dünaamilise hankesüsteemile kehtestatud erisusi. 1.4. Dünaamiline hankesüsteem on jaotatud viieks kategooriaks, soodustamaks konkurentsi. 1.5. Dokumendihaldussüsteemi dünaamilise hankesüsteemi esemeks on sealhulgas, aga mitte ainult, tarkvara arendustööd (sh. analüüsi- (nii ärianalüüs kui ka süsteemianalüüs), testimis- , kasutusmugavuse spetsialisti, programmeerimistööd) ning nende tulemid. Täpne lepingu ese ning hankija vajadused määratletakse igakordselt dünaamilise hankesüsteemi seotud hanke alusdokumentides. 1.6. Erinevate tööde hankimisel võib hankida küsida ühte või enamat rolli või kindlaksmääratud rollidega meeskonda, küsitud rollid võivad olla järgmised (kuid mitte ainult): 1.6.1. Vanemarendaja; 1.6.2. Arendaja; 1.6.3. Süsteemianalüütik; 1.6.4. Testija; 1.6.5. Ärianalüütik; 1.6.6. UI/UX disainer. 1.7. Hankija võib lubada rollide ühildamist, kui see on tulenevalt konkreetsest tööst mõistlik ja võimalik (täpsustatakse igakordselt seotud hanke alusdokumentides). 1.8. Kui seotud hankes on nõutud, esitab pakkuja meeskonnaliikmetele kehtestatud nõuete täitmise tõendamiseks andmed, täites iga nõutud meeskonnaliikme kohta etteantud CV vormi. Esitatud andmed peavad võimaldama hankijal kontrollida meeskonnaliikmete vastavust hankes esitatud nõuetele ja hankija kontrollib tingimuste täitmist eelkõige esitatud andmete alusel. 1.9. Hankija hangib eelpool nimetatud töid dokumendihaldussüsteemile, mille peamised tehnoloogiad on nimetatud punktis 2.7. 1.10. Juhul, kui seotud hankes on infosüsteemiga seotud osapoole (nt Siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT)) nõuetest tulenevalt vajalik täitja meeskonnaliikmete taustakontrolli teostamine, viiakse see läbi enne tööde alustamist (vajadus täpsustatakse igakordselt seotud hanke alusdokumentides). 1.11. Hankija rakendab kõikides seotud hangetes ühtseid mittefunktsionaalseid nõudeid, nii palju, kui see vähegi võimalik on. Mittefunktsionaalsed nõuded esitatakse ja vajadusel täpsustatakse iga seotud hanke juures eraldi tehnilise kirjelduse osana. 2024 2. Dokumendihaldussüsteemi lühitutvustus 2.1. Dokumendihaldussüsteemi eesmärgiks on võimaldada asutuseüleselt juhtida dokumentidega seotud tööd ja olla paindlikult seadistatav vastavalt organisatsiooni vajadustele. 2.2. Arendusprojekti osapoolteks on teenuse omanikuna Riigi Tugiteenuste Keskus (toote äriomanik) ning tooteomanikena Registrite ja Infosüsteemide Keskus ja Siseministeeriumi infotehnoloogia- ja arenduskeskus. 2.3. Dokumendihaldussüsteemi kasutajate sihtgrupiks on ligikaudu 160 riigiasutust ja 34 000 töötajat. 2.4. Arendustööd jagunevad 3 aasta peale ja põhifunktsionaalsuse kasutuselevõtt on esimeste asutustega kavandatud alates 2026. aasta algusest. 2.5. Põhifunktsionaalsus, mille arendamiseks ressurssi hangime: kasutajate tuvastus ja haldus, seadistuse funktsionaalsus, liigitusskeem, dokumendid, töövood ja tööülesanded (sh asutuste ülesed), õiguste haldus, töölaud, otsing, teated/teavitused ja abiinfo, nutiseadmete vaated ja API võimekus. 2.6. Loodava süsteemi nõuded: 2.6.1. arendamisel lähtutakse kasutajakesksest vaatenurgast ja e-teenuste kasutajasõbralikkuse ja kasutatavuse headest tavadest; 2.6.2. kujundus põhineb loodud prototüübil, mis on loodud Figma tarkvaralist lahendust kasutades; 2.6.3. põhineb mikroteenustel arhitektuuril; 2.6.4. avatud lähtekoodi printsiipidel; 2.6.5. vastab kaasaegse süsteemi turvalisuse nõuetele; 2.6.6. arendamiskeel on inglise keel (näiteks, meetodi nimetused ja funktsioonide nimetused), kommentaarid võivad olla eestikeelsed. 2.7. Arendamisel kasutatakse peamiselt järgnevaid tehnoloogiaid: 2.7.1. Java; 2.7.2. PostrgeSQL; 2.7.3. VueJS + PrimeVue; 2.7.4. GoLang; 2.7.5. Micronaut, Spring Boot raamistikud; 2.7.6. REST; 2.7.7. JSON, JSONB; 2.7.8. Swagger. 2.8. Igapäevaseks tööde prioriteetide seadmiseks, aja raporteerimiseks ning tööülesannete jälgimiseks kasutatakse Jira keskkonda. 2.9. Arendamisel kasutatakse agiilset arendusmetoodikat Scrum. 3. Arendus- ja hooldustööd 3.1. Arendus- ja hooldustöödeks on: analüüsitööd – süsteemi- ja ärianalüüs; tellija ja/või äripoolega analüüsikoosolekute läbiviimine projekti tööde teostuseks, analüüsi dokumentatsiooni koostamine, muutmine ja uuendamine; süsteemi nõuete ja vajalikku funktsionaalsuse, andmeobjektide ja seoste (sh erinevate diagrammide loomine), andmemudelite kirjeldamine (sh arendusülesannete kirjeldamine arendajatele); süsteemi nõuete ja funktsionaalsuse selgitamine osapooltele; süsteemi disaini väljatöötamisel osalemine pakkudes erinevaid kliendile parimaid lahendusi arvestades infosüsteemi kui tervikut. 3.2. programmeerimistööd/arendustööd – tarkvara lähtekoodi, automaattestide ja ühiktestide kirjutamine ja täiendamine; lähtekoodi ülevaatamine ja parandamine vastavalt koodistiili reeglitele; oma töö tulemuse tutvustamine (demo) huvigruppidele; andmesiirde teostamine; töö dokumenteerimine; andmemudelite loomine/täiendamine; tarnepakkide koostamine; andmevahetus- ja liidestustööde tegemine/arendamine; tiimis kokku lepitud Lk 2/3  tarkvaraarenduse loogika rakendamine; süsteemi disaini väljatöötamisel osalemine pakkudes erinevaid tehnilisi lahendusi (sh nõuete tehniline analüüsimine), arvestades süsteemi kui tervikut. 3.3. testimistööd (käsitsi- ja automaatestimine) – vastavalt spetsifikatsioonidele ja arendusülesannetele testimine, loodud dokumentatsiooni üle vaatamine/valideerimine; testjuhtumite loomine ja täiendamine valminud lahenduse testimiseks; automaattestide kirjutamine ja täiendamine; manuaaltestimine; andmevahetus- ja liidestustööde testimine, testandmete loomine jm tööd, mis kuuluvad testimistööde hulka; 3.4. UX/UI disainimistööd – kasutajakogemusega (UX) seotud tööde teostamine: sarnaste lahenduste uurimine, UX vajaduste väljaselgitamine, kasutajauuringute läbiviimine, kasutuslugude kirjeldamine, ekraanijooniste ja prototüüpide loomine, kasutatavuse testimine jne; veebidisainiga (UI) seotud tööde teostamine: ekraanivaadete lõppdisaini loomine, visuaalide disainimine, stiiliraamatute loomine ja täiendamine; prototüübi ajakohasena hoidmine; ühtse disaini hoidmine kogu arenduse vältel; jm tööd, mis kuuluvad UX/UI disainitööde hulka; Lk 3/3  DIREKTOR KÄSKKIRI 17.07.2024. a nr 55 Tallinn Alusdokumentide kinnitamine dünaamilise hankesüsteemis „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ (278726) 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 03.06.2024 käskkirjaga nr 44 kinnitan lisad. /allkirjastatud digitaalselt/ Aive Normak Asedirektor direktori ülesannetes Lisad: 1. hanketeade „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressurssi soetamiseks“ (278726) (vormistatud digitaalselt), 2. hankedokumendid „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressurssi soetamiseks“ (278726) koos lisadega (vormistatud digitaalselt).  KINNITATUD Direktori 17.07.2024 Käskkiri nr 55 Lisa 2 Dünaamiline hankesüsteem „ dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ Dünaamilise hankesüsteemi viitenumber 278726 KUTSE REGISTRITE JA INFOSÜSTEEMIDE KESKUS Registrite ja Infosüsteemide Keskus teeb dünaamilise hankesüsteemiga liitumisest huvitatud isikutele ettepaneku esitada taotlusi vastavalt hanketeates ja hankedokumentides sisalduvatele tingimustele. 2024 1. Üldosa 1.1. Kutse dokumendid on kohaldatavad ainult koos riigihangete seaduse ja selle alusel kehtestatud õigusaktidega. Hankija eeldab, et huvitatud isik või taotleja tunneb riigihangete seadust ja selle alusel kehtestatud õigusakte. 1.2. Huvitatud isik või taotleja kannab dünaamilises hankesüsteemis osalemisega seotud kogukulud ja - riski, kaasa arvatud vääramatu jõu (force majeure) toime võimalused. 1.3. Dünaamilise hankesüsteemi kehtivus on 48 kuud või kuni lepingute maksimaalse maksumuse täitumiseni. 1.4. Hankija on dünaamilise hankesüsteemi jaganud kategooriateks (RHR-is väljendub osadena): 1.3.1. Tarkvaraarendus eeldatava maksumusega kuni 199 999 EUR (km-ta); 1.3.2. Tarkvaraarendus eeldatava maksumusega alates 200 000 EUR (km-ta); 1.3.3. Arendusressursi soetamine eeldatava maksumusega kuni 149 999 EUR (km-ta); 1.3.4. Arendusressursi soetamine eeldatava maksumusega alates 150 000 kuni 449 999 EUR (km- ta); 1.3.5. Arendusressursi soetamine eeldatava maksumusega alates 450 000 EUR (km-ta). 1.4. Hanke osadeks jaotamine on kirjeldatud iga konkreetse hanke alusdokumentides. 1.5. Hankija ei arvesta olelusringi kulusid, kuivõrd pakkujatel on võimatu esitada RHS § 86 lg 2 p 2 nimetatud kulude osas näitajaid, mida oleks võimalik omavahel võrrelda. 1.6. Euroopa Liidu vahendid hankelepingute rahastamisel: Võib esineda, esinemise korral esitab Hankija andmed Euroopa Liidu vahendite osas igakordselt konkreetse dünaamilise hankesüsteemi alusel korraldatud seotud hanke alusdokumentides. 2. Dünaamilise hankesüsteemi dokumendid 2.1. Dünaamilise hankesüsteemi dokumendid koosnevad käesolevast kutse põhitekstist ja selle lisadest: 2.1.1 Lisa 1 kõrvaldamise alused ja kvalifitseerimistingimused (hankepass); 2.1.2 Lisa 2 hindamiskriteeriumid ja hinnatavad näitajad; 2.1.3 Lisa 3 alltöövõtjate kontrollimise tingimused; 2.1.4 Lisa 4 tehniline kirjeldus; 2.1.5 Lisa 5 arenduslepingu projekt; 2.1.6 Lisa 6 käsunduslepingu projekt; 2.1.7 Lisa 7 nõuete dokumendid: 2.1.7.1. Nõuded arendustele; 2.1.7.2. Nõuded testimisele; 2.1.7.3. Kasutajaliidese ja WCAG 2.1. nõuded; 2.1.7.4. Front End nõuded; 2.1.7.5. Arenduse tavad ja töökorraldus; 2.1.7.6. Dokumentatsiooniplaan; 2.1.7.7. Nõuded projektiplaanile; 2.1.7.8. Nõuded süsteemianalüüsile. 2.2. Kutse põhitekst ja selle juurde kuuluvad dokumendid on teineteist täiendavad. 2.3. Kutse lahutamatuks osaks on hankepass (alates 1.08.2019 alustatud hankes täidab ettevõtja hankepassi (ESPD v 2.0.2) registris. Vt hankepassi juhiseid https://www.fin.ee/riigihanked-riigiabi- osalused-kinnisvara/riigihangete-register/kasutusjuhendid), mille pakkujad esitavad hankijale esialgse tõendina kõrvaldamise ja kvalifitseerimistingimuste aluste kontrolliks. 2.4. RHS § 95 lg 4 p 9: Hankijal on õigus kõrvaldada hankemenetlusest taotleja, 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 taotlejatele, kaasa arvatud ühistaotlejad ning alltöövõtjad, kelle majandus-ja/või finantsnäitajatele ja/või tehnilisele ja kutsealasele pädevusele tuginetakse. Alltöövõtjate osas tuleb Lk 2/5  hankepass esitada ka juhul, kui tema näitajatele ei tugineta, kuid keda kavatsetakse kasutada tulevikus hankelepingu täitmisel. Hankija jätab õiguse alltöövõtjaid vajadusel kontrollida. 2.5. Juhul kui taotlejal esineb RHS § 97 nimetatud olukord, esitab ta hankepassis rikkumised ning info, et kohaldatud on heastamismeetmeid. Heastamismeetmetena esitab taotleja vastavad tõendid hankija sellekohase küsimise peale. 3. Täiendav teave ja selgitused 3.1. Küsimuse või taotluse täiendava teabe või selgituste saamiseks dünaamilise hankesüsteemi dokumentide kohta esitamisel peab huvitatud isik või taotleja arvestama, et hankijal on õigus tulenevalt riigihangete seaduse § 46 lõikest 1 vastata nimetatule 3 (kolme) tööpäeva jooksul. 3.2. Juhul, kui huvitatud isiku dünaamilise hankesüsteemi dokumentidega seotud selgitustaotluse hankijale laekumisega ja taotluste esitamise tähtpäeva vahele ei jää vähemalt 6 (kuus) päeva, ei ole hankijal kohustus selgitustaotlusele vastata. 3.3. Punktis 3.1. märgitud küsimus või taotlus esitatakse eesti keeles. 3.4. Huvitatud isik või taotleja esitab punktis 3.1. märgitud küsimuse või taotluse kirjalikku taasesitamist võimaldavas vormis elektrooniliselt riigihangete registris (https://riigihanked.riik.ee/). 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. 3.5. Hankija esitab dünaamilise hankesüsteemi käigus koostatud dokumendid ja antava täiendava teabe ning selgitused huvitatud isikule või taotlejatele elektrooniliselt läbi riigihangete registri. Lk 3/5 4. Dünaamilise hankesüsteemiga liitumine 4.1. Hankija võimaldab igal ettevõtjal dünaamilise hankesüsteemi kehtivusajal esitada liitumiseks taotlusi (hankepass). Liitumistaotlusi võib esitada igal ajal. 4.2. Ühistaotluse esitamisel peavad pakkujad nimetama taotluses hankemenetluses osalemise ning hankelepingu(-te) sõlmimise ja täitmisega seotud toimingute tegemiseks volitatud esindaja. Ühistaotluse esitamisel esitatakse hankepassid kõigi ühistaotlejate kohta. 4.3. Kui taotluse allkirjastab isik või isikud, kes ei oma seadusest tulenevalt taotleja esindamise õigust (nt juriidilise isiku poolt esitatud pakkumuse allkirjastab keegi teine, kui äriregistri registreerimistunnistusele kantud juhatuse liige, kes omab juriidilise isiku esindamise õigust), esitab taotluse esitaja koos taotlusega volikirja taotleja esindamiseks. 4.4. Taotlused, mis esitatakse 30 päeva jooksul hanketeate avaldamisest arvates, vaatab hankija läbi ja teeb vastava otsuse 30 päeva jooksul alates taotluse esitamisest. 4.4.1. Taotlused, mis esitatakse hiljem dünaamilise hankesüsteemi kehtivuse ajal, vaatab hankija läbi ja teeb otsuse taotleja liitmise kohta dünaamilise hankesüsteemiga kümne tööpäeva jooksul nende kättesaamisest arvates. 4.4.2. Hankija võib tähtaega põhjendatud juhtudel pikendada 15 tööpäevani (nt vajadusest läbi vaadata täiendavaid dokumente või muul viisil kontrollida, kas kvalifitseerimise tingimused on täidetud). 4.5. Dünaamilise hankesüsteemiga liitumiseks taotluse (hankepassi) esitanud ja kvalifitseerimistingimustele vastavad taotlejad liidetakse süsteemiga. Kui taotleja soovib liituda rohkem kui ühe dünaamilise hankesüsteemi osaga (kategooriaga), tuleb liitumistaotlus esitada igas osas (kategoorias) eraldi. Otsus taotleja liitmise kohta tehakse igas osas (kategoorias) eraldi. 4.6. Kui hankija jättis taotleja kvalifitseerimata või taotlejal esinevad kõrvaldamise alused, siis on taotlejal võimalik pärast kõrvaldamise aluste kõrvaldamist või kvalifikatsiooninõuete täitmist esitada uus taotlus süsteemiga liitmiseks. 4.7. Taotleja kohustub kandma kõik taotluse ettevalmistamise ja esitamisega seotud kulud. 4.8. Taotlejale ei hüvitata mis tahes kahju ega kulusid seoses hankemenetluses osalemisega. 5. Dünaamilise hankesüsteemi seotud hangete teostamise üldtingimused ja põhimõtted 5.1. Dünaamilise hankesüsteemi seotud hangete teostamisel kohaldatakse RHS-i piiratud hankemenetluse sätteid, võttes arvesse dünaamilise hankesüsteemile kehtestatud erisusi. 5.2. Pakkumusi saavad esitada kõik dünaamilise hankesüsteemiga liitumiseks taotluse esitanud ja konkreetse kategooria kvalifitseerimistingimustele vastavad, kvalifitseeritud taotlejad. Liidetud taotlejatele teeb hankija pakkumuse esitamise ettepanekuid (korraldab seotud hanke). 5.3. Pakkumuse esitamise õigus tekib taotlejal pärast tema suhtes kvalifitseerimisotsuse tegemist. Kvalifitseerimisotsus tehakse iga kategooria taotlejate osas eraldi. Dünaamilise hankesüsteemi kehtivusaja jooksul igal ajal dünaamilise hankesüsteemiga liitumistaotluse esitamine ei ole eelduseks samal ajal käimasolevates hangetes pakkumuse esitamise õiguse tekkimiseks, võttes arvesse hankijale ettenähtud taotluse läbivaatamise tähtaega. Pakkumuse esitamise ettepanek tehakse üheaegselt selleks ajaks liitunud taotlejatele - seega juhul kui pärast ettepaneku tegemist liitub uus taotleja, siis talle ettepanekut ei esitata ning tema pakkumust esitada ei saa. 5.4. Seotud hanke alusdokumendid esitab hankija igakordselt koos pakkumuse esitamise ettepanekuga, sh tehnilise kirjelduse, vastavustingimused, täpsustatud hindamiskriteeriumid, lepinguprojekti jm vajaliku info pakkumuse esitamiseks. 5.5. Pakkumuse vastavustingimused sätestatakse igakordselt seotud hanke teostamisel, lähtuvalt konkreetse hanke esemest. 5.6. Pakkumuste hindamise kriteeriumid on sätestatud DHS-i alusdokumentides. Hankija võib seotud hankes RHS § 35 lg 2 alusel pakkumuste hindamise kriteeriume täpsustada. 5.7. Hankijal on õigus lisada dünaamilises hankesüsteemis esitatud hindamiskriteeriumitele alamkriteeriume (nt täpsustamaks maksumuse ja/või kvaliteedi nõude komponente jne). 5.8. Hankijal on õigus pakkumuse esitamise ettepanekus täpsustada teatavaks tehtud hindamiskriteeriume, kuid sisuliselt hindamiskriteeriumite muutmine ei ole lubatav. 5.9. Pakkumused esitatakse kümne päeva jooksul pakkumuse esitamise ettepaneku saamisest arvates, Lk 4/5  kui hankija ei ole ettepanekus sätestanud pikemat pakkumuste esitamise tähtaega (RHS § 35 lg 3). 5.10. Hankija võib DHS-i kehtivusajal nõuda sellega liitunud taotlejatelt ajakohastatud hankepassi esitamist RHS §-s 104 sätestatud korras. Taotlejad esitavad hankepassi viie tööpäeva jooksul hankija nõude esitamisest arvates. 5.11. Pakkumusi saavad esitada kõik konkreetse osaga (kategooriaga) liidetud taotlejad. Seotud hankes osalemise ja pakkumuse esitamise õigus tekib taotlejal pärast tema suhtes süsteemiga liitumiseks esitatud taotluse alusel kvalifitseerimisotsuse tegemist. 5.12. Seotud hankes on pakkumuste jõusoleku minimaalne tähtaeg 3 kuud pakkumuse esitamise tähtpäevast arvates. 5.13. Leping sõlmitakse RHS § 35 lg 4 kohaselt hindamise tulemusena edukaks tunnistatud kvalifitseeritud pakkujaga, kes on esitanud seotud hanke alusdokumentidele vastava ja pakkumuste hindamise kriteeriumide alusel majanduslikult soodsaima pakkumuse. 5.14. Hankelepingu projekt, mida dünaamilise hankesüsteemi seotud hangetes kohaldatakse, on lisatud nii dünaamilise hankesüsteemi alusdokumentidesse kui ka täpsustatud kujul seotud hanke alusdokumentidesse. 5.15. RHS § 120 lõike 3 alusel ei kohalda hankija hankelepingu sõlmimisel ooteaega. Juba sõlmitud hankelepingut saab VAKOs vaidlustada RHS § 185 lg 4 p 5 alusel vaid juhul, kui selle maksumus ületab riigihanke piirmäära. 6. Seotud hangete kehtetuks tunnistamine ja kõikide pakkumuste tagasilükkamine 6.1. Hankijal on õigus kõik seotud hankes 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 6.2. Hankija võib põhjendatud vajaduse korral omal algatusel seotud hanke kehtetuks tunnistada. Põhjendatud vajaduseks võib olla eelkõige, kuid mitte ainult: 6.2.1.kui tekib vajadus lepingu eset olulisel määral muuta; 6.2.2. kui seotud hanke läbiviimise aluseks olevad tingimused on oluliselt muutunud ja seetõttu osutub lepingu sõlmimine mittevajalikuks või võimatuks; 6.2.3. kui seotud hanke läbiviimisel ilmnenud ebakõlasid ei ole võimalik kõrvaldada ega menetlust seetõttu ka õiguspäraselt lõpule viia; 6.2.4. hankemenetluses esitatakse tähtajaks vaid üks nõuetele vastav pakkumus. 7. Dünaamilise hankesüsteemi muutmine ja lõpetamine 7.1. Hankijal on õigus vastavalt RHS-le dünaamilise hankesüsteemi kehtivusaega muuta, sh pikendada hanketeates esitatud kehtivusaega. 7.2. Hankijal on õigus dünaamiline hankesüsteem vastavalt RHS-le enne tähtaega lõpetada (eelkõige (osade) eeldatava maksumuse täitumisel, kuid mitte ainult). /allkirjastatud digitaalselt/ Aive Normak Asedirektor direktori ülesannetes Lk 5/5  „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ (278726) hankedokumentide juurde Arendusleping nr ... Arenduslepingu eritingimused Tallinnas 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. Leping sõlmitakse dünaamilise hankesüsteemi „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ (278726) alusel korraldatud hankes „…………“ (…………) eduka pakkumuse esitanud pakkujaga (Täitja) Lepingu lisas 3 kirjeldatud tööde teostamiseks ning kõigi muude Lepingust tulenevate kohustuste täitmiseks (edaspidi ka Töö). 1.2. Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus, seonduvates õigusaktides 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). Lepingu hinnale lisandub käibemaks. 2.4. 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 Lisa nr 3; 4.1.4 Pakkumus 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 1 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 Toodangukeskkond Reaalseks andmevahetuseks mõeldud keskkond, mis ei ole test- või arenduskeskkond. 2. Hind 2.1 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 hankija on nimetatut pakkumuse esitamise ettepanekus 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. 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. 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. 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. 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. 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 12 (kaheteist) 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 10 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.2 (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. Kaldkirjas tekst lisatakse juhul, kui infosüsteemiga seotud osapoole (nt Siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT)) nõuetest tulenevalt on vajalik Täitja meeskonnaliikmete taustakontrolli teostamine. 18 Taustakontrolli teostamine 18.1 Kõigi Täitja poolt Töid teostavate meeskonnaliikmete osas viiakse enne nende poolt Tööde teostamisega alustamist läbi politsei ja piirivalve seaduse § 7(59) sätestatud taustakontroll (alus §  7 (59) lg 1 p 2). 18.2 Täitja on kohustatud informeerima tööle asuvaid meeskonnaliikmeid taustakontrolli teostamise vajadusest. 18.3 Tellija edastab Täitjale meeskonnaliikme nõusoleku vormi taustakontrolli läbiviimiseks. Täitja edastab Tellijale vastava meeskonnaliikme kirjaliku nõusoleku hiljemalt 5 (viie) tööpäeva jooksul vormi saatmisest. Juhul, kui Täitja ei edasta viidatud aja jooksul nõusolekut loetakse see Täitja poolseks viivituseks. 18.4 Kui meeskonnaliige keeldub taustakontrolliks nõusoleku andmisest, on Tellijal õigus keelduda vastava meeskonnaliikme tööle lubamisest ning nõuda meeskonnaliikme vahetamist. 18.5 Tellijal on õigus keelduda meeskonnaliiget Töid teostama lubamast, kui taustakontrolli tulemusena teatavaks saanud informatsiooni kohaselt ei ole meeskonnaliige sobilik Töid teostama. Lähtuvalt informatsiooni tundlikkusest, ei avaldata Täitjale taustakontrolli käigus saadud andmeid. 18.6 Juhul kui meeskonnaliige ei nõustu taustakontrolliga või ei osutu selle tulemusena Tellijale sobivaks, kohustub Täitja tagama uue meeskonnaliikme esitamise maksimaalselt kümne (10) tööpäeva jooksul. Kui konkreetses tellimuses või hankelepingus ei ole sätestatud teisiti, siis nimetatud põhjusel meeskonnaliikme vahetamine ei ole aluseks Tööde teostamise tähtaja muutmiseks. 19 Kolmandad isikud 19.1 Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled on kohustatud teineteist nõude loovutamisest viivitamatult kirjalikult informeerima. 19.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. 19.3 Pooled vastutavad kõigi isikute eest, keda nad kasutavad oma lepingujärgsete kohustuste täitmisel. 20 Auditeerimine 20.1 Mõlemal poolel on õigus kaasata auditeerimiseks sõltumatu audiitor. Audiitori kaasamiseks ei ole vajalik teise poole luba. 20.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. 20.3 Täitja peab täpset arvet lepingu täitmisel töötatud kalendripäevade ja –kuude kompenseerimisele kuuluvate kulude kohta. Audiitorile võimaldatakse piiramatu ligipääs nimetatud andmetele. 20.4 Audiitorit kaasanud pool tagab, et audiitor käsitleb saadud informatsiooni konfidentsiaalsena. Vastutus jääb audiitorit kaasanud poolele. 20.5 Pärast andmete auditeerimist ja kontrollimist teeb audiitor järeldusotsuse, mis on lõplik. 20.6 Auditi kulud kannab auditi tellinud pool. 21 Õigustest loobumine 21.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. 22 Konfidentsiaalsus ja isikuandmed 22.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. 22.2 Täitja on kohustatud: 22.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; 22.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; 22.2.3 ei edasta punktis 22.2.2 nimetatud isikuandmeid väljapoole Euroopa Liidu liikmesriikide ja Euroopa Majandusühendusse kuuluvate riikide territooriumit ilma tellija sellekohase selgesõnalise kirjaliku nõusolekuta; 22.2.4 kasutama ja töötlema punktis 22.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; 22.2.5 võimaldab juurdepääsu punktis 22.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; 22.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. 22.2.7 kohustub rakendama järgmisi organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid punktis 22.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. 22.2.8 teavitama tellijat toimunud või põhjendatult kahtlustatavast käesoleva lepingu punktis 22.2.1 ja/või 22.2.2 sätestatud konfidentsiaalsuskohustuse rikkumisest; punktis 22.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. 22.2.9 Tellija eelnevalt kirjalikul heakskiidul lõpetama käesoleva lepingu punktis 22.2.8.nimetatud rikkumise ning kohaldama meetmeid (isikuandmetega seotud) rikkumise lahendamiseks, sealhulgas vajaduse korral rikkumise võimaliku kahjuliku mõju kõrvaldamiseks ja leevendamiseks; 22.2.10 kohustub lepingu lõppemisel kustutama kõik punktis 22.2.2. nimetatud isikuandmed ja nimetatute koopiad 30 päeva jooksul, v.a juhul, kui õigusaktidest tuleneb teisiti;  22.2.11 teeb Tellijale kättesaadavaks kogu teabe, mida Tellija peab vajalikuks lepingus sätestatud kohustuste täitmise tõendamiseks; 22.2.12 võimaldab Tellijal või Tellija poolt volitatud audiitoril teha auditeid ja kontrolle ning panustab nendesse; 22.2.13 kohustub võimaluse piires asjakohaste tehniliste ja korralduslike meetmete abil punktis 22.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). 22.3 Käesoleva lepingu punktis 22.2.1. sätestatud konfidentsiaalsuse nõue ei laiene informatsiooni avaldamisele täitja audiitorile ja advokaadile. 22.4 Käesoleva lepingu punktides 22.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. 22.5 Tulenevalt konfidentsiaalse informatsiooni laadist on tellijal õigus seada täiendavaid nõuded ja/või juhised isikuandmete töötlemiseks. 22.6 Kõik käesoleva lepingu punktides 22.2.1. – 22.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. 23 Avalikud suhted 23.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. 23.2 Kõik eelnimetatud kohustused kehtestab pool ka kõigile kolmandatele isikutele, keda ta kasutab oma lepingujärgsete kohustuste täitmisel. 24 Lepingu täitmise peatamine ja lepingu lõpetamine 24.1 Tellija võib peatada Täitjale lepingujärgselt makstavate summade maksmise kas osaliselt või täielikult, kui: 24.1.1 Täitja ei täida Lepingut; 24.1.2 vastuvõtmise, testimise või auditeerimise käigus avastatakse puudusi või muid Täitja poolseid kohustuste rikkumisi; 24.1.3 Tellija Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada muu asjaolu, mille eest vastutab Täitja. 24.2 Täitja võib peatada Tellijale teenuse osutamise kas osaliselt või täielikult, kui: 24.2.1 Tellija ei täida Lepingut; 24.2.2 Täitja Lepingu järgsete kohustuste õigeaegset ja korrektset täitmist segab või ähvardab segada muu asjaolu, mille eest vastutab Tellija. 24.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. 24.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. 24.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. 24.6 Lepingu lõppemisel on Täitja kohustatud Tellijale tagastama kõik Lepingu täitmiseks üleantu. 25 Vääramatu jõud 25.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. 25.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: 25.2.1 takistava asjaolu esinemine, mis takistab kohustuse kohast täitmist; 25.2.2 takistava asjaolu asetsemine väljaspool võlgniku mõjusfääri; 25.2.3 asjaolu ettenägematus; 25.2.4 asjaolu vältimatus ja ületamatus. 25.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. 26 Kehtiv seadusandlus Lepingule ning kõikidele lepingu osaks olevatele dokumentidele kohaldatakse Eesti Vabariigi õigusakte. 27 Vaidluste lahendamine 27.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. 27.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. 27.3 Kokkuleppe mittesaavutamisel lahendatakse vaidlus Harju Maakohtus.  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.  „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ (278726) hankedokumentide juurde KÄSUNDUSLEPING nr Registrite ja Infosüsteemide Keskus, (registrikoodiga 70000310) asukohaga Lubja 4, 19081 Tallinn, mida esindab põhimääruse alusel direktor Rivo Reitmann (edaspidi Käsundiandja), ja ....... (registrikoodiga .....) asukohaga ........, ......., mida esindab ...... alusel ..... (edaspidi Käsundisaaja), keda nimetatakse eraldi Pool ja koos Pooled, sõlmisid käesoleva käsunduslepingu (edaspidi nimetatud Leping) alljärgnevas: 1. Lepingu sõlmimise alus ja ese ning dokumendid 1.1 Leping sõlmitakse dünaamilise hankesüsteemi „Dünaamiline hankesüsteem dokumendihaldussüsteemi tarkvaraarenduste ja arendusressursi soetamiseks“ (278726) alusel korraldatud hankes „…………“ (…………) eduka pakkumuse esitanud pakkujaga (Käsundisaaja) teenuse osutamiseks (edaspidi Käsund), vastavalt Lepingus ja nimetatu lisades toodule. 1.2 Lepingu dokumendid koosnevad käesolevast Lepingust ja Lepingu Lisadest. 1.3 Pooled kinnitavad, et teevad kõik enesest oleneva, et täita lepingu eesmärgid käesolevas lepingus, seonduvates õigusaktides ja juhtrühma otsustes sätestatud tingimustel ja mahus. 1.4 Lepingu lahutamatuteks lisadeks Lepingu sõlmimise hetkel on: 1.4.1 Lisa 1 Tehniline kirjeldus; 1.4.2 Lisa 2 Tööde üleandmise-vastuvõtmise akti vorm; 1.4.3 Lisa 3 Pakkumus. 2. Töökorraldus ja personal 2.1 Käsund täidetakse tehnilises kirjelduses märgitud kohas. 2.2 Käsundit täidetakse teenust osutavate isiku(te) poolt tehnilises kirjelduses märgitud ajaperioodil ja koormusega. 2.3 Käsund täidetakse tehnilises kirjelduses märgitud tingimustele vastava(te) isiku(te) poolt. Isikute andmed on toodud Lisas 3. 2.4 Käsundisaaja asendab Käsundit täitva isiku viivitamatult Lepingu objekti täitmise seisukohast võrdväärse kvalifikatsiooni ja kogemustega ning Käsundiandjale vastuvõetava isikuga, kui: 2.4.1 teenust osutav isik ei ole võimeline teenuse osutamist jätkama haiguse, õnnetusjuhtumi või muu temast tuleneva põhjuse tõttu; 2.4.2 Lepingus nimetatud teenust osutav isik osutub Käsundiandja 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; 2.4.3 teenust osutaval isikul on kehtiv karistus kuriteo toimepanemise eest. 2.5 Käsundisaaja kannab kõik punktis 2.4 nimetatud asendusest tulenevad või sellega kaasnevad kulud. 2.6 Käsundiandjal on õigus kontrollida, kas teenust osutavatel isikutel on kehtiv karistus kuriteo toimepanemise eest. 2.7 Teenust osutavad isikud ei tohi olla Käsundiandja töötajad või Käsundiandja töötajaga seotud juriidiliste isikute töötajad. Seotud juriidiline isik tähendab Lepingu mõistes juriidilist isikut, mille juhtimis- või kontrollorgani liige Käsundiandja töötaja on või juriidiline isik, milles vähemalt 1/10 osalusest kuulub Käsundiandja töötajale. 2.8 Teenust osutavate isikute loetelu ja kontaktandmed: 2.8.1 .............. 2.9 Käsundi nõuetekohaseks täitmiseks tuleb lähtuda Käsundiandja esindaja juhistest. Juhul, kui käsundit täidetakse Käsundiandja asukohas tuleb järgida lisaks Käsundiandja asukohale  kehtestatud kordasid ja juhendeid, mis edastatakse kas koos tehnilise kirjeldusega või pärastiselt lepingu täitma asumisel. Käsundiandja esindajaks Käsundi teostamise juhendamisel, Käsundisaajale vajaliku informatsiooni andmisel, Käsundi Lepingu tingimustele vastavuse kontrollimisel on ................ Käsundiandja esindajaks, kellel on õigus allkirjastada üleandmise- vastuvõtmise akte on .......... või tema ametlik asendaja. 2.10 Käsundisaaja esindajaks Käsundiga seotud teabevahetuse pidamisel, Käsundi Lepingu üleandmise-vastuvõtmise aktide allkirjastamisel jne on ............... või tema ametlik asendaja. Kaldkirjas tekst lisatakse juhul, kui infosüsteemiga seotud osapoole (nt Siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT)) nõuetest tulenevalt on vajalik täitja meeskonnaliikmete taustakontrolli teostamine. 3. Taustakontrolli teostamine 3.1 Kõigi Käsundisaaja poolt teenust osutavate isikute osas viiakse enne nende poolt tööde teostamisega alustamist läbi politsei ja piirivalve seaduse § 7(59) sätestatud taustakontroll (alus § 7 (59) lg 1 p 2). 3.2 Käsundisaaja on kohustatud informeerima teenust osutavaid isikuid taustakontrolli teostamise vajadusest. 3.3 Käsundiandja edastab Käsundisaajale meeskonnaliikme nõusoleku vormi taustakontrolli läbiviimiseks. Käsundisaaja edastab Käsundiandjale vastava meeskonnaliikme kirjaliku nõusoleku hiljemalt 5 (viie) tööpäeva jooksul vormi saatmisest. Juhul, kui Käsundisaaja ei edasta viidatud aja jooksul nõusolekut loetakse see Käsundisaaja poolseks viivituseks. 3.4 Kui teenust osutav isik keeldub taustakontrolliks nõusoleku andmisest, on Käsundiandjal õigus keelduda vastava isiku tööle lubamisest ning nõuda isiku vahetamist. 3.5 Käsundiandjal on õigus keelduda teenust osutavat isikut töid teostama lubamast, kui taustakontrolli tulemusena teatavaks saanud informatsiooni kohaselt ei ole isik sobilik töid teostama. Lähtuvalt informatsiooni tundlikkusest, ei avaldata Käsundisaajale taustakontrolli käigus saadud andmeid. 3.6 Juhul kui teenust osutav isik ei nõustu taustakontrolliga või ei osutu selle tulemusena Käsundiandjale sobivaks, kohustub Käsundisaaja tagama uue teenust osutava isiku esitamise maksimaalselt kümne (10) tööpäeva jooksul. 4. Lepingu hind ja maksmine 4.1 Lepingu hind on …….. eurot (netosumma), arvestusega, et ……….. töötunni maksumus on …….. eurot (netosumma) ja ……… töötunni maksumus on ……. eurot (netosumma). 4.2 Lepingu hinnas märgitud summad sisaldavad Käsundisaaja poolt Lepingu raames tehtavaid kõiki kulutusi ja tasu autoriõiguste eest. Lepingu hinnale lisandub käibemaks. 4.3 Pärast teenuse osutamist esitab Käsundisaaja Käsundiandjale tööde üleandmise-vastuvõtmise akti (Lisa 2). Akt esitatakse vastavalt tehnilise kirjelduse tingimustele kas igakuiselt või teenuse osutamise ajaperioodi lõppedes. 4.4 Käsundiandja kohustub tasuma Käsundisaajale nõuetekohaselt teostatud töö eest arve alusel. Arve esitatakse e-arvena masinloetaval kujul, pärast üleandmise-vastuvõtmise akti Käsundiandja poolset allkirjastamist. Käsundiandja tasub arve 30 kalendripäeva jooksul alates arve saamisest. 4.5 Arve peab sisaldama vähemalt alljärgnevaid andmeid: 4.5.1 info arve esitaja kohta; 4.5.2 info maksja kohta; 4.5.3 riigihanke viitenumber; 4.5.4 viide lepingule; 4.5.5 käibemaksukohustuslase number; 4.5.6 osutatud teenuse loetelu; 4.5.7 käibemaks; 4.5.8 kogusumma. 5. Käsundisaaja õigused ja kohustused 5.1 Käsundisaaja on kohustatud tagama, et:  5.1.1 Käsundi täitmisel arvestatakse, et lõunavaheaja ning võimalike muude vaheaegade algus ja lõpp on ära määratud töösisekorraeeskirjas, mida tutvustatakse teenust osutavatele isikutele tööde alustamisel Käsundiandja asukohas; 5.1.2 Käsundi täitmisel tegutsetakse Käsundiandjale lojaalselt ja Käsundi laadist tuleneva vajaliku hoolsusega ning muudest Käsundiandja poolt kehtestatud sisekorraeeskirjadest tulenevalt; 5.1.3 viivitamatult informeeritaks Käsundiandjat selliste asjaolude ilmnemisest, mis võivad takistada Lepingu objektiks oleva Käsundi täitmist (sealhulgas Käsundiandjalt saadud informatsiooni, lähteandmete, dokumentide vms puudulikkusest) või ajendada Käsundiandjat muutma Käsundi täitmiseks antud juhiseid; 5.1.4 järgitaks Käsundiandja poolt antud juhiseid. Kui Käsundisaaja soovib Käsundiandja juhistest kõrvale kalduda, peab ta sellest Käsundiandjale teatama ja tema otsuse ära ootama, välja arvatud juhul, kui viivitusega kaasneks Käsundiandjale ilmselgelt ebasoodus tagajärg; 5.1.5 andma Käsundiandjale aru Käsundi täitmise käigust ning võimaldama Käsundiandjale igal ajal teostada kontrolli täidetava Käsundi mahu ja kvaliteedi üle; 5.1.6 hoidma saladuses talle Lepingu täitmisega teatavaks saanud asjaolusid, isikuandmeid ja muud teavet, mille saladuses hoidmiseks on Käsundiandjal õigustatud huvi või mille saladuses hoidmist Käsundiandja on nõudnud. Saladuse hoidmise kohustust ei ole, kui teabe avalikustamiseks on Käsundiandja kirjalik luba või kui teabe avalikustamise kohustus tuleneb õigusaktidest; 5.1.7 tagastataks Lepingu lõppemisel viivitamatult Käsundiandjale Käsundi täitmiseks saadu (dokumendid, asjad jne); 5.1.8 pärast Lepingu lõppemist antaks Käsundiandjale üleandmise-vastuvõtmise akti alusel üle kõik Käsundisaaja poolt Lepingu täitmise käigus koostatud aruanded ja andmed (nagu joonised, spetsifikatsioonid, plaanid, arvestused, lisaandmed, materjalid jms). 5.2 Käsundisaajal on õigus: 5.2.1 teha Käsundiandjale põhjendatud ettepanekuid Käsundi paremaks täitmiseks; 5.2.2 nõuda Käsundiandjalt Käsundi täitmisega seotud juhiste andmist; 5.2.3 saada Käsundiandjalt Käsundi täitmiseks vajalikku teavet; 5.2.4 saada Lepingu kohaselt Käsundi täitmise eest tasu vastavalt Lepingus sätestatud tingimustele ja korrale. 6. Käsundiandja õigused ja kohustused 6.1 Käsundiandja on kohustatud: 6.1.1 esitama Käsundisaajale kõik Käsundi osutamiseks vajalikud lähteandmed ja dokumendid; 6.1.2 Käsundisaaja nõudmisel esitama Käsundisaajale vajalikku lisainformatsiooni, andmeid ja dokumente, mis on vajalikud Käsundi nõuetekohaseks täitmiseks; 6.1.3 andma viivituseta Käsundisaajale juhiseid Käsundi täitmiseks, kui Käsundisaaja neid nõutab; 6.1.4 informeerima viivitamatult Käsundisaajat asjaolude ilmnemisest, mis võivad takistada Lepingu objektiks oleva Käsundi täitmist; 6.1.5 maksma Käsundisaajale Lepinguga ettenähtud alustel ja korras tasu Käsundi täitmise eest. 6.2 Käsundiandjal on õigus: 6.2.1 nõuda Käsundisaajalt Lepingus sätestatud nõuetest ja Käsundi täitmise tähtaegadest kinnipidamist; 6.2.2 anda Käsundisaajale vajadusel Käsundi täitmiseks vastavaid juhiseid; 6.2.3 kontrollida Käsundi täitmise käiku igal ajal Lepingu täitmise tähtaja jooksul ning saada Käsundisaajalt informatsiooni Käsundi täitmise kohta; 6.2.4 teostada kontrolli ja järelevalvet Käsundisaaja poolt täidetava Käsundi üle; 6.2.5 teha Käsundisaajale ettekirjutus 10 tööpäeva jooksul üleandmise-vastuvõtmise akti esitamisest lepingust tuleneva kohustuse rikkumise puhul. Käsundiandja annab Käsundisaajale ettekirjutuses tähtaja puuduste kõrvaldamiseks, mis ei tohi olla lühem kui 5 tööpäeva. 7. Intellektuaalne vara 7.1 Lepingu allkirjastamisega kinnitab Käsundisaaja Käsundiandjale, et talle kuuluvad Lepingu  täitmiseks vajalikud 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. 7.2 Lepingu alusel välja töötatud ja Käsundiandjale üle antud töö (teose) omandiõigus ja kõik autori varalised õigused ning muud intellektuaalse omandi õigused lähevad vastuvõtmise akti allkirjastamise järgselt tervikuna üle Käsundiandjale. Samuti annab Käsundisaaja Käsundiandjale ainulitsentsi isiklikele autoriõigustele. Nimetatud õigused kehtivad kogu autoriõiguste kehtivuse aja ja nende kehtivuse territooriumiks on kogu maailm. 7.3 Käsundiandjal on õigus teha töös (teoses) ja selle üksikutes osades muudatusi, kohandusi, töötlusi, teost piiramatult kopeerida, muuta, edasi anda (alllitsentse anda) ning saadud teost kasutada ja levitada või teostada teose ja selle osade suhtes muid autori varalisi ja isiklikke õigusi. 7.4 Käsundisaaja 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 Käsundiandja poolt. 7.5 Kõik Käsundisaaja poolt Lepingu täitmise käigus koostatud dokumendid ja andmed kuuluvad Käsundiandjale. Käsundisaaja annab kõik nimetatud dokumendid ja andmed Käsundiandjale üle. Käsundisaaja võib jätta endale dokumentide ja andmete koopiad, kuid ilma Käsundiandja eelneva kirjaliku nõusolekuta ei tohi ta neid kasutada. 7.6 Lepingu täitmisel koostatud käsikirjade, tarkvara või nende osade omand, autori- ja muud õigused kuuluvad Käsundiandjale. 7.7 Käsundiandjal on omandiõigus materiaalsetele andmekandjatele, mille vahendusel töö (teos) Käsundiandjale edastatakse. 8. Konfidentsiaalsus 8.1 Pooled peavad lepingu täitmise käigus teineteiselt ükskõik mis vormis saadud kogu informatsiooni, millele seda avaldanud lepingupool on osutanud kui konfidentsiaalsele või mille konfidentsiaalsust võib mõistlikult eeldada, konfidentsiaalseks (sh intellektuaalset omandit ja know-how) ja ei anna seda edasi kolmandatele isikutele ilma teise poole kirjaliku nõusolekuta, välja arvatud õigusaktides ettenähtud juhtudel. 8.2 Konfidentsiaalsed on muuhulgas poolte poolt kasutatavad töömeetodid, töös kasutatavad protsessid, süsteemid jmt, millised neid kasutav pool on ise välja töötanud. 8.3 Konfidentsiaalsusnõue kehtib nii lepingu täitmise ajal kui ka pärast seda tähtajatult. 8.4 Käsundisaaja hoidub suhetest, mis võivad kompromiteerida tema sõltumatust. 8.5 Konfidentsiaalsuskohustuse rikkumist käsitletakse Lepingu olulise rikkumisena ja Käsundiandja võib, loobumata oma õigusest sellega seotud kahjude hüvitamiseks ja leppetrahvile, otsekohe lepingu üles öelda. 9. Isikuandmed 9.1 Pooled tagavad oma tegevuses vastavuse kohalduvatele andmekaitse õigusaktidele. Pooled täidavad kõiki lepingu täitmise kohas kehtivaid isikuandmete töötlemisalaseid nõudeid, andmete turvalisust puudutavaid ning isikuandmete kaitse alaseid Euroopa Liidu ja Eesti Vabariigi õigusakte. 9.2 Käsundisaaja töötleb teenuse osutamiseks vajalikus ulatuses isikuandmeid Käsundiandja ülesandel. 9.3 Käsundisaaja kasutab teenuse osutamise käigus saadud isikuandmeid üksnes lepingus sätestatud eesmärkide täitmiseks. Lepingu lõppemisel kohustub Käsundisaaja kustutama kõik talle lepingu täitmisel teatavaks saanud isikuandmed ja nimetatute koopiad, v.a juhul, kui õigusaktidest tuleneb teisiti. 9.4 Käsundiandja võimaldab juurdepääsu isikuandmetele üksnes 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 ka pärast käesoleva lepingu lõppemist.  9.5 Käsundisaaja rakendab vajalikke organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid isikuandmete kaitseks juhusliku või tahtliku volitamata muutmise, juhusliku hävimise, tahtliku hävitamise, avalikustamise jms eest. 9.6 Käsundisaajal ei ole õigust edastada isikuandmeid kolmandatele isikutele ega kasutada isikuandmete töötlemiseks omakorda volitatud töötlejaid ilma Käsundiandja eelneva kirjaliku loata. 9.7 Teenuse osutamise raames töödeldavate isikuandmetega seotud rikkumise korral teavitab Käsundisaaja Käsundiandjat sellest viivituseta pärast seda, kui ta on rikkumisest teada saanud. 9.8 Käsundiandjal on õigus lisaks nõuda täiendava isikuandmete töötlemise lepingu sõlmimist või esitada täiendavaid juhiseid isikuandmete töötlemisele Käsundisaaja poolt. 10. Avalikud suhted 10.1 Käsundisaaja ei tegele Lepinguga seoses avalike suhetega ega anna teateid pressile, elektroonilisele meediale, üldsusele või teistele auditooriumidele, va Käsundiandja eelneval kirjalikul nõusolekul. Avaldada võib vaid teateid, mis on Käsundiandjaga eelnevalt kooskõlastatud. 11. Poolte vastutus 11.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 käesolevas peatükis kokkulepitule. 11.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. 11.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. 11.4 Oluliseks lepingurikkumiseks loetakse muu hulgas järgmisi rikkumisi: 11.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; 11.4.2 Käsundisaaja rikub personaliga seonduvaid tingimusi; 11.4.3 Käsundisaaja suhtes on algatatud pankrotimenetlus, pankrot on välja kuulutatud, täitja varad arestitakse või täitja finantsseisund halveneb käsundiandja põhjendatud hinnangul oluliselt ja see halvenemine muudab vähetõenäoliseks lepingu nõuetekohase täitmise; 11.4.4 Pool on rikkunud intellektuaalse omandi õigusi ja nende kasutamise tingimusi; 11.4.5 Pool on rikkunud konfidentsiaalsuskohustust ja/või isikuandmetega seonduvaid kohustusi; 11.4.6 Pool on rikkunud avalikustamise keelu kohustust; 11.4.7 Pool on rikkunud kolmandate isikutega seonduvaid kohustusi; 11.4.8 Käsundiandja on viivituses lepingus kokku lepitud maksetähtajaga rohkem kui kolmkümmend (30) kalendripäeva. 11.5 Poolel on õigus nõuda lepingu olulise rikkumise korral leppetrahvi tasumist kuni 30% lepingu hinnast iga vastava juhtumi korral. 11.6 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 märgitud tähtaja jooksul. 11.7 Pool on kohustatud esitama leppetrahvi nõudele vastuväite enne leppetrahvi tasumise tähtaega kirjalikku taasesitamist võimaldavas vormis, kui leiab, et leppetrahvi nõue on alusetu. Kui Pool nõustub teise Poole vastuväitega ning leiab, et leppetrahvi aluseks olnud rikkumine on lepingust või seadusest tulenevalt vabandatav, esitab ta teisele Poolele vastava teatise kirjalikku taasesitamist võimaldavas vormis ja vajadusel kreeditarve. 11.8 Leppetrahvi nõudmine ei mõjuta poole õigust nõuda teiselt poolelt nõuetekohase töö või selle osa teostamist ning leppetrahvi ületavat kahju hüvitamist või kasutada muid seadusest tulenevaid õiguskaitsevahendeid. 11.9 Poolte rahaline koguvastutus on piiratud lepingu kogumaksumusega, välja arvatud juhul, kui Pool rikkus kohustust tahtlikult või raske hooletuse tõttu. 11.10 Lisaks leppetrahvi nõudele ja / või leppetrahvi asemel on käsundiandjal õigus nõuda käsundisaajalt lepingu mittenõuetekohasel täitmisel, et:  10.10.1 käsundisaaja kõrvaldaks puudused, sealhulgas nõuda, et käsundisaaja hangiks parema teenuse osutamiseks vajalikud lisa- või asendusseadmed, -telekommunikatsioonid, -tarkvara ja teenused; 10.10.2 olulise lepingurikkumise, samuti rikkumise kõrvaldamise ebaõnnestumise korral keelduda töö vastuvõtmisest ning leping erakorraliselt ühepoolselt lõpetada; 10.10.3 võtta pakutud töö vastu ning alandada vastavalt hinda. 11.11 Lepingust tulenevate leppetrahvide maksmine, samuti tekitatud kahju hüvitamine, ei vabasta lepingut rikkunud poolt lepingujärgsete kohustuste täitmisest. 12. Teadete edastamine 12.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. 12.2 Kui teisele poolele edastatav teade eeldab vastust, tuleb vastata viivitamatult, kuid mitte hiljem kui 2 tööpäeva jooksul. 12.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: 12.3.1 teade on üle antud allkirja vastu; 12.3.2 teade on edastatud tähitud kirjana poole postiaadressil ja teate postitamisest on möödunud 5 (viis) kalendripäeva; 12.3.3 e-posti või telefoni teel saadud teate saamist on kinnitatud e-posti teel. 13. Lepingu kehtivus ja muutmine 13.1 Leping kehtib Lepingu nõuetekohase täitmiseni. 13.2 Käsundiandjal on õigus Leping üles öelda 30-päevase etteteatamistähtajaga. Taolisel juhul kohustub Käsundiandja tasuma Käsundisaajale faktiliselt osutatud teenuste eest. 13.3 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. 13.4 Riigihangete seaduse § 123 lg 1 p 1 kirjeldatud muudatused lepitakse kokku Käsundiandja ja Käsundisaaja esindajate poolt kirjalikku taasesitamist võimaldavas vormis. 14. Vääramatu jõud 14.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. 14.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: 14.2.1 takistava asjaolu esinemine, mis takistab kohustuse kohast täitmist; 14.2.2 takistava asjaolu asetsemine väljaspool võlgniku mõjusfääri; 14.2.3 asjaolu ettenägematus; 14.2.4 asjaolu vältimatus ja ületamatus. 14.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. 15. Muud tingimused 15.1 Leping tühistab kõik pooltevahelised Lepingus ettenähtud Käsundi täitmist puudutavad varasemad suulised ja kirjalikud kokkulepped. 15.2 Poole nõue teisele Poolele, mis esitatakse tulenevalt Lepingu rikkumisest, peab olema esitatud kirjalikus vormis 15.3 Käsundisaaja ei või oma lepingujärgseid õigusi ega kohustusi üle anda kolmandatele isikutele.  15.4 Pooled võivad loovutada lepingust tulenevaid rahalisi nõudeid kolmandatele isikutele. Pooled on kohustatud teineteist nõude loovutamisest viivitamatult informeerima. Käsundiandja võib edastada arve tasumise Käsundiandjast erinevale isikule. Vastav teavitus on toodud pakkumuse esitamise ettepanekus. 15.5 Lepingu täitmisel tekkinud erimeelsused ja vaidlused lahendavad Pooled vastastikusel mõistmisel põhinevate läbirääkimiste teel, kokkuleppe mittesaavutamisel Harju Maakohtus. 15.6 Lepingus reguleerimata küsimustes juhinduvad Pooled Eesti Vabariigis kehtivatest õigusaktidest. 15.7 Pooled on Lepingu allkirjastanud digitaalselt. /digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/ Rivo Reitmann ...............  Leping nr …. Lisa 1 TEHNILINE KIRJELDUS Tehniline kirjeldus sisaldub Lepingu asice konteineris eraldi pdf failina.  Leping nr ....... Lisa 2 Töö üleandmise-vastuvõtmise akti vorm Töö üleandmise-vastuvõtmise akt Lähtudes ………………… (edaspidi Käsundisaaja) ja Registrite ja Infosüsteemide Keskuse (edaspidi Käsundiandja) vahel ............. sõlmitud käsunduslepingust nr ………(edaspidi Leping): 1. Annab Käsundisaaja, keda esindab …………, üle ja Käsundiandja, keda esindab ………………., võtab Käsundisaajalt vastu Lepingu kohaselt teostatud töö: / töö kirjeldus, periood / 2. Käsundi täitmise eest makstakse Käsundisaajale /kuu/aasta/ ......…… (/summa/) eurot. 3. Tööde teostamiseks kulunud aeg tundides: ……………….. 4. Juhul kui Käsundiandjal on pretensioone töö kvaliteedi või töö mittevastavuse kohta Lepingu tingimustele, mida Käsundisaaja pole vastavalt Lepingus sätestatule kõrvaldanud, märgitakse need käesolevas aktis. Käsundiandja: Käsundisaaja: Registrite ja Infosüsteemide Keskus .................................. registrikood: 70000310 registrikood: ......... aadress: Lubja 4, Tallinn aadress: ........... telefon: 663 6300 telefon: ............. e-post: [email protected] e-post: ................ Käsundiandja: Käsundisaaja: /digitaalselt allkirjastatud/ /digitaalselt allkirjastatud/  Leping nr ….. Lisa 3 PAKKUMUS Pakkumus sisaldub Lepingus asice konteineris eraldiseisva konteinerina.