URM INTRANETO INFORMACINĖS SISTEMOS ATNAUJINIMO PASLAUGOS
Išanalizuota
Lietuvos Respublikos užsienio reikalų ministerija
Rinkos konsultacijaCPV: 72262000 - Programinės įrangos kūrimo paslaugos
ID: 79908872026-05-21 15:25
Atidaryti CVP ISAprašymas
Perkamos Lietuvos Respublikos užsienio reikalų ministerijos intraneto informacinės sistemos atnaujinimo paslaugos. Jos apima informacinės architektūros, vartotojo sąsajos ir patirties sprendinių įgyvendinimą, funkcionalumo sukūrimą, turinio valdymo sistemos pritaikymą, turinio migravimą, testavimą, diegimą ir dokumentacijos parengimą bei apmokymą. Intranetas skirtas URM vidaus komunikacijai, keitimuisi informacija tarp padalinių ir kasdieniam darbuotojų naudojimui.
Kvalifikaciniai reikalavimai
Kvalifikacinių reikalavimų nerasta
Techniniai reikalavimai
Diegimo reikalavimai
- 1Diegimas vykdomas tuo metu, kai naudojimas yra mažiausias; grafikas suderinamas su URM.
- 2Tiekėjas turi užtikrinti galimybę atkurti sistemą ir, jei taikoma, duomenis į būseną iki diegimo pradžios, jei diegimas nesėkmingas arba sukelia kritinius veikimo sutrikimus.
- 3Atkūrimo procedūra turi būti aprašyta prieš diegimą ir, kai pagrįsta, praktiškai patikrinta testinėje aplinkoje.
- 4Jei paslaugų apimtis apima duomenų ar turinio migravimą, Tiekėjas prieš migravimą turi pateikti migravimo planą, o po migravimo – migravimo rezultatų patikrą, apimančią bent perkelto turinio apimtį, nustatytus neatitikimus ir jų pašalinimo būklę.
- 5Į gamybinę aplinką diegiami tik ištestuoti pakeitimai, kurie nedaro neigiamo poveikio kitiems komponentams.
- 6Turi būti užtikrintas atskirų aplinkų (kūrimo, testavimo ir gamybinės) atskyrimas, o prieiga prie jų valdoma pagal mažiausių būtinų teisių principą.
- 7Jei paslaugų apimtis apima duomenis ar konfigūraciją, Tiekėjas turi užtikrinti atsarginių kopijų sudarymą prieš diegimą ir pagrįstai patvirtintą atkūrimo procedūrą.
Testavimo reikalavimai
- 1Naujai sukurtiems ir pakeistiems funkcionalumams privalo būti atliekamas testavimas.
- 2Testavimas vykdomas testinėje aplinkoje prieš diegiant į gamybinę aplinką; testinės aplinkos funkcionalumas turi visiškai atitikti gamybinę aplinką.
- 3Tiekėjas parengia testavimui reikalingus duomenis, jei tokių duomenų neturi ar negali pateikti URM.
- 4Klaidos turi būti klasifikuojamos bent į kritines, didelio poveikio ir kitus neatitikimus.
- 5Kritinės ir didelio poveikio klaidos turi būti pašalintos iki rezultato priėmimo, išskyrus atvejus, kai URM raštu sutinka dėl motyvuotos išimties.
- 6Prieš diegiant į gamybinę aplinką privaloma: (a) atlikti automatizuotą pažeidžiamumų skenavimą; (b) atlikti skverbimosi testą; (c) pateikti šių patikrų ataskaitas; (d) pašalinti nustatytas kritines ir aukšto lygio spragas; (e) pakartotiniu testavimu patvirtinti, kad šios spragos pašalintos.
- 7Jei testavimo kriterijai netenkinami, vykdoma pakartotinė testavimo sesija, taikant tuos pačius reikalavimus.
- 8Tiekėjas turi parengti testavimo planą ir testavimo ataskaitą, kurioje būtų nurodyti testavimo scenarijai, rezultatai, nustatyti neatitikimai, jų būklė ir patvirtinimas, kad priėmimo kriterijai yra įvykdyti.
- 9Prieš galutinį rezultato priėmimą turi būti atliktas naudotojų priėmimo testavimas pagal iš anksto su URM suderintus scenarijus ir priėmimo kriterijus.
- 10Rezultato priėmimo pagrindu laikomi testavimo rezultatai, neatitikimų būklė ir kiti sutartyje ar techninėje specifikacijoje numatyti įrodymai.
Prieinamumo reikalavimai
- 1Sistema turi būti kuriama ir atnaujinama laikantis skaitmeninio prieinamumo principų, kad ja galėtų naudotis įvairių poreikių naudotojai, įskaitant naudotojus, besinaudojančius pagalbinėmis technologijomis.
- 2Sprendinys turi atitikti bent WCAG 2.1 AA lygio prieinamumo kriterijus ir EN 301 549 standarto taikytinus reikalavimus.
- 3Lygiaverčiai standartai gali būti taikomi, jeigu jie užtikrina ne mažesnį prieinamumo lygį.
- 4Turi būti užtikrinta navigacija klaviatūra, pakankamas spalvinis kontrastas, alternatyvieji tekstai netekstiniam turiniui, prasminga antraščių struktūra ir aiškiai identifikuojami formų laukai bei klaidų pranešimai.
- 5Tiekėjas, prieš rezultatų priėmimą, turi pateikti prieinamumo atitikties įvertinimą arba kitą pagrįstą atitikties patvirtinimą, kuriame būtų nurodyti nustatyti neatitikimai ir jų pašalinimo būklė.
- 6Kritiniai prieinamumo neatitikimai turi būti pašalinti iki priėmimo, išskyrus atvejus, kai URM motyvuotai nustato kitaip.
Dokumentacijos reikalavimai
- 1Visa dokumentacija turi būti parengta lietuvių kalba, vadovaujantis bendrinės lietuvių kalbos taisyklėmis.
- 2Prieš rengiant dokumentus, Tiekėjas preliminarų turinį ir formą suderina su URM.
- 3Galutinės dokumentų versijos pateikiamos redaguojamu formatu (.doc/.docx/.pdf ar kitu suderintu) ir pasirašomos Tiekėjo atsakingo asmens el. parašu (jei taikoma).
- 4Pateikus pastabas dokumentacijai, Tiekėjas pataisymus atlieka per suderintą terminą.
- 5Jei pagal paslaugų apimtį taikoma, perduodamos dokumentacijos rinkinį turi sudaryti ne mažiau kaip: architektūros aprašas, diegimo instrukcija, konfigūravimo aprašas, administravimo instrukcija, naudotojo instrukcija, integracijų aprašas, testavimo dokumentai ir perdavimo eksploatuoti medžiaga.
Bendrieji sistemos principai
- 1Pagrindiniame puslapyje turi būti pateikiama tik naudotojui aktualiausia, reguliariai atnaujinama ir greitai pasiekiama informacija.
- 2Turinys, kuriam reikalinga išplėstinė struktūra, archyvavimas arba dažnesnis teminis grupavimas, turi būti pateikiamas teminiuose polapiuose.
- 3Intraneto struktūra turi būti semantiškai aiški (tikslūs pavadinimai), su nuoseklia navigacija ir „greito peržvelgimo“ principu (struktūra suprantama per trumpą laiką).
Funkciniai reikalavimai: Paieška
- 1Turi būti įgyvendinta globali paieška per intraneto turinį (puslapiai, įrašai, dokumentai), su filtravimo galimybe (jei taikoma).
- 2Paieškos rezultatai turi gerbti prieigos teises (nerodyti riboto turinio neautorizuotiems naudotojams).
- 3Paieška turi indeksuoti ne mažiau kaip puslapių pavadinimus, pagrindinį turinį ir, jei taikoma, metaduomenis.
- 4Jei sistemoje naudojamos kategorijos, žymos ar turinio tipai, paieškos rezultatų filtravimas pagal šiuos požymius turi būti numatytas bent administravimo arba naudotojo sąsajoje, kai tai aktualu konkrečiam turinio tipui.
Kibernetinio saugumo reikalavimai
- 1Sistema turi būti sukurta ir valdoma laikantis organizacinių ir techninių kibernetinio saugumo reikalavimų, užtikrinant tinkamą rizikos valdymą ir incidentų prevenciją.
- 2Programinis kodas ir architektūra turi būti sukurti taip, kad būtų užkirstas kelias bent OWASP Top 10 klasės pažeidžiamumams.
- 3Jei saugumo reikalavimai detalizuojami pagal saugumo patikros standartą, Tiekėjas turi aiškiai nurodyti jo versiją ir taikymo apimtį.
- 4Tiekėjas ir jo darbuotojai privalo laikytis URM IS informacijos saugos reikalavimų, numatytų URM IS duomenų saugos dokumentuose (teikiama tiekėjams nustatyta tvarka).
- 5URM turi teisę prašyti Tiekėjo pateikti saugumo reikalavimų laikymąsi pagrindžiančius dokumentus, įskaitant taikomų saugumo priemonių aprašymus, testavimo ataskaitas, pažeidžiamumų šalinimo informaciją ir kitus pagrįstus įrodymus.
- 6Sistema turi registruoti saugai reikšmingus įvykius, įskaitant autentifikavimą, nesėkmingus prisijungimus, teisių keitimus, administratoriaus veiksmus ir kitus kritinius sistemos veiksmus, kad būtų užtikrintas audito pėdsakas.
- 7Tiekėjas turi taikyti saugaus kūrimo praktiką, įskaitant naudojamų bibliotekų ir kitų programinių komponentų pažeidžiamumų stebėseną, savalaikį saugos pataisų diegimą ir priklausomybių valdymą.
- 8Jei Tiekėjas saugumo kontrolėms pagrįsti remiasi OWASP ASVS standartu, nuoroda turi būti pateikiama su tiksliu standarto versijos numeriu.
- 9Rekomenduojamas ne žemesnis kaip OWASP ASVS 5.0.0 2 lygis tai sprendinio daliai, kuri tvarko autentifikavimą, prieigos valdymą, konfidencialius duomenis ar administravimo funkcijas.
Garantinio aptarnavimo reikalavimai
- 1Garantinio aptarnavimo metu Tiekėjas atlygintinai arba neatlygintinai (pagal sutartį) užtikrina klaidų taisymą, sistemos veiklos atkūrimą ir neatitikimų specifikacijai pašalinimą.
- 2Garantinio aptarnavimo metu klaidos klasifikuojamos į kritines ir nekritines; reakcijos ir sprendimo terminai nustatomi sutartyje (SLA).
- 3Garantinio aptarnavimo metu Tiekėjas turi registruoti visus gautus incidentus ir prašymus. Kiekvienam įrašui turi būti fiksuojamas bent unikalus identifikatorius, gavimo data ir laikas, klasifikacija, būsena, atsakingas vykdytojas, atlikti veiksmai ir sprendimo data bei laikas.
- 4Sutartyje turi būti nustatyti minimalūs reagavimo ir sutrikimų šalinimo terminai pagal incidento kritiškumą, taip pat komunikavimo su URM tvarka incidentų valdymo metu.
Išeities kodo perdavimo reikalavimai
- 1Visa programinė įranga, sukurta projekto apimtyje, turi būti perduota URM kartu su visais jos veikimui, kompiliavimui, diegimui ir priežiūrai būtinais artefaktais, įskaitant išeities kodą, konfigūracijas, šablonus, skriptus ir kitus sukurtus komponentus, jeigu jie reikalingi savarankiškam sprendinio perėmimui.
- 2Tiekėjas turi pateikti naudojamų trečiųjų šalių komponentų, bibliotekų ar modulių sąrašą, nurodydamas jų paskirtį, licencijos tipą ir tai, ar jų naudojimas sukuria papildomas įsigijimo, palaikymo ar atnaujinimo sąlygas.
- 3Išeities kodas turi būti perduodamas elektroniniu būdu kartu su kompiliavimui ar surinkimui reikalingais failais, naudojamų priemonių aprašu ir diegimo instrukcija, kiek tai būtina savarankiškam sprendinio perėmimui.
- 4Išeities kodas turi būti pakankamai dokumentuotas, struktūruotas ir parengtas taip, kad URM arba kitas teisėtai paskirtas paslaugų teikėjas galėtų jį perimti, prižiūrėti ir toliau vystyti.
Funkciniai reikalavimai: Turinio tipai
- 1Dinaminis turinys: naujienos, pranešimai, kvietimai, registracijos, skelbimai, priminimai, apklausos ir kt.
- 2Kiekvienas dinaminio turinio įrašas privalo turėti ne mažiau kaip šiuos laukus: pavadinimą, paskelbimo datą arba galiojimo laikotarpį, trumpą santrauką ir pilną turinį atskirame puslapyje arba išplėstiniame rodinyje.
- 3Jei pagal turinio tipą naudojami priedai, vizualai ar registracijos nuorodos, sistema turi sudaryti galimybę juos pridėti kaip struktūruotus turinio elementus.
- 4Informacinis turinys (tvarkos, atmintinės, instrukcijos, dokumentai, kontaktai ir pan.) turi būti pateikiamas teminiais informaciniais blokais pagal praktinį poreikį.
- 5Turinio dubliavimas turi būti valdomas pagal nustatytas taisykles: centrinis naujienų kanalas yra pirminė publikavimo vieta, o turinys į teminius polapius gali būti atvaizduojamas pakartotinai nekeičiant pirminio šaltinio.
Paslaugų ir projekto valdymo reikalavimai
- 1Tiekėjas užtikrina, kad visa komunikacija Projekto įgyvendinimo metu vyks lietuvių kalba. Jei pasitelkiami užsienio ekspertai – Tiekėjas užtikrina vertimą į lietuvių kalbą savo sąskaita.
- 2Tiekėjas privalo paskirti Projekto vadovą ir užtikrinti jo pavadavimą; apie pasikeitimus nedelsiant informuoja URM.
- 3Visi Projekto metu sukurti ir įgyti rezultatai ir su jais susijusios teisės (autorių, intelektinės nuosavybės ir kt.) yra URM nuosavybė; URM gali naudoti, publikuoti ir disponuoti be apribojimų.
- 4Esant poreikiui, URM suderintu laiku Tiekėjui gali būti suteikta ribota nuotolinė prieiga darbų vykdymui, naudojant URM įdiegtas išorės tiekėjų prieigos priemones.
- 5Tiekėjas privalo užtikrinti, kad jokios testinės intraneto versijos nebus prieinamos trečiosioms šalims be URM sutikimo.
- 6Tiekėjas, pradėdamas paslaugų teikimą, turi pateikti ir su URM suderinti projekto įgyvendinimo planą.
- 7Projekto įgyvendinimo plane turi būti nurodyti bent šie elementai: etapų pavadinimai, kiekvieno etapo rezultatai, terminai, atsakingi asmenys, priklausomybės, pagrindinės rizikos ir jų valdymo priemonės.
- 8Tiekėjas projekto vykdymo metu turi reguliariai teikti projekto būsenos informaciją apie atliktus darbus, nustatytas rizikas, kliūtis, planuojamus darbus ir sprendimus, reikalingus suderinti su URM.
- 9Jei projekto vykdymo metu keičiasi apimtis, terminai, techniniai sprendiniai ar priklausomybės, pakeitimai turi būti fiksuojami ir derinami su URM prieš juos įgyvendinant, išskyrus avarinius atvejus, kai delsimas galėtų sukelti didesnę žalą sistemos veikimui ar saugai.
Turinio valdymo sistema (TVS) reikalavimai
- 1TVS turi leisti URM darbuotojams savarankiškai kurti, redaguoti ir publikuoti turinį be tiekėjo įsitraukimo.
- 2Teisių valdymas turi būti grindžiamas naudotojų vaidmenimis ir (ar) grupėmis. Turi būti atskirtos bent šios funkcijos: turinio kūrimas ir redagavimas, publikavimo tvirtinimas, sistemos konfigūravimas ir naudotojų teisių administravimas.
- 3TVS privalo palaikyti juodraščius, peržiūrą prieš publikavimą, publikavimo ir nuėmimo planavimą, turinio versijavimą ir galimybę atkurti bent vieną ankstesnę turinio versiją.
- 4TVS turi turėti šablonus ir komponentus (blokų principas), leidžiančius kurti vieningą struktūrą be programavimo.
- 5TVS turi turėti medijos biblioteką (failų, nuotraukų, vaizdo įrašų valdymą) ir metaduomenis (pavadinimas, aprašymas, žymos).
- 6TVS audito žurnaluose turi būti registruojami bent šie įvykiai: turinio sukūrimas, keitimas, publikavimas, nuėmimas, teisių pakeitimas ir prisijungimai prie administravimo aplinkos.
- 7Audito žurnalai turi būti prieinami peržiūrai įgaliotiems naudotojams ir, jei techniškai taikoma, eksportuojami į įprastą kompiuteriu apdorojamą formatą.
- 8Audito žurnalų saugojimo terminas turi būti ne trumpesnis kaip 12 mėnesių nuo įvykio sukūrimo dienos.
- 9TVS turi leisti valdyti turinio kategorijas, žymas, publikavimo laikotarpius ir kitus metaduomenis, reikalingus turinio klasifikavimui, paieškai ir automatizuotam atvaizdavimui.
- 10TVS turi palaikyti turinio peržiūros ir tvirtinimo eigą, įskaitant galimybę nustatyti bent vieną papildomą turinio patvirtinimo žingsnį prieš publikavimą, kai to reikia pagal URM vidaus procesus.
Licencinės programinės įrangos reikalavimai
- 1Visa projekto metu naudojama programinė įranga turi būti naudojama teisėtai, laikantis licencijų sąlygų.
- 2Tiekėjas neturi diegti tokių licencinių, techninių ar sutartinių apribojimų, kurie be atskiro URM sutikimo nepagrįstai ribotų naudotojų skaičių, integracijų galimybes, administravimą, palaikymo perdavimą kitam tiekėjui ar sistemos vystymą.
- 3Tiekėjas garantuoja URM nuostolių atlyginimą dėl trečiųjų šalių reikalavimų, susijusių su autorių teisėmis, patentais, licencijomis ar prekių ženklais, jei jie kyla dėl sukurto sprendimo naudojimo.
- 4Tiekėjas užtikrina, kad URM bus suteiktos teisės naudotis trečiųjų šalių autorinių teisių objektais ta apimtimi, kiek tai būtina sutarties rezultatams pasiekti.
Naudotojo sąsajos ir naudojamumo reikalavimai
- 1Visi naujai kuriami arba keičiami naudotojo sąsajos elementai turi atitikti vieningus vizualinius ir elgsenos principus toje pačioje sistemoje.
- 2Tiekėjas, jei prašoma, turi pateikti naudojamų komponentų arba dizaino taisyklių aprašą.
- 3Tie patys sąsajos elementai turi būti nuosekliai atvaizduojami skirtinguose puslapiuose ir skirtingose naudotojo kelionėse (pvz., šriftai, spalvos, išdėstymas, mygtukų elgsena).
- 4Klaidų ir įspėjamieji pranešimai turi būti aiškūs, suprantami ir naudotojui nurodyti, kas įvyko ir kokių veiksmų jis gali imtis.
Našumo, pasiekiamumo ir stebėsenos reikalavimai
- 1Sistema turi užtikrinti pakankamą veikimo spartą įprastomis ir pagrįstai prognozuojamomis naudojimo sąlygomis.
- 2Jei konkretūs našumo rodikliai nėra nustatyti pirkimo dokumentuose, jie turi būti suderinti ne vėliau kaip projektavimo arba techninio sprendinio detalizavimo etape ir taikomi rezultatų priėmimui.
- 3Turi būti sudarytos galimybės stebėti sistemos būklę, klaidas ir kritinius sutrikimus, kad atsakingi asmenys galėtų laiku nustatyti veikimo problemas ir imtis priemonių joms šalinti.
- 4Jei projektui nustatomi konkretūs našumo arba apkrovos rodikliai, Tiekėjas prieš priėmimą turi pateikti jų pasiekimą pagrindžiančius testavimo rezultatus.
- 5Jei sutartyje nustatomi pasiekiamumo rodikliai, planiniai priežiūros darbai ir jų langai turi būti aiškiai apibrėžti ir iš anksto derinami su URM.
Nuosavybės ir tiekėjo nepriklausomumo reikalavimai
- 1Sprendimas turi būti sukurtas taip, kad URM galėtų savarankiškai redaguoti turinį, administruoti TVS ir, esant poreikiui, perduoti sistemos palaikymą kitam tiekėjui be nepagrįstų techninių, licencinių, organizacinių ar sutartinių kliūčių.
- 2Perdavimo URM metu Tiekėjas turi perduoti ne tik išeities kodą, bet ir konfigūracijos aprašus, diegimo instrukcijas, integracijų aprašus, administravimo informaciją bei kitą informaciją, būtiną savarankiškam sistemos eksploatavimui ir tolesniam vystymui.
- 3Jei sutarties pabaigoje ar jos nutraukimo atveju URM sprendžia perduoti palaikymą kitam tiekėjui, esamas Tiekėjas privalo bendradarbiauti tiek, kiek tai pagrįstai būtina sklandžiam perdavimui užtikrinti, perduodant informaciją, prieigas, dokumentaciją ir kitą sukurto sprendinio perėmimui reikalingą medžiagą pagal sutartyje nustatytą apimtį.
Teisinės atitikties ir duomenų apsaugos reikalavimai
- 1Tiekėjas, teikdamas paslaugas, vadovaujasi ir užtikrina šių teisės aktų reikalavimų įgyvendinimą: Reglamentas (ES) 2016/679 (BDAR).
- 2Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymas.
- 3Lietuvos Respublikos kibernetinio saugumo įstatymas.
- 4Lietuvos Respublikos valstybės informacinių išteklių valdymo įstatymas.
- 5LST EN ISO/IEC 27002:2017 ir LST EN ISO/IEC 27002:2023 (rekomendacinės priemonės) ir kiti atitinkami „Saugumo metodų“ standartai.
- 6Tiekėjas įsipareigoja visus sutarties vykdymo laikotarpiu gautus asmens duomenis tvarkyti laikantis BDAR, LR asmens duomenų teisinės apsaugos įstatymo ir kitų taikytinų teisės aktų.
- 7Jei sistemoje tvarkomi asmens duomenys, turi būti taikomi duomenų kiekio mažinimo, prieigos ribojimo, saugojimo terminų nustatymo ir atskaitomybės principai, o prieiga prie tokių duomenų turi būti suteikiama tik tiems asmenims, kuriems ji būtina pagal funkcijas.
- 8Sprendinyje turi būti numatytos priemonės, kurios, kai taikoma, sudarytų galimybę įgyvendinti duomenų subjektų teises, registruoti prieigos prie asmens duomenų veiksmus ir pagrįstai atsekti duomenų tvarkymo operacijas.
Funkciniai reikalavimai: Privalomi polapiai ir rubrikos
- 1Naujienų pulsas: išorės naujienos, „naujienų agentūros“ principas; trumpi, faktiniai pranešimai; jei įgyvendinama – prenumerata/filtravimas pagal temas.
- 2Ministro kabinetas: vadovybės komunikacijos srautas (ministro, viceministrų, kanclerės); palaikomi įrašai su nuotraukomis; (jei nuspręsta) – vaizdo turinio talpinimas.
- 3URM gyvenimas / URM aktualijos: centrinis URM vidaus naujienų kanalas (pirminė vieta vidaus naujienoms); žanrai: šventės, renginiai, skelbimai, registracijos, portretai, netektys.
- 4Kalendorius: mišrus polapis: virtualus kalendorius, operatyvūs pranešimai arba informacinė juosta, kavinės meniu ir navigaciniai informaciniai blokai (pvz., rezervacija, protokolas ir pan.).
- 5Projektai: projektų polapiai turi būti kuriami pagal vieningą struktūrą, pavyzdžiui: „Apie projektą“, „Naujienos“ (jei taikoma), „Atmintinės / formos / taisyklės“.
- 6Padaliniai: padalinių sąrašas turi būti pateikiamas informacinių blokų principu; kiekvienam padaliniui turi būti numatytas atskiras polapis (pvz., „Apie padalinį“, „Atmintinės“, „Naujienos“, jei aktualu).
- 7Mokymai: pirmas lygis – keli lygiaverčiai box’ai; sub-puslapiai su vieninga struktūra (Apie; tvarka; registracija; naujienos – jei aktualu).
- 8Vertinimas/Vertinimai: informacinė skiltis: Apie; Instrukcijos/atmintinės; Naujienos – jei aktualu.
- 9Talentai: grafinė skiltis su sub-puslapiais ir vienodais elementais (Apie; Foto; Naujienos; Instrukcija/registracija; Kalendorius).
- 10Biblioteka: funkcinis puslapis su nekintama struktūra (Biblioteka; Archyvas; Kalbininkės), aiškios tvarkos ir kontaktai.
- 11Nuostatai/įstatai: centralizuota teisinės/administracinės informacijos bazė; grupavimas pagal temą ir praktinį poreikį.
- 12URM žmonės: kontaktų ir profilių skiltis: bazinis profilis + savanoriški laukai pagal politiką; savarankiškas pildymas pagal teises.
- 13Partneriai: partnerių logo siena + naujienų srautas apie partnerystes; naujienos dubliuojamos centriniame kanale.
- 14Socialinė atsakomybė / Mums rūpi: sub-box’ai iniciatyvoms (profsąjunga, lygybė, tvarumas, psichologinė pagalba, savanorystė ir kt.).
- 15Pagalba: sub-polapiai: IT; Ūkio administravimas; Apsauga/Saugumas; instrukcijos, atmintinės, kontaktai.
- 16Šoniniai baneriai: turi būti numatytos šoninių reklaminių ar informacinių skydelių pozicijos (pvz., apklausoms, iniciatyvoms, nuorodoms į albumus, funkcijai „Pranešti naujieną“), administruojamos pagal naudotojų vaidmenis ir suteiktas teises.
Ryšio šifravimo ir naršyklių palaikymo reikalavimai
- 1Duomenų perdavimas tarp naudotojo sąsajos, taikomųjų komponentų ir kitų sisteminių sluoksnių turi būti apsaugotas naudojant TLS arba lygiavertes šifravimo priemones.
- 2Sistema turi tinkamai veikti ir būti korektiškai atvaizduojama bent Edge, Firefox, Chrome, Safari ir Safari Mobile naršyklėse, įskaitant naujausią ir dvi ankstesnes šių naršyklių versijas, jei gamintojas jas palaiko.
- 3Tiekėjas turi atlikti suderinamumo patikrą bent 6.4.2 punkte nurodytose naršyklėse ir, jei prašoma, pateikti tokios patikros rezultatus arba kitą pagrįstą atitikties įrodymą.
Funkciniai reikalavimai: Informacinė architektūra ir meniu
- 1Sistema turi įgyvendinti pastovų pagrindinį meniu su teminiais polapiais ir jų žemesnio lygmens polapiais.
- 2Sistema turi palaikyti šiuos polapių tipus: informacinius (statiškesnio turinio), dinaminius (turinio srautų) ir mišrius (dinaminio turinio zona kartu su informaciniais blokais).
- 3Sistema turi sudaryti galimybę administratoriui ar įgaliotam redaktoriui laikinai paslėpti dar neparengtus polapius arba apriboti jų matomumą tik įgaliotiems naudotojams iki oficialaus publikavimo.
tendis.lt · Sukurta recodin.lt