Grįžti į sąrašą

Naujos NPB svetainės sukūrimo ir palaikymo paslaugos

Išanalizuota

UAB ILTE

Rinkos konsultacijaCPV: 72243000 - Programavimo paslaugos
ID: 70866722026-03-24 16:24
Atidaryti CVP IS

Aprašymas

Perkamos naujos nacionalinio plėtros banko (NPB) interneto svetainės su turinio valdymo sistema (TVS) sukūrimo ir palaikymo paslaugos. Tai apima svetainės testavimą, diegimą, naudotojų apmokymus, automatizuotą duomenų perkėlimą, svetainės vystymo darbus ir garantinį aptarnavimą, siekiant sukurti modernų, saugų ir patogų sprendimą.

Kvalifikaciniai reikalavimai

Kvalifikacinių reikalavimų nerasta

Techniniai reikalavimai

TVS nustatymai

  • 1Administratorius turi galėti keisti Svetainės ir turinio valdymo sistemos nustatymus: įkeliamų nuotraukų didžiausią saugomą dydį, pvz., nurodyti, kad visos saugomos nuotraukos turi būti ne didesnės kaip 1000x800 px, tokiu būdu visos įkeliamos nuotraukos turi būti sumažinamos iki nustatyto dydžio ir originalas automatiškai pašalinamas.
  • 2Administratorius turi galėti keisti informaciją sisteminiams tinklalapiams, kurie rodomi, kai lankytojas kreipiasi į nuorodą, kuri yra neveikianti ar informacija buvo pašalinta („Tinklapis nerastas“), ir sisteminiams tinklalapiams, kurie rodomi, kai lankytojas bando pasiekti turinį, prie kurio jam yra uždrausta prieiga („Prieiga uždrausta“).
  • 3Turi būti realizuotas Svetainėje naudojamų sisteminių žodžių (pvz.: spausdinti, paieška, pirmyn, ieškoti, filtras, žiūrėti, daugiau ir kt.) valdymas ir vertimas į kitas kalbas.
  • 4Administratorius naudodamas TVS įrankius turi galėti atlikti paiešką, filtruoti kurių vertimų trūksta. Vertimai turi būti administruojami įvedant tekstą arba WYSIWYG redaktoriaus pagalba.

Vedlių modulis

  • 1Svetainėje turi būti sukurti vieno ar kelių tipų vedliai, skirti skirtingoms lankytojų reikmėms: paslaugos identifikavimo vedlys, padedantis lankytojui nustatyti, kuri paslauga jam aktualiausia; informacinis vedlys, parodantis žingsnius ar kelionę iki konkrečios paslaugos gavimo.
  • 2Visi vedliai turi būti formuojami žingsnių principu. Kiekviename žingsnyje lankytojas turi atlikti pasirinkimus arba susipažinti su pateikta informacija, o žingsnių struktūra bei seka turi būti valdoma TVS aplinkoje.
  • 3Paslaugos identifikavimo vedlio atveju, PO pateiks klausimų ir pasirinkimo reikšmių matricą.
  • 4Paslaugos identifikavimo vedlyje lankytojo pasirinkimai turi lemti rezultatų sąrašą (aktualias paslaugas).
  • 5Informaciniame vedlyje žingsniai turi nuosekliai paaiškinti procesą iki paslaugos gavimo, pateikiant reikalingus veiksmus, reikalavimus ar dokumentus.
  • 6Vedlio rezultatų puslapyje turi būti pateikiamas aktualių paslaugų sąrašas arba procesą apibendrinanti informacija.
  • 7TVS aplinkoje turi būti suteikta galimybė kurti, redaguoti ir šalinti vedlio žingsnius, klausimus, atsakymų variantus bei jų ryšį su paslaugomis.
  • 8Vedlio sąveikoje turi būti rodoma žingsnių eiga (vizualus žingsnių rodiklis) ir galimybė grįžti į ankstesnį žingsnį neprarandant įvestos informacijos.
  • 9TVS turi suteikti galimybę koreguoti, papildyti ar pašalinti paslaugas, rodomas paslaugos identifikavimo vedlio rezultatuose.
  • 10Turi būti renkami vedlio naudojimo duomenys: pradėtų, užbaigtų sesijų skaičius, pasirinkimų dažniai.

Sąrašo modulis

  • 1Sąrašo tinklalapis skirtas vidinėje Svetainės dalyje atvaizduoti tekstą ar nuorodų sąrašą į kitus tinklalapius: tiek į vidinius, tiek į išorinius.
  • 2Turi būti galimybė nustatyti, ar nuoroda atsidarys naujame, ar tame pačiame naršyklės lange.
  • 3Sąrašas Svetainėje turi būti atvaizduojamas grafiškai, pvz., blokeliai su ikonomis, ar kitaip. Jei tai ikonos ar kiti panašūs grafiniai elementai, turi būti galimybė juos TVS aplinkoje keisti.
  • 4Turi būti galimybė redaguoti sąraše esančią tekstinę informaciją WYSIWYG redaktoriaus pagalba.
  • 5Turi būti galimybė įjungti ir tvarkyti tekstinę informaciją virš ir po sąrašu. Ši informacija turi būti valdoma WYSIWYG redaktoriaus pagalba.

Paslaugų apimtis

  • 1Naujos NPB interneto svetainės su turinio valdymo sistema (TVS) sukūrimas.
  • 2Svetainės testavimas ir diegimas į Perkančiosios organizacijos (PO) pateiktą infrastruktūrą.
  • 3Naudotojų apmokymai, apimantys Svetainės administravimo ir TVS naudojimo įgūdžių įgijimą.
  • 4Automatizuotas duomenų perkėlimas iš esamos interneto svetainės į naujai sukurtą Svetainę, užtikrinant duomenų vientisumą, konfidencialumą ir prieinamumą.
  • 5Svetainės vystymo darbai, apimantys papildomų, techninėje specifikacijoje neįvardintų, funkcionalumų kūrimą ir esamų atnaujinimą pagal Perkančiosios organizacijos poreikius.
  • 6Svetainės palaikymo paslaugos.
  • 7Garantinio aptarnavimo paslaugos, apimančios galimų klaidų, sistemos atnaujinimų ar trikdžių šalinimą Sutarties galiojimo metu nuo Svetainės įdiegimo ir perdavimo naudojimui dienos.

Renginių modulis

  • 1Sistema turi suteikti galimybę kurti, redaguoti ir trinti renginius, nurodant visus svarbiausius renginio atributus.
  • 2Renginio kortelėje turi būti pateikiama ši informacija: renginio pavadinimas; pagrindinis vaizdas (thumbnail); trumpas aprašymas; renginio data (viena data arba kelių dienų intervalas); renginio vieta; žyma, nurodanti, ar renginys mokamas, ar nemokamas; mygtukas ar kita žyma su nuoroda, nukreipianti į vidinį renginio puslapį.
  • 3Turi būti sukurtas vidinis renginio puslapis, kuriame pateikiama išsami informacija: renginio pavadinimas; išsami informacija (valdoma WYSIWYG redaktoriaus pagalba); programa, pranešėjai ar kita papildoma struktūruota informacija (jei numatyta); nuoroda ar mygtukas registracijai (jei numatyta); galimybė pridėti dokumentus, vaizdus ar kitą mediją (jei numatyta); papildomos žymos (tags), jei jos naudojamos filtravimui ar paieškai.
  • 4Renginių sąraše turi būti realizuota filtravimo sistema: pagal datą (artėjantys renginiai, praėję, konkreti data, intervalas); pagal renginio tipą (gyvas, nuotolinis, vebinaras ar kiti tipai); pagal kainą (mokamas / nemokamas).
  • 5Lankytojas, ką tik atėjęs į renginių puslapį, turi matyti visus būsimus renginius nuo artimiausio iki tolimiausio.
  • 6Renginių sąraše turi būti realizuota paieška pagal renginio pavadinimą, vietą, tipą ir kitus reikšmingus atributus.
  • 7Renginių sąrašas turi palaikyti puslapiavimą.
  • 8Turi būti realizuota galimybė įsidėti renginį į Outlook, Google Calendar ar kitus plačiai naudojamus, populiarius kalendorius.
  • 9Turi būti galimybė padaryti renginių išvedimą pasirinktame puslapyje.
  • 10TVS aplinkoje renginių sąrašas turi būti patogiai filtruojamas ir rūšiuojamas pagal datą, tipą, statusą (artėjantis / praėjęs), kainą ar kitus požymius.
  • 11Renginių vaizdai (thumbnail) turi būti automatiškai optimizuojami (dydis, formatas pagal naršyklę).
  • 12Lankytojai turi galėti pasidalinti renginiu socialiniuose tinkluose, pasinaudoję specialiai įdiegtais dalinimosi mygtukais.
  • 13Modulis turi būti pilnai pritaikytas mobiliesiems įrenginiams.

Dokumentų modulis

  • 1Turi būti sukurta galimybė Svetainėje talpinti įvairius dokumentus: doc, pdf, xsl ir kt.
  • 2Patalpinus Svetainėje dokumentą ir po to jį keičiant (įdedant naują dokumento failą), turi išlikti ta pati dokumento nuoroda.
  • 3Talpinamų dokumentų kiekis turi būti neribojamas.
  • 4TVS turi būti galimybė dokumentus skirstyti į kategorijas (aplankus), subkategorijas.

Mediatekos modulis

  • 1Sistema turi suteikti galimybę valdyti vaizdo įrašų mediateką: įkelti, redaguoti, trinti ir klasifikuoti vaizdo įrašus.
  • 2Vaizdo įrašai turi būti palaikomi iš šių šaltinių: YouTube platformos; Vimeo platformos; tiesiogiai įkelti vaizdo failai (pvz., MP4) iš vietinio disko.
  • 3Turi būti realizuota neribota kategorijų ir subkategorijų struktūra, leidžianti klasifikuoti mediatekos įrašus hierarchiniu principu.
  • 4Kiekvienam vaizdo įrašui turi būti galima nurodyti šiuos duomenis: pavadinimą (antraštę); trumpą aprašymą (paantraštę), pasitelkiant WYSIWYG redaktorių; priskirti kategoriją, subkategoriją; matomumo būseną (rodyti / nerodyti); vaizdo įrašo įkėlimo datą (su galimybe administratoriui ją išjungti / įjungti rodymui).
  • 5Mediatekos puslapiai turi užtikrinti lankstų modulių (blokų) derinimą tarpusavyje.
  • 6Sistema turi automatiškai generuoti vaizdo įrašų miniatiūras (thumbnail) įkeliamiems vaizdo failams arba naudoti numatytas miniatiūras iš YouTube/Vimeo.
  • 7Turi būti užtikrinta galimybė atlikti mediatekos įrašų paiešką pagal pavadinimą, kategorijas, datą ir kitus atributus.
  • 8Turi būti realizuotas filtravimas pagal kategorijas / subkategorijas, įkėlimo datą ar kitus požymius.
  • 9Vaizdo įrašų grotuvas turi būti pilnai pritaikytas mobiliems įrenginiams ir atitikti šiuolaikinius naršyklių standartus.
  • 10Modulis turi užtikrinti aukštą našumą – palaikyti vaizdo įrašų sąrašų krovimą su puslapiavimu (pagination) ir efektyvų užklausų valdymą.
  • 11Turi būti galimybė padaryti pasirinktos kategorijos / subkategorijos ar visos mediatekos video įrašų išvedimą pasirinktame puslapyje.

Nukreipimo modulis

  • 1Turi būti sukurta galimybė kurti meniu punktus (įskaitant esančius Svetainės poraštėje), kurie leistų lankytoją nukreipti į kitą adresą: kitas svetaines ar vidinius Ilte.lt tinklalapius.
  • 2Turi būti galimybė nustatyti, ar nuoroda atsidarys naujame, ar tame pačiame naršyklės lange.

TVS SEO reikalavimai

  • 1TVS turi sudaryti galimybę kiekvienam tinklalapiui atskirai valdyti šiuos parametrus: tinklalapio pavadinimą; lango antraštės pavadinimą (HTML „Title“ žymė); nuorodos adresą; meniu pavadinimą; aprašymą (HTML „Meta Description“ žymė); raktažodžius; open Graph duomenis (pavadinimas, aprašymas, vaizdas); canonical žymas; kitas pažangias SEO žymes.
  • 2Svetainėje turi būti įdiegta galimybė automatiškai generuoti ir/ar paveldėti meta duomenis iš aukštesnio lygmens turinio struktūros, su galimybe juos rankiniu būdu koreguoti.
  • 3TVS turi automatiškai generuoti Svetainės žemėlapį XML formatu (sitemap.xml) ir jį atnaujinti kiekvieną kartą pakeitus turinį.
  • 4Sistemoje turi būti sudaryta galimybė redaguoti robots.txt failą per TVS administravimo sąsają.
  • 5TVS turi sudaryti galimybę administratoriui savarankiškai kurti, redaguoti ir trinti peradresavimus (301/302), įskaitant masinio importo funkciją (CSV formatas).
  • 6TVS turi leisti užregistruoti svetainę „Google Search Console“ sistemoje.
  • 7Svetainėje turi būti realizuotas Schema.org struktūrizuotų duomenų palaikymas (JSON-LD formatu), užtikrinant galimybę juos taikyti svarbiausioms svetainės turinio kategorijoms.
  • 8Daugiakalbėse svetainėse (LT ir EN versijos) turi būti automatiškai generuojamos tinkamos hreflang žymės visoms kalbinėms tinklalapių versijoms.
  • 9TVS turi sudaryti galimybę identifikuoti pagrindines technines SEO klaidas (pvz., dubliuojami arba trūkstami meta duomenys, neveikiančios nuorodos) ir jas atvaizduoti administravimo sąsajoje.
  • 10Tiekėjas privalo užtikrinti tinkamą Svetainės SEO paruošimą prieš jos paleidimą gamybinėje aplinkoje.
  • 11Tiekėjas privalo atlikti išsamų SEO testavimą ir pateikti dokumentuotus įrodymus Perkančiajai organizacijai, kad Svetainė yra tinkamai optimizuota paieškos sistemoms.
  • 12Tiekėjas, sukūręs naują Svetainę ir perkėlęs turinį iš senosios svetainės, privalo užtikrinti, kad visos esamos Google paieškos sistemoje indeksuotos nuorodos iš senosios svetainės būtų nukreiptos į naujas atitinkamo turinio nuorodas naujojoje Svetainėje. Šiam tikslui turi būti sukurti ir įdiegti 301 tipo nukreipimai.

TVS saugumo valdymas

  • 1Patekimas į TVS turi būti realizuotas, naudojant vartotoją vardą, slaptažodį ir antrą faktorių (pvz. Google authenticator vienkartinis kodas, vienkartinis kodas siunčiamas el.paštu, sms kodas ar pan.).
  • 2Turi būti įdiegta galimybė, leidžianti apriboti prieigą prie TVS administravimo dalies ir interneto svetainės, naudojant tinklo IP adresų šablonus. Juos valdyti ir koreguoti nustatant draudimus ir leidimus prisijungimams.
  • 3Turi būti galimybė blokuoti interneto svetainės lankytojus, naudojant tinklo IP adresų šablonus.
  • 4TVS sistema turi turėti apsaugą nuo XSS, SQL injection tipo atakų, slaptažodžiai duomenų bazėje saugomi ne atviru tekstu, bet šifruotai.
  • 5Turi būti įdiegta įkeliamų failų kompleksinė validacija (dokumento topas, plėtinys ir pan.).
  • 6Turi būti realizuotas stiprių slaptažodžių sudarymo mechanizmas. Administratorius turi turėti galimybę keisti reikalavimus naudotojų slaptažodžiams.
  • 7TVS sistema turi užtikrinti saugomų duomenų bei darbo sesijos su sistema saugumą, t.y. turi būti eliminuota arba kiek įmanoma sumažinta galimybė sutrikdyti sistemos darbą arba duomenų korektiškumą, nesankcionuotai prisijungus prie sistemos.
  • 8Administratorius turi galėti nustatyti, kiek laiko galioja slaptažodžiai. Praėjus nustatytam laikui, prisijungęs administratorius privalo jį pasikeisti į naują saugų slaptažodį, atitinkantį nustatytus saugumo parametrus.

TVS įvykių istorija

  • 1TVS turi būti registruojama administratorių darytų veiksmų istorija (prisijungimai, atsijungimai, turinio redagavimai, šalinimai, vartotojų sukūrimai, veiksmai sistemoje, darantys įtaką sistemos stabilumui, saugumui ar funkcionalumui ir pan.) ir generuojamos ataskaitos CSV, Excel ar kitu standartiniu formatu.
  • 2Taip pat turi būti pateikiamas sistemos klaidų registras.
  • 3Administratorius turi galėti gauti informaciją, iš kokio IP adreso jungėsi naudotojas ir kokius veiksmus jis atliko sistemoje.
  • 4Veiksmų istorijos ataskaitose turi būti realizuota lanksti paieška pagal įvairius parametrus: datą, vartotojų grupes, vartotojus, administratorius, IP adresus, modulius, veiksmus, prisijungimus ir t.t.

Mokymai ir konsultacijos

  • 1Tiekėjas įsipareigoja pravesti Svetainės administravimo mokymus PO patalpose ar pagal poreikį nuotoliniu būdu. Mokymų medžiagą rengia Tiekėjas.
  • 2Mokymuose dalyvaus iki mokymo dienos sutartas PO darbuotojų skaičius.
  • 3Mokymai turi apimti šias dalis: svetainės struktūros kūrimas ir administravimas; modulių naudojimas, administravimas; administratorių kūrimas, administravimas; administruojamų funkcijų valdymas; administravimo veiksmų demonstravimas; atsakymai į PO darbuotojams kylančius klausimus.
  • 4Tiekėjas visu garantiniu laikotarpiu privalo suteikti konsultacijas telefonu, elektroniniu paštu ar kitomis el. priemonėmis (pvz., MS Teams, Zoom ar kt.) Svetainės administravimo, funkcionalumų naudojimo ir vystymo galimybių klausimais.
  • 5Visa mokymų medžiaga ir TVS naudojimosi instrukcija turi būti pateikta PO elektroniniu būdu PDF ar lygiaverčiu formatu.

TVS struktūros valdymas

  • 1TVS turi būti galimybė valdyti, keisti Svetainės struktūrą: kurti, šalinti meniu punktus, padaryti tinklalapius nematomus ir/ar nepasiekiamus Svetainės lankytojams, galimybė maketuoti tiek Svetainės pirmąjį puslapį, tiek pagal hierarchiją žemesnio lygmens Svetainės puslapius.
  • 2Turi būti galimybė perkelti visą struktūros šaką ar vieną elementą į kitą struktūros vietą vilkimo būdu. Atlikus perkėlimo veiksmą visos nuorodos į tinklalapį turi išlikti veikiančios.
  • 3Struktūros valdymas turi būti intuityvus ir paprastas, t. y. turi būti galimybė vieno paspaudimo pagalba padaryti struktūros elementą-tinklalapį nematomą ar nepasiekiamą lankytojams.
  • 4Svetainės struktūros atvaizdavimas turi veikti dinamiškai, t. y. turi būti galimybė paspaudus peržiūrėti submeniu punktus, suskleisti ir išskleisti struktūrą.
  • 5Struktūroje prie kiekvieno struktūros elemento turi būti pateikiama ne mažiau kaip: pavadinimas, puslapis rodomas ar slepiamas, aktyvus ar neaktyvus, naudojamas modulis, tinklalapis viešas ar su ribota prieiga.
  • 6Turi būti galimybė redaguoti tinklalapių nustatymus, tinklalapius peržiūrėti Svetainėje, valdyti Svetainės lankytojų ir TVS administratorių teises į konkretų tinklalapį.

Paslaugų sąrašo modulis

  • 1Turi būti sukurta galimybė kurti paslaugų tinklalapius, naudojant bet kurį TVS esantį modulį.
  • 2Svetainėje turi būti sukurta galimybė atvaizduoti pasirinktas ILTE paslaugas vienoje vietoje, kur lankytojas galėtų atlikti paiešką pagal projekto analizės metu susiderintus priemonės kriterijus.
  • 3Turi būti sukurta galimybė kurti paslaugų kategorijas, joms priskirti paslaugas.
  • 4Turi būti galima vienos kategorijos paslaugas atvaizduoti kituose pasirinktuose tinklalapiuose.
  • 5Turi būti sukurta galimybė vieną paslaugą priskirti kelioms kategorijoms.

TVS bendrieji reikalavimai

  • 1Darbas su TVS turi būti lengvai suprantamas asmenims, neturintiems programavimo patirties, nereikalauti specialių techninių žinių.
  • 2Vartotojo sąsaja, valdymo elementai, informacijos pateikimas turi būti orientuotas į atliekamus veiksmus ir pagelbėti susiorientuoti sistemoje bei išlaikyti vientisumą visuose moduliuose.
  • 3Sukuriamoje TVS turi būti užtikrintas kokybiškas, be klaidų ir iškraipymų veikimas, nepriklausomai nuo administratoriaus naudojamos operacinės sistemos (pvz., Windows, Linux, Unix ar kt.).
  • 4Sistemos palaikomos naršyklės – bent dvi paskutinės stabilios kiekvienos naršyklės versijos bei jų dar remiama versija (Microsoft Edge, Mozilla Firefox, Google Chrome, Opera, Safari).
  • 5Tiekėjas privalo užtikrinti, kad Svetainė veiktų su šių naršyklių stabiliausiomis versijomis ir kad prieš priėmimą būtų atliktas testavimas bent dviem paskutinėmis versijomis.
  • 6TVS turi būti pritaikyta valdymui iš mobilių įrenginių nepriklausomai nuo platformos (iOS, Android, Windows).
  • 7TVS neturi riboti vartotojų, darbo vietų, prisijungimų skaičiaus.
  • 8TVS turi palaikyti daugelį administratorių vienu metu, kad keli nepriklausomi naudotojai turėtų galimybę vienu metu kurti turinį, o visi interneto svetainės lankytojai – jį pasiekti.
  • 9Administratoriai realiu laiku turi matyti, ar nėra redaguojamas tas pats turinys tuo pačiu metu.
  • 10Sistemoje turi būti kaupiamos visos Svetainėje pateikiamos nuotraukos, dokumentai, vaizdo įrašai, animacijos, garsiniai ir kitokie svetainėje naudojami failai.
  • 11Informacija turi būti saugoma sugrupuota, administratoriui turi būti galimybė atlikti paiešką ir peržiūrėti surastą medžiagą, ją tvarkyti (keisti matmenis, META duomenis, perkelti, pašalinti, pakeisti ir pan.).
  • 12Sistema turi užtikrinti kiekvieno nedalomo informacijos vieneto – objekto (pvz.: struktūros elemento, naujienos) – funkcijas, kurios leistų objektą padaryti nematomą arba neaktyvų.
  • 13TVS neturi riboti, kiek kartų tam tikri moduliai bus panaudoti, t. y. Svetainėje turi būti galima naudoti neribotą kiekį teksto tinklalapių, sąrašo tinklalapių ar pan.
  • 14Bet kuris Svetainėje naudojamas modulis (blokas) turi būti savarankiškas funkcionalumo vienetas, kuris gali būti panaudotas bet kuriame Svetainės tinklalapyje ir bet kurioje jo dalyje, neribojant jų skaičiaus.
  • 15Turi būti sudaryta galimybė TVS aplinkoje vienu mygtuko paspaudimu dubliuoti esamus puslapius kartu su jų turiniu, struktūra, blokų išdėstymu, nustatymais ir meta informacija.
  • 16Visur (pvz., naujienose, galerijose ir kt.), kur naudojamas paveiksliukų įterpimas, turi būti naudojamas automatinis nuotraukų sumažinimas ir/ar apkirpimas pritaikant prie numatyto dizaino. Administratorius taip pat turi galėti pasinaudoti įrankiu iškirpti tik norimą paveiksliuko vietą.
  • 17Kiekvieno puslapio antraštė turi būti kuriama automatiškai pagal pavadinimą. Svetainės nuorodos (URL) turi būti unikalios, trumpos ir aiškios.
  • 18TVS automatiniu būdu sugeneruotas puslapio adresas turi išlikti pastovus to puslapio viso gyvavimo ciklo metu.
  • 19Perkėlus tinklalapį į kitą Svetainės vietą, pakeitus Svetainės struktūrą, visos sąsajos ir nuorodos į sukurtus tinklalapius turi išlikti ir nereikalauti papildomo administratoriaus darbo jų sutvarkymui.
  • 20Turi būti galimybė rankiniu būdu koreguoti URL administravimo sąsajoje.
  • 21TVS turi turėti automatinį informacijos archyvavimą (turinio versijavimą), kuris užtikrina Svetainės atstatymą iš rezervinių kopijų sąrašo. Rezervinės kopijos turi būti daromos ne rečiau nei kiekvieną naktį ir saugomos ne trumpiau nei 3 mėnesius.
  • 22Turi būti galimybė valdyti skirtingas Svetainės kalbų versijas: lietuvių, anglų.
  • 23TVS turi būti lengvai pritaikoma naujiems poreikiams – esant reikalui praplečiama, patobulinama papildomais moduliais.
  • 24Pagrindinio tinklalapio titulinis skydelis (hero section) ir likusi titulinio puslapio dalis turi būti pilnai valdomi per TVS, suteikiant galimybę keisti tekstą, vaizdinę medžiagą, pridėti arba pašalinti mygtukus, keisti jų nuorodas ir išdėstymą.
  • 25TVS administratoriui turi būti suteikta galimybė pasirinkti vidiniuose tinklalapiuose rodyti paskutinio informacijos atnaujinimo datą.

Procesų žingsnių modulis

  • 1Turi būti sukurta galimybė atvaizduoti veiklos procesus žingsnių principu. Žingsnių eiliškumas turi būti pavaizduotas grafiškai.
  • 2Turi būti galimybė žingsnių tekstą redaguoti ir formatuoti WYSIWYG redaktoriaus pagalba.
  • 3Turi būti galimybė pačiam administratoriui įterpti mygtukus, įvairių tipų nuorodas.
  • 4Turi būti galimybė TVS įterpti bei redaguoti žingsnius vienijančią antraštę ir paantraštę (neprivalomi laukai).
  • 5Kiekviename žingsnyje turi būti galimybė įterpti išskleidžiamą turinį. Jį turi būti galima redaguoti WYSIWYG redaktoriaus pagalba.

Reikalavimai dokumentacijai

  • 1Tiekėjas privalo parengti ir perduoti PO šiuos dokumentus: Techninė dokumentacija, Naudotojo (administratoriaus) dokumentacija, Pakeitimų (versijų) žurnalas, Duomenų migravimo dokumentacija, Diegimo dokumentacija.
  • 2Dokumentacija turi būti pateikta lietuvių kalba, skaitmeniniu formatu (PDF arba DOCX).
  • 3Dokumentacija turi būti atnaujinama viso projekto įgyvendinimo ir garantinio aptarnavimo laikotarpiu, jei atliekami esminiai pakeitimai, turintys įtakos sistemos veikimui ar naudojimui.

Terminų laikmačio modulis

  • 1Turi būti galimybė kurti ir valdyti neribotą skaičių terminų skaičiuoklių – laikmačių atvirkštinio skaičiavimo principu, rodančių, kiek laiko (mėnesių, dienų, valandų, minučių) liko iki tam tikro termino.
  • 2Turi būti galimybė laikmatį priskirti pasirinktam tinklalapiui, kuriame jis būtų atvaizduojamas.
  • 3Laikmačio administruojamos dalys turi būti šios: pavadinimas (rodyti/ne); trumpas aprašymas (rodyti/ne); galutinis terminas; mygtukas (rodyti/ne); mygtuko tekstas (jei mygtukas rodomas); mygtuko nuoroda (jei mygtukas rodomas); paveikslėlis, jei dizaino gamybos metu bus suderintas laikmačio dizainas su paveikslėliu.

Statistikos grafikų modulis

  • 1Turi būti sukurta galimybė TVS aplinkoje kurti ir valdyti statistikos grafikus: vertikalius stulpelinius grafikus; horizontalius stulpelinius grafikus; linijines diagramas; žiedines ir skritulines (pie) diagramas; kitus, suderintus analizės metu.
  • 2Grafikus turi būti galima atvaizduoti Svetainėje, kartu pateikiant grafikų legendas. Legendose turi būti aiškiai nurodyti duomenų tipai, spalvos ir reikšmių paaiškinimai.
  • 3Virš grafikų ir po jais turi būti galimybė pridėti informaciją, valdomą WYSIWYG redaktoriaus pagalba.
  • 4Duomenys grafikams turi būti įvedami TVS aplinkoje per aiškią duomenų įvedimo formą. Turi būti galima redaguoti, trinti ir pridėti naujas eilutes su duomenų reikšmėmis.
  • 5Turi būti galimybė įjungti / išjungti grafikų animacijas (pvz., stulpelių išaugimas, linijos atsiradimas).
  • 6Turi būti įgyvendintas alternatyvus tekstinis duomenų atvaizdavimas (lentelė ir / arba diagramos reikšmių išklotinė), užtikrinant informacijos prieinamumą pagal WCAG reikalavimus.
  • 7Grafikai turi būti pritaikyti mobiliems įrenginiams.

Iššokančių langų modulis

  • 1Turi būti numatyta galimybė kurti ir valdyti iššokančius langus, kurių turinys yra pilnai redaguojamas TVS aplinkoje.
  • 2Administratorius turi galėti: keisti tekstą naudojant WYSIWYG redaktorių; įkelti paveikslėlius; įterpti mygtukus ir nuorodas nurodant, ar jos atidaromos tame pačiame, ar naujame lange; keisti spalvas, šriftus, dydžius ir kitus stiliaus parametrus; keisti iššokančio lango išdėstymą ekrane (pvz., centras, apačia, viršus ir pan.), dydį ir tipą (pvz., su fono užtemdymu ar be jo).
  • 3Turi būti galima TVS aplinkoje nustatyti iššokančio lango rodymo logiką: rodymo laiką (pradžia / pabaiga), su tikslumu iki minučių; rodymo dažnį (pvz., rodyti vieną kartą per sesiją, vieną kartą per dieną, kas kartą įėjus į puslapį); rodyti tik tam tikrame įrenginyje (desktop / mobilus), jei administratorius tai pasirenka.
  • 4Administratorius turi galėti parinkti puslapius, kuriuose langas bus rodomas.
  • 5Visi skydeliai turi būti pilnai responsyvūs ir tinkamai prisitaikyti prie skirtingų ekrano dydžių, be iškraipymų ar funkcionalumo praradimo.
  • 6Iššokantys langai turi būti optimizuoti našumui taip, kad jų įkrovimas nedidintų pirminio tinklalapio užkrovimo laiko.

TVS administratorių valdymas

  • 1Turi būti realizuota aiški ir suprantama teisių sistema. Turi būti galimybė priskirti naudotojus grupėms. Naudotojų skaičius neturi būti ribojamas.
  • 2Grupės turi būti skirstomos į administratorių ir lankytojų. Grupių skaičius neturi būti ribojamas.
  • 3Turi būti galimybė nustatyti, kokius tinklalapius, Svetainės dalis, modulius, kalbas galės valdyti skirtingų lygių administratoriai.
  • 4Turi būti galimybė apriboti administratoriams teises (redagavimo, šalinimo, kūrimo, nustatymų keitimo).

Tekstinis tinklalapis modulis

  • 1Tekstinis tinklalapis turi būti visiškai valdomas WYSIWYG redaktoriaus pagalba.
  • 2Svetainėje atvaizduojama tokia informacija, kokią įvedė administratorius.

Bendrieji sistemos reikalavimai

  • 1Prieš kuriant Svetainės koncepciją, turi būti atlikta analizė, apimanti funkcinio ir techninio sprendimo detalizavimą, vartotojų scenarijų ir informacijos struktūros apibrėžimą, turinio tipų ir duomenų struktūros nustatymą, integracijų su išorinėmis sistemomis reikalavimų patikslinimą, turinio migracijos principų apibrėžimą, TVS funkcionalumų ir administravimo logikos patikslinimą, pagrindinių UX/UI principų suderinimą ir interaktyvaus prototipo parengimą.
  • 2Atsižvelgiant į atliktos analizės rezultatus, turi būti sukurta Svetainės koncepcija ir dizainas bei sukurta Svetainė.
  • 3Turi būti sukurta Svetainės dokumentacija, įvykdyti naudotojų apmokymai, apimantys Svetainės administravimo ir TVS naudojimo įgūdžių įgijimą.
  • 4Tiekėjas turi suderinti detalų paslaugų teikimo planą, kuriame turi būti įvardytos tiektinos paslaugos ir apibrėžta: projekto etapai, jų įgyvendinimo trukmė, numatomi rezultatai; projekto valdymo struktūra, projekto dalyvių atsakomybės; projektų rezultatų derinimo, tvirtinimo procedūros.
  • 5Turi būti užtikrintas automatizuotas turinio perkėlimas iš esamos svetainės į naująją. Po perkėlimo administratorius turi galėti atlikti reikiamus koregavimus TVS aplinkoje.
  • 6Tiekėjas iš senosios ILTE svetainės turės perkelti visas naujienas (įskaitant visą turinį – tekstus, nuotraukas, kt.), skelbtas nuo 2015 m. sausio 7 d.
  • 7Turi būti galimybė nuo pasirinktos datos naujienas archyvuoti, kad jos būtų pasiekiamos visiems Svetainės lankytojams.
  • 8Svetainėje turi būti įdiegta TVS. TVS licencija neturi riboti administratorių, darbo vietų, prisijungimų skaičiaus ir turi būti palaikoma visu garantiniu priežiūros laikotarpiu.
  • 9Svetainė privalo būti pritaikyta stacionariems ir mobiliesiems įrenginiams, užtikrinant dinaminį navigacijos ir elementų išdėstymo prisitaikymą prie naudojamo įrenginio ekrano dydžio (responsive design).
  • 10Svetainė privalo užtikrinti daugiakalbę (multilingual) aplinką, t.y. turi turėti galimybę jos turinį skelbti anglų (ar kita) kalba, lankytojams sudarant galimybę pasirinkti (naudotis) Svetainės kitos kalbos versiją. Visos funkcijos ir moduliai turi veikti analogiškai tiek lietuvių, tiek kitos kalbos interneto svetainės versijose.
  • 11Sukurta Svetainė turi atitikti Europos darniojo standarto EN 301 549 „Informacinių ir ryšių technologijų produktų ir paslaugų prieinamumo reikalavimai“ (aktualios versijos), įskaitant ir Pasaulinio saityno konsorciumo (W3C) parengtų Žiniatinklio turinio prieinamumo gairių WCAG 2.2 ne žemesnio nei AA atitikties lygio nuostatas arba lygiaverčio standarto reikalavimus.
  • 12Visų modulių galutinis funkcionalumas, reikalingi laukai ir parametrai bei veikimo principai turi būti suderinti su PO paslaugų teikimo plane nustatytais terminais.
  • 13Svetainė turi būti sukurta naudojant atvirojo kodo programinę įrangą.
  • 14Visa sukurta programinio kodo bazė (įskaitant TVS, jos papildinius ir individualiai sukurtus sprendimus) turi būti perduota PO, suteikiant neribotas teises ją naudoti, keisti, platinti ir perduoti tretiesiems asmenims be papildomų mokesčių.
  • 15Sistemoje negali būti naudojami uždaro kodo ar licencijomis apriboti komponentai, ribojantys kodo modifikavimą, diegimą ar perdavimą.
  • 16Perdavimo metu tiekėjas privalo pateikti visą programinį kodą ir dokumentaciją, būtiną savarankiškam sistemos diegimui, priežiūrai ir tolesniam vystymui.
  • 17Sistema turi būti sukurta viena iš naujausių PHP versijų arba kita lygiaverte programavimo kalba.
  • 18Aprašomoji (META) ir sąsajų informacija turi būti saugoma reliacinėje duomenų bazėje, o dokumentai, failai, multimedija, duomenys turi būti saugomi diske.
  • 19TVS turi būti įdiegti visi įrankiai ir užtikrintos galimybės optimaliam SEO valdymui.
  • 20Turi būti galimybė integruoti Svetainę su trečiųjų šalių CRM (kandidatų atrankos ir įdarbinimo procesų valdymo platforma, kt.), naudojant trečiųjų šalių modulius.
  • 21Sistema turi užtikrinti galimybę naudotis saugiu HTTPS ryšiu.
  • 22Pateiktą PO SSL sertifikatą diegia ir atnaujina paslaugų tiekėjas. Baigiantis SSL sertifikato galiojimo laikui, tiekėjas informuoja PO Sutartyje nurodytu terminu.
  • 23Jeigu duomenų bazių valdymo sistemai bei kitai programinei įrangai, kuri yra būtina Svetainės funkcionavimui, reikalingos mokamos licencijos, jas turi pateikti Tiekėjas. Licencijų kaina turi būti įtraukiama į bendrą pasiūlymo kainą sutarties galiojimo laikotarpiui.
  • 24Sistemoje turi būti galimybė lauko lygmenyje patikrinti įvedamų duomenų logikos korektiškumą.
  • 25Turi būti numatyta apsauga nuo kenkėjiško kodo įkėlimo (pvz., apribota galimybė įkelti formatus su plėtiniais .com, .exe, .bat ir pan.) tiek Svetainėje, tiek TVS aplinkoje.
  • 26Sistema turi būti kuriama moduliniu (blokų) principu, užtikrinančiu Sistemos vientisumą, lankstumą, lengvas vystymo galimybes.
  • 27Informacija Svetainėje turi būti koduojama UTF-8 koduote ir palaikyti įvairių kalbų simbolius.
  • 28Visos Svetainės funkcijos turi be priekaištų funkcionuoti ir mobiliuosiuose įrenginiuose.
  • 29Svetainė turi būti pilnai suderinama su populiariausiomis interneto naršyklėmis. Palaikymas turi būti užtikrintas bent dviejų paskutinių oficialiai išleistų šių naršyklių versijų: Microsoft Edge, Mozilla Firefox, Google Chrome, Opera, Safari.
  • 30Sukurtoje Svetainėje turi būti atliktas mobiliųjų įrenginių pritaikomumo testas, naudojant Google Lighthouse arba Google PageSpeed Insights ar lygiavertes priemones. Testas turi patvirtinti, kad puslapiai atitinka mobiliųjų naršyklių ir naudotojų sąsajos reikalavimus, o bendras rodiklių rezultatų vidurkis turi būti ≥ 90.
  • 31Tiekėjas turi parengti ir talpinti Sistemą darbinėje (testinėje) aplinkoje projekto vykdymo ir garantinio aptarnavimo metu.
  • 32Visi atnaujinimai, pakeitimai ir testavimai turi būti atliekami darbinėje aplinkoje ir PO patvirtinus perkeliami į PO serverius.
  • 33Svetainėje negali būti nuorodos į Tiekėjo interneto svetainę bei kitos Tiekėjo reklamos.
  • 34Tiekėjas negali naudoti PO logotipo ar kito identifikuojančio elemento be PO sutikimo.

Duomenų migravimo reikalavimai

  • 1Tiekėjas turi užtikrinti nurodyto turinio, duomenų ir/ar struktūrų perkėlimą iš senosios ILTE Svetainės į naująją, pagal PO pateiktą apimtį ir duomenų sąrašą.
  • 2Prieš pradedant migravimo darbus, Tiekėjas turi pateikti PO atstovui trečiosios šalies saugos patikrinimo ataskaitą pagal OWASP TOP10 pažeidžiamumų sąrašą ir/arba įsilaužimo (Pentest) ataskaitą.
  • 3Migracija turi būti automatizuota tiek, kiek įmanoma techniškai, siekiant sumažinti rankinio darbo poreikį ir riziką suklysti. Automatizavimo lygis derinamas projekto metu.
  • 4Migracijos metu turi būti išsaugoti esminiai elementai: turinys (puslapiai, tekstai, atvaizdai, failai); kategorijos, struktūra, hierarchija; URL adresų logika; metaduomenys (SEO žymos, pan.); lankytojų, užpildžiusių Svetainėje esančias formas, duomenys.
  • 5Tiekėjas turi atlikti bandomąją migraciją testinėje aplinkoje, pateikti PO migracijos rezultatų ataskaitą ir ištaisyti trūkumus, netikslumus arba duomenų neatitikimus.
  • 6Galutinė migracija į produkcinę aplinką atliekama tik po sėkmingos bandomosios migracijos ir PO patvirtinimo.
  • 7Migracija negali sutrikdyti veikiančios Svetainės darbo. Turi būti užtikrintas sklandus perėjimas iš senosios į naująją, numatant reikiamus laikinius langus ir rizikos mažinimo veiksmus.
  • 8Tiekėjas prieš galutinę migraciją privalo pateikti: migracijos planą (laikai, trukmės, rizikos, atsakomybės); atsarginio kopijavimo planą; sistemos atstatymo planą, jei migracija nepavyktų.
  • 9Migracija negali būti atliekama penktadieniais, šventinių dienų išvakarėse ar kitais PO nurodytais aukštos rizikos laikais, išskyrus atvejus, kai tai suderinta su PO.
  • 10Po migracijos Tiekėjas privalo patvirtinti, kad visa perkelta informacija yra pilna, tiksli ir atitinka naujosios Svetainės struktūrą. Esant neatitikimų, Tiekėjas privalo juos ištaisyti savo resursais.

Informacinių skydelių modulis

  • 1Turi būti numatyta galimybė skirtingose Svetainės vietose kurti ir valdyti skirtingo tipo informacinius skydelius: tekstinius, reklaminius, dinaminius (rotuojantys/karuselės tipo), bėgančios eilutės tipo skydelius.
  • 2Svetainės vietas, kuriose gali būti naudojami skydeliai, nustato administratorius. Galimas pozicijas su iliustruotais pavyzdžiais Tiekėjas pateikia dizaino gamybos etape ir jos yra suderinamos bei patvirtinamos su PO.
  • 3TVS turi būti galimybė skydelius keisti vietomis naudojant vilkimo funkciją, laikinai paslėpti, redaguoti bei šalinti.
  • 4Dinaminių skydelių atveju turi būti galimybė keisti rodymo eiliškumą ir perėjimo parametrus.
  • 5Turi būti galimybė nustatyti skydelio rodymo laiką, nurodant pradžios ir pabaigos laiką minučių tikslumu.
  • 6TVS turi būti galimybė pasirinkti, kuriuose puslapiuose skydeliai bus rodomi: visuose Svetainės puslapiuose; tik tam tikruose Svetainės puslapiuose (administratorius gali nurodyti neribotą puslapių skaičių); išskirti puslapius, kuriuose skydeliai neturi būti rodomi (administratorius gali nurodyti neribotą puslapių skaičių).
  • 7Visi skydeliai turi būti pilnai responsyvūs ir tinkamai prisitaikyti prie skirtingų ekrano dydžių, be iškraipymų ar funkcionalumo praradimo.
  • 8Skydeliai turi būti optimizuoti našumui taip, kad jų įkrovimas nedidintų pirminio tinklalapio užkrovimo laiko.

Išskleidžiamo turinio modulis

  • 1Turi būti galimybė Svetainėje talpinti išskleidžiamą, suskleidžiamą turinį.
  • 2Šį turinį turi būti galima skirstyti į kategorijas, subkategorijas – tiek vienos, tiek kitos turi išsiskleisti, susiskleisti.
  • 3Turi būti galimybė tarp suskleidžiamų kategorijų įterpti tekstą, kuris nebūtų priskirtas nei vienai kategorijai ir kuris matytųsi iš karto be jokio paspaudimo.
  • 4Turi būti galimybė talpinti tekstą prieš ir po kategorijų ir subkategorijų.
  • 5Visi tekstai: kategorijų, subkategorijų, įterptiniai tarp kategorijų, tekstai prieš ir po, turi būti valdomi WYSIWYG redaktoriaus pagalba.
  • 6TVS turi būti sukurta galimybė keisti kategorijų ir subkategorijų eiliškumą vilkimo būdu.
  • 7Turi būti galimybė padaryti kategorijas, subkategorijas nematomas – tokios kategorijos, subkategorijos turi būti nerodomos svetainėje.
  • 8Rodymo nustatymai turi būti realizuoti kiekvienai kategorijai, subkategorijai atskirai.
  • 9Naudojant išskleidžiamo turinio modulį turi būti sudaryta galimybė nurodyti, kurios sekcijos pagal nutylėjimą turi būti išskleistos.
  • 10Išskleidžiant naują kategoriją, prieš tai buvusi yra suskleidžiama automatiškai (galimybė vienu metu lankytojui matyti tik vienos kategorijos išskleistą turinį). Tas pats galioja ir subkategorijoms.
  • 11Išskleidimuose (tiek kategorijose, tiek subkategorijose) turi būti galimybė įterpti procesų žingsnių, turinio atvaizdavimo ir kt. modulius, suderintus analizės etape.

Svetainės dizaino reikalavimai

  • 1Svetainės dizaino koncepcija turi būti kuriama kartu su PO, įvertinant ir atsižvelgiant į jos pastabas.
  • 2Dizainas turi būti pritaikytas įvairių tipų įrenginiams (responsive design): standartinei (desktop), planšečių (tablet) bei mobiliųjų įrenginių (mobile) versijoms.
  • 3Svetainės dizainas turi atitikti šiandienines tendencijas, naudojamas technines galimybes, orientuotas į vartotojo naršymo įpročius ir vartotojo sąsajos patogumą.
  • 4Svetainės dizainas turi būti orientuotas į projekto tikslinius naudotojus, jų įpročius, naudojamas technologijas.
  • 5Svetainės dizainas turi būti unikalus ir vientisas (atskiros svetainės dalys neturi išsiskirti iš bendros svetainės dizaino koncepcijos) ir lengvai suprantamas vartotojui.
  • 6Svetainės išdėstymas ir informacijos pateikimas turi būti kuriamas pagal vartotojo sąsajos gerąsias praktikas, atsižvelgiant į goodui.org rekomendacijas.
  • 7Tiekėjas turi pateikti ir pagrįsti ne mažiau kaip tris skirtingas dizaino koncepcijas.
  • 8Susiderinus ir PO pasirinkus bei patvirtinus Svetainės dizaino koncepciją, tiekėjas turi sukurti visų tinklalapių šablonų (titulinis tinklalapis, vidinis tinklalapis, paieškos rezultatai, naujienos, įvairūs informacijos pateikimo blokai ir kt.), ikonų, siunčiamų elektroninių laiškų dizainus.
  • 9Kuriant dizainą, turi būti pateikti ir mobiliosios versijos maketai (pagrindinių dalių: titulinio tinklalapio, vidinio tinklalapio, paieškos rezultatai, naujienos).
  • 10Svetainės turinio architektūra turi būti suderinta projekto analizės metu. Tiekėjas pagal analizės rezultatus turi pasiūlyti turinio architektūros sprendimą, kuris turi atsispindėti siūlomuose dizainuose pateikiant konkrečius meniu punktų pavadinimus.
  • 11Svetainės viršuje turės būti du logotipai: ILTE ir Europos Sąjungos struktūrinių ir investicinių fondų. Pagal keliamus reikalavimus, logotipai turi būti lygiaverčiai, pateikiami vienas šalia kito.

Kategorizuotų naujienų modulis

  • 1Turi būti galimybė kurti ir valdyti naujienas.
  • 2Turi būti galimybė kurti ir valdyti naujienų kategorijas ir joms priskirti naujienas. Viena naujiena gali būti priskirta kelioms kategorijoms.
  • 3Svetainėje turi būti sukurta galimybė rodyti tiek bendrą naujienų srautą, tiek naujienas pagal kategoriją.
  • 4Turi būti galimybė padaryti pasirinktos kategorijos naujausių naujienų išvedimą pasirinktame puslapyje.
  • 5Turi būti galimybė nurodyti, kada naujiena bus išpublikuota viešai (iš karto arba nustatyta data ir laikas).
  • 6Turi būti galimybė nurodyti, ar naujieną rodyti tituliniame puslapyje ir iki kada ji ten turėtų būti, jei jos neišstums jokia kita naujiena.
  • 7Naujienos administruojamos dalys turi būti šios: pavadinimas; trumpas tekstas (santrauka); visas tekstas (administruojamas per WYSIWYG redaktorių); citatos grafinis išskyrimas tekste; pagrindinė naujienos nuotrauka (jei numatyta pagal dizainą); naujienos nuotraukų galerija.
  • 8Lankytojai turi galėti peržiūrėti naujienas, filtruoti jas pagal metus, mėnesius (kol neparinkti metai, mėnesių filtras nerodomas arba yra neaktyvus), kategorijas.
  • 9Lankytojai turi galėti pasidalinti naujiena socialiniuose tinkluose, pasinaudoję specialiai įdiegtais dalinimosi mygtukais.
  • 10Lankytojai turi galėti atsispausdinti naujieną, pasinaudoję specialiai įdiegtu spausdinimo funkcijos mygtuku.

Svetainės bendrieji reikalavimai

  • 1Svetainėje naudojamose formose, kur lankytojas gali įvesti bet kokio pobūdžio informaciją, turi būti įdiegta CAPTCHA tipo apsauga nuo automatizuotų robotų. Priimtini sprendimai: reCAPTCHA v2/v3, hCaptcha arba kiti lygiaverčiai mechanizmai.
  • 2Visos funkcijos ir moduliai turi veikti analogiškai visose Svetainės kalbų versijose.
  • 3Turi būti galimybė tinklalapio informaciją atsispausdinti ir rekomenduoti (nusiųsti el. paštu) kitam vartotojui (lankytojui).
  • 4Vidiniuose tinklalapiuose turi būti atvaizduojama tinklalapio kelio eilutė (breadcrumb).
  • 5Tiekėjas privalo pateikti naudojamų komponentų sąrašą (SBOM), užtikrinti trečiųjų šalių įskiepių/servisų saugos vertinimą (CVE stebėsena, versijų atnaujinimai), sutartinę pareigą pranešti apie pažeidžiamumą/incidentą ne vėliau kaip per 24 val.
  • 6Visi perduodami duomenys į išorines paslaugas (pvz., naujienlaiškių tiekėjas, SMS, analitika) – šifruoti, su griežtais prieigos valdymo ir saugojimo terminais.
  • 7Svetainėje turi būti galimybė įdiegti neribotą kiekį išorinių įskiepių ir integracijų, tokių kaip: lankomumo statistika ir analitika (pvz., Google Analytics, Meta Pixel); naujienlaiškių prenumerata (pvz., MailerLite); realaus laiko pokalbiai (pvz., Genesys); saugumo mechanizmai (pvz., reCAPTCHA), kita.

Svetainės paieškos reikalavimai

  • 1Paieškos funkcija turėtų būti aiškiai matomoje Svetainės vietoje, pasiekiama iš bet kurio puslapio.
  • 2Lankytojams turi būti sukurta galimybė atlikti greitąją ir išplėstinę paiešką.
  • 3Greita paieška turėtų turėti automatinio žodžio ar frazės nuspėjimo funkciją ir nukreipti lankytoją tiesiai į rastą elementą (tinklalapį, naujieną ar kt.).
  • 4Atlikus išplėstinę paiešką, lankytojas turi galėti filtruoti rezultatus pagal nustatytus kriterijus: datą, tipą ar kt.
  • 5Paieška turi ieškoti visame lankytojams viešai pasiekiamame turinyje.
  • 6Į paieškos rezultatus neturi patekti neaktyvūs, lankytojams neprieinami puslapiai.

TVS nerastų tinklalapių valdymas

  • 1Visos užklausos (nuorodos), kurių metu lankytojas pateko į nesamus puslapius (gauti 404 klaidos pranešimai), turi būti saugomos sistemoje ir pateikiamos TVS.
  • 2Kiekvienas toks įrašas turi saugoti šią informaciją: nuoroda, į kurią buvo kreiptasi; kreipimosi data ir laikas; lankytojo naršyklės informacija; lankytojo IP adresas; šaltinis, iš kur buvo kreiptasi.
  • 3Visos sukauptos neveikiančios nuorodos turi būti sugrupuotos: jei kelis kartus buvo kreiptasi į tą pačią nuorodą, turi būti rodomas vienas įrašas.
  • 4Turi būti galimybė peržiūrėti to įrašo detalią informaciją: visi šaltiniai, iš kur buvo kreiptasi į tą nuorodą, kiek kartų ir kt.
  • 5Administratorius turi galėti patogiai išspręsti problemą: jei patalpintos neteisingos nuorodos šaltinis yra pagal šią techninę specifikaciją sukurta www.ilte.lt interneto svetainė, tuomet turi būti galimybė vienu paspaudimu pereiti į šaltinio redagavimo vietą ir pataisyti nuorodą; jei patalpintos neteisingos nuorodos šaltinis yra kita interneto svetainė, administratorius turi turėti galimybę nueiti tiesiai į tą kito šaltinio vietą, kurioje yra pateikiama neteisinga nuoroda.
  • 6Turi būti galimybė pašalinti išsaugotus įrašus.
  • 7Turi būti galimybė eksportuoti neveikiančių nuorodų sąrašą CSV, Excel ar kitu standartiniu formatu.

Konsultacijų registracijos modulis

  • 1Turi būti sudaryta galimybė Svetainėje lankytojams registruotis ILTE konsultacijai.
  • 2Konsultacijų modulis turi sudaryti galimybę lankytojui registruotis į konsultaciją pagal konsultacijos tipą, datą, laiką, temą ir kitus požymius, suderintus projekto analizės metu.
  • 3Registracijos konsultacijai forma turi būti daugiažingsnė (multi-step), su galimybe lankytojui patogiai judėti pirmyn ir atgal, neištrinant jau įvestų duomenų.
  • 4Modulis turi veikti lietuvių ir anglų kalbomis.
  • 5Turi būti sudaryta galimybė TVS aplinkoje redaguoti registracijos formoje, taip pat ILTE siunčiamuose el. laiškuose esančius tekstus (įskaitant antraštes, paantraštes, laukų pavadinimus ir kt.).
  • 6Modulis turi būti pilnai pritaikytas mobiliesiems įrenginiams.
  • 7Turi būti galimybė nustatyti neribotą kiekį konsultacijų tipų (pvz. gyvai, nuotoliu, el. paštu, telefonu), taip pat esant poreikiui juos tvarkyti: šalinti, pridėti naujus.
  • 8Gyvoms konsultacijoms administratorius turi galėti tvarkyti miestų sąrašą.
  • 9Visi pasirinkimai (tipai, miestai, temos ir kiti) turi būti redaguojami TVS aplinkoje.
  • 10Datas ir laikus lankytojas turi pasirinkti kalendoriaus ir laiko parinkiklio pagalba.
  • 11Administratorius turi galėti nustatyti galimas datas, laikus, užimtumą ir maksimalų registracijų skaičių vienu metu.
  • 12Turi būti galimybė TVS aplinkoje žymėti šventines (nedarbo) dienas.
  • 13Turi būti galimybė TVS aplinkoje blokuoti kalendorių pasirinktai savaitei ar mėnesiui (tuo metu lankytojai neturi galimybės registruotis konsultacijai).
  • 14Lankytojas turi galėti suvesti savo kontaktinius duomenis (vardas, pavardė, el. paštas, telefono numeris, kt.).
  • 15Turi būti galimybė įjungti vieną ar kelis sutikimų laukus. Administratorius turi galėti redaguoti kiekvieno sutikimo tekstą ir nustatyti, kurie sutikimai yra privalomi. Turi būti galimybė sutikimų tekstuose įterpti nuorodas.
  • 16Visi duomenys turi būti saugomi pagal BDAR reikalavimus. Turi būti galimybė TVS aplinkoje nustatyti, kiek laiko lankytojo įvesti duomenys bus saugomi sistemoje.
  • 17Pateikus registraciją konsultacijai, lankytojui turi būti siunčiamas automatinis pranešimas el. paštu arba SMS (priklausomai nuo konsultacijos tipo).
  • 18Administratorius turi galėti redaguoti pranešimų turinį TVS WYSIWYG redaktoriaus pagalba.
  • 19Artėjant konsultacijai, lankytojui turi būti siunčiamas automatinis priminimas el. paštu arba SMS (priklausomai nuo konsultacijos tipo) su konsultacijos data, laiku ir kita informacija. TVS aplinkoje turi būti galima nustatyti priminimo siuntimo laiką kiekvienam konsultacijos tipui atskirai.
  • 20Administratorius turi turėti galimybę pats pasirinktam laikui nustatyti automatinį priminimą apie konsultaciją.
  • 21Lankytojui į priminimo SMS atsakius neigiamai, konsultacija turi būti automatiškai atšaukiama sistemoje.
  • 22Įvykus konsultacijai, lankytojui automatiškai turi būti siunčiamas el. laiškas su konsultacijos įvertinimo forma. Turi būti galimybė laiško turinį redaguoti TVS WYSIWYG redaktoriaus pagalba.
  • 23Administratorius turi galėti matyti pateiktus įvertinimus TVS ir juos eksportuoti standartiniu formatu (pvz., Excel).
  • 24Visi pateikti registracijų į konsultacijas duomenys turi būti matomi TVS aplinkoje, įskaitant registracijų pateikimo datą ir laiką.
  • 25Turi būti galimybė keisti registracijos statusą (registruota, atšaukta, įvyko, neatvyko, kt.).
  • 26Turi būti galimybė filtruoti registracijų duomenis pagal numatytos konsultacijos tipą, datą, laiką, temą ir kitus duomenis.
  • 27Turi būti galimybė eksportuoti registracijų duomenis į CSV, Excel ar kitą standartinį formatą.
  • 28Modulis turi sudaryti galimybę lankytojui pridėti konsultaciją į kalendorių (Google, Outlook, Apple).
  • 29Turi būti realizuota SMS siuntimo paslaugos integracija.
  • 30Turi būti realizuota integracija MS Teams dėl automatinio nuorodų formavimo nuotolinėms konsultacijoms. Susitikimo nuorodos konsultantams turi būti matomos ir TVS aplinkoje.
  • 31Turi būti realizuota integracija su Outlook dėl automatinio konsultacijų pridėjimo į konsultantų kalendorius.
  • 32Turi būti galimybė TVS aplinkoje įjungti / išjungti iššokantį langą, kuris pasirodo po lankytojo praleisto laiko puslapyje. Tekstas, pranešimo pasirodymo laikas turi būti redaguojami TVS. Tekste turi būti galimybė įterpti nuorodą.

TVS paieškos rezultatų statistika

  • 1TVS turi būti kaupiama ir pateikiama visa lankytojų svetainėje atliktų paieškų informacija: kokios informacijos lankytojas ieškojo, ar buvo gauti rezultatai.
  • 2Vienodi paieškos raktažodžiai turi būti sugrupuoti.
  • 3Turi būti pateikiama, kokias dažniausiai paieškas atlieka lankytojai, kokias paieškas atliekant lankytojas neranda informacijos.
  • 4Visi kaupiami duomenys turi būti išskirstyti pagal tai, kokioje svetainės kalbos versijoje lankytojas atliko paiešką.

Turinio atvaizdavimo blokų modulis

  • 1Turi būti sukurta galimybė kurti skirtingų grafinių sprendimų turinio atvaizdavimą: paslaugų blokeliai, kuriuos sudaro: nuotrauka/ikona, pavadinimas, aprašymas, nuoroda/mygtukas; turinys kortelėse (tabs), kurias sudaro: kortelės pavadinimas, eiliškumo valdymas, kortelės turinys; nuotrauka dešinėje ir tekstas; nuotrauka kairėje ir tekstas; nuotrauka viršuje ir tekstas žemiau; nuotrauka žemiau ir tekstas aukščiau; slankiojamos kortelės (carousel); spalvinis infoblokas; statistiniai skaitliukai (counter) duomenims vizualizuoti; ikonų rinkiniai su tekstais; ar kiti pasiūlyti ir susiderinti analizės etape.
  • 2Pageidautinos elementų animacijos užvedus pelės žymeklį (hover animation), skirtos vizualiai išryškinti pasirinktus turinio blokų elementus.
  • 3Turi būti galimybė skirtingus turinio atvaizdavimus sudėti į vieną tinklalapį, keisti jų eiliškumą pagal poreikį.

Dažnai užduodamų klausimų modulis

  • 1Turi būti sukurta galimybė kurti ir valdyti klausimų kategorijas: jas rikiuoti pagal poreikį vilkimo funkcija, redaguoti, šalinti, padaryti nematomas.
  • 2Turi būti galimybė priskirti kategorijoms klausimus su atsakymais ir juos valdyti: rikiuoti pagal poreikį vilkimo funkcija, redaguoti WYSIWYG redaktoriaus pagalba, paslėpti, šalinti.
  • 3Turi būti galimybė konkrečius klausimus ar jų kategorijas išvesti pasirinktuose Svetainės tinklalapiuose.
  • 4Kiekvienas atskiras klausimas turi turėti nuorodą, kad klientų aptarnavimo specialistai, atsakinėdami į klientų klausimus, turėtų galimybę jiems nusiųsti konkretaus klausimo su atsakymu nuorodą.

Garantinis aptarnavimas ir palaikymas

  • 1Tiekėjas Sutarties galiojimo laikotarpiu turi atlikti sistemos programinės įrangos garantinį aptarnavimą.
  • 2Garantinis aptarnavimas turi apimti: sistemos programinės įrangos klaidų ar netikslumų registravimą; sistemos programinės įrangos klaidų ar netikslumų taisymą, testavimą; sistemos programinės įrangos atnaujinimą, siekiant ištaisyti klaidas ir netikslumus.
  • 3Reakcijos (atsakymo) laikas nuo pranešimo apie gedimą gavimo telefonu, elektroniniu paštu arba gedimo registravimo tiekėjo klaidų registravimo sistemoje turi būti ne ilgesnis kaip 4 PO darbo valandos.
  • 4Gedimų pašalinimo laikas garantinio aptarnavimo laikotarpiu – ne ilgiau kaip 8 darbo valandos nuo pranešimo apie gedimą gavimo telefonu, elektroniniu paštu arba registracijos klaidų registravimo sistemoje.
  • 5Palaikymo paslaugos turi apimti: sisteminių ir saugumo atnaujinimų periodinį diegimą; naudojamų komponentų, bibliotekų ir priklausomybių atnaujinimą; veikimo sutrikimų prevenciją ir šalinimą; konsultacijas PO dėl sistemos veikimo ir naudojimo; smulkius konfigūracinius pakeitimus, nereikalaujančius programavimo darbų; sistemos veikimo stebėseną (monitoringą).
  • 6Tiekėjas privalo kas mėnesį pateikti atliktų palaikymo darbų ataskaitą kartu su paslaugų priėmimo–perdavimo aktu ir sąskaita faktūra.
  • 7Tiekėjas įsipareigoja suteikti skubią pagalbą įsilaužimo atveju ir interneto svetainės informacijos atstatymą per 4 darbo valandas.
  • 8Tiekėjas įsipareigoja PO suteikti prieigą prie klaidų registravimo sistemos. PO darbuotojai turi turėti galimybę fiksuoti užklausas sistemoje, matyti užklausų būsenas ir gauti ataskaitas.
  • 9Tiekėjas įsipareigoja atnaujinti programinį kodą, kad jis visada atitiktų naujausius saugumo kriterijus, užtikrinti visų interneto svetainės funkcionalumų nuolatinį veikimą, taip pat reguliariai atnaujinti naudojamus programinius komponentus.
  • 10Visi atnaujinimai pirmiausia turi būti testuojami darbinėje (testinėje) aplinkoje ir tik po PO patvirtinimo diegiami produkcinėje aplinkoje.
  • 11Tiekėjas turi užtikrinti, kad palaikymo metu atlikti pakeitimai būtų dokumentuojami ir įtraukiami į pakeitimų (versijų) žurnalą ir, esant poreikiui, pateikiami PO kartu su mėnesine ataskaita.
  • 12Garantinis aptarnavimas ir palaikymas neapima naujų funkcionalumų kūrimo ar esamų funkcionalumų esminių pakeitimų, kurie laikomi vystymo darbais ir vykdomi pagal atskirus PO užsakymus.

Naujienlaiškių prenumeratos modulis

  • 1Svetainėje turi būti suteikta galimybė lankytojui užsisakyti ILTE naujienų prenumeratą.
  • 2Svetainėje turi būti realizuota naujienlaiškio prenumeratos forma kaip atskiras komponentas, kurį administratorius gali įkelti į bet kurį Svetainės puslapį naudojant TVS.
  • 3Forma turi būti rodoma svetainės poraštėje (footer). Poraštėje esanti forma turi būti matoma visuose Svetainės puslapiuose.
  • 4Forma turi būti sudaryta iš šių elementų: antraštės; paantraštės; el. pašto adreso įvedimo laukas (privalomas įvesti laukas, žymimas žvaigždute); BDAR sutikimo (pateikiamas kaip teiginys, be galimybės pasirinkti) su galimybe ant teksto įterpti nuorodą į kitą Svetainės puslapį; teksto, pateikiamo prieš temų pasirinkimus; temų pasirinkimų, pateikiamų „radio buttons“ ar kita forma (neprivalomas įvesti laukas).
  • 5Turi būti užtikrinta galimybė TVS aplinkoje pridėti, redaguoti ar pašalinti temas, nenustatant jų skaičiaus ribos. Temų eiliškumą turi būti galima TVS keisti vilkimo būdu.
  • 6Administratorius turi turėti galimybę TVS aplinkoje redaguoti visų formos elementų tekstus, keisti eiliškumą ir matomumą.
  • 7El. pašto laukas turi būti validuojamas realiu laiku (neteisingas formatas turi būti atpažįstamas prieš pateikiant formą).
  • 8Lankytojo įvestas el. pašto adresas, pasirinktos prenumeratos temos ir kiti detalios analizės metu suderinti duomenys ar metaduomenys turi būti automatiškai perduodami į naujienlaiškių siuntimo platformą.
  • 9Formos pateikimo funkcionalumas turi būti suprogramuotas taip, kad duomenys automatiškai būtų perduodami į naujienlaiškio siuntimo platformą pagal nustatytas temas.
  • 10Turi būti įdiegta apsauga nuo automatizuotų robotų.
  • 11Turi būti rodomas aiškus sėkmės pranešimas užpildžius formą, neperkraunant puslapio. Sėkmės pranešimo tekstą turi būti galima redaguoti TVS aplinkoje.

TVS paieška administravimo aplinkoje

  • 1TVS administravimo aplinkoje turi veikti paieška, kuri turi būti aiškiai visą laiką matoma prisijungus administratoriams.
  • 2Paieška turi turėti automatinio žodžio ar frazės nuspėjimo funkciją.
  • 3Paieškos rezultatuose turi būti pateikiamos greitosios funkcijos: administratoriaus nukreipimas tiesiai į rasto elemento nustatymus; administratoriaus nukreipimas tiesiai į rasto elemento redagavimą; administratoriaus nukreipimas tiesiai į rasto elemento teisių valdymą; galimybė vienu paspaudimu pakeisti elemento būsenas (matomas/nematomas, aktyvus/neaktyvus).
  • 4Paieška turi ieškoti visų elementų visuose naudojamuose tekstuose: pavadinimuose, aprašymuose, raktiniuose žodžiuose ir t.t.

Užklausų formų ir apklausų modulis

  • 1Administratorius turi galėti kurti neribotą kiekį užklausų formų, apklausų.
  • 2Turi būti galima sukurti klausimus ir parinkti atsakymų tipus. Atsakymų tipai turi būti ne mažiau kaip: įvedimo laukas (input); didelis įvedimo laukas (text area); išsiskleidžiantis sąrašas (dropdown); vienas pasirinkimas iš sąrašo (radio buttons); keli pasirinkimai iš sąrašo (check box); el. paštas; data (renkantis kalendoriuje); prisegamas failas (turi būti galimybė prisegti iki 5 skirtingų arba vienodų formatų failų vienu metu); įterpiamas tekstas tarp klausimų.
  • 3Turi būti numatyta galimybė atskirti klausimų kategorijas vizualiai išskirtomis antraštėmis administratoriui jas įvedant TVS.
  • 4Turi būti galimybė nurodyti, kuriuos klausimus atsakyti privaloma. Lankytojui tie klausimai turi būti pažymėti žvaigždute.
  • 5Lankytojui užpildžius užklausos formą, apklausą, apie tai turi būti informuojamas administratorius el. paštu. El. pašto adresas turi būti valdomas. Turi būti galimybė laiško turinį redaguoti WYSIWYG redaktoriaus pagalba.
  • 6Turi būti galimybė administratoriui redaguoti lankytojui pateikiamą tekstą po užklausos formos, apklausos užpildymo.
  • 7Turi būti galimybė įvesti ir redaguoti tekstą, kuris lankytojui būtų rodomas virš pateikiamos užklausos formos, apklausos.
  • 8Turi būti galimybė TVS peržiūrėti užpildytas užklausų formas, apklausas ir eksportuoti duomenis CSV, Excel ar kitu standartiniu formatu.
  • 9Užpildytoms užklausų formoms ir apklausoms turi būti automatiškai registruojama pateikimo data, laikas ir lankytojo IP adresas, šie duomenys turi būti matomi TVS aplinkoje ir įtraukiami į eksportuojamus duomenis.
  • 10Turi būti galimybė filtruoti užpildytas užklausų formas, apklausas pagal formos, apklausos pateikimo datą (metai, mėnesis, diena).
  • 11Turi būti galimybė nustatyti, ar lankytojams rodyti apklausų rezultatus. Jei nustatyta rodyti, lankytojai turi galėti juos peržiūrėti.
  • 12Turi būti galimybė nustatyti, kiek laiko formų, apklausų rezultatai bus saugomi TVS aplinkoje (mėnesių, dienų tikslumu).
  • 13Kiekvienai užklausos formai ar apklausai turi būti realizuota galimybė įjungti vieną ar kelis varnele žymimus sutikimus.
  • 14TVS turi sudaryti galimybę: administratoriui savarankiškai pridėti neribotą skaičių sutikimų laukų; redaguoti kiekvieno sutikimo tekstą TVS aplinkoje; teksto lauke įterpti nuorodas į kitus puslapius; keisti sutikimų laukų eiliškumą naudojant vilkimo funkciją; pažymėti, kurie sutikimai yra privalomi, o kurie – pasirenkami.
  • 15Užklausų formose ir apklausose turi būti realizuota laukų validavimo funkcija, apimanti: minimalų ir maksimalų įvedamų simbolių kiekį; duomenų formato tikrinimą (pvz., el. pašto, telefono numerio formato atpažinimą); privalomus ir pasirenkamus laukus; aiškiai vartotojui pateikiamus klaidų pranešimus, kurių tekstą administratorius turi galėti redaguoti TVS.
  • 16Failų įkėlimo laukai turi turėti nustatomus parametrus: Leidžiamų failų tipų sąrašą (administratoriaus valdomas); Didžiausią leidžiamo failo dydį (administratoriaus valdomas).
  • 17Visos užklausų formos ir apklausos turi būti pilnai pritaikytos mobiliesiems įrenginiams, įskaitant prisitaikantį išdėstymą ir tinkamus įvesties laukų tipus mobiliesiems įrenginiams.

Atitiktis teisės aktams ir standartams

  • 1Teikiant paslaugas turi būti vadovaujamasi Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatymu.
  • 2Teikiant paslaugas turi būti vadovaujamasi Lietuvos Respublikos kibernetinio saugumo įstatymu.
  • 3Teikiant paslaugas turi būti vadovaujamasi Organizacinių ir techninių kibernetinio saugumo reikalavimų, taikomų kibernetinio saugumo subjektams, aprašu, patvirtintu Lietuvos Respublikos Vyriausybės 2018 m. rugpjūčio 13 d. nutarimu Nr. 818 „Dėl Lietuvos Respublikos kibernetinio saugumo įstatymo įgyvendinimo“, ar naujomis teisės akto redakcijomis.
  • 4Teikiant paslaugas turi būti vadovaujamasi Techniniais valstybės registrų (kadastrų), žinybinių registrų, valstybės informacinių sistemų ir kitų informacinių sistemų elektroninės informacijos saugos reikalavimais, patvirtintais Lietuvos Respublikos vidaus reikalų ministro 2013 m. spalio 4 d. įsakymu Nr. 1V-832 „Dėl Techninių valstybės registrų (kadastrų), žinybinių registrų, valstybės informacinių sistemų ir kitų informacinių sistemų elektroninės informacijos saugos reikalavimų patvirtinimo“, ar naujomis teisės akto redakcijomis.
  • 5Svetainė turi būti vystoma vadovaujantis gerosiomis saugumo praktikomis, atsižvelgiant į OWASP (angl. Open Web Application Security Project) naujausių TOP 10 išvardytų žinomų WEB pažeidžiamumų sąrašą bei OWASP teikiamas rekomendacijas (http://www.owasp.org).
  • 6Sukurta svetainė negali turėti OWASP TOP10 aktualiame dokumente ir ankstesnėse šio dokumento versijose nurodytų pažeidžiamumų.
  • 7Turi būti vadovaujamasi Saityno turinio prieinamumo gairių naujausia redakcija: https://www.w3.org/TR/WCAG22/.

TVS WYSIWYG redaktoriaus funkcionalumas

  • 1Teksto redaktoriaus redagavimo aplinka turi būti artima Microsoft Word ar kitų panašaus tipo programų aplinkai.
  • 2Informacija turi būti lengvai perkeliama iš Microsoft Word, Microsoft Excel ir kitų lygiaverčių programų (taip pat naudojant standartines operacinės sistemos kopijavimo ir įkelties funkcijas).
  • 3Turi būti papildoma galimybė pašalinti visus ankstesnius dokumentų tekstų formato nustatymus.
  • 4Turi būti realizuota teksto formavimo funkcijos: kursyvas, paryškintas, pabrauktas, perbrauktas. Taip pat turi būti realizuoti ir skirtingi antraščių lygiai.
  • 5Turi būti galimybė keisti teksto lygiavimą: lygiuoti dešinėje, lygiuoti kairėje, centruoti, išplėsti per visą plotį.
  • 6Turi būti galimybė keisti teksto šriftą, dydį, spalvą, foną.
  • 7Turi būti galimybė keisti tarpus tarp eilučių, raidžių ir kitų įterptų objektų.
  • 8Turi būti realizuota galimybė pritaikyti ir keisti ženklinimą, kurti teksto sąrašus numeruojant ar žymint simboliais.
  • 9Turi būti galimybė įterpti citatą, kuri tekste būtų akcentuojama vizualinėmis priemonėmis.
  • 10Elementams (tekstui, paveiksliukams, nuorodoms, lentelėms ir pan.) turi būti galimybė pritaikyti patvirtintus bazinio dizaino stilius.
  • 11Turi būti lentelių kūrimo, jų redagavimo ir lentelės bei jos langelių formatavimo funkcijos. Turi būti numatyti keli lentelių atvaizdavimo stiliai, kurie turi būti suderinti su PO analizės metu.
  • 12Turi būti galimybė kurti įvairias nuorodas (į kitą tinklalapį, dokumentą, kitą svetainę, el. pašto adresą, tel. nr., kt.).
  • 13Kuriant nuorodas į dokumentą turi būti galimybė pasirinkti, ar nuorodą rodyti su dokumento ikonėle, ar be jos.
  • 14Kuriant nuorodą į dokumentą ar kitą vidinį tinklalapį turi būti galimybė atlikti paiešką ir greitai atrasti reikiamą šaltinį.
  • 15Turi būti galimybė pasirinkti, kur bus vaizduojamas per nuorodą prieinamas turinys (tame pačiame puslapyje, naujame puslapyje, iššokančiame (pop-up) lange).
  • 16Turi būti įgyvendintas paveikslėlių įkėlimas į tekstą, naudojant paveikslėlių paieškos-naršymo langą administratoriaus lokaliame diske.
  • 17Turi būti realizuota jau patalpintų serveryje ir panaudotų kitose vietose paveikslėlių paieška.
  • 18Talpinant paveiksliuką turi būti galimybė administratoriui pridėti META informaciją, raktinius žodžius.
  • 19Galimi paveiksliukų formatai: JPEG / JPG, PNG, GIF, SVG, WEBP, JIFF, AVIF, BMP ir kiti saugūs formatai.
  • 20Turi būti galimybė formatuoti įkeltą paveiksliuką, atliekant: lygiavimo keitimus; paveiksliuko matmenų keitimą (proporcingas matmenų keitimas, paveiksliuko apkirpimas nurodžius matmenis) naudojant TVS funkcijas; apvado keitimus; teksto atstumų nuo paveiksliuko nustatymą; paveikslėlio komentaro suteikimą; paveikslėlio aprašo suteikimą.
  • 21Turi būti sukurta funkcija, leidžianti lankytojui paspaudus kairįjį pelės klavišą paveikslėlį padidinti. Administratorius turi galėti konkrečiu atveju TVS aplinkoje nustatyti, ar tokią funkciją aktyvuoti.
  • 22Teksto redaktoriuje turi būti galimybė tiesiogiai redaguoti HTML kodą.
  • 23Turi būti galimybė įterpti multimedijos (vaizdo, garso) failus iš administratoriaus kietojo disko arba išorinių šaltinių (pvz. Youtube.com, Vimeo.com).
  • 24Redaguojantis turinį administratorius turi turėti galimybę peržiūrėti įkeltą informaciją dar neparodžius jos Svetainės lankytojams ir matyti puslapį tokį, koks jis bus rodomas svetainės lankytojams.
  • 25Turi būti galimybė sugeneruoti peržiūros nuorodą (preview link), leidžiančią peržiūrėti turinį dar prieš viešinimą.
  • 26Peržiūros nuoroda turi būti unikali, prieinama tik turinį peržiūrintiems naudotojams ir negali būti indeksuojama paieškos sistemų.
  • 27Turi būti realizuota vilkimo funkcija keičiant išdėstymą, perkeliant paveikslėlius ar kitus elementus į kitą vietą.
  • 28Turi būti sukurta funkcija išskirti turinį kaip itin svarbų, šalia kurio svetainėje atsirastų svarbumą žyminti ikonėlė (pvz., šauktukas ar kt.).
  • 29Turi būti sukurta funkcija parinkti nuorodos tipą: paprasta nuoroda, dokumento nuoroda, nukreipimas į kitą interneto svetainę, mygtukas.
  • 30TVS privalo turėti galimybę nuorodoms pritaikyti stiliaus keitimą užvedus pelyte (hover efect), pagalbines užuominas (tooltips).
  • 31TVS turi sudaryti galimybę bet kuriame puslapyje ir bet kuriame modulyje esančias nuorodas susieti su konkrečia vieta tame pačiame puslapyje (anchor link).
  • 32Redaktorius turi palaikyti versijavimą. Atlikus turinio redagavimą, TVS turi automatiškai išsaugoti senesnę versiją.
  • 33Galima peržiūrėti ir įkelti senesnes turinio versijas. Versijos turi būti saugomos mėnesį, o praėjus šiam laikotarpiui, jos turi būti automatiškai ištrinamos.
  • 34TVS turi fiksuoti ir pateikti, kas ir kada redagavo turinį, kuri versija yra išpublikuota.
  • 35Redaguojant puslapį, administratorius prieš publikuodamas turinį gali peržiūrėti, kaip puslapis po pakeitimų bus atvaizduojamas interneto naršyklėje.

Sistemos diegimo ir perkėlimo reikalavimai

  • 1Svetainė turi būti tinkamai vizualiai atvaizduojama įvairiuose įrenginiuose. Priklausomai nuo įrenginio ekrano dydžio ir tipo, turi pasikeisti navigacija ir elementų išdėstymas. Svetainės dizainas turi būti sukurtas taip, kad prisitaikytų prie naudojamo įrenginio ekrano (responsive design) standartinei (desktop), planšečių (tablet) bei mobiliųjų įrenginių (mobile) versijoms.
  • 2Svetainė turi atitikti šiuolaikinius HTML5 standartus ir W3C rekomendacijas, o sugeneruoti puslapiai neturi turėti esminių validacijos klaidų.
  • 3Svetainė turi veikti be klaidų su pagrindinėmis šiuolaikinėmis naršyklėmis (Microsoft Edge, Google Chrome, Mozilla Firefox, Safari, Opera), palaikant bent dvi paskutines stabilias versijas.
  • 4Svetainėje turi būti naudojami šiuolaikiniai asinchroninio turinio užkrovimo metodai (pvz., AJAX, fetch API, dinaminis komponentų atnaujinimas), leidžiantys atnaujinti turinį be pilno puslapio perkrovimo.
  • 5Turi būti sudiegti visi sisteminiai laiškai. Laiškai turi būti tinkamai atvaizduojami šiuolaikinėse pašto programose ir interneto pašto sistemose (pvz., Gmail, Outlook). Laiškų siuntimas turi užtikrinti SPF, DKIM ir DMARC suderinamumą, HTML ir atviro teksto (plain-text) versijų generavimą, UTF-8 koduotę ir galimybę naudoti išorines siuntimo paslaugas (pvz., SMTP, API).
  • 6Tiekėjas turi įdiegti Svetainę į PO pateiktą testinę ir produkcinę aplinką, užtikrindamas pilną funkcionalumą, veikimą ir suderinamumą su PO infrastruktūra.
  • 7PO teikia Tiekėjui reikiamus prisijungimus prie testinės ir produkcinės aplinkos (serverių, duomenų bazių valdymo sistemų, failų saugyklų), taip pat informaciją apie saugumo ir prieigos politiką.
  • 8Tiekėjas ne vėliau kaip prieš 30 kalendorinių dienų iki diegimo į produkcinę aplinką turi pateikti PO techninius reikalavimus aplinkai.
  • 9PO paruošia serverius pagal Tiekėjo pateiktus reikalavimus, jei nesutarta kitaip.
  • 10Tiekėjas testinėje aplinkoje įdiegia Svetainę, atlieka pilną funkcinį ir techninį testavimą, ištaiso rastas klaidas ir pateikia PO testavimo scenarijus bei testavimo protokolą.
  • 11PO atlieka priėmimo testavimą pagal pateiktus scenarijus ir Techninę specifikaciją. Nustačius trūkumų ar neatitikčių, Tiekėjas privalo juos ištaisyti ir pakartotinai pateikti testavimo dokumentus.
  • 12Po sėkmingo testavimo Svetainė diegiama į produkcinę aplinką. Visi diegimai pirmiausia atliekami testinėje aplinkoje; diegimas į produkcinę aplinką galimas tik po PO patvirtinimo.
  • 13Tiekėjas turi užtikrinti, kad esant poreikiui būtų galima atstatyti ankstesnę Svetainės versiją. Tam Tiekėjas privalo prieš kiekvieną diegimą atlikti visų failų ir duomenų bazių atsargines kopijas.
  • 14Po galutinio diegimo Tiekėjas turi pateikti diegimo dokumentaciją: naudojamų komponentų sąrašą; serverių konfigūracijos aprašą; diegimo žingsnių aprašą; duomenų bazių struktūros aprašą; nurodymus, kaip atlikti būsimus atnaujinimus.

Svetainės sutikimo su duomenų rinkimu valdymas

  • 1Svetainėje turi būti įdiegtas slapukų valdymo sprendimas, atitinkantis BDAR reikalavimus ir užtikrinantis, kad reklaminiai (nebūtinieji) slapukai nebūtų aktyvuojami iki lankytojo sutikimo gavimo.
  • 2Lankytojui apsilankius Svetainėje turi būti rodomas pranešimas apie slapukų naudojimą, suteikiant galimybę: sutikti su visais slapukais; tęsti tik su būtinaisiais slapukais.
  • 3Slapukai turi būti suskirstyti į šias kategorijas: būtini slapukai, reikalingi svetainės veikimui; funkciniai slapukai; statistiniai slapukai; reklaminiai slapukai, kurie aktyvuojami tik gavus lankytojo sutikimą.
  • 4Turi būti pateikiamas atskiras informacinis puslapis, kuriame nurodomi naudojami slapukai, jų tikslai, galiojimo terminai ir suteikiama galimybė bet kuriuo metu pakeisti sutikimų nustatymus.
  • 5Slapukų valdymo sprendimas turi užtikrinti, kad reklaminiai slapukai ir juos naudojančios trečiųjų šalių integracijos būtų aktyvuojamos tik gavus aiškų naudotojo sutikimą.

Atgalinio ryšio (ar informacija buvo naudinga) modulis

  • 1Turi būti sukurta galimybė pasirinktų tinklalapių pabaigoje rodyti atgalinio ryšio formą, kurioje lankytojas galėtų pažymėti, ar puslapyje pateikta informacija buvo naudinga (taip / ne).
  • 2Jei pasirenkama „ne“, turi atsirasti papildomas laukas komentarui įvesti.
  • 3Visi gauti atgalinio ryšio duomenys turi būti kaupiami TVS: naudinga / nenaudinga atžymų skaičius pagal konkretų tinklalapį; lankytojų pateikti komentarai; atgalinio ryšio pateikimo datos ir tinklalapių URL.
  • 4Turi būti sudaryta galimybė sukauptus duomenis eksportuoti CSV ar Excel formatu.
  • 5Administratorius turi būti informuojamas el. laišku apie gautą atgalinį ryšį. TVS turi būti galimybė nurodyti el. pašto adresą, į kurį siunčiami pranešimai, ir įjungti / išjungti informavimą.
  • 6Siunčiamame informaciniame laiške turi matytis: lankytojo įvertinimas (taip / ne), komentaras (jei pateiktas) ir nuoroda į tinklalapį, kuriame paliktas atgalinis ryšys.
  • 7Turi būti galimybė TVS priemonėmis įjungti / išjungti šį bloką konkrečiuose tinklalapiuose.
  • 8Turi būti įdiegta apsauga nuo automatizuoto pildymo (pvz., CAPTCHA ar kita lygiavertė priemonė).
  • 9TVS turi būti matomi sumuoti statistiniai rodikliai: bendras „taip / ne“ santykis pagal kiekvieną tinklalapį, komentarų skaičius ir jų peržiūra. Vizualus atvaizdavimo būdas bus suderintas analizės metu.

Dokumentai3

  • 2_TS_NPB_svetainės_sukurimas_0324.pdf
  • 1_Kvietimas dalyvauti konsultacijoje_NPB svetainės sukurimas_0324.docx
  • 1047_7086672.pdf
tendis.lt · Sukurta recodin.lt