Par SIA “Rīgas ūdens” WEB portāla izstrādi

Līgums Nr.    

Par SIA “Rīgas ūdens” WEB portāla izstrādi

(iepirkuma xx.Xx. RŪ-2017/115) Rīgā, 2018.gada      .     

SIA „Rīgas ūdens”, reģ. Nr. 40103023035, turpmāk tekstā Pasūtītājs, tās valdes priekšsēdētājas Dagnijas Kalniņas personā, kura rīkojas uz SIA „Rīgas ūdens” valdes 2018.gada 11.aprīļa lēmuma (protokols Nr.2.4.1/2018/24) pamata, no vienas puses, un

SIA „Softikom”, reģ. Nr. 40003674327, turpmāk – Izpildītājs, tās valdes locekles Inese Gludītes personā, kura rīkojas uz statūtu pamata, no otras puses,

abi turpmāk Līgumā kopā vai individuāli saukti Puses, noslēdz šādu līgumu (turpmāk – Līgums):

1. Līguma priekšmets

1.1. Pasūtītājs uzdod un Izpildītājs, ievērojot Līguma noteikumus, apņemas nodrošināt SIA “Rīgas ūdens” klientu portāla (turpmāk – Portāls) izstrādi (turpmāk tekstā – Pakalpojums).

1.2. Izpildītājs veic Pakalpojumu saskaņā ar atklāta konkursa ar id. Nr.RŪ-2017/115 (turpmāk – Iepirkums) Tehnisko specifikāciju (Līguma 1.pielikums) un Izpildītāja piedāvājumu Xxxxxxxxxx (Līguma 2.pielikums).

1.3. Pakalpojums ir Portāla izstrāde, kas ietver:

1.3.1. Portāla programmatūras prasību specifikācijas (PPS) izstrādi;

1.3.2. Portāla programmatūras projektējuma (PPA) izstrādi;

1.3.3. Portāla izstrādi un testēšanu;

1.3.4. Portāla klientu portāla nodošanu ekspluatācijā;

1.3.5. Portāla garantijas pakalpojumu nodrošināšanu.

1.4. Pakalpojuma izpildes vieta ir Rīga.

2. Līguma summa un samaksas kārtība

2.1. Līguma summa ir EUR 371 700,00 (trīs simti septiņdesmit viens tūkstotis septiņi simti euro un 00 centi) bez PVN saskaņā ar Izpildītāja piedāvājumu Xxxxxxxxxx. PVN tiek aprēķināts normatīvajos aktos noteiktajā kārtībā.

2.2. Līguma summā ietverta Pakalpojuma izpildes kopējā vērtība, kā arī visi citi tiešie un netiešie Izpildītāja izdevumi, kas varētu rasties un ir saistīti ar Līgumā noteikto saistību izpildi.

2.3. Pasūtītājs ir tiesīgs izmaksāt Izpildītājam avansu pirms Pakalpojumu izpildes. Avansa apmērs nedrīkst pārsniegt 20 % (divdesmit procentus) no kopējās Līguma summas.

2.4. Lai saņemtu avansu, Izpildītājam ir jāiesniedz Pasūtītājam pieprasījumu ar pieprasītā avansa apmēru, avansa rēķinu un Pasūtītājam pieņemamu avansa atmaksas nodrošinājumu (Līguma 3.nodaļa) pieprasītās avansa summas apmērā.

2.5. Pasūtītājs 10 (desmit) darba dienu laikā pēc pieņemšanas-nodošanas akta parakstīšanas par Līguma 1.3.1. punktā minētās Pakalpojuma daļas izpildi, balstoties uz Izpildītāja izrakstītu rēķinu, samaksā Izpildītājam 2.maksājumu, kas sastāda ne vairāk kā 10% (desmit procentus) no Līguma summas.

2.6. Pasūtītājs 10 (desmit) darba dienu laikā pēc pieņemšanas-nodošanas akta parakstīšanas par Līguma 1.3.2. punktā minētās Pakalpojuma daļas izpildi, balstoties uz Izpildītāja izrakstītu rēķinu, samaksā Izpildītājam 3.maksājumu, kas sastāda ne vairāk kā 5% (piecus procentus) no Līguma summas.

2.7. Pasūtītājs 10 (desmit) darba dienu laikā pēc pieņemšanas-nodošanas akta parakstīšanas par Līguma 1.3.3. punktā minētās Pakalpojuma daļas izpildi, balstoties uz Izpildītāja izrakstītu rēķinu, samaksā Izpildītājam 4.maksājumu, kas sastāda ne vairāk kā 15% (piecpadsmit procentus) no Līguma summas.

2.8. Pasūtītājs 10 (desmit) darba dienu laikā pēc pieņemšanas-nodošanas akta parakstīšanas par Līguma 1.3.4. punktā minētās Pakalpojuma daļas izpildi, balstoties uz Izpildītāja izrakstītu rēķinu, samaksā Izpildītājam atlikušo Līguma summu.

2.9. Līguma 2.3. punktā norādītais avansa maksājums no Līguma summas tiks dzēsts ar pieņemšanas - nodošanas akta parakstīšanu par Līguma 1.3.4. punktā minēto Pakalpojuma daļu izpildi.

3. Avansa atmaksas nodrošinājums

3.1. Ja Izpildītājs vēlas saņemt Līguma 2.3. un 2.4.punktā noteikto avansu, tas kopā ar avansa pieprasījumu iesniedz Pasūtītājam tā saskaņotu avansa atmaksas nodrošinājumu no kredītiestādes, kura saņēmusi atļauju sniegt finanšu pakalpojumus Eiropas savienības vai Eiropas ekonomiskās zonas dalībvalstī, ekspromisorisko garantiju vai apdrošināšanas kompānijas, kura saņēmusi atļauju sniegt apdrošināšanas pakalpojumus Eiropas Savienības vai Eiropas Ekonomiskās zonas dalībvalstī, ekspromisorisku garantiju avansa maksājuma summas apmērā (līguma 2.3.punkts), Garantijā jābūt nepārprotami norādītām, ka tai ir piemērojami Starptautiskās Tirdzniecības palātas izdotie Vienotie noteikumi par pieprasījumu garantijām Nr.758 („The ICC Uniform Rules for Demand Guaranties”, ICC Publication No.758). Avansa atmaksas nodrošinājumā jābūt atsaucei uz Līgumu un tam jābūt izdotam vienā oriģinālā eksemplārā – nodrošinājuma saņēmējam.

3.2. Avansa atmaksas nodrošinājumu Pasūtītājs ir tiesīgs izmantot, lai kompensētu avansu, ja Izpildītājs nepilda savas saistības saskaņā ar Līgumu.

3.3. Avansa atmaksas nodrošinājums ir kredītiestādes vai tās filiāles vai apdrošināšanas sabiedrības vai tās filiāles, kurai ir tiesības veikt darbību Latvijas Republikā izsniegts avansa atmaksas nodrošinājums, kura saturs atbilst Līguma 3.nodaļas noteikumiem.

3.4. Avansa atmaksas nodrošinājuma jābūt spēkā līdz brīdim, kad Izpildītājs ir izpildījis Līguma

1.3.4. punktā minēto Pakalpojumu un vēl 30 (trīsdesmit) dienas pēc tam.

3.5. Ja avansa atmaksas nodrošinājums jebkāda iemesla dēļ zaudē spēku pirms avansa pilnīgas atmaksas, tas uzskatāms par Izpildītāja saistību neizpildi un Pasūtītājs ir tiesīgs nekavējoties vienpusēji izbeigt Līgumu, rakstiski informējot par to Izpildītāju.

3.6. Pasūtītājs nedrīkst pieņemt nodrošinājumu, ja konstatējams vismaz viens no šādiem apstākļiem:

3.6.1. nodrošinājuma dokumentā ir noteikts nodrošinātā prasījuma cesijas vai nodrošinājuma izlietošanas tiesību aizliegums;

3.6.2. nodrošinājums var tikt izlietots, tikai ceļot prasību tiesā vai šķīrējtiesā;

3.6.3. nodrošinājuma dokumenta noteikumi ierobežo, apgrūtina vai novilcina Pasūtītāja iespēju izlietot tajā paredzēto nodrošinājumu vai nodrošinājuma izlietošana ir saistīta ar nepamatoti īsu termiņu vai citiem Pasūtītāju ierobežojošiem noteikumiem;

3.6.4. nodrošinājuma dokuments paredz Izpildītāja tiesības atkāpties no nodrošinājuma dokumenta bez Pasūtītāja piekrišanas (vienpusēji atcelt nodrošinājuma dokumentu);

3.6.5. nodrošinājums vai nodrošinājuma dokuments neatbilst Līgumam;

3.6.6. nodrošinājuma dokumentam vai tajā paredzētajam nodrošinājumam ir piemērojams ārvalsts likums;

3.6.7. Pasūtītājam ir cits pamatots iemesls atteikties pieņemt nodrošinājumu.

3.7. Ja avansa atmaksas nodrošinājums ir kredītiestādes garantija, tai piemērojami garantijai piemērojami Starptautiskās tirdzniecības kameras noteikumi „The ICC Uniform Rules for Demand Guarantees”, ICC Publication No.758, bet attiecībā uz jautājumiem, kurus neregulē minētie Starptautiskās tirdzniecības kameras noteikumi, šai garantijai piemērojami Latvijas Republikas normatīvie akti. Prasības un strīdi, kas saistīti ar šo garantiju, izskatāmi Latvijas Republikas tiesā saskaņā ar Latvijas Republikas normatīvajiem tiesību aktiem.

4. Sistēmas izstrādes organizācija

4.1. Līguma 1.3.1. punktā noteiktās Pakalpojuma daļas izpildes termiņš, skaitot no Līguma spēkā stāšanās dienas, noteikts Izpildītāja piedāvājumā Xxxxxxxxxx (Laika grafikā).

4.2. Līguma 1.3.2. punktā noteiktās Pakalpojuma daļas izpildes termiņš, skaitot no Līguma spēkā stāšanās dienas, noteikts Izpildītāja piedāvājumā Xxxxxxxxxx (Laika grafikā).

4.3. Līguma 1.3.3. punktā noteiktās Pakalpojuma daļas izpildes termiņš, skaitot no Līguma spēkā stāšanās dienas, noteikts Izpildītāja piedāvājumā Xxxxxxxxxx (Laika grafikā).

4.4. Līguma 1.3.4. punktā noteiktās Pakalpojuma daļas izpildes termiņš, skaitot no Līguma spēkā stāšanās dienas, noteikts Izpildītāja piedāvājumā Xxxxxxxxxx (Laika grafikā).

4.5. Līguma 1.3.5. punktā noteiktās Pakalpojuma daļas izpildes termiņš ir noteikts 36 (trīsdesmit seši) mēneši pēc Līguma 1.3.4. punktā minētās Pakalpojuma daļas izpildes.

4.6. Līguma 1.3.1.- 1.3.5. punktos noteikto Pakalpojuma posmu izpildes termiņi ir noteikti saskaņā ar Izpildītāja iesniegto Laika grafiku, kas iekļauts Izpildītāja Tehniskajā piedāvājumā (Līguma 2.pielikums). Līguma 1.3.1. – 1.3.4.punktos noteikto Pakalpojumu posmu izpildes termiņos ir ietverts tai skaitā laiks, kas nepieciešams Pakalpojumu posmu pieņemšanai un trūkumu novēršanai saskaņā ar Līguma 4.7.1.-4.7.4.punktos noteikto kārtību.

4.7. Pakalpojumu posmu izpildes kārtība:

4.7.1. Katrs Pakalpojuma posma nodevums, kuru Izpildītājs iesniedz Pasūtītājam, ir uzskatāms par pieņemtu tikai ar brīdi, kad Pasūtītājs nodevumus pārbaudījis (t.i. pārbaudījis to atbilstību Līguma nosacījumiem), pieņēmis un parakstījis atbilstošu nodošanas – pieņemšanas aktu (turpmāk – Akts).

4.7.2. Pakalpojuma posmu izpildes pieņemšana tiek noformēta ar Aktu, kuru paraksta Puses un kas tiek sagatavots divos eksemplāros, pa vienam – katrai Pusei. Aktā norāda Pakalpojuma sniegšanas atbilstību tehniskajai specifikācijai un Līguma noteikumiem, Pakalpojuma sniegšanas laiku, kā arī citas ziņas par Pakalpojuma izpildi.

4.7.3. Pakalpojuma posmu nodevumu nepieņemšanas gadījumā Pasūtītājs ne vēlāk kā 10 (desmit) darba dienu laikā pēc nodevuma saņemšanas nosūta Izpildītājam motivētu atteikumu pieņemt darbus, norādot termiņu konstatēto trūkumu novēršanai. Ja netiek konstatēti īpaši apstākļi, par kuriem savstarpēji vienojas Pasūtītājs un Izpildītājs, termiņš trūkumu novēršanai ir 10 (desmit) darba dienas. Ja pēc trešās Pakalpojuma posma iesniegšanas reizes (iterācijas) nodevuma trūkumi nav novērsti, Pasūtītājs pēc savas izvēles ir tiesīgs vai nu pieprasīt nodevuma pārstrādāšanu, vai vienpusēji izbeigt Līgumu.

4.7.4. Par Pakalpojuma posma pieņemšanā vai akcepttestēšanā atklātajām nepilnībām vai kļūdām Pasūtītājs informē Izpildītāju ne vēlāk, kā 10 (desmit) darba dienu laikā.

4.7.5. Gadījumā, kad tiek konstatētas papildus prasības, kas nav bijušas iekļautas tehniskajā specifikācijā, vai kādu iepriekš definētu prasību izpilde nav nepieciešama, Pasūtītājs/ Izpildītājs definē nepieciešamos izmaiņu pieprasījumus un rakstveidā informē par to otru Pusi atbilstoši pasūtītāja apstiprinātajai izmaiņu pārvaldības kārtībai.

4.7.6. Izpildītājs 15 (piecpadsmit) darba dienu laikā sagatavo un rakstveidā iesniedz Pasūtītājam izmaiņu pieprasījumu realizācijas piedāvājumu.

4.7.7. Pasūtītājs 10 (desmit) darba dienu laikā apstiprina vai noraida Izpildītāja izmaiņu pieprasījumu realizācijas piedāvājumu.

4.7.8. Ja Puses nevar vienoties par izmaiņu pieprasījumu izstrādes noteikumiem, Pasūtītājs ir tiesīgs pasūtīt izmaiņu pieprasījumu izstrādi trešajām personām. Šajā gadījumā Izpildītājam ir pienākums sniegt šādai trešajai personai visu nepieciešamo informāciju.

5. Līguma pārvaldība un atbildīgās personas

5.1. Līguma izpildei katra no Pusēm nozīmē vienu vai vairākus pārstāvjus, kuru pienākums ir vadīt

un sekot Līguma izpildei un informēt par Līguma izpildi gan savu, gan arī otru Pusi.

5.2. Pasūtītāja nozīmētais pārstāvis: [..]

5.3. Izpildītāja nozīmētais pārstāvis: [..]

5.4. Pārstāvjiem ir šādas tiesības:

5.4.1. attiecīgi pieņemt vai nodot Līguma ietvaros sniegtos Pakalpojumus un Pakalpojumu posmus, parakstot Aktu;

5.4.2. risināt citus organizatoriskos jautājumus, kas saistīti ar Līguma nosacījumu izpildi.

5.5. Pasūtītāja nozīmētais pārstāvis [..] tai skaitā ir pilnvarots:

5.5.1. izteikt Izpildītājam pretenzijas par Līguma ietvaros sniegtajiem Pakalpojumiem, tai skaitā par akcepttestēšanā atklātajām nepilnībām vai kļūdām;

5.5.2. saskaņot iespēju izmantot Pasūtītāja tehnisko un sistēmu nodrošinājumu, ja tas ir nepieciešams Izpildītāja saistību veikšanai;

5.5.3. pieprasīt Pakalpojumu sniegšanā iesaistīto speciālistu aizstāšanu un saskaņot Izpildītāja ierosināto speciālistu aizstāšanu un papildu personāla iesaistīšanu Līguma izpildē.

5.6. Pārstāvju nomaiņas gadījumā otra Puse par to tiek rakstiski informēta ne vēlāk, kā 3 (trīs) darba dienas iepriekš.

5.7. Jebkurš oficiāls paziņojums, lūgums, pieprasījums vai cita informācija (izņemot tehniskas dabas informāciju) saskaņā ar šo Līgumu tiek iesniegta rakstveidā un tiek uzskatīta par iesniegtu vai nosūtītu tai pašā dienā, ja tā nosūtīta pa faksu, vai nodota rokās otrai Pusei pret parakstu vai nosūtīta elektroniski ar drošu elektronisko parakstu un laika zīmogu. Ja paziņojums nosūtīts kā reģistrēts pasta sūtījums, tad saņemšanas diena būs pasta paziņojuma datums par šāda sūtījuma izsniegšanu. Visi paziņojumi Pusēm tiks nosūtīti uz Līgumā norādītajām adresēm.

6. Pasūtītāja tiesības un pienākumi

6.1. Pasūtītājs apņemas:

6.1.1. Sniegt Izpildītājam visu nepieciešamo informāciju, kas nepieciešama Līguma izpildei.

6.1.2. Pieņemt pienācīgi izpildītu darbu un veikt samaksu saskaņā ar Līguma noteikumiem un nosacījumiem.

6.1.3. Nodrošināt Izpildītāja personālam iespēju izmantot Pasūtītāja tehnisko un sistēmu nodrošinājumu, ja tas ir nepieciešams Izpildītāja saistību veikšanai, saskaņojot to ar Pasūtītāju.

6.2. Pasūtītājam ir tiesības:

6.2.1. Veikt izmaiņas Portāla izstrādes prasībās atbilstoši Tehniskajā specifikācijā definētajam apjomam un kārtībai.

6.2.2. Līguma izpildes uzraudzībai piesaistīt trešās personas.

6.2.3. Līguma izpildes laikā iesniegt Izpildītājam rakstisku pieprasījumu atsaukt vai aizstāt kādu no Pakalpojumu sniegšanā iesaistītajiem speciālistiem ar citu speciālistu, kuram ir līdzvērtīga vai augstāka kvalifikācija, norādot pamatotus iemeslus speciālista atsaukšanai vai aizstāšanai, ja Pasūtītājs ir neapmierināts ar Pakalpojumu sniegšanā iesaistīto Izpildītāja speciālistu darbību. Pasūtītājs nesedz Izpildītāja zaudējumus, kas saistīti ar Pakalpojumu sniegšanā iesaistīto speciālistu pamatotu atsaukšanu vai aizstāšanu.

7. Izpildītāja tiesības un pienākumi

7.1. Izpildītājs apņemas:

7.1.1. Sniegt Pakalpojumus kvalitatīvi un pilnā apjomā atbilstoši Tehniskajai specifikācijai (Līguma 1.pielikums) un Izpildītāja piedāvājumam (Līguma 2.pielikums), kā arī saistošiem noteikumiem un tiesību normām. Izpildītājs atbild par Portāla izstrādes gala rezultātu. Šī atbildība ietver gan sistēmas funkcionalitāti, gan tehnisko izpildījumu un nav ierobežota ar to, ka Pasūtītājs akceptējis kādu no starpnodevumiem vai sistēmu kopumā. Izpildītāja atbildība ir ierobežota ar tiešu un nepārprotamu Pasūtītāja rīkojumu izpildīšanu ar noteikumu, ka Izpildītājs ir brīdinājis, ka rīkojuma izpilde var atstāt negatīvu ietekmi uz gala rezultātu.

7.1.2. Veikt visas nepieciešamās darbības, lai pārliecinātos, ka Portāls kopumā varēs darboties atbilstoši tam definētajai funkcionalitātei, sistēmā esošie dati un informācija netiks zaudēti, grozīti vai padarīti par neprecīziem un neuzticamiem.

7.1.3. Nodrošināt, ka Portāla izstrādes un ieviešanas darbu veikšanai saskaņā ar šo Līgumu tiek piesaistīti pienācīgi kvalificēti speciālisti, kuri norādīti Izpildītāja piedāvājumā un speciālistu skaits ir pietiekams, lai visi Pakalpojumi saskaņā ar Līgumu tiktu veikti noteiktajos termiņos, apjomā un kvalitātē. Gadījumā, ja Līguma izpildes gaitā no Izpildītāja neatkarīgu apstākļu dēļ nepieciešams aizvietot kādu no sākotnēji piedāvātajiem speciālistiem, nodrošināt ne zemākas kvalifikācijas speciālistu iesaisti, iepriekš to saskaņojot ar Pasūtītāju. Pasūtītājs nav tiesīgs atteikt speciālista nomaiņu, ja konstatēti objektīvi šķēršļi piedāvātā speciālista nodarbināšanai un jaunā speciālista kvalifikācija ir atbilstoša. Gadījumā, ja Pasūtītājs, pamatojoties uz konstatētām kļūdām, kuras norāda uz nepietiekamu speciālista kvalifikāciju, pieprasījis nomainīt speciālistu, Izpildītājam ir pienākums veikt šādu nomaiņu 10 (desmit) darba dienu laikā.

7.1.4. Visu Līguma darbības laikā izstrādāto dokumentāciju noformēt atbilstoši Latvijas Valsts informācijas tehnoloģijas standartiem programminženierijā un/vai atbilstošiem starptautiskajiem standartiem informācijas tehnoloģiju jomā. Visa Līguma ietvaros izstrādājamā dokumentācija jāiesniedz Pasūtītājam gan papīra, gan elektroniskā formātā.

7.1.5. Izmantojot Pasūtītāja tehnisko un sistēmu nodrošinājumu, ievērot Pasūtītāja

noteikumus.

7.1.6. Izpildītājs apņemas līdz garantijas termiņa beigām nodrošināt pieejamību tehniskā atbalsta dienestam, kurš ir izvietots Latvijā.

7.2. Izpildītājs ir atbildīgs par zaudējumiem, kas Pasūtītājam radušies sistēmas izstrādes un ieviešanas pakalpojumu vai sistēmas lietošanas rezultātā Izpildītāja rupjas neuzmanības, ļauna nolūka dēļ, kā arī Izpildītāja vieglas uzmanības dēļ, ja Izpildītājam ir bijis zināms, ka Pasūtītāja norādījumu izpilde vai darba paņēmiens var radīt zaudējumus, bet Izpildītājs par šādu zaudējumu risku Pasūtītāju nav brīdinājis.

8. Garantijas

8.1. Garantijas periodā Izpildītājam ir pienākums novērst visus sistēmas defektus, kuri būs radušies Izpildītāja kļūdaini veiktā izpildījuma dēļ.

8.2. Garantijas periodā konstatētās sistēmas problēmas Izpildītājam jānovērš ar savu darbaspēku un līdzekļiem, ievērojot tehniskajā specifikācijā norādīto problēmu novēršanas laiku.

9. Pušu atbildība

9.1. Puses vienojas, ka gadījumā, ja iestājas ārēji, no Pasūtītāja neatkarīgi apstākļi, kas būtiski ietekmē vai atceļ Portāla izstrādes nepieciešamību, Pasūtītājs ir tiesīgs vienpusēji izbeigt Līgumu, nemaksājot Izpildītājam nekādas soda sankcijas. Ja Līgums tiek izbeigts minēto apstākļu dēļ un Izpildītājs līdz Līguma izbeigšanas paziņojuma saņemšanai ir pienācīgi pildījis visas savas līgumsaistības, Pasūtītājs samaksā Izpildītājam par pienācīgi veikto darbu līdz Līguma izbeigšanas paziņojumam.

9.2. Izpildītājs par Pakalpojumu vai tā posmu sniegšanas termiņu pārkāpumu maksā Pasūtītājam līgumsodu 0,1% (viena procenta desmitdaļas) apmērā no attiecīgā Pakalpojuma posma līgumcenas par katru kavējuma dienu, bet ne vairāk kā 10% (desmit procenti) no attiecīgā Pakalpojuma posma līgumcenas.

9.3. Par Līgumā noteikto maksājumu kavējumu Pasūtītājs maksā Izpildītājam līgumsodu 0.1% (viena procenta desmitdaļas) apmērā no laikā nesamaksātās summas par katru kavējuma dienu, bet ne vairāk par 10% (desmit procentiem) no attiecīgā Pakalpojuma posma līgumcenas.

9.4. Pasūtītājam ir tiesības ar vienpusēju paziņojumu izbeigt Līgumu, ja:

9.4.1. ir stājies spēkā tiesas spriedums par Izpildītāja atzīšanu par maksātnespējīgu vai tiesa ir pieņēmusi pieteikumu par Izpildītāja atzīšanu par maksātnespējīgu;

9.4.2. pret Izpildītāju tikušas vērstas tiesiskas darbības, kas saistītas ar aresta uzlikšanu vairāk kā 50% no Izpildītāja bilances aktīviem;

9.4.3. Izpildītājs nepilda jebkādas Līguma saistības saskaņā ar Līguma noteikumiem un neatbilstības nav novērstas 30 (trīsdesmit) dienu laikā no rakstiska brīdinājuma saņemšanas;

9.4.4. Izpildītājs kavē jebkura darbu rezultātu nodošanu ilgāk par 30 (trīsdesmit) dienām;

9.4.5. veicot programmatūras akcepttestēšanu, sekmīgu akcepttestu nav izdevies veikt ar trīs iterācijām;

9.4.6. pēc Līguma noslēgšanas atklājas, ka, iesniedzot piedāvājumu, Izpildītājs ir apzināti sniedzis nepatiesu informāciju.

9.5. Ja Izpildītājs atkāpjas no Līguma bez tiesiska pamata, izņemot šajā Līgumā atrunātos gadījumus, un Pasūtītājs ir pienācīgi pildījis visas savas līgumsaistības, tad Izpildītājs maksā Pasūtītājam līgumsodu, kas sastāda 10% (desmit procenti) no Līguma 2.1. punktā noteiktās kopējās Līguma summas.

9.6. Par maksimālo pieļaujamā problēmas risināšanas laika pārsniegšanu Izpildītājs maksā līgumsodu 100,00 EUR (viens simts euro un 00 centi) par katru virslimita zaudlaika stundu.

9.7. Ja sistēma nenodrošina Līguma pielikumos norādīto veiktspēju, problēmu novēršanai tiek piemērotas prasības, kādas attiecināmas uz nozīmīgas problēmas novēršanu.

9.8. Līgumsoda samaksa pati par sevi neatbrīvo Izpildītāju no zaudējumu atlīdzināšanas pienākuma.

9.9. Par zaudējumiem un Līguma pārkāpumiem, kas radušies tādu objektīvu un no Pusēm neatkarīgu apstākļu dēļ, kurus tās neparedzēja, nevarēja paredzēt, kā arī nevarēja novērst to nelabvēlīgās sekas, atbildība neiestājas.

10. Konfidencialitātes nosacījumi

10.1. Puses apņemas bez otras Puses iepriekšējas rakstveida piekrišanas neizpaust jebkādu informāciju par otru Pusi, ko tie ieguvuši Līguma izpildes gaitā. Šis nosacījums ir spēkā gan Līguma izpildes laikā, gan arī 3 (trīs) gadus pēc Līguma darbības termiņa izbeigšanas.

10.2. Izpildītājs un Pasūtītājs apņemas sniegt informāciju saviem darbiniekiem tikai nepieciešamības gadījumā un tādā apjomā, kas nepieciešams tikai Līguma izpildei.

10.3. Ja Līguma 10.1. punktā minēto konfidenciālo informāciju pieprasa Latvijas Republikas Prokuratūra, Iekšlietu ministrija vai arī citas Latvijas Republikas likumos paredzētās institūcijas, kurām uz to ir likumīgas tiesības, jebkurai Pusei ir tiesības izpaust šādu informāciju bez otras Puses iepriekšējas atļaujas.

11. Autortiesības un licences

11.1. Izpildītājs pilnībā nodod Pasūtītājam visas Autortiesību likuma 15.panta pirmajā, otrajā un trešajā daļā noteiktās autora mantiskās izņēmuma tiesības uz visiem Līguma izpildes rezultātā radītajiem un Pasūtītājam nodotajiem un Pasūtītāja pilnā apmērā apmaksātajiem autortiesību objektiem, x.xx. izgatavotajiem un Pasūtītājam nodotajiem materiāliem.

11.2. Trešās personas izstrādātas programmatūras lietošanas tiesības Pasūtītājam tiek piešķirtas saskaņā ar attiecīgās programmatūras licencēšanas noteikumiem.

11.3. Izpildītājs garantē, ka nodevumu autori neizmantos Autortiesību likuma 14.panta pirmajā daļā noteiktās autora personiskās tiesības uz izlemšanu, vai darbs tiks izziņots un kad tas tiks izziņots (14.panta pirmās daļas 2.punkts), darba atsaukšanu (14.panta pirmās daļas 3.punkts), uz darba neaizskaramību (14.panta pirmās daļas 5.punkts) un pretdarbību (14.panta pirmās daļas 6.punkts).

11.4. Izpildītājam savos iesniedzamajos darbu nodevumos ir aizliegts iekļaut jebkādas norādes, kas satur ierobežojumus Pasūtītājam pilnīgi brīvi rīkoties (sadalīt, publicēt, iekļaut izvilkumus citos tekstos, nodot citām personām u.c.) ar saņemtajiem nodevumiem vai to daļām. Izpildītājs nedrīkst nekādos gadījumos pieprasīt, lai Pasūtītājs, jebkādi izmantojot nodevumus, obligāti publicē atsauces uz Izpildītāju. Šajā punktā raksturotās norādes nodevumos, rīkojoties ar tiem vai jebkādām to daļām, Pasūtītājs neņem vērā.

11.5. Izpildītājs atzīst, ka sistēmas darbināšanas rezultātā radīto elektronisko datubāzu veidotājs ir Pasūtītājs (saskaņā ar Autortiesību likuma IX nodaļu).

12. Force majeure

12.1. Xxxxxxx Xxxx nav atbildīga par savu saistību daļēju vai pilnīgu neizpildi, ja tas ir rezultāts tādiem notikumiem kā plūdi, ugunsgrēks, karadarbība, valdības lēmumi u.c., kas notikuši pēc Līguma slēgšanas un nav izraisīti ar kādas Puses nolūku un šādu notikumu seku novēršana nav iespējama ar Puses samērīgām darbībām.

12.2. Pusei, kas nokļuvusi nepārvaramas varas apstākļos, bez kavēšanās, bet ne vēlāk kā 3 (trīs) dienu laikā, rakstiski jāinformē par to otru Pusi pēc iespējas īsākā laikā pēc nepārvaramas varas apstākļu iestāšanās. Puses apņemas vienoties par to vai šādi nepārvaramas varas apstākļi traucē vai padara šī Līguma saistību izpildi par neiespējamu, kā arī izlems līgumsaistību turpināšanas (vai izbeigšanas) būtiskos jautājumus.

12.3. Nepārvaramas varas apstākļu esamību un to pastāvēšanas termiņu apliecina ar kompetentas institūcijas atzinumu.

13. Apakšuzņēmēja vai personāla nomaiņa un papildus piesaiste

13.1. Izpildītājam ir pienākums saskaņot ar Pasūtītāju papildu personāla iesaistīšanu Līguma izpildē.

13.2. Izpildītājs nav tiesīgs bez saskaņošanas ar Pasūtītāju veikt piedāvājumā norādītā personāla un apakšuzņēmēju nomaiņu un iesaistīt papildu apakšuzņēmējus Līguma izpildē.

13.3. Piedāvājumā norādītā personāla nomaiņa pieļaujama tikai šī Līguma noteikumos norādītajā kārtībā un gadījumos. Pasūtītājs nepiekrīt piedāvājumā norādītā personāla nomaiņai gadījumos, kad piedāvātais personāls neatbilst Xxxxxxxxx procedūras dokumentos personālam izvirzītajām prasībām vai tam nav vismaz tādas pašas kvalifikācijas un pieredzes kā personālam, kas tika vērtētas, piešķirot Izpildītājam Līguma slēgšanas tiesības.

13.4. Pasūtītājs nepiekrīt piedāvājumā norādītā apakšuzņēmēja nomaiņai, ja pastāv kāds no šādiem nosacījumiem:

13.4.1. piedāvātais apakšuzņēmējs neatbilst iepirkuma procedūras dokumentos apakšuzņēmējiem izvirzītajām prasībām;

13.4.2. tiek nomainīts apakšuzņēmējs, uz kura iespējām Izpildītājs balstījies, lai apliecinātu savas kvalifikācijas atbilstību iepirkuma procedūras dokumentos noteiktajām prasībām, un piedāvātajam apakšuzņēmējam nav vismaz tādas pašas kvalifikācijas, uz kādu Izpildītājs atsaucies, apliecinot savu atbilstību iepirkuma procedūrā noteiktajām prasībām, vai tas atbilst Sabiedrisko pakalpojumu sniedzēju iepirkuma likuma 48. panta pirmajā vai otrajā daļā minētajiem kandidātu un pretendentu izslēgšanas gadījumiem;

13.4.3. apakšuzņēmēja maiņas rezultātā tiktu izdarīti tādi grozījumi Izpildītāja piedāvājumā, kuri, ja sākotnēji būtu tajā iekļauti, ietekmētu piedāvājuma izvēli atbilstoši iepirkuma procedūras dokumentos noteiktajiem piedāvājuma izvērtēšanas kritērijiem.

13.5. Pasūtītājs nepiekrīt jauna apakšuzņēmēja piesaistei gadījumā, kad šādas izmaiņas, ja tās tiktu veiktas sākotnējā piedāvājumā, būtu ietekmējušas piedāvājuma izvēli atbilstoši iepirkuma procedūras dokumentos noteiktajiem piedāvājuma izvērtēšanas kritērijiem un šādā gadījumā līguma slēgšanas tiesības netiktu piešķirtas Izpildītājam.

13.6. Pārbaudot jaunā apakšuzņēmēja atbilstību, Pasūtītājs piemēro Sabiedrisko pakalpojumu sniedzēju iepirkuma likuma 48. panta noteikumus. Likuma 48. panta ceturtajā daļā minētos termiņus skaita no dienas, kad lūgums par apakšuzņēmēja nomaiņu iesniegts Pasūtītājam.

13.7. Pasūtītājs pieņem lēmumu atļaut vai atteikt Izpildītāja personāla vai apakšuzņēmēju nomaiņu vai jaunu apakšuzņēmēju iesaistīšanu Līguma izpildē iespējami īsā laikā, bet ne vēlāk kā 5 (piecu) darbdienu laikā pēc tam, kad saņēmis visu informāciju un dokumentus, kas nepieciešami lēmuma pieņemšanai saskaņā ar šī Līguma noteikumiem.

14. Citi noteikumi

14.1. Līgums tiek abpusēji parakstīts un stājas spēkā ar parakstīšanas brīdi un ir spēkā līdz Pušu līgumsaistību pilnīgai izpildei.

14.2. Attiecībā uz iespējamo domstarpību un strīdu risināšanu Līgums ir spēkā līdz Līgumā paredzēto Pušu savstarpējo saistību izpildei.

14.3. Izmaiņas un papildinājumi Līgumā ir spēkā tikai tad, ja tie noformēti rakstveidā un apstiprināti ar abu Pušu parakstiem.

14.4. Jebkuru pretrunu gadījumā jebkuros datos, noteikumos vai nosacījumos jebkurā no Līguma pantiem no vienas puses un uz Līguma pamata īstenoto Pakalpojuma izpildes posmu datos, noteikumos vai nosacījumos no otras puses, informācija, ko satur Līguma punkti, ir noteicošā, ja vien Puses tieši nav vienojušās par pretējo. Gadījumā, ja tiek atklāta pretruna starp Līguma pielikumiem – tehnisko specifikāciju un precizētu Izpildītāja piedāvājumu, strīda izskatīšanai piemērojami noteikumi vai nosacījumi, kuri ir izdevīgāki Pasūtītājam.

14.5. Līgums var tikt papildināts ar pielikumiem pēc Pušu savstarpējas vienošanās.

14.6. Jebkurš Līguma pielikums ir uzskatāms par Līguma neatņemamu sastāvdaļu.

14.7. Visi strīdi un domstarpības, kas varētu rasties starp Pusēm Līguma izpildes rezultātā, tiek risināti sarunu ceļā. Ja savstarpēja vienošanās netiek panākta, Pusēm ir tiesības griezties tiesā Latvijas Republikas normatīvajos aktos noteiktajā kārtībā.

14.8. Līgums sagatavots latviešu valodā divos eksemplāros, katrs uz 8 (astoņām) lapām ar Līguma 14.9.punktā minētajiem pielikumiem. Viens eksemplārs glabājas pie Pasūtītāja, bet otrs – pie Izpildītāja, un tiem ir vienāds juridisks spēks.

14.9. Līgumam tiek pievienoti šādi pielikumi, kas ir Līguma neatņemamas sastāvdaļas:

14.9.1. 1.pielikums – Iepirkuma Tehniskā specifikācija, uz 60 (sešdesmit) lapām;

14.9.2. 2.pielikums – Izpildītāja piedāvājums Xxxxxxxxxx, uz 114 (simtu četrpadsmit) lapām uz elektroniskā datu nesēja.

15. Pušu rekvizīti un paraksti

SIA „Rīgas ūdens”

Reģ. Nr. 40103023035

Xxxxxxxx Xxxxx Xxxxxxxxxx xxxxxxxx 0 Xxxx, XX-1494

Reģ. Nr. 40103023035

AS „Swedbank”

Bankas kods: XXXXXX00

Konts: XX00XXXX0000000000000

SIA „Softikom”

Reģ. Nr. 40003674327

Brīvības gatve 214 M Rīga, LV-1039

Reģ. Nr. 40003674327

AS „Swedbank”

Bankas kods: XXXXXX00

Konts: XX00XXXX0000000000000

Valdes priekšsēdētāja Xxxxxxx Xxxxxxx

Valdes locekle

Xxxxx Xxxxxxx

Tehniskā specifikācija

Pielikums Nr.1

Saturs

1. Ievads 11

1.1 Saīsinājumi un skaidrojumi 11

1.2 Esošās situācijas raksturojums 11

1.2.1 Esošās infrastruktūras apraksts 13

1.3 Dokumenta mērķis un konteksts 15

1.4 Saistītie dokumenti 15

1.5 Normatīvie akti, kuri jāievēro, veicot Portāla izstrādi 15

1.6 Pieņēmumi un ierobežojumi 16

2. Portāla prasību apraksts 17

2.1 Funkcionālās prasības 17

2.1.1 Vispārējās funkcionālās prasības 17

2.1.2 Lietotāju saskarņu funkcionālās prasības 17

2.1.3 Portāla saskarnes funkcionālās prasības 19

2.1.4 Pieteikumu izveide un iesniegšana 22

2.1.5 Administrēšanas funkcionālās un saskarnes prasības 24

2.1.6 Saistīto sistemu izstrādes prasības 26

2.2 Nefunkcionālās prasības 27

2.2.1 Arhitektūras prasības 27

2.2.2 Veiktspējas prasības 27

2.2.3 Drošības prasības 28

2.2.4 Lietojamības prasības 29

2.2.5 Ieviešanas prasības 30

2.2.6 Administratoru apmācības 31

2.2.7 Pārbaudāmības prasības 32

2.2.8 Integrācijas prasības 33

2.3 Organizatoriskās prasības 35

2.3.1 Projekta pārvaldības prasības 35

2.3.2 Prasību analīzes procesa prasības 37

2.3.3 Projekta nodevumu prasības 38

2.3.4 Garantijas prasības 41

3. Portāla procesu raksturojums 44

3.1 Patēriņa rādījumu nodošana un apstrāde 44

3.1.1 Patēriņa rādījumu nodošana un apstrāde (klientiem ar KUM) 44

3.1.2 Patēriņa apjoma kritēriju izmaiņu ziņošana (klientiem bez KUM) 46

3.2 Līgumattiecību vadība 47

3.2.1 Līguma slēgšana (jauni klienti) 47

3.2.2 Līguma slēgšana (esoši klienti) 47

3.2.3 Līguma grozīšana 48

3.2.4 Līguma apturēšana un izbeigšana 49

3.3 Kontu vadība 50

3.3.1 Lietotāja konta izveide portālā 50

3.3.2 Lietotāja konta uzturēšana portālā 51

3.3.3 Lietotāja konta slēgšana portālā 53

3.4 Rēķinu gatavošana un koriģēšana 53

3.4.1 Rēķinu gatavošana (pamatdarbības pakalpojumi) 53

3.4.2 Rēķina gatavošana (citi RŪ sniegtie pakalpojumi) 54

3.4.3 Rēķina korekcijas piemērošana klientiem 54

3.5 Rēķinu apmaksas kontrole 54

3.5.1 Maksājumu apstrāde un atpazīšana 54

3.5.2 Debitoru uzskaite un attēlošana 55

3.5.3 Norēķinu cikla maiņas pieteikšana un attēlošana 55

3.6 Citu pakalpojumu pieteikšana 56

3.6.1 Pakalpojumu pieteikšana (jauni klienti) 56

3.6.2 Pakalpojumu pieteikšana (esoši klienti) 57

3.7 Būvniecības dokumentācijas saskaņošana un izsniegšana 59

3.7.1 Tehniskās dokumentācijas izsniegšana un saskaņošana 59

3.8 Bojājumu pieteikšana un apstrāde 59

3.8.1 Pieteikšanās paziņojumu saņemšanai par bojājumiem 59

3.8.2 Bojājumu pieteikšana 61

3.9 RŪ pārstāvju izsaukšana 62

4. Portāla grafiskās vadlīnijas 63

5. Prasības Tehniskā piedāvājuma sagatavošanai 66

Ievads

Saīsinājumi un skaidrojumi

Dokumentā izmantotie sistēmu, tehnoloģiju nosaukumi, jēdzieni, terminu skaidrojumi un citu nosaukumu saīsinājumi ir norādīti zemāk (skat. 1. tabula. Definīcijas un saīsinājumi.).

1. tabula. Definīcijas un saīsinājumi.

Termins vai saīsinājums	Apraksts
CSV	Komatatdalīto vērtību fails (no angļu val.- Comma Separated Values)
EDUS	SIA “Rīgas ūdens” elektroniskā dokumentu uzskaites sistēma
ĢIS	SIA “Rīgas ūdens” ģeogrāfiskā informācijas sistēma
HORIZON	SIA “Rīgas ūdens” resursu vadības sistēma jeb ERP programma, kas nodrošina grāmatvedības uzskaiti un finanšu vadību, klientu uzskaiti un noliktavas pārvaldību
IS	Informācijas sistēma
Izpildītājs	Portāla izstrādātājs un piegādātājs
KUM	Komercuzskaites mēraparāts
OWASP	Atvērtais tīmekļa lietojumprogrammu drošības projekts (no angļu val.- Open Web Application Security Project)1
Pasūtītājs, RŪ	SIA “Rīgas ūdens”
Portāls, Sistēma	SIA “Rīgas ūdens” WEB portāls
Pretendents	Potenciālais Portāla izstrādātājs un piegādātājs, kurš iesniedz Piedāvājumu Portāla izstrādes un piegādes realizācijai
REST	Rest protokols (no angļu val.- Representational state transfer protocol)
SSL	Drošligzdu slānis (no angļu val.- Secure Sockets Layer)
TS	Tehniskā specifikācija
ŪKTUS	SIA “Rīgas ūdens” ūdensvada un kanalizācijas traucējumu uzskaites sistēma

Esošās situācijas raksturojums

Sabiedrība ar ierobežotu atbildību „Rīgas ūdens” (turpmāk – Pasūtītājs, RŪ) ir Latvijas Republikas Uzņēmumu reģistrā reģistrēts Rīgas pilsētas pašvaldības uzņēmums, kas dibināts, lai nodrošinātu centralizētus ūdensapgādes un kanalizācijas pakalpojumus Rīgas pilsētā. RŪ ir lielākais centralizēto ūdensapgādes un kanalizācijas pakalpojumu sniedzējs Latvijā un vienīgais Rīgā, kas nodrošina rīdziniekus ar kvalitatīvu dzeramo ūdeni, kā arī nodrošina notekūdeņu pārvadi un attīrīšanu.

Pasūtītāja attīstības virzieni gan īstermiņā, gan vidējā termiņā un ilgtermiņā ir:

• infrastruktūra – ūdenssaimniecības infrastruktūras tehnoloģiskās modernizācijas nodrošināšana (x.xx. tīklu infrastruktūras atjaunošana un jauno tīklu izbūve);

• tehnoloģiskā attīstība – tehnoloģiju modernizēšana un pilnveide, elektrosistēmu centralizēta pārvaldīšana, inteliģentu vadības un ekspertu sistēmu nodrošināšana un efektīva resursu pārvaldes modeļa ieviešana;

• klientu apkalpošana un pakalpojumu sniegšana – klientu apkalpošanas procesa centralizācija, elastīga, mērķtiecīga un uz rezultātiem balstīta materiālu resursu vadība un plānošana, sistemātiska un augstāk kvalificēta personāla apmācība;

• efektivitātes uzlabošana – uzņēmuma saimnieciskās darbības, x.xx. strādājošo darba efektivitātes paaugstināšana, nekustamo īpašumu apsaimniekošanas modeļa pilnveide, enerģijas efektivitātes paaugstināšana un vides aizsardzības veicināšana.

Viena no RŪ prioritātēm, kas ir saistīta ar mārketinga kanālu attīstību, ir WEB klientu portāla (turpmāk – Portāls, Sistēma) izstrāde. Portāla izveide, kas apvienos gan iespēju nodot komercuzskaites mēraparāta (turpmāk – KUM) rādījumus, gan vienuviet apkopos informāciju par maksājumu vēsturi un KUM rādījumiem, samazinās gan klientu apkalpošanas centra un zvanu centra noslodzi, gan kļūs par platformu, lai efektīvāk nodrošinātu komunikāciju ar klientu. Šāda portāla izveide, kurā klientam būtu iespēja ērti mainīt savu kontaktinformāciju arī atrisinātu līdzšinējās problēmas, kas saistītas ar klientu kontaktinformācijas nepietiekamu atjaunotni.

Lai nodrošinātu mērķu sasniegšanu Portāla funkcionalitāte paredz:

1 xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxx_Xxxx

• klientu autentificēšanos un autorizāciju;

• klientu reģistrācijas un sadarbības uzsākšanas procesu (līgumu slēgšanu);

• klientu informācijas uzturēšanu;

• patēriņa rādītāju nodošanu un pārbaudi;

• rēķinu informācijas piegādes procesu;

• rēķinu apmaksas procesu;

• komunikāciju starp klientu un pakalpojumu sniedzēju;

• ērtu sabiedrības informēšanu par bojājumiem un plānotajiem remontdarbiem.

Lai nodrošinātu Portāla darbību, tiek plānota tā integrācija ar šādām Pasūtītāja informācijas sistēmām:

• Elektroniskā dokumentu uzskaites sistēma (turpmāk – EDUS);

• Resursu vadības sistēma, kas nodrošina grāmatvedības uzskaiti un finanšu vadību, klientu uzskaiti un noliktavas pārvaldību (turpmāk – HORIZON);

• RŪ Ģeogrāfiskā informācijas sistēma (turpmāk – ĢIS);

• Esošais Rīgas ūdens portāls xxx.xxxxxxxxxx.xx.

EDUS

EDUS ir dokumentu uzskaites sistēma. Kopš 2010. gada, kad šī sistēma ir ieviesta, EDUS nodrošina vienotu elektronisko dokumentu uzskaiti un reģistrāciju (izņemot personāla dokumentus un līgumus ar klientiem par pilsētas ūdensvada un/vai kanalizācijas lietošanu). Biznesa procesu efektīvākai norisei EDUS integrēta ar HORIZON. Šī sistēma tiek izmantota, lai apstrādātu Pasūtītājam adresētos klientu un sabiedrības pieprasījumus. EDUS tiek izmantots darba plūsmas veidošanai un pārvaldīšanai, nodrošina pārskatus par saņemtajiem un uzdotajiem uzdevumiem, nodrošina darbības ar dokumentiem (piemēram, rezolūciju veidošana), kā arī atbalsta standarta e-pasta atbildes formu izveidi un izsūtīšanu.

Lai mazinātu uzņēmuma administratīvo slogu un veicinātu procesu automatizāciju klientu iesniegumu apstrādē, ir jāveido Portāla sasaiste ar EDUS, nodrošinot automatizētu Portālā iesniegto formu un ziņojumu nodošanu EDUS atbilstoši 3. nodaļā definētajiem procesiem (skat. prasību NFP-58).

HORIZON

HORIZON ir uzņēmuma resursu vadības un grāmatvedības sistēma, kas nodrošina vienotu finanšu, materiālo un cilvēkresursu uzskaiti un pārvaldību. Šobrīd ir veikti nozīmīgi sistēmas funkcionalitātes uzlabojumi, integrējot sistēmu EDUS. Uzņēmums šajā sistēmā fiksē visu ar klientiem saistīto informāciju (piemēram, sagatavē esošie un noslēgtie līgumi, objekti, KUM un KUM rādījumi, klientu kontaktinformācija, utt.). HORIZON nodrošina arī rādījumu uzskaiti, rēķinu izrakstīšanas funkcionalitāti un parādu uzskaiti.

Lai pilnveidotu un automatizētu KUM rādījumu nodošanas, kā arī rēķinu saņemšanas funkcionalitāti, paredzēts veidot Portāla integrāciju ar HORIZON (skat. prasību NFP-57).

ĢIS

ĢIS ir uzņēmuma ģeogrāfiskā informācijas sistēma, kas apkopo ūdensvadu un kanalizācijas tīklu ģeotelpisko datu/karšu informāciju. Tā ir saistīta ar Valsts zemes dienesta, RŪ adrešu reģistru, Latvijas Ģeotelpiskās informācijas aģentūras IS un Rīgas domes IS.

Lai automatizētu uzņēmuma procesus un piedāvātu klientiem ērtāku bojājumu informācijas ziņošanas veidu, kā arī nodrošinātu jauna pakalpojuma funkcionalitāti, kas saistīta ar pieteikšanos paziņojumu saņemšanai par plānotajiem remontdarbiem vai bojājumiem, kuru rezultātā var tikt novēroti pakalpojuma pārtraukumi, paredzēts veidot saskarni starp Portālu un ĢIS (skat. prasību NFP-59).

Rīgas ūdens tīmekļa vietne xxx.xxxxxxxxxx.xx

Šobrīd Pasūtītājam jau ir izveidota tīmekļa vietne. Šajā vietnē pieejama informācija par uzņēmuma aktualitātēm un paziņojumiem presei, par uzņēmuma pārvaldību, mērķiem, darbību, finanšu rādītājiem, izsludinātajiem iepirkumiem, izsolēm un vakancēm, bojājumu pieteikšanas un pakalpojumu pieejamības informācija, klientu apkalpošanas centra un citu struktūrvienību kontaktinformācija un darba laiki, kā arī lejupielādei pieejamas virkne elektronisku formu.

Pasūtītājs vēlas saglabāt esošo tīmekļa vietni un daļu no šobrīd tīmekļa vietnē pieejamās informācijas un funkcionalitātes pilnveidot un izstrādāt Portālā.

Klientu portāls

EDUS

Tīmekļa vietne

xxx.xxxxxxxxxx.xx

HORIZON

ŪKTUS

Pasūtītājs apņemas izpildītāju nodrošināt ar Rīgas ūdens izmantotajām IS, to datu apmaiņas protokoliem un citu tehnisko informāciju. Projektā iecerētās starpsistēmu saskarnes attēlotas IS nākotnes arhitektūrā (skat. 1. attēls).

RŪ ĢIS

Projektā paredzēta integrācija

Esoša integrācija

1. attēls. Rīgas ūdens izmantoto IS nākotnes arhitektūra.

Esošās infrastruktūras apraksts

Pasūtītāja infrastruktūrā ir uzstādīta IBM H šasija ar 12 gab. HS22 IBM asmens serveriem (Type 7870). 2.

tabulā un 3. tabulā aprakstīts serveru operatīvās atmiņas apjoms un serveru procesori un to noslodze.

2. tabula. Pasūtītāja asmens serveru izmantotais un pieejamais operatīvās atmiņas apjoms.

Asmens servera nosaukums	Izmantotais operatīvās atmiņas (RAM) apjoms, %	Pieejamais operatīvās atmiņas apjoms, GB
Blade01	72	7,84
Blade03	23	36,96
Blade06	75	18
Blade07	81	13,68
Blade08	55	32,4
Blade09	50	36
Blade10	81	13,68
Blade11	58	20,16
Blade12	64	17,28
Blade13	54	22,08
Blade14	74	6,24

3. tabula. Pasūtītāja asmens serveru procesori un to noslodze.

Nosaukums	Procesora (CPU) modelis	Takts fekvence, MHz	Procesora kodolu skaits	Procesora pavedienu (threads) skaits	Procesora šī brīža noslodze, %
Blade01	Intel Xeon E5620	2 400	4	8	3

Nosaukums	Procesora (CPU) modelis	Takts fekvence, MHz	Procesora kodolu skaits	Procesora pavedienu (threads) skaits	Procesora šī brīža noslodze, %
Blade03	Intel Xeon E5620	2 400	4	8	2
Blade06	Intel Xeon E5649	2 533	6	12	16
Blade07	Intel Xeon E5649	2 533	6	12	2
Blade08	Intel Xeon E5649	2 533	6	12	21
Blade09	Intel Xeon E5649	2 533	6	12	11
Blade10	Intel Xeon E5649	2 533	6	12	8
Blade11	Intel Xeon E5649	2 533	6	12	24
Blade12	Intel Xeon E5649	2 533	6	12	2
Blade13	Intel Xeon E5649	2 533	6	12	2
Blade14	Intel Xeon E5649	2 533	6	12	1

Pasūtītāja produkcijas vidē tiek darbināts IBM V3700 SAN disku masīvs - IBM System Storage V3700 SFF

Dual Controller (Type 2072 Model 24C), kurā uzstādīti:

• 24 gab. diski ar datu ietilpību 600GB un maksimālo diska apgriezienu skaitu minūtē 10000. Diski izvietoti neatkarīgu disku redundantā kārtojumā RAID 10. Kopējā piejamā disku vieta 6 TB, atvēlātā diska vieta - 5 TB.

• 12.gab diski ar datu ietilpību 3TB un maksimālo diska apgriezienu skaitu minūtē 7200. Diski izvietoti neatkarīgu disku redundantā kārtojumā RAID 6. Kopējā piejamā disku vieta 24,42TB, šobrīd atvēlātā diska vieta - 18,35 TB.

Sīkāk par katru no diska masīviem skatīt 4. tablulā.

4. tabula. Pasūtītāja disku masīvā pieejamā vieta.

Disku masīva nosaukums	Kopējais fiziskais disku apjoms, GB	Atvēlētā disku vieta, GB	Izmantotā diska vieta, MB	Pieejamā diska vieta, GB
xx01	1 740	1 683	1 683	56,19
xx02	2 980	2 694	2 694	279,63
Fast1	1 048	948	948	97,39
Fast2	1 048	1 570	942	102,92
Fast3	460	310	294	161,83
Mega1	3 145	1 641	1 421	1683,09
Mega2	3 669	3 218	3 218	440,61
Mega3	3 145	2 299	2 212	910,74
Mega4	3 145	2 074	1 836	1278,76
Mega5	3 145	768	634	2452,47

Disku masīva nosaukums	Kopējais fiziskais disku apjoms, GB	Atvēlētā disku vieta, GB	Izmantotā diska vieta, MB	Pieejamā diska vieta, GB
			Kopā	7463,63

Virtualizācijai tiek izmantots VMWare ESXi 5.5.0, vCenter 6.0.0, kas licencēts uz esošo asmens serveru apjomu un jaudu. Virtualizācijai uz virtuālajiem serveriem ir uzstādītas un tiek izmantotas 40 MS Windows Server licences un 30 Red Hat Enterprise Linux licences.

Dokumenta mērķis un konteksts

Šī dokumenta mērķis ir definēt augsta līmeņa funkcionālās, nefunkcionālās, integrācijas un piegādes prasības Pasūtītāja Portāla izstrādei un ieviešanai. Tehniskā specifikācija izmantojama piedāvājumu izstrādei un izvērtēšanai, Iepirkuma līguma slēgšanai, kā arī detalizētas programmatūras dokumentācijas izstrādei.

Pēc iepirkuma procedūras noslēgšanās dokuments ir saistošs iepirkuma uzvarētājam (turpmāk - Izpildītājam), lai nodrošinātu piedāvāto pakalpojumu piegādes atbilstību prasībām. Pasūtītājam un Pasūtītāja pieaicinātiem trešās puses pārstāvjiem dokuments ir saistošs, lai pārbaudītu sniegto pakalpojumu atbilstību dokumentā noteiktajām kvalitātes prasībām.

Saistītie dokumenti

Zemāk norādīti saistošie dokumenti obligātai ievērošanai izstrādes laikā, kas Xxxxxxxxx procesa laikā ir pieejami pie Pasūtītāja pēc pieprasījuma un tiks izsniegti Izstrādātājam:

• SIA “Rīgas ūdens” Uzņēmuma stila lietošanas kartība”;

• HORIZON Lietotāja dokumentācija;

• EDUS izstrādes dokumentācija;

• ĢIS izstrādes dokumentācija.

Normatīvie akti, kuri jāievēro, veicot Portāla izstrādi

Normatīvie akti, kuri jāievēro, veicot Portāla izstrādi:

• Informācijas atklātības likums;

• Publisko iepirkumu likums;

• Fizisko personu datu aizsardzības likums;

• Eiropas Parlamenta un Padomes 2016. gada 27. aprīļa regula (Es) 2016/679 par fizisku personu aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti un ar ko atceļ Direktīvu 95/46/EK (Vispārīgā datu aizsardzības regula);

• Likums „Par sabiedrisko pakalpojumu regulatoriem”;

• Publiskas personas kapitāla daļu un kapitālsabiedrību pārvaldības likums;

• Rīgas domes 2004. gada 30. novembra lēmums Nr.3674 "Par ūdensapgādes un kanalizācijas pakalpojumu patēriņa normām, ja uzskaite netiek veikta ar ūdens patēriņa skaitītājiem, kā arī atsevišķu Rīgas domes lēmumu atzīšanu par spēku zaudējušiem”;

• Rīgas domes saistošie noteikumi Nr.39 „Rīgas ūdensvada un kanalizācijas tīklu un būvju ekspluatācijas, lietošanas un aizsardzības noteikumi”;

• Patērētāju tiesību aizsardzības likums;

• Dokumentu juridiskā spēka likums;

• Elektronisko dokumentu likums;

• Dokumentu un arhīvu pārvaldības noteikumi;

• Elektronisko dokumentu izstrādāšanas, noformēšanas, glabāšanas un aprites kārtība valsts un pašvaldību iestādēs un kārtība, kādā notiek elektronisko dokumentu aprite starp valsts un pašvaldību iestādēm vai starp šīm iestādēm un fiziskajām un juridiskajām personām;

• Ūdenssaimniecības pakalpojumu likums;

• Ministru kabineta 2016. gada 22. martā pieņemtie noteikumi Nr.174 “Noteikumi par sabiedrisko ūdenssaimniecības pakalpojumu sniegšanu un lietošanu”;

• Dzīvojamo māju pārvaldīšanas likums;

• Dzīvokļa īpašuma likums.

Pieņēmumi un ierobežojumi

Dokuments ir sagatavots, ņemot vērā šādus pieņēmumus un ierobežojumus:

• dokuments ir sagatavots 2017. gada februārī un raksturo situāciju konkrētajā brīdī;

• dokumentā ietvertās prasības var tikt precizētas izstrādes procesa laikā, ja šīs izmaiņas nemaina kopējo darbu apjomu vairāk kā to pieļauj iepirkuma un Pasūtītāja definētie nosacījumi.

Portāla prasību apraksts

Funkcionālās prasības

Vispārējās funkcionālās prasības

Vispārējās funkcionālās prasības nosaka, kādus procesus Portālam jāatbalsta. Pie katras prasības pievienotas norādes uz atbilstošām detalizētām funkcionālajām prasībām. Vispārējā prasība uzskatāma par izpildītu, ja visas saistītās funkcionālās prasības izpildītas veidā, kas nodrošina vispārējās prasības izpildi.

5. tabula. Portāla procesu atbalsts.

Nr.	Prasība	Apraksts
FP-1	Patēriņa rādījumu nodošana un apstrāde	Jānodrošina Portāla funkcionalitāte patēriņa rādījumu nodošanai un apstrādei atbilstoši nodaļā 3.1. ietvertajam procesa aprakstam.
FP-2	Līgumattiecību vadība	Jānodrošina Portāla funkcionalitāte līgumattiecību pārvaldībai un attēlošanai atbilstoši nodaļā 3.2. ietvertajam procesa aprakstam.
FP-3	Klientu kontu vadība	Jānodrošina Portāla funkcionalitāte kontu pārvaldībai atbilstoši nodaļā 3.3. ietvertajam procesa aprakstam.
FP-4	Rēķinu gatavošana un koriģēšana	Jānodrošina Portāla funkcionalitāte rēķinu izveides un koriģēšanas attēlošanai atbilstoši nodaļā 3.4. ietvertajam procesa aprakstam.
FP-5	Rēķinu apmaksas kontrole	Jānodrošina Portāla funkcionalitāte rēķinu apmaksai un attēlošanai atbilstoši nodaļā 3.5. ietvertajam procesa aprakstam.
FP-6	Citu pakalpojumu pieteikšana	Jānodrošina Portāla funkcionalitāte citu pakalpojumu pieteikšanai un attēlošanai atbilstoši nodaļā 3.6. ietvertajam procesa aprakstam.
FP-7	Būvniecības dokumentācijas saskaņošana un izsniegšana	Jānodrošina Portāla funkcionalitāte tehnisko dokumentu izsniegšanas un saskaņošanas pieteikšanai un attēlošanai atbilstoši nodaļā 3.7. ietvertajam procesa aprakstam.
FP-8	Pieteikšanās informācijas saņemšanai par pakalpojumu darbības pārtraukumiem	Jānodrošina Portāla funkcionalitāte, lai pieteiktos ziņojumu saņemšanai par pakalpojumu darbības pārtraukumiem, atbilstoši nodaļā 3.8.1. ietvertajam procesa aprakstam.
FP-9	Bojājumu pieteikšana	Jānodrošina Portāla funkcionalitāte bojājumu pieteikšanai un attēlošanai atbilstoši nodaļā 3.8.2. ietvertajam procesa aprakstam.
FP-10	Izmaiņas saistītajās sistēmās portāla procesu atbalstam	Ja Pasūtītāja izmantoto saistītās sistēmas Ģeogrāfiskās Informācijas Sistēma (ĢIS), Finanšu uzsakaites sistēma Horizon un dokumentu vadības sistēma EDUS nenodrošina FP-1 - FP-9 prasībās minēto procesu, 0 un 0 nodaļā minēto prasību atbalstam nepieciešamo funkcionalitāti un datu apmaiņas interfeisus, tad, Pretendentam ir jānodrošina nepieciešamo pielāgojumu veikšana šajās saistītajās IS. Izmaiņu izstrāde saistītajās sistēmās veicama ņemot vērā TS sadaļā 0 noteiktās Organizatoriskās prasības kā arī sadaļā 0 Saistītie dokumenti minēto sistēmu izstrādes dokumentāciju.

Lietotāju saskarņu funkcionālās prasības

6. tabula. Lietotāju saskarņu atbalsts.

Nr.	Prasība	Apraksts
FP-11	Klientu portāla saskarne	Jāizveido lietotāja klientu Portāla saskarne, kas nodrošina aprakstīto procesu darbības atbalstu (skat. 3. nodaļa). Atbilstoši procesiem klientu portāla saskarnē Portālā autorizētiem lietotājiem jāparedz funkcionalitāte vismaz šādu darbību veikšanai: 1. Aplūkot un ziņot KUM rādījumus; 2. Aplūkot un lejupielādēt maksājumu un patēriņa pārskatus; 3. Aplūkot līgumus un veikt ar tiem saistītās informācijas pārvaldīšanu, x.xx. veikt sagatavoto līgumu parakstīšanu ar elektronisko parakstu; 4. Saņemt, aplūkot rēķinus un veikt to apmaksu;

Nr.	Prasība	Apraksts
		5. Pieteikt izmaiņas piemērotajā ūdens patēriņa normas aprēķinā; 6. Pieteikt izmaiņas norēķinu cikla regularitātē; 7. Aplūkot un rediģēt klienta profila informāciju; 8. Izveidot un iesniegt pieteikumu vai iesniegumu saistībā ar vismaz šādiem procesiem: a. līgumattiecību pārvaldība (iesniegums līgumattiecību slēgšanai, iesniegums līgumattiecību grozīšanai vai pagarināšanai, iesniegum līgumattiecību pārtraukšanai), b. citu maksas pakalpojumu pieteikšana; c. tehniskās dokumentācijas izsniegšanas vai saskaņošanas pieteikšana. 9. Pārvaldīt klienta konta lietotājus un deleģēt tiem funkcijas; 10. Pieteikt bojājumu un sūdzību ziņojumus; 11. Aplūkot un rediģēt vēlamos saziņas kanālus un saņemto paziņojumu veidus; 12. Saņemt paziņojumus un brīdinājumus; 13. Aplūkot bojājumu karti; 14. Pieteikt pārstāvju ierašanos (rakšanas darbiem). Portāla publiskajā daļā jāparedz funkcionalitāte vismaz šādu darbību veikšanai: 1. Izveidot un iesniegt pieteikumu vai iesniegumu saistībā ar vismaz šādiem procesiem, klientam autentificējoties (skat. prasību NFP-13NFP-14): a. Līgumattiecību pārvaldība (iesniegums līgumattiecību slēgšanai); b. Citu maksas pakalpojumu pieteikšana; c. Tehniskās dokumentācijas izsniegšanas vai saskaņošanas pieteikšana; d. Pieteikt pārstāvju ierašanos (rakšanas darbiem). 2. Izveidot un iesniegt bojājumu un sūdzību ziņojumus; 3. Pieteikties paziņojumu saņemšanai par bojājumiem un pakalpojumu nodrošināšanas pārtraukumiem; 4. Aplūkot bojājumu karti. Izstrādātajai funkcionalitātei jābūt savietojamai ar un integrējamai esošajā Pasūtītāja tīmekļa vietnē xxx.xxxxxxxxxx.xx. Portālā lietotajiem pieejamās funkcionalitātes saraksti var tikt mainīti vai papildināti Portāla izstrādes laikā, ja tas ir nepieciešams iekšējo normatīvo aktu vai citu dokumentu izmaiņu dēļ (skat. nodaļu 2.2.8. Integrācijas prasības).
FP-12	Administrēšanas saskarne	Jāizveido klientu portāla administrēšanas saskarne administrēšanas funkcionālo prasību izpildei (skat. nodaļu 2.1.5. Administrēšanas funkcionālās un saskarnes prasības).
FP-13	Saskarņu dizaina prasības	Portāla saskarņu dizains jāizstrādā ievērojot lietojamības un grafiskā dizaina tendences, Pasūtītāja stila grāmatu un Pasūtītāja esošo mājas lapu. Portāla saskarnes jāizstrādā, ņemot vērā grafiskā stila vadlīnijas (skat. 3. nodaļa). Izveidotās tīmekļa vienes dizainam jābūt testējamam, tas ir, dizaina pamatelementiem jābūt viennozīmīgi un standartizēti definētiem. Portāla sadaļām jābūt veidotām vizuāli pievilcīgām un ērti lietojamām, vienlaikus nodrošinot to, ka apmeklētāji informāciju uztver ne tikai ar tekstuālās informācijas, bet arī ar vizuālo elementu palīdzību. Jānodrošina dizaina atbilstība World Wide Web Consortium (turpmāk - W3C) uzturētajām pēdējām Cascading Style Sheets (turpmāk – CSS), HyperText Markup Language (turpmāk – HTML) vai Extensible Hypertext Markup Language (turpmāk – XHTML) standartu versijām.

Nr.	Prasība	Apraksts
		Grafiskajos dizainos izvēlētās interaktīvās tehnoloģijas nedrīkst traucēt mājaslapas veiktspēju.

Portāla saskarnes funkcionālās prasības

7.tabula. Portāla saskarnes funkcionālās prasības.

Nr.	Prasība	Apraksts
FP-14	KUM rādījumu ziņošana	Izstrādājot lietotāja saskarnes KUM ziņošanai, jāņem vērā rādījumu nodošanas ērtums un jāparedz atsevišķas saskarnes: 1. Klientiem, kuriem jāziņo KUM rādījumi par vienu objektu; 2. Klientiem, kuriem jāziņo KUM rādījumi par vienu objektu, kur uzstādīti vairāki KUM; 3. Klientiem, kuriem jāziņo KUM rādījumi par diviem un vairāk objektiem. Izšķir divus KUM veidus: 1. Parastie KUM. Izpildītājam jāparedz mehānisms KUM rādījumu ziņošanas iespējošanai un atspējošanai atbilstoši aprakstītajiem procesiem, nodrošinot, ka viena rādījuma nodošanas perioda ietvaros KUM rādījumus nevar ievadīt atkārtoti (skat. nodaļa 3.1.). 2. Viedie KUM. Izpildītājam jānodrošina KUM rādījumu ziņošanas funkcionalitātes atspējošana Portālā klientiem, kuriem ir uzstādīti šī tipa KUM. Portālam jānodrošina patēriņa apjoma aprēķināšana un atspoguļošana Portālā uzreiz pēc tam, kad klients ievadījis KUM rādījumu, ņemot vērā klienta noziņoto rādījumu un iepriekšējā perioda saglabāto rādījumu.
FP-15	Masveida KUM rādījumu datu ielāde	Jānodrošina KUM rādītāju datu importu no strukturētiem teksta failiem šādos formātos: 1. Comma-separated Values Format (CSV); 2. eXtensible Markup Language Format (XML). Portālam jānodrošina funkcionalitāte dažādu CSV failu kodējuma apstrādei, nodrošinot iespēju lietotājam iesniegt datus ar dažādiem norobežotājiem (delimiter) un komtata atdalītājiem (separator). Jānodrošina Portāla funkcionalitāte KUM rādītāju datu ielādei no Microsoft Excel izklājlapām (turpmāk - XLSX).
FP-16	Datu ielādes kļūdu pārbaudes	Nodrošināt kļūdu apstrādi un lietotāja informēšanu gadījumā, ja ir pārkāpti obligātie datu validācijas nosacījumi vai radušās citas problēmas. Obligātie validācijas nosacījumi – norādīts klienta numurs, līguma numurs, KUM numurs un rādījums.
FP-17	Rādījumu ievades pārbaudes	Pēc rādītājuma ievadīšanas, Portālam ir jānodrošina patēriņa vērtības atspoguļošana ar iespēju klientam vērtību atkārtoti pārbaudīt un apstiprināt rādījuma vērtību. Portālam jānodrošina klienta ievadīto un apstiprināto KUM rādījumu vērtību validācija pret iepriekš definētiem svārstību apgabaliem. Ņemot vērā KUM rādījumu vērtību validācijas rezultātus, Portālam jāveic šādas darbības: 1. Ja rādījuma vērtība atbilst pieļaujamajiem svārstību apgabaliem, Portālam jānodrošina noziņotā rādījuma un patēriņa saglabāšana. 2. Ja rādījuma vērtība ir augstāka nekā pieļaujamais svārstību apgabals, Portālam jānodrošina: - paziņojuma attēlošana par to, ka klientam atkārtoti jāapstiprina ievadītā rādījuma vērtība, jo patēriņa vērtība ir lielāka kā klienta iepriekš vidēji ziņotais patēriņš;

Nr. Prasība Apraksts
		- iespēja klientam labot vai atkārtoti apstiprināt rādījuma vērtību; - pēc vērtības atkārtotas apstiprināšanas, Portālam jānodrošina noziņotā rādījuma un patēriņa vērtības saglabāšana. 3. Gadījumos, kad rādījuma vērtība ir zemāka nekā pieļaujamais svārstību apgabals, Portālam jānodrošina: - paziņojuma attēlošana par to, ka ziņotais patēriņš ir zemāks nekā klienta vidēji ziņotais patēriņš; - iespēja klientam labot rādījuma vērtību vai ievadīt komentāru par iespējamiem iemesliem. - pēc vērtības atkārtotas apstiprināšanas, Portālam jānodrošina noziņotā rādījuma un patēriņa vērtības saglabāšana HORIZON ar norādi pārbaudes veikšanai. Portālam jānodrošina klasificēta iemesla izvēle kā obligāts priekšnoteikums rādījuma vērtības atkārtotai apstiprināšanai, ar iespēju klientam ievadīt komentāru brīvā tekstā. Portālam jānodrošina, ka rādījuma atkārtota ievade vai labošana pēc rādījuma saglabāšanas vairs nav iespējama.
FP-18	Rēķinu saņemšana un skatīšana	Portālam jānodrošina iespēju klientam saņemt un aplūkot rēķinus un to raksturojošo informāciju, kas ģenerēti atbilstoši nodotajiem KUM rādījumiem vai ģenerēti citā līgumā starp Pasūtītāju un Klientu atrunātā kārtībā. Klientam izrakstītajiem rēķiniem jābūt aplūkojamiem atsevišķā Portāla sadaļā, nodrošinot vismaz šādu informāciju par katru no rēķiniem: 1. Rēķina numurs; 2. Periods, par kuru rēķins sastādīts; 3. Apmaksas termiņš; 4. Rēķina summa; 5. Laiks, kurā veikts maksājums; 6. Apmaksātā summa.
FP-19	Rēķinu lejupielāde	Portālā jānodrošina iespēja aplūkot un lejupielādēt rēķinu datnes Portable Document Format (turpmāk - PDF) formātā.
FP-20	Rēķinu apmaksa	Jānodrošina iespēju klientam veikt rēķinu apmaksu, izmantojot interneta banku. Izpildītājam Portālā jānodrošina saskarne, kas ļauj izvēlēties no izrakstīto un neapmaksāto rēķinu saraksta tos, par kuriem klients vēlas veikt apmaksu. Izpildītājam jāparedz funkcionalitāte visu vai daļas rēķinu apmaksai.
FP-21	Līgumu pārvaldība	Portālā jānodrošina līgumu un ar tiem saistītās informācijas piesaiste klientu kontiem (detalizētu funkcionalitātes aprakstu skat. nodaļā 3.3.1. un nodaļā 2.2.8.). Portālā jānodrošina iespēja Klientam aplūkot savus līgumus un ar tiem saistīto informāciju, iekļaujot, bet neaprobežojoties ar: 1. Līgumu ietvaros pieslēgtiem objektiem; 2. Objektu adresēm; 3. Uzstādītiem KUM; 4. Līgumu slēgšanas datumiem; 5. Pakalpojumu cenām un apmaksas nosacījumiem. Līgumu pārvaldības ietvaros jānodrošina funkcionalitāte šādas informācijas apskatīšanai un rediģēšanai (ja tas iespējams Pasūtītāja un Klienta noslēgtā līguma ietvaros): 1. Rēķina saņemšanas veids; 2. Korespondences adrese; 3. E-pasta adrese;

Nr. Prasība Apraksts
		4. Kontakttālrunis; 5. Norēķinu cikla regularitāte.
FP-22	Klienta profila informācija	Portālā jānodrošina iespēja uzturēt, labot, saglabāt un nodot citām sistēmām Klientu raksturojošos datus. Klienta kartiņā jāiekļauj vismaz šādi dati: 1. Klienta nosaukums; 2. Līguma slēdzēja vārds, uzvārds; 3. Pilnvaroto personu vārdi, uzvārdi; 4. Juridiskā un faktiskā adrese (korespondences adrese); 5. E-pasta adrese; 6. Kontakttālrunis; 7. Dokumenta, uz kura pamata darbojas persona/organizācija, kopija, reģistrācijas nr., izdošanas datums.
FP-23	Lietotāju pārvaldība	Portālam jānodrošina iespēja Klienta konta galvenajam lietotājam veidot sava konta apakškontus, tādejādi deleģējot tiesības citiem lietotājiem veikt konkrētas darbības Portālā klienta vārdā. Jānodrošina iespēja tiesības deleģēt par vienu vai vairākām adresēm, objektiem, līgumiem. Portālam jānodrošina vismaz šādu tiesību deleģēšanas iespējamība: 1. Aplūkot KUM rādījumus; 2. Nodot izvēlēto KUM rādījumus; 3. Aplūkot rēķinus; 4. Apmaksāt rēķinus; 5. Aplūkot līguma informāciju; 6. Labot līguma informāciju (x.xx. mainīt norēķinu cikla regularitāti).
FP-24	Bojājumu un sūdzību ziņojumu pieteikšana	Portālam jānodrošina iespēja lietotājiem izveidot un iesniegt bojājumu/ sūdzību ziņojumus. Ziņojot par bojājumu, Portāla apmeklētājam jāspēj aizpildīt elektroniska forma, norādot vismaz šādu informāciju: 1. Adrese no adrešu klasifikatora vai koordinātas no punkta kartē; 2. Komentārs par bojājumu; 3. Bojājuma tips no klasifikatora. Jāparedz iespēja ziņojumam pievienot attēlu (x.xx. no mobilajām ierīcēm).
FP-25	Maksājumu un patēriņa pārskati	Portālā jānodrošina pārskats par klienta vai klienta deleģētu pārstāvju ziņoto ūdens patēriņu, izrakstītajiem rēķiniem un apmaksātajām summām. Statistikas datiem jāattēlo tabulu un diagrammu formātā un jābūt attēlojamiem dažādos laika periodos (mēnesis, ceturksnis, gads). Visām atskaitēm, kuras tiek ģenerētas Portālā jānodrošina iespēju tās eksportēt XLSX, CSV un PDF formātā.
FP-26	Paziņojumi Portālā	Portāla administrēšanas saskarnē jānodrošina iespēja konfigurēt paziņojumus klientiem par Pasūtītāja Portālā ieviešamo procesu (skat. 3. nodaļa) soļu rezultātiem. Automātiski paziņojumi jārealizē kā paziņojumi Portāla Klientu sadaļā un automātiska paziņojumu nosūtīšana Portāla lietotāju (vai grupu) norādītajām e-pasta adresēm. Izpildītājam jānodrošina vismaz šādu Procesu paziņojumi par: 1. Atgādinājums par rādījuma nodošanu; 2. Brīdinājums par vairākkārt nenodotu rādījumu 3. Brīdinājums par maksājuma kavēšanu;

Nr.	Prasība	Apraksts
		4. Paziņojums par līguma statusa maiņu; 5. Paziņojums par iesnieguma statusa maiņu; 6. Paziņojums par pieteikuma RŪ pārstāvju izsaukšanai saņemšanu; 7. Paziņojums par klienta konta dzēšanas uzsākšanu; 8. Paziņojums par līguma termiņa beigu tuvošanos; 9. Paziņojums par līguma termiņa beigšanos un ar tā saistītās informācijas uzturēšanu Portālā; 10. Paziņojums par iesniegtas elektroniskas pieteikuma formas saņemšanu un tālākas izskatīšanas termiņiem; 11. Paziņojums par pieteikta bojājuma veiksmīgu piereģistrēšanu. Jāparedz iespēja Portāla autorizētajam lietotājam mainīt notifikāciju un atgādinājumu uzstādījumus, piemēram, izvēlēties saziņas kanālus, uz kuru tiek nosūtītas notifikācijas par notikumu vai cita veida informācija (sms vai e-pasts), pārvaldīt Portāla automātisko atgādinājumu par rādījumu iesniegšanu uzstādījumus. Portālam jānodrošina paziņojumu nosūtīšanas risinājumu to nosūtīšanai sms formātā, ņemot vērā klientu veikto izvēli par šādu paziņojumu saņemšanu mobilajā telefonā.

Pieteikumu izveide un iesniegšana

8. tabula. Dokumentu veidošanas un iesniegšanas funkcionālās prasības.

Nr.	Prasība	Apraksts
FP-27	Formu funkcionalitāte	Portālā jāparedz atsevišķu dokumentu formas (sagataves) atbilstoši 3. nodaļā aprakstītajiem procesiem. Izstrādātajām elektroniskajām formām jāsatur datu laukus, kurus daļu aizpilda Portāla lietotājs un laukus, kas tiek aizpildīti automātiski, izmantojot Portālā vai RŪ IS pieejamo informāciju, piemēram, objekta adrese, uzņēmuma reģistrācijas numurs u.c. informācija. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, adrešu klasifikators, kurā vērtības tiek ņemtas no RŪ adrešu reģistra vai klasifikators, kurā autentificētais lietotājs var izvēlēties, vai aizpilda formu kā fiziska vai kā juridiska persona. Autorizētiem lietotājiem, aizpildot dokumentu formas, jāparedz iesāktu, bet neiesniegtu formu saglabāšanu un rediģēšanu gadījumā, ja jebkādu apstākļu dēļ tiek pārtraukta esošā sesija. Jānodrošina lietotāja augšupielādēto datņu īslaicīga glabāšana. Jānodrošina tāds dokumentu elektronisko datņu saglabāšanas risinājums, lai pieaugošais pievienoto elektronisko datņu apjoms neietekmētu Portāla veiktspēju.
FP-28	Formu izveide	Izpildītājam Portālā jārealizē lietotājam saprotamas un ērti aizpildāmas formas, kas saturiski balstītas uz šobrīd RŪ izmantotajām formām2. No jauna izstrādātajām formām jāatbilst Pasūtītāja darbu reglamentējošajiem normatīvajiem aktiem (skat. nodaļu 0). Atbilstoši procesiem klientu portāla saskarnē, Portālā lietotājiem jābūt pieejamām vismaz šādām dokumentu formām, kas nodrošina juridisku un fizisku personu iesniegumu iesniegšanu: 1. Iesniegums līguma slēgšanai par ūdenssaimniecības pakalpojumu lietošanu; 2. Iesniegums līguma grozījumu vai pārslēgšanas pieteikšanai; 3. Iesniegums līgumattiecību pārtraukšanas pieteikšanai; 4. Forma citu maksas pakalpojumu pieteikšanai;

2 SIA “Rīgas ūdens” elektroniski pieejamās veidlapas. Pieejams: xxxxx://xxx.xxxxxxxxxx.xx/xxxxxxxxxxx/xxxxxxxxx/

Nr. Prasība Apraksts
		5. Iesniegums tehniskās dokumentācijas izsniegšanai vai saskaņošanai; 6. Forma pārstāvju izsaukšanai (rakšanas darbiem); 7. Iesniegums klienta datu maiņas pieteikšanai; 8. Forma ūdens patēriņa normu maiņas pieteikšanai; 9. Forma norēķinu cikla maiņas pieteikšanai; 10. Forma pirmreizējai konta reģistrēšanai; 11. Forma klienta datu ievadei konta reģistrēšanas laikā; 12. Forma bojājumu pieteikšanai. Iepriekš uzskaitīto formu elektroniskai iesniegšanai ir jānodrošina lietotāja autentifikācija, izmantojot pieejamos autentifikācijas veidus (skat. prasību NFP-13). Portāla publiskajā daļā jābūt pieejamām vismaz šādām formām: 1. Formas, kuru izveidei nepieciešams autentificēties (skat. prasību NFP-13): a. Iesniegums līguma slēgšanai par ūdenssaimniecības pakalpojumu lietošanu; b. Forma citu maksas pakalpojumu pieteikšanai; c. Iesniegums tehniskās dokumentācijas izsniegšanai vai saskaņošanai; d. Forma pārstāvju izsaukšanai (rakšanas darbiem); 2. Forma bojājumu pieteikšanai; 3. Forma, lai pieteiktos informācijas saņemšanai par pakalpojumu darbības pārtraukumiem. Formu saraksts var tikt mainīts vai papildināts Portāla izstrādes laikā.
FP-29	Teksta validācija un automātiska aizpildīšana	Izveidotajām formām un aizpildāmajiem laukiem jāveido automātiska ievadītā teksta validācija un automātiska aizpildīšana, piemēram, automātiski aizpildot uzņēmuma informāciju pēc reģistrācijas numura norādīšanas vai automātiski aizpildot datus par autentificēto personu (piemēram, vārds, uzvārds, personas kods) attiecīgajās sadaļās. Jānodrošina iespēja saglabāt dokumentu (iesniegumu) kā melnrakstu Portālā.
FP-30	Darbības ar formām	Administrēšanas saskarnē jāparedz iespēja veidot jaunas formas, mainīt esošās formas un dzēst formas. Mainot formu, tā tiek saglabāta kā atsevišķa, jauna forma, reģistrējot lietotāju un laiku, kad forma tikusi mainīta.
FP-30	Dokumentu pievienošana	Sistēmai jānodrošina, ka iesniegumam ir iespējams pievienot dokumentu elektroniskas kopijas. Sistēmai jānodrošina, ka iesnieguma formas iesniegšanu nav iespējams turpināt, pirms nav pievienoti tie dokumenti, kuri ir obligāti. Administrēšanas saskarnē jāparedz iespēja definēt maksimāli pieļaujamo augšupielādējamās datnes lielumu.
FP-31	Datņu formātu atbalsts	Portālam jāatbalsta šādi datņu formāti: 1. Portable Document Format (PDF); 2. Document File Format (DOC); 3. Plain Text Format (TXT); 4. Microsoft Excel Spreadsheet File Format (XLSX); 5. Portable Network Graphics (PNG); 6. Joint Photographic Experts Group (JPG, JPEG); 7. eXtensible Markup Language Format (XML); 8. Comma-separated Values Format (CSV); 9. eDokumentu formāts (eDOC); 10. Datorizētās projektēšanas formāti (DWG, DNG).

Nr. Prasība Apraksts
		Administrēšanas saskarnē jāparedz iespēja ierobežot un papildināt iesniedzamo dokumentu formātus.
FP-32	Iesnieguma apstrāde	Saistībā ar elektroniski aizpildītu formu reģistrēšanu, Portālam jānodrošina: - Iesnieguma unikāla identifikācijas numura un statusa piešķiršana iesniegumam par iesnieguma pieņemšanu izskatīšanā; šo elementu attēlošana Portālā; - Datu nosūtīšana uz EDUS par saņemto iesniegumu (skat. prasību NFP-58); - Iespēja klientam savā kontā piekļūt iesnieguma kopijai PDF formātā.
FP-33	Papildus dokumentu pievienošana	Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusa maiņu, kas norāda uz papildu dokumentu nepieciešamību (skat. prasību NFP-58). Portālam jānodrošina šī statusa attēlošana Portālā. Sistēmai jānodrošina automātiska paziņojuma izveide un attēlošana Portālā par papildus dokumentu nepieciešamību. Sistēmai jānodrošina iespēja pievienot elektroniskas dokumentu kopijas tiem iesniegumiem Portālā, kam statuss norāda uz papildus dokumentu nepieciešamību Sistēmai jāatbalsta PDF un elektroniski parakstītu failu pievienošana. Sistēmai jānodrošina statusa piešķiršana oriģinālajam iesniegumam par dokumentu pieņemšanu izskatīšanā un šī statusa attēlošana. Sistēmai jānodrošina datu nosūtīšana uz EDUS saistībā ar saņemto iesniegumu un tā statusu, norādot iesnieguma oriģinālo unikālo identifikācijas numuru (skat. prasību NFP-58). Administrēšanas saskarnē jāparedz iespēja definēt maksimāli pieļaujamo augšupielādējamās datnes lielumu.

Administrēšanas funkcionālās un saskarnes prasības

9. tabula. Administrēšanas funkcionālās prasības.

Nr.	Prasība	Apraksts
FP-34	Portāla uzturēšanas procesu atbalsts	Portālam ir jānodrošina šādu uzturēšanas procesu atbalsts: 1. Atskaišu iegūšana; 2. Portāla problēmu pārvaldība un kļūdu novēršana; 3. Lietotāju un tiesību pārvaldība; 4. Portāla darbības monitorings; 5. Portāla žurnalēšanas pierakstu analīze; 6. Portāla konfigurācijas un izmaiņu pārvaldība, versiju kontrole; 7. Portāla satura administrēšana; 8. Klientu apmierinātības (u.c. veida) aptaujas.
FP-35	Atskaišu iegūšana	Jānodrošina funkcionalitāte un lietotāja saskarne statistikas iegūšanai par Portāla pakalpojumu izmantošanu. Jānodrošina vismaz šāda Portāla apmeklētības statistika: 1. Apmeklējumu, apmeklētāju un apmeklēto lapu skaits pa dienām izvēlētā laika periodā (unikālo apmeklējumu skaits, kopējais apmeklējumu skaits, apmeklējumu intensitāte); 2. Vidējais apmeklētāja uzturēšanās laiks; 3. Interneta pārlūkprogrammas un ierīces, kuras izmanto Portāla apmeklētāji; 4. Lejupielādēto failu statistika pa dienām izvēlētā laika periodā; 5. Ienākošo saišu uzskaitījums un ienākošo apmeklējumu skaits pa dienām izvēlētā laika periodā.

Nr. Prasība Apraksts
		Portāla funkcionalitātei jāparedz iespēju pievienot/filtrēt konkrētas IP adreses, no kurām statistika netiek iekļauta konkrētā atskaitē. Statistikas datiem jābūt atspoguļojamiem tabulu un diagrammu formātā un jābūt attēlojamiem dažādos laika periodos (diena, nedēļa, mēnesis, gads). Visām atskaitēm, kuras tiek ģenerētas Portālā jānodrošina iespēju tās eksportēt XLSX un CSV formātā.
FP-36	Problēmu pieteikumu apstrāde	Jānodrošina funkcionalitāte un lietotāja saskarne problēmu pieteikumu apritei. Jānodrošina Portāla lietotājiem iespēja pieteikt problēmu par Portāla darbību.
FP-37	Lietotāju un tiesību pārvaldība	Jānodrošina funkcionalitāte un lietotāja saskarne Portāla sadaļu un funkcionalitātes izmantošanas tiesību pārvaldībai. Jānodrošina papildināms sākotnējais lietotāju lomu un grupu komplekts.
FP-38	Konta bloķēšanas un atbloķēšanas funkcionalitāte	Sistēmai jānodrošina konta bloķēšanas un atbloķēšanas funkcionalitāte Portāla administrēšanas saskarnē ar iespēju pievienot komentāru par konta bloķēšanas un atbloķēšanas iemesliem.
FP-39	Notikumu žurnalēšana	Jānodrošina sistēmas notikumu un lietotāju veikto darbību reģistrēšanu un lietotāja saskarne to apskatei. Lietotāja saskarnē ir jānodrošina notikumu kategorizēšanas un filtrēšanas iespējas. Jānodrošina žurnalēšanas ierakstu izveide, iekļaujot vismaz šādu informāciju: 1. Darbības veicējs; 2. Veiktā darbība; 3. Darbības izpildes rezultāts; 4. Veiktās darbības sākuma un beigu datums un laiks. Kļūdainas darbības gadījumā norādāms kļūdas kods, Portāla daļa, kurā radusies kļūdas situācija. Žurnalēšanas pierakstiem kļūdainas darbības jākategorizē atbilstoši to kritiskumam un nozīmei Portāla darbībā.
FP-40	Versiju kontrole	Jānodrošina funkcionalitāte un lietotāja saskarne versiju kontrolei.
FP-41	Notikumu auditācija	Jānodrošina funkcionalitāte un lietotāja saskarne auditācijas notikumu apstrādei. Portālā jāveido auditācijas pieraksti (log faili) par šādiem notikumiem: 1. Portāla lietotāju darbības; 2. Portāla lietotāju tiesību izmaiņas; 3. Pieprasījumu apstrādes sākuma un beigu laiks; 4. Portāla sistēmas kļūdas un izņēmumu situācijas (exceptions). Lietotāju saskarnē ir jānodrošina auditācijas notikumu kategorizēšanas un filtrēšanas iespējas. Jānodrošina iespēja veikt autitācijas pierakstu eksportu .xlsx un .csv formātā. Auditācijas pierakstiem jānodrošina kategorizēšana atbilstoši to kritiskumam un nozīmei.
FP-42	Portāla satura administrēšana	Jānodrošina lietotāja saskarne Portāla administratoru lietošanai. Saskarnei Portāla administratoram ir jānodrošina šāda funkcionalitāte: 1. Jānodrošina saskarne Portāla satura tulkošanai; Jānodrošina teksta pārskatīšana pirms tā publicēšanas.
FP-43	Klientu aptaujas	Portāla administrācijas saskarnē jānodrošina iespēju veidot aptaujas formas (x.xx. klienta apmierinātības aptauju formas) un nodrošināt to apstrādes funkcionalitāti.

Nr.	Prasība	Apraksts
		Aptauju veidošanai un pārvaldībai jāparedz vismaz šāda funkcionalitāte: 1. Aptaujas tipa noteikšana (anonīma, ne-anonīma); 2. Aptaujas jautājumu pievienošana, rediģēšana, dzēšana; 3. Aptaujas jautājuma tipa definēšana x.xx. izvēles rūtiņas (check box), datuma, nolaižamais lodziņš (dropdown box), teksta lodziņs, radio pogas (radio buttons); novērtējuma skalas, jā/nē tipa; 4. Aptaujas aizpildīšanas termiņa noteikšana; 5. Iespēja izvēlēties lietotājus vai lietotāju grupas, kuriem piedāvāt aizpildīt aptauju; Aptaujas rezultātu apskatīšana kā arī lejupielāde teksta formātā un datu apstrādes programmām piemērotā formātā.
FP-44	Pieslēgšanās klienta kontam	Tehnisku problēmu risināšanai Pasūtītāja Klientu apkalpošanas centra klientu atbalsta speciālistam jāparedz iespēju skatīšanās režīmā pieslēgties Portālam kā konkrētam klientam, lai sniegtu konsultāciju klientam problēmas novēršanai.

Saistīto sistēmu izstrādes prasības

10. tabula. Saistīto sistēmu prasības.

Nr.	Prasība	Apraksts
FP-45	Izmaiņu veikšana Horizon	Ja portāla izstrādē pretendents konstatē, ka pasūtītāja izmantotā Horizon sistēma nenodrošina FP-1 - FP-9 prasībās minēto procesu, 0 un 0 nodaļā minēto prasību atbalstam nepieciešamo funkcionalitāti, Pretendentam ir jānodrošina pielāgojumu veikšana šajās saistītajās sistēmās. Izmaiņu izstrāde veicama ņemot vērā šajā TS noteiktās 0 Organizatoriskās prasības kā arī 0 Saistītie dokumenti minēto sistēmu izstrādes dokumentāciju. Izmaiņu izstrāde, x.xx. izmaiņu nepieciešamības un apjoma noteikšana realizējama sadarbībā ar Horizon piegādātāju. Horizon piegādātājs ir apliecinājis pasūtītājam, ka ir gatavs veikt izmaiņas izstrādātajā sistēmā un nepieciešamo izmaiņu veikšanai visiem ieinteresētajiem piegādātājiem tiks piedāvāta vienāda stundas likme, savukārt veicamo izmaiņu darba apjomu cilvēkstundās nav iespējams novērtēt, jo darba apjoms ir atkarīgs no katra pretendenta izstrādātā piedāvājuma projekta realizācijai.
FP-46	Izmaiņu veikšana EDUS	Ja portāla izstrādē pretendents konstatē, ka pasūtītāja izmantotās EDUS sistēma nenodrošina FP-1 - FP-9 prasībās minēto procesu, 0 un 0 nodaļā minēto prasību atbalstam nepieciešamo funkcionalitāti, Pretendentam ir jānodrošina pielāgojumu veikšana šajās saistītajās sistēmās. Izmaiņu izstrāde veicama ņemot vērā šajā TS noteiktās 0 Organizatoriskās prasības kā arī 0 Saistītie dokumenti minēto sistēmu izstrādes dokumentāciju. Izmaiņu izstrāde, x.xx. izmaiņu nepieciešamības un apjoma noteikšana realizējama sadarbībā ar EDUS piegādātāju. EDUS piegādātājs ir apliecinājis pasūtītājam, ka ir gatavs veikt izmaiņas izstrādātajā sistēmā un nepieciešamo izmaiņu veikšanai visiem ieinteresētajiem piegādātājiem tiks piedāvāta vienāda stundas likme, savukārt veicamo izmaiņu darba apjomu cilvēkstundās nav iespējams novērtēt, jo darba apjoms ir atkarīgs no katra pretendenta izstrādātā piedāvājuma projekta realizācijai..
FP-47	Izmaiņu veikšana ĢIS	Ja portāla izstrādē pretendents konstatē, ka pasūtītāja izmantotās ĢIS sistēma nenodrošina FP-1 - FP-9 prasībās minēto procesu, 0 un 0 nodaļā minēto prasību atbalstam nepieciešamo funkcionalitāti, Pretendentam ir jānodrošina pielāgojumu veikšana šajās saistītajās sistēmās.

Nr.	Prasība	Apraksts
		Izmaiņu izstrāde veicama ņemot vērā šajā TS noteiktās 0 Organizatoriskās prasības kā arī 0 Saistītie dokumenti minēto sistēmu izstrādes dokumentāciju. Izmaiņu izstrāde, x.xx. izmaiņu nepieciešamības un apjoma noteikšana realizējama sadarbībā ar ĢIS piegādātāju. ĢIS piegādātājs ir apliecinājis pasūtītājam, ka ir gatavs veikt izmaiņas izstrādātajā sistēmā un nepieciešamo izmaiņu veikšanai visiem ieinteresētajiem piegādātājiem tiks piedāvāta vienāda stundas likme, savukārt veicamo izmaiņu darba apjomu cilvēkstundās nav iespējams novērtēt, jo darba apjoms ir atkarīgs no katra pretendenta izstrādātā piedāvājuma projekta realizācijai.

Nefunkcionālās prasības

Arhitektūras prasības

11. tabula. Arhitektūras prasības.

Nr.	Prasība	Apraksts
NFP	Arhitektūras uzbūve	Portāls realizējams kā atsevišķu komponenšu kopums (modulāra sistēma) visiem Portāla procesiem. Piedāvātajam risinājumam jānodrošina sistēmas papildināšana ar jauniem funkcionāliem moduļiem, neietekmējot esošos funkcionālos moduļus.
NFP	Sistēmas mērogojamība	Portāla arhitektūrai jābūt gan vertikāli, gan horizontāli mērogojamai. Izpildītājam arhitektūras izstrādē jāparedz risinājumi, kas nodrošinās Portāla veiktspējas palielināšanu, pievienojot papildu aparatūru bez Portāla darbības traucējumiem.
NFP	Slodzes dalīšana	Arhitektūrai ir jāparedz risinājumi automātiskai slodzes dalīšanai.
NFP	Sistēmas monitorings	Jāparedz programmatūras kļūdu un izņēmumu paziņošanas iespēja monitoringa serverim. Sistēmas monitorings ir jāveic vismaz lietotāju saskarnes, aplikāciju un datubāžu līmenī.
NFP	Autentifikācijas un autorizācijas principi	Portāla arhitektūras izstrādē jāparedz tādi autentifikācijas un autorizācijas principi, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Portāla funkcionalitāti vai piekļūt sistēmas datiem.

Veiktspējas prasības

12. tabula. Veiktspējas prasības.

Nr.	Prasība	Apraksts
NFP	Portāla lietotāju skaits	Portālam jāvar apstrādāt 100 vienlaicīgus lietotāju pieprasījumus bez ietekmes uz pieprasījumu izpildes laiku.
NFP	Slodzes balansēšana un Portāla darbības nepārtrauktība	Piedāvātajam risinājumam jānodrošina servera slodzes balansēšanas iespējas un Portāla darbības nepārtrauktība pieaugot pieprasījumu skaitam un liela apjoma pieprasījumu apstrādes laikā.
NFP	Lietotāju saskarņu attēlošanas laiks	Lietotāja saskarnē lietotāju ievadīto datu apstrādei, gan iesniegtas formas apstrādei jānotiek ne ilgāk kā 3 sekundes (neņemot vērā datu pārsūtīšanas aizturi un pieprasījumu izpildes laiku ārējās sistēmās). Prasītais attēlošanas laiks jānodrošina vienlaicīgo lietotāju skaitam, kas norādīts NFP-6.
NFP	Darbības nepārtrauktība	Jānodrošina iespēja veikt šādas darbības nepārtraucot Portāla darbību: 1. Lietotāju pārvaldība; 2. Konfigurācijas maiņa; 3. Rezerves kopēšana; 4. Jaunas Portāla sadaļas pievienošana vai dzēšana; 5. Portāla satura rediģēšana.

Nr.	Prasība	Apraksts
NFP	Portāla produkcijas vides tehniskie ierobežojumi	Piegādātajam Portāla risinājumam jāspēj darboties un izpildīt veiktspējas un nepārtrauktības prasības uz servera, ar šādiem tehniskajiem parametriem: • atmiņas apjoms: nepārsniedz 8 GB; • diska apjoms: 20 GB; • procesors: 4 vCPU3; • tīkla pieslēgums: 1Gbs.

Drošības prasības

13. tabula. Drošības prasības.

Nr.	Prasība	Apraksts
NFP	Izstrādes vadlīnijas	Portāla izstrādē jāievēro OWASP izstrādes principi un vadlīnijas: 1. “Category:Principle” xxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxxx:Xxxxxxxxx; 2. “OWASP Secure Coding Practices - Quick Reference Guide” xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/XXXXX_Xxxxxx_Xxxxx g_Practices_-_Quick_Reference_Guide; 3. “Session_Management” xxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxx_Xxxxxxxxxx.
NFP	Atbilstība normatīviem	Portālam jāatbilst šādiem normatīviem: 1. Ministru kabineta 2012.gada 19.jūnija noteikumi Nr.421 “Valsts informācijas sistēmu savietotāju un integrēto valsts informācijas sistēmu aizsardzības prasības”; 2. Ministru kabineta noteikumi Nr. 442 “Kārtība, kādā tiek nodrošināta informācijas un komunikācijas tehnoloģiju sistēmu atbilstība minimālajām drošības prasībām”; 3. Likums “Fizisko personu datu aizsardzības likums” un saistītie ministru kabineta noteikumi; 4. Eiropas Parlamenta un Padomes regula (ES) 2016/679 par fizisku personu aizsardzību attiecībā uz personas datu apstrādi un šādu datu brīvu apriti un ar ko atceļ Direktīvu 95/46/EK (Vispārīgā datu aizsardzības regula).
NFP	Lietotāja autentifikācijas veidi	Jānodrošina šādas lietotāju autentifikācijas iespējas Portāla pakalpojumu un funkcionalitātes izmantošanai: 1. Autentifikācija izmantojot internetbanku autentifikācijas servisus; 2. Autentifikācija, izmantojot drošu elektronisko parakstu (ar Pilsonības un migrācijas lietu pārvaldes izsniegto elektronisko identifikācijas karti (eID)); 3. Autentifikācijas mehānisms ar lietotājvārdu un paroli (autentifikācijas mehānisms pieejams tikai klientiem, pirmreizējas autentifikācijas gadījumā norādot personu un noslēgto līgumu viennozīmīgi identificējamu informāciju, piemēram, personas datus un līguma numuru).
NFP	Lietotāja paroļu uzglabāšana	Lietotāju paroles jāuzglabā drošā veidā, kas nepieļauj orģinālās paroles iegūšanu, piemēram izmantojot MD5+SALT vai citas drošākas jaucējfunkcijas.
NFP	Piekļuves ierobežošana pēc Interneta Protokola adrešu segmenta	Administratoru pieeja Portālam jāspēj ierobežot ar vienu vai vairākiem Internet Protokola adrešu apgabaliem. Ar Internet Protokola adrešu apgabalu šeit tiek saprasts IPV4 vai IPV6 adrešu intervāls.

3 Viens vCPU ir līdzvērtīgs Amazon m3.medium instancei.

Nr. Prasība Apraksts
NFP	Lietotāja tiesību pārvaldība	Portāla lietotājiem drīkst būt pieejama tikai tā funkcionalitāte un tikai tādai lietošanai, kā atrunāts līgumā starp Pasūtītāju un klientu vai kā noteikts tehniskajās prasībās un Pretendenta izstrādātā tehniskajā specifikācijā.
NFP	Datu rezerves kopēšana	Portālam jānodrošina iespēja izveidot datu rezerves kopijas, glabāt un arhivēt tās, kā arī izmantot rezerves kopijas datu atgūšanai un atjaunošanai, izmantojot Pasūtītāja rīcībā esošo rezerves kopēšanas risinājumu Veritas BackupExec.
NFP	Informācijas aizsardzība	Portālam jānodrošina aizsardzība pret darbības traucējumiem un tajā esošās informācijas neautorizētu piekļuvi un mainīšanu. Jānodrošina apstrādājamās informācijas aizsardzību, lai neautorizētas personas vai sistēmas nevarētu izgūt vai modificēt informāciju, kas nav publiski pieejama.
NFP	Portāla drošība	Informācijas apmaiņa jānodrošina, izmantojot HTTPS un komerciāli izsniegtus SSL sertifikātus.
NFP	Sesijas identifikators	Nodrošināt, ka autentificējoties Portālā, tiek izveidots unikāls lietotāja sesijas identifikators, kura vērtību nav iespējams iepriekš paredzēt.
NFP	Sesiju pārtraukšana	Nodrošināt lietotāja sesijas pārtraukšanu, ja lietotājs noteiktu laiku nav veicis nevienu darbību.
NFP	Kiberuzbrukumu konstatēšana un novēršana	Nodrošināt saņemto pieprasījumu un notikumu žurnalēšanu tādā apjomā, lai būtu iespējama datoruzbrukumu noteikšana un novēršana. Žurnalēšanas informāciju paredzēts izmantot SIEM risinājumā IBM QRaradar.

Lietojamības prasības

14. tabula. Lietojamības prasības.

Nr.	Prasība	Apraksts
NFP	Lietojamības vadlīniju izmantošana	Izstrādājot Portāla lietotāju saskarni, jāpielieto vismaz šādas vadlīnijas: 1. ANSI/HFES 200 "Human Factors Engineering of Software User Interfaces"4; 2. XXXXX/ELMER2 "User Interface Guidelines for Governmental Forms on the Internet"5; 3. Microsoft "Inductive User Interface Guidelines"6; 4. “Web Content Accessibility Guidelines (WCAG) 2.0”
NFP	Mobilo iekārtu atbalsts	Jānodrošina Portāla tīmekļa vietnes lietojamība uz mobilajām iekārtām, tās izstrādē pielietojot reaģējoša tīmekļa vietnes dizaina (Responsive Web Design7) izstrādes labo praksi.
NFP	Tīmekļa pārlūka programmu atbalsts	Jānodrošina Portāla funkcionalitāte un savietojamība ar šādām un jaunākām tīmekļa lietojumprogrammu versijām: 1. Microsoft Edge (sākot no versijas 38.14393); 2. Microsoft Internet Explorer (sākot no versijas 11.0); 3. Google Chrome (sākot no versijas 56.0); 4. Mozilla Firefox (sākot no versijas 51.0); 5. Safari (sākot no versijas 10.0).
NFP	Mobilo iekārtu operētājsistēmu atbalsts	Jānodrošina Portāla funkcionalitāte un savietojamība ar populārākajām mobilo ierīču operētājsistēmām IPhone, Android un Windows Phone kā arī atbilstošu HTML koda atbalstu. Portālam pilna funkcionalitāte uz šādām un jaunākajām mobilo ierīču operētājsistēmu versijām: 1. Android (sākot no 4.4 KitKat); 2. Apple iOS (sākot no 9.x);

4 xxxx://xxx.xxxx.xxx/Xxxxxxxxxxxx/XxxxxxxXxxxxx.xxxx?Xxx00

5 xxxx://xxx.xxxxx.xx/xxxxxxxxxxxxxx/xxx/xxxxx0-xxxxxxx.xxx

6 xxxx://xxxx.xxxxxxxxx.xxx/xx-xx/xxxxxxx/xx000000.xxxx

7 xxxx://xxxx.xxxxxxxxx.xxx/xx-xx/xxxxxxxx/xx000000.xxxx

Nr. Prasība Apraksts
		3. Windows Mobile (sākot no 10).
NFP	Lietotāja saskarņu valoda	Portāla lietotāja saskarnes (izvēlnes, spiedpogas, informatīvie paziņojumi u.c.) jānodrošina daudzvalodu atbalsts ar iespēju pievienot jaunas valodas. Lietotāja saskarne jānodrošina vismaz latviešu, krievu un angļu valodā.
NFP	Lietotāja palīdzības resursu pieejamība	Jānodrošina darbības konteksta jūtīga lietotāja palīdzības pieejamība visās Portāla lietotāju un administrēšanas saskarnēs. Lietotāja palīdzība jānodrošina kā: 1. Lietotājam pieejama informācija par katru no aizpildāmajiem laukiem; 2. Saite uz Portāla izmantošanas aprakstiem; 3. Meklēšanas iespēju Portāla platformas saskarnēs.
NFP	Portāla izmantošanas aprakstu formāts un apjoms	Izpildītājam jānodrošina visu Portāla procesu un pakalpojumu izmantošanas dokumentācija datorizētas tiešsaistes bibliotēkas veidā. Portāla izmantošanas aprakstiem jāsatur vismaz: 1. Detalizētu procesa aprakstu; 2. Saskarnes aprakstus; 3. Iespējamās kļūdu situācijas un darbības to novēršanai vai apiešanai, ja tādas iespējamas. Jānodrošina iespēju aprakstus papildināt ar atbildēm uz lietotāju biežāk uzdotajiem lietotāju jautājumiem.
NFP	Atlase un filtrēšana	Portālam jānodrošina elastīgas un plašas datu izgūšanas un atveidošanas funkcijas. Portālā jāparedz iespēju atlasīt un attēlot reģistrētos dokumentus, kā atlases kritēriju norādot atslēgvārdus un/vai tekstuālo ierakstu saturu. Jānodrošina Portālā autorizētajiem klientiem iespēja filtrēt vai sakārtot sarakstus, piemēram, KUM, veikto maksājumu, patēriņa, līgumu, u.c. sarakstus, pēc attēlotajiem laukiem vai sakārtot attēlotās vērtības.
NFP	Lapas satura koks	Portāla klientu saskarnē jānodrošina lapas satura koks, kas veidojas automātiski. Karte hierarhiski viegli uztverama un sastāv no sadaļas nosaukuma kā aktīvas saites uz attiecīgo sadaļu Portālā. Nepublicētās, izslēgtas vai slēptas sadaļas lapas kartē netiek ievietotas.
NFP	Kontaktinformācija	Portālā jānodrošina Pasūtītāja kontaktinformācijas atspoguļošanu. Aplūkojot Portāla kontaktinformācijas sadaļu uz mobilajām ierīcēm, jānodrošina iespēju zvanīt konkrētiem numuriem.
NFP	Obligāto lauku aizpildīšana	Iesniedzot elektronisko pieteikumu formu datus, ja nav izpildīts kāds no obligātajiem laukiem, jānodrošina datu pārbaudes paziņojumi un jāattēlo neaizpildītie datu lauki, tos iezīmējot citā krāsā.

Ieviešanas prasības

15. tabula. Portāla ieviešana un konfigurēšana.

Nr.	Prasība	Apraksts
NFP	Portāla vides	Izpildītājam ir jānodrošina testa vide atbilstoši prasībā NFP-10 noteiktajam un Izpildītāja piedāvājumam izstrādes laikā. Pasūtītājs nodrošina infrastruktūru produkcijas videi, kas atbilst Izpildītāja testa vides infrastruktūras parametriem.
NFP	Piegādes versijas apraksts	Programmatūras pirmkods un tā izmantošanas tiesības Izpildītājam ir jānodod Pasūtītājam pēc uzturēšanas un garantijas termiņa beigām, kā arī pēc katras izmaiņas vai uzlabojuma veikšanas Portālā. Ar Portāla programmnodrošinājuma daļas piegādi Izpildītājam jāpiegādā programmatūras versijas apraksts, kas ietver:

Nr. Prasība Apraksts
		1. Piegādātās programmnodrošinājuma identifikāciju; 2. Aprakstu; 3. Konfigurācijas aprakstu; 4. Konfigurācijas pārbaudes aprakstu; 5. Instalācijas aprakstu; 6. Atrites (Rollback) scenāriju; 7. Automātisko skriptu sarakstu.
NFP	Programmatūras koda piegāde	Portāla programmatūras koda piegāde jāveic, izmantojot koda pārvaldības sistēmu. Portāla izstrādes gaitā Izpildītājam jāizmanto koda pārvaldības sistēma, piemēram, GIT, GITLAB, kurai Pasūtītājam jānodrošina patstāvīga pieeja lasīšanas režīmā.
NFP	Portāla uzstādīšana testa vidē	Izpildītājam ir jāveic Portāla uzstādīšana un konfigurēšana (pielāgošana darbībai konkrētajā vidē) Pasūtītāja infrastruktūrā testa vidē.
NFP	Automātiskie testi	Izpildītājam jānodrošina automātiskie testi pamata konfigurācijas un funkcionalitātes pārbaudei pēc Portāla uzstādīšanas. Jānodrošina automātiskie testi visiem akcepttestēšanas scenārijiem, kurus ir iespējams automatizēt. Pēc instalācijas testiem Pasūtītājs izpilda automātisko testu skriptus. Ja automātisko testu izpilde ir neveiksmīga, akcepttestēšana tiek pārtraukta.
NFP	Portāla uzstādīšana produkcijas vidē	Izpildītājam ir jāveic Portāla uzstādīšana un konfigurēšana (pielāgošana darbībai konkrētajā vidē) Portāla produkcijas vidē. Portāla uzstādīšana produkcijas vidē ietver arī atbalstu Portāla konfigurēšanā.

Administratoru apmācības

16. tabula. Administratoru apmācības.

Nr.	Prasība	Apraksts
NFP	Administratoru apmācību apjoms	Izpildītājam jānodrošina administratoru apmācības par Portāla komponentēm tādā apjomā, lai administratori patstāvīgi un pilnvērtīgi spētu: 1. Izmantot Portāla piedāvāto funkcionalitāti; 2. Veikt Portāla administrēšanu un uzturēšanu; 3. Veikt Portāla saskarņu lietotāju reģistrēšanu un administrēšanu; 4. Veikt Portāla atjaunošanu; 5. Diagnosticēt un aprakstīt Portāla darbībā konstatētās problēmas to iesūtīšanai Izpildītājam uz tālāko apstrādi un novēršanu; 6. Iegūt statistiku par Portāla lietošanas apjomu un regularitāti; 7. Veikt Portāla tiesību pārvaldības procedūras; 8. Veikt Portāla veiktspējas uzlabošanu, pielāgojot Portālu atbilstoši izmaiņām Pasūtītāja infrastruktūrā.
NFP	Apmācāmo lietotāju skaits	Izpildītājam jānodrošina apmācības Pasūtītāja norādītām personām (ne vairāk par 10) – personām, kuras veiks Portāla administrēšanu, uzturēšanu un pilnveidi.
NFP	Administratoru apmācību vieta	Izpildītājam apmācību plānošanas laikā jāsaskaņo ar Pasūtītāju administratoru apmācību norises vieta.
NFP	Tehniskais aprīkojums administratoru apmācību veikšanai	Izpildītājam jānodrošina visu nepieciešamo apmācību materiālu (x.xx. ilustratīvu izdales materiālu un rokasgrāmatas) sagatavošana un pieejamība apmācību laikā, kas nepieciešama veiksmīgai Portāla administratoru apmācību norisei. Pasūtītājs nodrošina tehnisko infrastruktūru apmācību veikšanai.
NFP	Apmācību valoda	Izpildītājam jānodrošina, ka administratoru apmācības tiek veiktas latviešu valodā.

Pārbaudāmības prasības

17. tabula. Portāla testēšana.

Nr.	Prasība	Apraksts
NFP	Testēšanas apjoms	Izpildītājam jānodrošina Portāla testēšana, kas aptver pilnvērtīgu testu veikšanu izstrādātajiem Portāla komponentēm (vismaz vienībtestus, funkcionālos testus, integrācijas testus, drošības testus, lietojamības testus, akcepttestus, veiktspējas testus), lai pārliecinātos par piegādātā risinājuma atbilstību prasībām. Testēšanas apjomā ir jāiekļauj visi Portāla nodrošinātie procesi (skat. 3.nodaļu). Jānodrošina pozitīvo un robežgadījumu scenāriju testēšana.
NFP	Testa dati drošības, veiktspējas, integrācijas un lietojamības testēšanai	Izpildītājam ir jāpiegādā testa datu kopa, kas tiek izmantota drošības, integrācijas, veiktspējas un lietojamības testēšanā.
NFP	Drošības testēšana	Drošības testēšanas ietvaros jāveic pārbaudes, novērtējot drošības apdraudējumu iestāšanās iespējamību un pārliecinoties par Portāla iebūvēto drošības mehānismu korektu darbību un izvirzīto drošības prasību izpildi. Drošības testu jāveic ņemot vērā OWASP izstrādāto Testing guide8. Testēšanā ir jāiekļauj vismaz Testing Checklist9 pārbaudes. Drošības testēšana izpildāma saskaņā ar Pasūtītāja apstiprinātu Portāla testēšanas plānu.
NFP	Veiktspējas testēšana	Veiktspējas testēšanas ietvaros jāveic pārbaudes, lai pārliecinātos par visu TS veiktspējas prasību ievērošanu, simulējot veiktspējas prasībās noteiktos maksimālo lietotāju un sesiju skaitus. Veiktspējas testēšana izpildāma saskaņā ar Pasūtītāja apstiprinātu Portāla testēšanas plānu.
NFP	Lietojamības testēšana	Izpildītājam lietojamības testēšanas ietvaros ir jāveic pārbaudes, lai pārliecinātos par visu TS lietojamības prasību ievērošanu. Testēšanas pieeja jārealizē iteratīvā procesā saskaņā ar Pasūtītāja apstiprinātu Portāla testēšanas plānu.
NFP	Integrācijas testēšana	Izpildītājam testēšanas ietvaros ir jāveic pārbaudes, lai pārliecinātos par visu TS integrācijas prasību ievērošanu. Integrācijas testēšana ir jāveic sadarbībā ar Pasūtītāja partneriem un personālu. Testēšana izpildāma saskaņā ar saskaņotu Portāla testēšanas plānu.
NFP	Darbības atjaunošanas procedūras testēšana	Portāla darbības atjaunošanas procedūrai jābūt izpildāmai atbilstoši iesniegtajai administratora rokasgrāmatai bez papildu konsultācijām ar Izpildītāju. Darbības atjaunošanas testēšana izpildāma saskaņā ar Pasūtītāja apstiprinātu Portāla testēšanas plānu.
NFP	Akcepttestēšana	Izpildītājam jānodrošina testa vides konfigurēšana, kā arī nepieciešamais atbalsts Pasūtītājam, lai Pasūtītājs varētu veikt akcepttestēšanu.
NFP	Akcepttestēšanas procedūra un plāns	Izpildītājam jānodrošina atbalsts (tajā skaitā klātbūtne akcepttestos) Portāla vai tā daļu akcepttestēšanā saskaņā ar Izpildītāja saskaņoto akcepttestēšanas pieeju, kas tiek detalizēta testēšanas plānā. Procedūrai jāparedz, ka akcepttestēšana tiek pārtraukta, ja tās laikā tiek konstatētas problēmas, kas neļauj turpināt testus saskaņā ar plānoto scenāriju vai liecina par nepieciešamību veikt būtiskus labojumus, kas var ietekmēt citu Portāla funkcionalitāti. Šādā gadījumā jāparedz, ka testēšana tiek ierobežota tikai ar to apjomu, kas ir notestējams, bet Izpildītājam ir jānovērš konstatētās problēmas un jāsagatavo Portāla versija atkārtotai akcepttestēšanai termiņā, par kuru Puses ir vienojušās. Akcepttestēšanas laikā atrastās kļūdas tiek vērtētas pēc turpmāk lasāmajiem nozīmības līmeņiem. 1. Kļūdu neizdevās apiet un scenāriju nebija iespējams pilnībā izpildīt, tika piešķirta: a. Kritiska prioritāte (1.prioritāte) – funkcionalitāte pilnībā nedarbojas;

8 xxxxx://xxx.xxxxx.xxx/xxxxxx/0/00/XXXXX_Xxxxxxx_Xxxxx_x0.xxx

9 xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxxxxxx_Xxxxxxxxx

Nr.	Prasība	Apraksts
		b. Augsta prioritāte (2.prioritāte) - funkcionalitāte darbojas nepilnīgi. 2. Ja scenāriju bija iespējams izpildīt, kļūdu apejot, tika piešķirta: a. Vidēja prioritāte (3.prioritāte); b. Zema prioritāte (4.prioritāte).

Integrācijas prasības

18. tabula. Integrācijas prasības.

Nr.	Prasība	Apraksts
NFP	Internetbanku autentifikācijas saskarnes	Jānodrošina autentifikācijas iespējas Portālā paredzēto procesu izpildei, izmantojot vismaz šādu banku nodrošinātos autentifikācijas servisus: pakalpojumu funkcionalitāti atbilstoši Portālā paredzētajiem procesiem (skat. prasību NFP-13) atbilstoši izvēlētās bankas internetbankas autentifikācijas līdzekļus. Jānodrošina autentifikācijas funkcionalitāte ar vismaz šādu banku internetbanku sistēmām: • Swedbank; • SEB bankas; • DNB; • Nordea; • Citadele; • Norvik.
NFP	Elektroniskās identifikācijas kartes autentifikācijas saskarne	Jānodrošina autentifikācijas iespējas Portālā paredzēto procesu izpildei, izmantojot drošu elektronisko parakstu (ar Pilsonības un migrācijas lietu pārvaldes izsniegto elektronisko identifikācijas karti (eID)) (skat. prasību NFP-13).
NFP	Internetbanku maksājumu saskarnes	Jānodrošina norēķinu iespējas Portālā paredzēto procesu ietvaros (skat. nodaļu 3.5.), izmantojot vismaz šādu banku internetbanku servisus: • Swedbank; • SEB bankas; • DNB; • Nordea; • Citadele; • Norvik.
NFP	HORIZON datu apmaiņas saskarne	Jānodrošina Portāla integrācija ar Pasūtītāja izmantoto Horizon sistēmu. Jānodrošina Portāla pakalpojumu funkcionalitāti atbilstoši Portālā paredzētajiem procesiem (skat. 3. nodaļu). Saskarņu veidošanai izmantojams Representational state transfer (turpmāk REST) protokols. Saskarne izmantojama šādas informācijas saņemšanai un nodošanai: 1. Sistēmai jānodrošina vismaz šādu datu nosūtīšana uz HORIZON: - noziņotā rādījuma un patēriņa vērtība, tās statuss, kā arī dati par klienta pievienotu komentāru vai, piemēram, izvēlētu iemeslu klasifikatora vērtību (ja attiecināms); - pieprasījums par klienta konta vai līguma informācijas dzēšanas uzsākšanas reģistrāciju; - pieprasījums par klienta konta vai līguma informācijas dzēšanas reģistrāciju. 2. Sistēmai jānodrošina vismaz šādu datu saņemšana no HORIZON: - vismaz šādi dati par rādījumiem un patēriņu:

o noziņotā rādījuma un patēriņa vērtība, un tās statuss, ja Klients ir noziņojis patēriņu, izmantojot citu RŪ piedāvāto patēriņa noziņošanas veidu;

o rādījuma un patēriņa vērtība, un tās statuss tajos gadījumos, kad ir tikusi veikta rādījumu attālināta nolasīšana;

o aprēķinātā patēriņa vērtība un tās statuss gadījumos, ja klients nav laicīgi noziņojis patēriņa vērtību vai līgumam ir piemērojama ūdens patēriņa norma;

o dati par izmaiņām, kas ir tikušas veiktas manuāli HORIZON saistībā ar noziņoto rādījumu, patēriņu un tā statusu;

o dati par klientam piešķirto pieļaujamā patēriņa svārstību apgabalu vērtībām.

- vismaz šādi dati par klienta līgumiem:

o līguma statuss un tā maiņa, kas ir tikusi veikta HORIZON;

o pieprasījums no HORIZON attēlot paziņojumu par līguma statusa maiņu;

o dati par visiem līgumiem, kas ir spēkā esoši un klientam saistoši;

o klientam piešķirto pieļaujamā patēriņa svārstību apgabalu vērtības un jebkuras to izmaiņas, kas tiek veiktas HORIZON (tiem klientu līgumiem, kam ūdens patēriņš tiek mērīts ar KUM palīdzību);

o līgumā ar klientu norādītās piemērojamās ūdens patēriņa normas un jebkuras to izmaiņas, kas tiek veiktas HORIZON (tiem klientu līgumiem, kam tiek piemērotas ūdens patēriņa normas);

o dati par līguma norēķinu ciklu un jebkurām izmaiņām, kas ir tikušas veiktas HORIZON saistībā ar šiem datiem;

- vismaz šādi dati par rēķiniem:

o pieprasījums no HORIOZN attēlot paziņojumu par rēķina izrakstīšanu klientam (par jebkura rēķina izrakstīšanu, kas tikusi veikta manuāli, gan automātiski saistībā ar aktīvu klienta līgumu vai maksas pakalpojumiem, kurus klients ir pieteicis)

o izrakstītais rēķins, rēķina statuss un tā summa (gan par RŪ pamatpakalpojumiem, gan citiem maksas pakalpojumiem), x.xx. ja rēķina statusa maiņa notikusi maksājumu atpazīšanas rezultātā un rēķins ir ticis atzīts par pilnībā apmaksātu;

o pieprasījums no HORIZON attēlot paziņojumu par piemērotu rēķina korekciju;

o koriģēts rēķins, tā statuss un summa;

o pieprasījums no HORIZON attēlot 1. brīdinājumu par rēķinu apmaksas kavēšanu;

o pieprasījums no HORIZON attēlot atgādinājumu par rēķina apmaksu (citiem RŪ piedāvātajiem maksas pakalpojumiem)

- pieprasījums no HORIZON attēlot darba izpildes aktu vai cita pieteiktā pakalpojuma veikšanu apstiprinošu aktu vai dokumentu.

3. Sistēmai jānodrošina vismaz šādu datu apmaiņa ar HORIZON:

- klienta kontaktinformācijas dati un jebkuras saistītās izmaiņas, kas ir tikušas veiktas Portālā vai HORIZON (x.xx. saistībā ar atšķirīgas kontaktinformācijas datiem dažādiem paziņojumu veidiem);

- konta izveidošanas pieprasījuma validācija, veicot šādu datu apmaiņu:

o autentificētas personas datu pārbaudes pieprasījuma nosūtīšana uz HORIZON;

o datu saņemšana no HORIZON par autentificētas personas datu pārbaudes rezultātiem.

NFP	EDUS datu apmaiņas saskarne	Jānodrošina Portāla integrācija ar Pasūtītāja izmantoto EDUS sistēmu. Jānodrošina Portāla pakalpojumu funkcionalitāti atbilstoši Portālā paredzētajiem procesiem (skat. 3. nodaļa). Datu apmaiņa jārealizē izmantojot datu apmaiņas saskarni. Sistēmai jānodrošina iesnieguma reģistrēšanas pieprasījuma nosūtīšana uz EDUS, kas ietver vismaz šādus datus: 1. pieteikuma informācijas datu lauki un tajos ievadītā informācija; 2. pieteikuma unikālais identifikācijas numurs; 3. pieteikuma statuss; 4. iesnieguma iesniedzēja kontaktinformācijas dati, kā arī papildus kontaktinformācijas datus, ja tādus paredz iesniegumu forma. Sistēmai jānodrošina interfeiss vismaz šādu datu saņemšanai no EDUS un attēlošana Portālā: 1. Portālā saņemtu iesniegumu statusi un to maiņa; 2. caur citiem RŪ piedāvātajiem kanāliem saņemtu klienta aizpildītu iesniegumu saturs, unikālais identifikācijas numurs, statusi un to maiņa; 3. paziņojumi par RŪ iesniegumu un tā statusa maiņu.
NFP	ĢIS datu apmaiņas saskarne	Jānodrošina Portāla integrācija ar Pasūtītāja izmantoto ĢIS. Jānodrošina Portāla pakalpojumu funkcionalitāti atbilstoši Portālā paredzētajiem procesiem (skat. 3. nodaļa). Sistēmai jānodrošina vismaz šādu datu saņemšana no ĢIS: - dati par adresē pieteiktajiem bojājumiem, x.xx. vismaz šādi saistītie dati: o bojājuma pieteikuma reģistrēšanas datums; o bojājuma veids; - pieteiktā bojājuma statuss un tā izmaiņas. Sistēmai jānodrošina vismaz šādu datu nosūtīšana ĢIS: - pieprasījums bojājuma pieteikuma reģistrēšanai, nosūtot vismaz pieteikuma informācijas datu laukus un tajos ievadīto informāciju; - pieteikums RŪ pārstāvja izsaukšanai, nosūtot vismaz pieteikuma informācijas datu laukus un tajos ievadīto informāciju, x.xx. par izvēlēto datumu un laiku.
NFP	Laika un datuma izvēles funkcionalitāte, piesakot RŪ pārstāvja ierašanos	Jānodrošina Portālā iespēja Portāla lietotājiem izvēlēties datumu, uz kuru indikatīvi pieteikt RŪ pārstāvja ierašanos, tādejādi nodrošinot Portāla pakalpojumu funkcionalitāti atbilstoši nodaļā 3.9. aprakstītajam. Izvēloties datumu, kalendāram jānodrošina ierobežotas datuma un laika izvēles iespējas. Kalendārā iekļauto datumu ierobežošanai ir jābūt modificējamai Portāla administratora saskarnē. Papildus datuma izvēlei portāla lietotājiem jānodrošina arī iespēja ievadīt aptuvenu laiku vai laika intervālu, kad pieteiktajam pārstāvim nepieciešams ierasties. Sistēmai jānodrošina datu nosūtīšana uz ĢIS saskaņā ar prasību NFP-59.
NFP	Rīgas ūdens tīmekļa vietne xxx.xxxxxxxxxx.xx	Jānodrošina Portāla integrācija ar Pasūtītāja izmantoto tīmekļa vietni xxx.xxxxxxxxxx.xx. Izstrādājot Portāla funkcionalitāti jāparedz publiskas pieejamības ĢIS kartes attēlošana par bojājumiem, kā aprakstīts 3.8.2. nodaļas prasībā RDP-10.

Organizatoriskās prasības

Projekta pārvaldības prasības

19. tabula. Projekta realizācija.

Nr.	Prasība	Apraksts
ORG-	Projekta realizācijas laiks	Izpildītājam jānodrošina projekta realizācija atbilstoši Pretendenta piedāvājumā minētajajam realizācijas laikam, bet ne ilgāk kā 12 (divpadsmit) mēnešu laikā no līguma noslēgšanas brīža.
ORG-	Programmizstrādes metodikas	Izpildītājam Portāla programmatūras izstrāde jāīsteno atbilstoši kādai no starptautiski atzītajām programmizstrādes metodikām. Izstrādes metodoloģijai ir jāparedz Portāla izstrādi pa daļām. Izstrādes posmi drīkst pārklāties laikā.

Nr.	Prasība	Apraksts
		Portāla izstrāde var tikt realizēta iteratīvi, atbilstoši modernām, praksē pārbaudītām IT projektu realizācijas pieejām un metodēm.
ORG-	Projekta vadības standarts	Projekta pārvaldība nodrošināma atbilstoši kādam no starptautiski atzītiem nozares standartiem projektu pārvaldības jomā (piemēram, PRINCE2 vai PMBOK).

20. tabula. Projekta vadības struktūra.

Nr.	Prasība	Apraksts
ORG-	Projekta organizatoriskā struktūra	Izpildītājam jānodrošina Projekta grupas izveide, kuras sastāvā ietilpst Pasūtītāja un Izpildītāja vadības pārstāvji, kā arī citi Pasūtītāja uzaicinātie projektā iesaistīto pušu pārstāvji. Izpildītājam jānodrošina Projekta komandas izveide, kuras sastāvā ietilpst Pasūtītāja un Izpildītāja projekta vadītāji un vadošie speciālisti, kā arī konkrēto darba posmu izpildē iesaistītie Izpildītāja un Pasūtītāja puses speciālisti.
ORG-	Projekta vadības grupas funkcijas	Izpildītājam jānodrošina vismaz šādu Projekta vadības grupas funkciju izpilde: 1. Projekta vadības grupas informēšana par projekta statusu un progresu; 2. Projekta progresa pārvaldību; 3. Detalizētu projekta pasākumu plānošanu, ievērojot Projekta vadības grupas lēmumus; 4. Projekta vadības aspektu vadību; 5. Projekta darba grupas izveide un tās sastāva noteikšana.
ORG-	Projekta komandas funkcijas	Izpildītājam jānodrošina vismaz šādu Projekta komandas funkciju izpilde: 1. Uzdevumu izpilde atbilstoši Projekta vadības grupas lēmumiem; 2. Projekta vadības grupas informēšana un pārskatu iesniegšana par projektā paredzēto darbu izpildes progresu un statusu; 3. Pārskatu iesniegšana par projektā veicamo darbu.
ORG-	Sanāksmju protokolēšana	Izpildītājam jānodrošina visu projekta sanāksmju (tai skaitā interviju / lietotāju stāstu) protokolēšana. Izpildītājam jānodrošina uzrakstīto protokolu saskaņošana ar visiem sanāksmes dalībniekiem ne vēlāk kā 5 darba dienu laikā pēc sanāksmes norises.

21. tabula. Projekta vadības procesi.

Nr.	Prasība	Apraksts
ORG-	Projekta laika grafika aktualizēšana	Izpildītājam jānodrošina projekta plāna un tajā ietilpstošā projekta laika grafika atjaunināšana, projekta plānā veicamās izmaiņas saskaņojot ar Pasūtītāju.
ORG-	Projekta progresa ziņojumi	Izpildītājam jāsagatavo un elektroniski jāiesniedz Pasūtītājam šādi progresa ziņojumi: 1. Iknedēļas ziņojums par aktuālajiem uzdevumiem un atvērtajiem jautājumiem; 2. Ikmēneša ziņojums Projekta vadības grupai par Projekta uzdevumu izpildes progresu, sasniegtajām robežšķirtnēm, atvērtajiem riskiem/problēmām un nepieciešamajiem lēmumiem. Ziņojums jāiesniedz Pasūtītāja Projekta vadītājam ne vēlāk kā 2 (divas) darba dienas pirms plānotās Projekta vadības grupas sēdes, kurā ziņojums saskaņojams.
ORG-	Projekta kvalitātes vadība	Izpildītājam jānodrošina šādu kvalitātes pasākumu realizācija: 1. Dokumentu nodevumu struktūras un plānotā satura saskaņošana ar Pasūtītāju, pirms dokumenta izstrādes uzsākšanas;

Nr.	Prasība	Apraksts
		2. Iekšēja nodevumu kvalitātes novērtēšana pirms iesniegšanas Pasūtītājam; 3. Nodevumu iesniegšana saskaņošanai.
ORG-	Problēmu ziņojumu uzskaite	Izpildītājam jānodrošina Pasūtītāja pieteikto problēmu ziņojumu problēmu ziņojuma pieņemšana, reģistrēšana, izpēte, klasifikācija, atbildes sniegšana pieteicējam par problēmas novēršanas termiņiem, kā arī jānovērš Pasūtītāja konstatētās Portāla problēmas Pasūtītāja noteiktajā termiņā saskaņā ar prasībām (skat. prasību ORG-46, ORG- 47, ORG-48, ORG-49),un jāinformē Pasūtītāju par problēmas novēršanas progresu un statusu.
ORG-	Projekta izmaiņu vadība	Tehniskajā specifikācijā noteiktās prasības var tikt mainītas, pamatojoties uz izstrādes gaitā identificētajiem alternatīvajiem risinājumiem, precizētām lietotāju prasībām vai konstatētiem tehnoloģiskiem ierobežojumiem, bet nepārsniedzot 10% (desmit procentus) no kopējās projekta līguma summas. Izpildītājam jānodrošina projekta Tehniskās specifikācijas prasību izmaiņu saskaņošana ar Pasūtītāju, novērtēšana un noformēšana, aizpildot izmaiņu pieprasījumu. Izmaiņu pieprasījumu saskaņo Pasūtītājs.
ORG-	Projekta izmaiņu pieprasījums	Izpildītājam jānodrošina ar Pasūtītāju iepriekš saskaņotas izmaiņu pieteikuma formas aizpildīšana, norādot: 1. Izmaiņu ietekmi uz Portāla arhitektūru; 2. Izmaiņu ietekmi uz projekta laika grafiku; 3. Darbietilpības novērtējumu - izmaiņu realizācijai nepieciešamo cilvēkdienu skaits; 4. Izmaiņu ietekmi uz projekta; 5. Risinājuma aprakstu.

Prasību analīzes procesa prasības

22. tabula. Prasību definēšana.

Nr.	Prasība	Apraksts
ORG-	Prasību analīze	Projekta realizācijas ietvaros jādetalizē prasības visu Portāla procesu (skat. 3. nodaļu) un uzturēšanas procesu programmnodrošinājuma izstrādei. Atkāpes no tehniskajā specifikācijā noteiktajām prasībām ir iespējamas tikai formāla izmaiņu pārvaldības procesa rezultātā, kuras izstrādes gaitā pieprasa Pasūtītājs vai piedāvā Izpildītājs. Veicot Portāla struktūras izstrādi, ja Izpildītājs redz problēmas Tehniskajā specifikācijā definēto prasību ieviešanai vai arī iespējas Portāla struktūras uzlabošanai, Izpildītājs ar izmaiņu pieprasījuma palīdzību par to informē Pasūtītāju un vienojas par turpmāko darba gaitu.
ORG-	Prasību trasējamība	Izpildītājam jānodrošina viennozīmīga trasējamība starp projekta prasībām un projekta nodevumiem. Trasējamība jānodrošina visām Portāla Tehniskās specifikācijas prasībām.
ORG-	Akcepttestēšanas prasību saskaņošana	Izpildītājam un Pasūtītājam jāsaskaņo Portāla akcepttestēšanas kritēriji, kas tiek iekļauti testēšanas plānā (skat. prasību ORG-39).
ORG-	Saskarņu dizaina saskaņošana	Izpildītājam dizaina saskaņošanai ir jānodrošina vairāki (vismaz 2) prototipi. Pasūtītāja izvēlētajai versijai jānodrošina uzlabojumu veikšana līdz trijām iterācijām.
ORG-	Lietotāja saskarņu un lietojamības testēšana	Izstrādājot Portāla dizainu, jāveic analīzi un testēšanu, iesaistot vismaz 15 Pasūtītāja izvēlētus cilvēkus. Veicot analīzi jāizvērtē vismaz Portāla sadaļu un apakšsadaļu izkārtojums, lietošanas ērtums, navigācijas ērtums, saprotamība un interaktivitāte. Izpildītājs uzsāk lietojamības testēšanu pēc saskarņu dizaina saskaņošanas ar Pasūtītāju. Pirms lietojamības testēšanas uzsākšanas Izpildītājs saskaņo ar Pasūtītaju lietojamības testēšanas

Nr.	Prasība	Apraksts
		pieeju un testēšanas kritērijus (x.xx. testēšanā izmantotās datu kopas, jautājumus un scenārius). Izpildītājs veic testu rezultātu apkopošanu un prezentē Pasūtītājam iespējamo Portāla struktūrkoku.

Projekta nodevumu prasības

23. tabula. Projekta nodevumu pieņemšana.

Nr.	Prasība	Apraksts
ORG-	Projekta nodevumi	Projektā realizācijas ietvaros Izpildītājam jāiesniedz nodevumi, kas sastāv no šādiem vienumiem: 1. Programmatūras nodevumi (skat. prasību ORG-25); 2. Dokumentācijas nodevumi (skat. prasību ORG-28).
ORG-	Nodevumu formāts	Visiem iesniegtajiem projekta nodevumiem jāatbilst turpmāk lasāmajām formāta prasībām. 1. Visiem nodevumiem ir jābūt Pasūtītājam iesniegtiem elektroniskā formā; 2. Visiem dokumentiem jābūt sagatavotiem MS Office 2007 vai jaunākas versijas MS Word, MS Excel, MS PowerPoint, MS Xxxxx, MS Project, citā ar Pasūtītāju saskaņotā formātā; 3. Visiem nodevumiem ir jābūt viennozīmīgi identificējamiem atbilstoši ar Pasūtītāju saskaņotam dokumentu identificēšanas veidam.
ORG-	Nodevumu iesniegšanas termiņi un secība	Izpildītājs saskaņo ar Pasūtītāju nodevumu iesniegšanas termiņus un secību projekta plānošanas fāzē. Nodevumu iesniegšanas termiņiem un secībai ir jāatbilst šādiem nosacījumiem: 1. Pirms izstrādes darbu uzsākšanas Izpildītājam jāiesniedz un jāsaskaņo ar Pasūtītāju Projekta pārvaldības plāns, tajā iekļaujot iesniedzamo nodevumu sarakstu un katra nodevuma iesniegšanas termiņus. 2. Nodevumu izstrādes un saistītajiem saskaņošanas termiņiem ir jāatbilst projekta realizācijas laika prasībai (skat. prasību ORG-1).
ORG-	Nodevumu saskaņošana	Projekta nodevumu saskaņošana ietver: 1. Dokumentācijas nodevumu saskaņošanu; 2. Programmatūras nodevumu akcepttestēšanu.
ORG-	Dokumentācijas nodevumu saskaņošana	Iesniegtos dokumentus Pasūtītājs izskata 10 darba dienu laikā, ja vien ar Izpildītāju nav panākta vienošanās par citu izskatīšanas termiņu. Pēc dokumentu izskatīšanas Pasūtītājs iesniedz Izpildītājam iebildumu, komentāru un jautājumu sarakstu. Izpildītāja pienākums ir apstrādāt Pasūtītāja iesniegtos komentārus 5 darba dienu laikā pēc nodevuma izskatīšanas beigām, ja vien ar Pasūtītāju nav panākta vienošanās par citu termiņu. Izpildītājs pēc nepieciešamības var organizēt komentāru izskatīšanas sanāksmes. Pasūtītājs saskaņo dokumentu līdz ar visu komentāru un iebildumu apstrādi.
ORG-	Programmatūras nodevumu akcepttestēšana	Portāla akcepttestēšana tiek uzsākta pēc tā veiksmīgas uzstādīšanas testa vidē un veiksmīgi izpildītiem Izpildītāja iesniegtajiem automātiskajiem testiem. Akcepttestēšanu Pasūtītājs veic 20 darba dienu laikā pēc programmatūras nodevumu iesniegšanas. Programmatūras nodevums tiek akceptēts, ja akcepttestēšanas laikā netiek konstatētas: 1. Kritiskas un augtas prioritātes kļūdas, un 2. Vidējas prioritātes kļūdu skaits nepārsniedz 10. Vidēja un zema līmeņa kļūdas tiek uzskaitītas akceptēšanas protokolā ar noteiktu novēršanas termiņu, kas nedrīkst pārsniegt 20 darba dienas. Kļūdu klasifikācijas nozīmi skat. prasībā NFP-53.

24. tabula. Projekta nodevumu saraksts.

Nr.	Prasība	Apraksts
ORG-	Programmatūras nodevumi	Izpildītājam Portāla izstrādes un ieviešanas projekta rezultātā jāpiegādā Pasūtītājam šādi programmatūras nodevumi: 1. Sistēmas programmnodrošinājums; 2. Trešo pušu programmatūra, licences un dokumentācija.
ORG-	Trešo pušu programmnodrošinājuma piegāde	Ja tiek izmantots trešās puses izstrādāts programmnodrošinājums, tad Izpildītājam jāpiegādā: 1. Programmatūras uzstādīšanas pakotne; 2. Programmatūras lietošanai nepieciešamās licences; 3. Programmatūras lietotāja un administratora dokumentācija. Ja attiecīgā dokumentācija nav pieejama latviešu valodā, tad ir pieļaujama tās piegāde angļu valodā.
ORG-	Dokumentācijas nodevumi	Izpildītājam Portāla izstrādes un ieviešanas projekta laikā jāizstrādā un jāiesniedz Pasūtītājam šādi dokumenti: 1. Projekta pārvaldības plāns; 2. Programmatūras prasību specifikācija; 3. Programmatūras projektējuma apraksts; 4. Arhitektūras apraksts; 5. Prasību trasējamības tabula; 6. Testēšanas plāns; 7. Testēšanā izmantotās datu kopas un scenāriji; 8. Testēšanas kopsavilkuma pārskats; 9. Administratora rokasgrāmata; 10. Lietotāja dokumentācija; 11. Portāla saskarņu lietošanas instrukcija; 12. Apmācību materiāli; 13. Grafiskie nodevumi. Izpildītājam jāiesniedz šādi projekta ietvaros izstrādāti dokumenti: 1. Sanāksmju (tai skaitā interviju / lietotāju stāstu) protokolu apkopojums (saraksts un saskaņotās versijas); 2. Progresa ziņojumu apkopojums (saraksts un saskaņotās versijas); 3. Izmaiņu pieprasījumu apkopojums (saraksts un saskaņotās versijas); 4. Programmatūras versiju aprakstu apkopojums (saraksts un saskaņotās versijas); 5. Cita dokumentācija, ja tāda tiek izstrādāta projekta ietvaros.
ORG-	Dokumentācijas nodevumu standarti	Dokumentācijas nodevumiem jāizstrādā atbilstoši kādam no vispārpieņemtajiem programminženierijas standartiem: LVS, ISO/IEC vai IEEE.
ORG-	Projekta pārvaldības plāns	Projekta pārvaldības plānam jābūt izstrādātam atbilstoši Izpildītāja piedāvātajai izstrādes metodoloģijai. Pārvaldības plānam jāsatur šāda detalizēta informācija: 1. Projekta organizācija; 2. Pārvaldības procesi (veicamās aktivitātes, to norises kārtība un atbildīgie); 3. Projekta kalendārais plāns; 4. Konfigurācijas vadība; 5. Risku vadība; 6. Izmaiņu vadība.
ORG-	Programmatūras prasību specifikācija	Izpildītājam prasību analīze jādetalizē programmatūras prasību specifikācija (turpmāk - PPS , izstrādājot vienu vai vairākus

Nr. Prasība Apraksts
		dokumentus. PPS jābūt izstrādātam saskaņā ar programminženierijas standartiem atbilstoši Izpildītāja piedāvātajai izstrādes metodoloģijai. Prasību specificēšana veicama, balstoties uz konkursa nolikuma tehniskās specifikācijas informāciju, normatīvajos aktos ietverto un Pasūtītāja sniegto dokumentāciju un intervijām ar Pasūtītāja darbiniekiem vai Pasūtītāja nozīmētām kontaktpersonām.
ORG-	Programmatūras projektējuma apraksts	Izpildītājam ir jāveic Portāla sistēmas projektēšana, balstoties uz dokumenta PPS izveides rezultātā iegūto informāciju. Projektējuma aprakstā ir jāiekļauj prasību realizācijas apraksts visām PPS norādītajām prasībām, ievērojot programminženierijas standartus un atbilstoši Izpildītāja piedāvātajai izstrādes metodoloģijai.
ORG-	Arhitektūras apraksts	Portāla arhitektūras apraksts sagatavojams saskaņā ar standartu ISO/IEC/IEEE 42010:2011. Portāla arhitektūras aprakstā ir jāiekļauj vismaz šādi skatu punkti: 1. Biznesa arhitektūra (sasniedzamo biznesa mērķu, atbalstāmo funkciju un procesu uzskaitījums); 2. Programmatūras arhitektūra (programmatūras komponenšu uzskaitījums, apraksts un to sadarbības shēma); 3. Datu arhitektūra (būtiskāko datu objektu uzskaitījums, apraksts un to savstarpējās sasaistes shēma); 4. Infrastruktūras arhitektūra (fiziskā arhitektūra, virtuālā arhitektūra, programmatūras komponenšu izvietojums uz infrastruktūras elementiem); 5. Drošības arhitektūra (drošības zonas, drošības kontroles, drošības prasību ievērošana izstrādes procesā); 6. Uzturēšanas apsvērumi (auditācijas pierakstu veidošana un apskate, jauninājumu un piegāžu uzstādīšanas pieeja, rezerves kopēšanas un atjaunošanas pieeja).
ORG-	Prasību trasējamība	Izpildītājam izstrādes laikā jāuztur aktuāla prasību trasējamības tabula, kurā ar unikāliem identifikatoriem tiek trasēta katra Portāla prasība.
ORG-	Testēšanas plāns	Testēšanas plānā jāiekļauj visas Izpildītāja, Pasūtītāja un Pasūtītāja projekta partneru testēšanas aktivitātes. Testu plānam jāpārklāj visu funkcionālo, nefunkcionālo testējamo prasību izpildes pārbaudes, akcepttestēšanas pieeja un scenāriji.
ORG-	Testēšanā izmantotās datu kopas un scenāriji	Izpildītājam jāizstrādā un jāiesniedz Pasūtītājam testa datu kopas, kas tiks izmantotas drošības, integrācijas, veiktspējas un lietojamības testēšanā. Pirms testēšanas plāna apstiprināšanas, Izpildītājs vienojas ar Pasūtītāju par to, kādā formātā tiks piegādāti nodevumu testēšanas scenāriji un dokumentācija, kā tiks saskaņoti un iesniegti testpiemēri.
ORG-	Testēšanas kopsavilkuma pārskats	Izpildītājam jānodrošina, ka Izpildītāja testēšanas process tiek dokumentēts un jāiesniedz Pasūtītājam kopsavilkums par testēšanas rezultātiem. Pasūtītājs pieprasīs uzrādīt testēšanas procesa dokumentāciju, ja tiks konstatēts, ka testēšanas kopsavilkumā sniegtā informācija atšķiras no faktiski Portāla novērojamās situācijas.
ORG-	Administratora rokasgrāmata	Izpildītājam jāizstrādā un jāiesniedz Pasūtītājam Portāla administrēšanas rokasgrāmata. Rokasgrāmatai jāsatur vismaz šāda informācija: 1. Pārskats par programmatūras būtiskākajām īpašībām un Portāla arhitektūru; 2. Nepieciešamie resursi un vide Portāla funkcionalitātes un tās darbību nodrošināšanai veicamo darbību izpildei; 3. Instrukcijas sākotnējai Portāla ekspluatācijas uzsākšanai vai darbības atjaunošanai pēc pilnīga sistēmas zuduma.

Nr. Prasība Apraksts
ORG-	Lietotāja dokumentācija	Izpildītājs izstrādā un portālā ievieš lietotāja tiešsaistes palīgu, kurā aprakstīta Portāla funkciju lietošana, piemēram, datu ievade, rēķinu apmaksa un citas funkcijas. Tiešsaistes lietotāja palīgam jāsatur informācija par vismaz: 1. Portāla lietotāja saskarnē lietotajiem terminiem un to skaidrojumi; 2. Portāla izvēļņu aprakstu un funkcionālās iespējas; 3. Portāla formu aprakstu; 4. Formu un portāla lauku aprakstu (x.xx sniedz papildus nepieciešamo informāciju, lai saprastu laukā ievadāmo informāciju); 5. Portāla paziņojumu aprakstu. Tiešsaistes lietotāja palīga jāiekļauj arī pamācības, kādā veidā veikt noteiktas darbības. Izstrādājot lietotāja tiešsaistes palīgu, jāparedz iespēja portāla administrēšanas saskarnē veidot, rediģēt un dzēst lietotāju grupas, nodrošinot gan dinamisku, gan manuālu lietotāju pievienošanu grupām. Portāla administrēšanas saskarnē jānodrošina funkcionalitāte iespējot un atspējot tiešsaistes palīga sadaļas izvēlētajām lietotāju grupām.
ORG-	Portāla saskarņu lietošanas instrukcija	Izpildītājam jāizstrādā un jāiesniedz Pasūtītājam Portāla saskarņu lietošanas instrukcija. Lietošanas instrukcijai jāsatur vismaz šāda informācija: 1. Portāla saskarņu būtiskākās īpašības un darbības principi; 2. Detalizēts soļu apraksts Portāla saskarņu integrācijai; 3. Instrukcija Portāla saskarņu funkcionalitātes izmantošanai pēc integrācijas pabeigšanas; 4. Kļūdu situācijas, kļūdu ziņojumi, to rašanās cēloņi un kļūdu novēršanai veicamās procedūras. 5. Portāla saskarņu lietošanas piemēri.
ORG-	Apmācību materiāli	Izpildītājam jāiesniedz visi administratoru apmācībās (skat. prasību NFP-40) izmantotie materiāli kā atkārtoti izmantojams materiāls Portāla administratoru apmācībai.
ORG-	Grafiskie nodevumi	Izpildītājam jānodod Pasūtītājam Portāla dizaina apraksts, kas ietver grafiskā dizaina aprakstu (x.xx. krāsas, grafiskos elementus u.c.) un struktūras skices. Portāla vajadzībām izmantotajiem un radītajiem dizaina elementiem pēc darba pieņemšanas jānonāk Pasūtītāja īpašumā turpmākai izmantošanai un pārvaldībai. Dizainu elementi nedrīkst saturēt elementus, kurus Pasūtītājs pēc tam nedrīkst izplatīt vai izmantot citos nolūkos.

Garantijas prasības

25. tabula. Portāla garantija.

Nr.	Prasība	Apraksts
ORG-	Garantija	Portāla garantijas ietvaros Izpildītājam jānodrošina vismaz šādu pakalpojumu sniegšanu Pasūtītājam saistībā ar piegādātajām Portāla komponentēm: 1. Pēc akcepttestēšanas pabeigšanas atrasto programmatūras izstrādes un ieviešanas kļūdu un jebkuru funkcionalitātes problēmu novēršana vai līdzvērtīgas funkcionalitātes bezatlīdzības atkārtota izstrāde; 2. Dokumentācijas kļūdu un nepilnību novēršana, kā arī dokumentācijas atjaunošana gadījumos, kad izstrādes un ieviešanas kļūdu novēršanas rezultātā ir mainīta vai papildināta esošā Portāla funkcionalitāte un arhitektūra.

ORG-	Garantijas darbības laiks	Izpildītājam jānodrošina izstrādāto un piegādāto Portāla komponenšu garantija vismaz 1 (viena) gada periodā pēc Portāla nodošanas ekspluatācijā bez maksas.
ORG-	Konsultācijas	Izpildītājam jāsniedz konsultācijas par Portāla funkcionalitāti, dokumentāciju, uzturēšanu pēc Pasūtītāja pieprasījuma 2 (divu) gadu laika periodā no Portāla pieņemšanas kopumā līdz 60 cilvēkdienu apjomam (4 mēnešu laikā ne vairāk kā 10 cilvēkdienas). Izpildītājam jānodrošina pieprasījumu apstrāde un klasificēšana.
ORG-	Izmaiņu pieprasījumi garantijas periodā	Portāla garantijas darbības laikā Pretendentam par papildus samaksu jānodrošina Portāla izmaiņu un papildināšanas darbu izpilde. Xxxxx veicami pamatojoties uz Pasūtītāja un pretendenta abpusēji saskaņotiem Izmaiņu pieprasījumiem.

26. tabula. Problēmu reakcijas un novēršanas laiks.

Nr.	Prasība	Apraksts
ORG-	Problēmu pieteikumu klasifikācija	Izpildītājam jāievēro šāda Pasūtītāja noteiktā problēmu pieteikumu prioritāšu klasifikācija: Ļoti kritiska (Immediate) – Portāla darbība ir apstājusies vai arī Portāls nav izmantojams būtisku problēmu dēļ. Kritiska (Urgent) – nopietna kļūda Portāla funkcionalitātē un/vai datos, kas ietekmē vairāk kā vienu Portāla moduli/funkciju. Portāla darbība ir nopietni traucēta un var izraisīt Portāla darbības pārtraukumu, svarīgas funkcijas/moduļa lietošana nav iespējama. Augsta (High) – nopietna kļūda Portāla funkcionalitātē un/vai datos viena Portāla moduļa/funkcijas ietvaros. Portāla ikdienas darbība ir nopietni traucēta, funkcijas/moduļa lietošana ir apgrūtināta vai nav iespējama. Vidēja (Normal) – kļūda/nepilnība Portāla funkcionalitātē, neērtības Portāla lietošanā. Portāla ikdienas darbība ir traucēta, Portāla lietošana apgrūtināta. Zema (Low) – neliela kļūda/nepilnība Portāla funkcionalitātē. Portāla ikdienas darbība netiek ietekmēta. Pasūtītājs problēmu pieteikumus izveido Pasūtītaja uzturētā projektu vadības un problēmu pieteikumu pārvaldības sistēmā Redmine. Uzsākot projektu, Pasūtītājs izveido un nodod Izpildītaja projekta vadītājam piekļuves informāciju Redmine sistēmai. Citu Izpildītāja pārstāvju pievienošana Redmine sistēmai tiek veikta Izpildītāja pieprasījuma. Izpildītājam problēmu pieteikumu pieņemšana jānodrošina darba dienās no 9:00 - 18:00. Pieteikumiem, kas ienākuši darba dienā pēc 16:00, brīvdienā vai svētku dienā, par saņemšanas laiku uzskata nākamās darba dienas rītu plkst. 9:00. Ļoti kritiskas (immediate) prioritātes pieteikumiem ir jānodrošina pieteikšanas iespēja arī pa Izpildītāja norādītu tālruni 24 stundas un 7 dienas nedēļā, uz to neattiecinot darba laika ierobežojumus.
ORG-	Reakcijas laiki uz problēmu ziņojumiem	Izpildītājam jānodrošina šādi reakcijas laiki, kas veidojas no problēmu pieteikšanas brīža līdz brīdim, kad Izpildītājs ir veicis pieteikuma apstrādi un tiek piedāvāts konkrētās problēmas risinājums: Ļoti kritiska - līdz 4 stundām; Kritiska - līdz 4 stundām; Augsta - līdz 4 stundām; Vidēja vai zema – līdz 2 darba dienām. Ja problēmas risinājuma noteikšanai ir nepieciešama papildu informācija no Pasūtītāja, tad reakcijas laiku skaita no visas nepieciešamās informācijas saņemšanas brīža. Izmaiņu pieprasījuma realizācija tiek uzsākta pēc izmaiņu pieprasījuma (tai skaitā novērtējuma) saskaņošanas ar Pasūtītāju un izmaiņu pieprasījuma pasūtījuma saņemšanas vai arī pusēm vienojoties par individuālu realizācijas laika grafiku.
ORG-	Problēmu novēršanas laiks	Izpildītājam jānodrošina šādi problēmu novēršanas laiki, kas veidojas no problēmu reģistrēšanas brīža, kad Pasūtītājs saņem informāciju ar par to, ka problēmu ziņojums ir apstrādāts un reģistrēts, līdz brīdim,

Nr.	Prasība	Apraksts
		kad Izpildītājs pabeidzis visus nepieciešamos darbus pie problēmu novēršanas un informējis par to Pasūtītāju: Ļoti kritiska – 8 darba stundu laikā; Kritiska – 16 darba stundu laikā; Augsta – 40 darba stundu laikā; Vidēja vai zema – ne vēlāk kā 80 darba stundu laikā.
ORG-	Reakcijas laika uz problēmu ziņojumu pieteikumu un problēmu novēršanas laika pārsniegšana	Problēmu novēršanas laika pārsniegšanas gadījumā Izpildītājam savlaicīgi jāinformē Pasūtītājs par to, ka problēmu novēršanai nepieciešams papildu laiks un jāsaskaņo tālākā rīcība, kā arī plānotais problēmu novēršanas laiks. Reakcijas laika pārsniegšanas gadījumā Izpildītājam jāsniedz informācija Pasūtītājam par reakcijas laika pārsniegšanas iemesliem, kā arī jānodrošina problēmu novēršana laikā, kas ir samazināts par pārsniegto reakcijas laiku.

Portāla procesu raksturojums

Zemāk aprakstīti biznesa procesi, kuru atbalstu nodrošinās Portāls, kā arī šī atbalsta nodrošināšanai nepieciešamās funkcionalitātes prasības.

Patēriņa rādījumu nodošana un apstrāde

Portālam jānodrošina patēriņa rādījumu nodošanas un apstrādes biznesa process. Šī procesa atbalstā Portālam vajadzēs nodrošināt funkcionalitāti šādām klientu grupām:

- Klienti ar KUM.

Šo klientu grupu var iedalīt šādās divās kategorijās:

o Klienti ar KUM, kura rādījumu ir iespējams iegūt, veicot rādījuma attālinātu nolasīšanu un tā ielādi

HORIZON;

o Klienti ar KUM, kura rādījumu klientiem ir nepieciešams nolasīt un noziņot, izmantojot RŪ piedāvātos kanālus (piemēram, telefoniski).

- Klienti bez KUM.

Šai klientu grupai ir noslēgts līgums ar RŪ par ūdens patēriņa normu piemērošanu, ņemot vērā dažādas kategorijas (piemēram, labierīcības pakāpi, deklarēto iedzīvotāju skaitu, utt.), kā arī līguma noslēgšanas brīdī noteiktās piemērojamo kategoriju vērtības (piemēram, līguma slēgšanas brīdī ir bijuši vairāki deklarēti iedzīvotāji objektā).

Zemāk aprakstītas šī biznesa procesa nodrošināšanai nepieciešamās Portāla funkcionalitātes prasības.

Patēriņa rādījumu nodošana un apstrāde (klientiem ar KUM)

27. tabula. Skaidrojums: Patēriņa rādījumu noziņošana un apstrāde.

Solis	Prasības Portāla funkcionalitātei				Lietotāja darbības
1.	PPP-1. Portālam jānodrošina rādījumu ievades funkcionalitātes iespējošana autorizētiem klientiem gadījumos, kad KUM attālināta nolasīšana nav iespējama vai nav paredzēta, ievērojot prasību FP-14.				N/A
2.	PPP-2. Sistēmai ir jānodrošina rādījumu ievade tikai noteiktos laika periodos, piemēram, sākot ar katra mēneša 20. datuma plkst. 0:00. PPP-3. Rādījumu nodošanas laika periodam jābūt modificējamam lielumam.				N/A
3.	PPP-4. Brīdī, kad Portālā automātiski tiek iespējota rādījumu ievades funkcionalitāte, Portālam jānodrošina automātiska atgādinājuma nosūtīšana uz klienta e-pasta adresi, kas ir tikusi saglabāta pie klienta kontaktinformācijas HORIZON un Portālā.				N/A
4.	PPP-5. Sistēmai jānodrošina fizisku autentificēšanās (skat. prasību NFP-13).	un	juridisku	personu	Xxxxx publiskajā Portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
5.	PPP-6. Klientu portāla saskarnē jānodrošina iespēja autorizētam lietotājam ievadīt KUM rādījumu. Datu ievadei rādījumu ievades laukā klientu portāla saskarnē jābūt iespējotai tikai gadījumos, ja ir iestājies iepriekš definētais rādījumu nodošanas periods un šajā periodā rādījums vēl nav ticis noziņots, izmantojot Portālu vai jebkuru citu RŪ piedāvāto rādījumu ziņošanas veidu. Sistēmai jānodrošina KUM rādījumu ziņošana, ņemot vērā prasībās FP-15, FP-16 un FP-17 aprakstīto funkcionalitāti.				Ievada aktuālo KUM rādījumu.
6.	PPP-7. Portālam jānodrošina aktuālā patēriņa aprēķins un tā vērtības attēlošana, ņemot vērā portālā saglabāto informāciju par iepriekšējā rādījumu nodošanas periodā noziņoto vai aprēķināto rādījuma vērtību un klienta ievadīto aktuālā rādījuma vērtību.				Aplūko vērtību.	aktuālo	patēriņa

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
7.	PPP-8. Portālam jānodrošina iespēja klientam apstiprināt ievadīto rādījuma vērtību. Klientam arī jānodrošina iespēja ievadīto rādījuma vērtību labot pirms tās apstiprināšanas.	Nepieciešamības gadījumā labo ievadīto rādījuma vērtību. Apstiprina rādījuma vērtību.
8.	PPP-9. Sistēmai jānodrošina datu saņemšana no HORIZON par klientam piešķirto pieļaujamā patēriņa svārstību apgabalu vērtībām (skat. prasību NFP-57). PPP-10. Sistēmai jānodrošina rādījumu ievades pārbaudes funkcionalitāte (skat. prasību FP-17).	Gadījumā, ja patēriņa vērtība pārsniedz pieļaujamo patēriņa svārstību apgabalu, atkārtoti apstiprina vai labo un apstiprina rādījuma vērtību.
		Gadījumā, ja patēriņa vērtība ir zemāka par pieļaujamo patēriņa svārstību apgabalu, labo rādījuma vērtību vai izvēlas iespējamo iemeslu no
		klasifikatora. Ja nepieciešams, ievada brīvā tekstā papildus skaidrojumu. Atkārtoti apstiprina rādījuma vērtību.
9.	PPP-11. Portālam jānodrošina datu apmaiņa ar HORIZON saistībā ar rādījuma vērtību, tās statusu un, ja attiecināms, klienta ievadīto komentāru (skat. prasību NFP-57) gan gadījumos, kad rādījums ir noziņots Portālā, gan caur citiem RŪ piedāvātajiem kanāliem (piemēram, telefoniski). Portālam jānodrošina šo datu attēlošana.	N/A
10.	PPP-12. Portālam jānodrošina datu saņemšana no HORIZON saistībā ar rādījuma vērtības un tās statusa maiņu gadījumos, ja RŪ atbildīgais darbinieks ir veicis manuālu rādījuma vērtības vai rādījuma statusa labošanu (skat. prasību NFP-57). Portālam jānodrošina izmainītās rādījuma vērtības attēlošana, paziņojuma attēlošana par precizēto rādījuma vērtību un koriģētā rēķina attēlošana gadījumos, kad ir tikusi piemērota rēķina korekcija. PPP-13. Sistēmai jānodrošina iespēja klientam apmaksāt rēķinu (skat. nodaļu 3.5.1.)	RŪ atbildīgais darbinieks ievada precizēto rādījuma vērtību HORIZON un manuāli nomaina rādījuma statusu uz tādu, kas norāda, ka rādījuma vērtība ir apstiprināta. Klients saņem paziņojumu par precizēto rādījuma vērtību un rēķinu.
		Klients autentificējas Portālā un aplūko korekcijas rēķinu un precizēto rādījuma vērtību ar statusu, kas norāda, ka rādījuma vērtība ir apstiprināta.
11.	PPP-14. Portālam ir jānodrošina rādījumu ievades atspējošana šādos gadījumos: a. Klients ir noziņojis rādījuma vērtību par aktuālo periodu, izmantojot jebkuru RŪ piedāvāto KUM rādījumu noziņošanas kanālu. b. RŪ noteiktais rādījumu nodošanas periods ir noslēdzies, piemēram, katra mēneša 30. datuma 23:59.	N/A
12.	PPP-15. Portālam jānodrošina funkcionalitāte arī tajos gadījumos, kad tiek veikta attālināta rādījumu nolasīšanas procedūra, kuras ietvaros dati tiek nodoti HORIZON. Šādos gadījumos Portālam jānodrošina datu saņemšana no HORIZON saistībā ar attālinātās nolasīšanas rezultātā iegūto un HORIZON saglabāto rādījumu vērtību un to statusu, kā arī šo datu attēlošana Portālā (skat. prasību NFP-57).	RŪ atbildīgais darbinieks veic attālinātu rādījumu nolasīšanas procedūru un tās ietvaros identificētais rādījums tiek ievadīts HORIZON.

Xxxxxxxx apjoma kritēriju izmaiņu ziņošana (klientiem bez KUM)

28.tabula.Skaidrojums: Patēriņa apjoma kritēriju izmaiņu ziņošana (klientiem bez KUM).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	PPP-16. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās (skat. prasību NFP-13).	Xxxxx publiskajā Portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
2.	PPP-17. Portālam jānodrošina datu saņemšana no HORIZON saistībā ar tiem klientiem, kuriem ir noslēgts līgums ar RŪ par pamatpakalpojumu izmantošanu bez KUM, piemērotajām ūdens patēriņa normām un rēķina aprēķinā izmantotajām vērtībām (piemēram, labierīcības pakāpi, deklarēto iedzīvotāju skaitu, u.c.). Portālam jānodrošina šo datu attēlošana minētajai klientu grupai.	Aplūko informāciju par piemērotajām ūdens patēriņa normām un aprēķinā izmantotajām vērtībām.
3.	PPP-18. Sistēmai jānodrošina elektroniska forma izmaiņu pieteikšanai kādā no piemērotajām ūdens patēriņa normu vērtībām klientu portāla saskarnē, nodrošinot formu izveides un funkcionalitātes prasības (skat. prasības FP-27, FP-28, FP-29, FP-30). PPP-19. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, klasifikators ar objektu adresēm, par kuriem klientam ir noslēgts līgums par ūdens patēriņa normu piemērošanu.	Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas objekta adresi.
4.	PPP-20. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus un izvēlēties to veidu, izmantojot klasifikatoru (piemēram, dokuments, kas apliecina labierīcības pakāpes maiņu, utt.) (skat. prasības FP-30 un FP-31). Dokumentu pievienošana jāparedz kā obligāta prasība formas iesniegšanai. PPP-21. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Apstiprina pieteikuma iesniegšanu.
5.	PPP-22. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
6.	PPP-23. Sistēmai jānodrošina papildus dokumentu pievienošanas funkcionalitāte iesniegumam (skat. prasību FP- 33).	RŪ darbinieks sazinās ar klientu par papildus dokumentu nepieciešamību un par to veic atzīmi EDUS. Klients sagatavo elektroniskas dokumentu kopijas, autentificējas Portālā un pievieno iesniegumam papildus dokumentus. Klients apstiprina papildus dokumentu iesniegšanu.
7.	PPP-24. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS..
8.	PPP-25. Sistēmai jānodrošina datu saņemšana un attēlošana no HORIZON par izmaiņu veikšanu (skat. prasību NFP-57).	RŪ darbinieki veic izmaiņas saistībā ar piemēroto ūdens patēriņa normu vērtībām HORIZON.
9.	PPP-26. Sistēmai jānodrošina datu apmaiņa ar EDUS saistībā ar paziņojumu attēlošanu par iesnieguma statusu maiņu un pieņemtā lēmuma iemesliem Portālā (skat. prasību NFP-58).	RŪ darbinieks sagatavo ziņojumu saistībā ar iesniegumu, to nosūtot uz klienta e-pasta adresi un veicot pieprasījumu EDUS par paziņojuma attēlošanu Portālā.

Līgumattiecību vadība

Līguma slēgšana (jauni klienti)

29. tabula. Skaidrojums: Līguma slēgšana (jauni klienti).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	LVP-1. Sistēmai jānodrošina elektroniskas pieteikuma formas iesniegumam par līguma slēgšanu aizpildīšana Portāla publiski pieejamajā daļā (skat. prasības FP-27, FP-28, FP-29, FP-30).	Lietotājs ieiet publiskajā portāla saskarnē un izvēlas aizpildīt elektronisku pieteikuma formu.
2.	LVP-2. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās pirms pieteikuma veidlapas aizpildīšanas (skat. prasību NFP-13).	Izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentificēšanās informāciju.
3.	LVP-3. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram: a. Adrešu klasifikators; b. Klasifikators, vai iesniegumu aizpilda kā fiziska vai juridiska persona; c. Atzīmes par vēlamo saziņas kanālu un līguma parakstīšanas veidu u.c.	Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas objekta adresi. No klasifikatora izvēlas, vai iesniegumu aizpilda kā fiziska, vai kā juridiska persona.
4.	LVP-4. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus, norādot to veidu, izmantojot klasifikatoru (piemēram, īpašuma tiesības, nodošanas-pieņemšanas akts, utt.) (skat. prasības FP-30 un FP-31). LVP-5. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu. LVP-6. Sistēmai jānodrošina paziņojuma attēlošana par iesnieguma saņemšanu un citu informāciju, kas saistīta ar iesnieguma tālāku apstrādi un līguma slēgšanu.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Pārskata aizpildīto elektronisko formu skatīšanās režīmā. Apstiprina pieteikuma iesniegšanu.
5.	LVP-7. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
6.	LVP-8. Sistēmai jānodrošina automātiska e-pasta nosūtīšana personai, kas ir iesniegusi aizpildītu veidlapu, par iesnieguma saņemšanu. E-pastā jābūt iekļautai informācijai par to, ka iesniegums ir saņemts, kā arī jābūt norādītam tā unikālajam identifikācijas numuram un iesnieguma izskatīšanas termiņam.	N/A

Līguma slēgšana (esoši klienti)

30. tabula. Skaidrojums: Līguma slēgšana (esoši klienti).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	LVP-9. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās (skat. prasību NFP-13).	Xxxxx publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
2.	LVP-10. Sistēmai jānodrošina elektroniskas pieteikuma formas iesniegumam par līguma slēgšanu aizpildīšana klientu portāla saskarnē (skat. prasības FP-27, FP-28, FP-29, FP-30). LVP-11. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram: a. Adrešu klasifikators; b. Klasifikators, vai iesniegumu aizpilda kā fiziska vai juridiska persona.	Identificē sevi kā objekta īpašnieku, līgumslēdzēju vai personu, kas parakstīs līgumu. Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas objekta adresi. No klasifikatora izvēlas, vai iesniegumu aizpilda kā fiziska, vai kā juridiska persona.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
3.	LVP-12. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus, norādot to veidu, izmantojot klasifikatoru (piemēram, īpašuma tiesības, nodošanas-pieņemšanas akts, utt.) (skat. prasības FP-30 un FP-31). LVP-13. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu. LVP-14. Sistēmai jānodrošina paziņojuma attēlošana par iesnieguma saņemšanu un citu informāciju, kas saistīta ar iesnieguma tālāku apstrādi un līguma slēgšanu.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Pārskata aizpildīto elektronisko formu skatīšanās režīmā. Apstiprina pieteikuma iesniegšanu.
4.	LVP-15. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
5.	LVP-16. Sistēmai jānodrošina papildus dokumentu pievienošanas funkcionalitāte iesniegumam (skat. prasību FP-33).	RŪ darbinieks sazinās ar klientu par papildus dokumentu nepieciešamību un par to veic atzīmi EDUS. Klients sagatavo elektroniskas dokumentu kopijas, autentificējas Portālā un pievieno iesniegumam papildus dokumentus. Klients apstiprina papildus dokumentu iesniegšanu.
6.	LVP-17. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS.
7.	LVP-18. Sistēmai jānodrošina iespēja klientam veikt sagatavota līguma parakstīšanu, izmantojot elektronisku parakstu. Sistēmai jānodrošina saistīto datu nosūtīšana uz HORIZON par līguma parakstīšanu. LVP-19. Sistēmai jānodrošina datu nosūtīšana, saņemšana un attēlošana no HORIZON par līguma statusu maiņu (skat. prasību NFP-57).	RŪ darbinieki veic līguma sagatavošanu, nodod klientam parakstīšanai un RŪ paraksttiesīgā persona parakstās. Attiecīgi HORIZON tiek manuāli mainīti līguma statusi.
8.	LVP-20. Sistēmai jānodrošina līgumu pievienošana lietotāja kontam ar pilnu saistīto funkcionalitāti un administrēšanas tiesībām brīdī, kad no HORIZON tiek saņemti dati par to, ka līgumam tiek piešķirts statuss, kas norāda uz tā stāšanos spēkā.	RŪ atbildīgais darbinieks abpusēji parakstītam līgumam maina statusu HORIZON.
9.	LVP-21. Sistēmai jānodrošina datu apmaiņa ar EDUS saistībā ar ziņojumu attēlošanu par iesniegumu Portālā (skat. prasību NFP-58).	RŪ darbinieks sagatavo ziņojumu saistībā ar iesniegumu, to nosūtot uz klienta e-pasta adresi un veicot pieprasījumu EDUS par paziņojuma attēlošanu Portālā.

Līguma grozīšana

31. tabula. Skaidrojums: Līguma grozīšana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	LVP-22. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās (skat. prasību NFP-13).	Xxxxx publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
2.	LVP-23. Sistēmai jānodrošina elektroniskas pieteikuma formas iesniegumam par līguma grozījumiem aizpildīšana klientu portāla saskarnē (skat. prasības FP-27, FP-28, FP-29, FP-30).	Identificē sevi kā objekta īpašnieku, līgumslēdzēju vai personu, kas parakstīs līgumu. Aizpilda iesnieguma formas laukus
		elektroniski.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
	LVP-24. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, klasifikators ar klienta noslēgtajiem aktīvajiem līgumiem.	No klasifikatora izvēlas līgumu, par kuru tiek sastādīts iesniegums.
3.	LVP-25. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus, norādot to veidu, izmantojot klasifikatoru (piemēram, īpašuma tiesības, nodošanas-pieņemšanas akts, utt.) (skat. prasības FP-30 un FP-31). LVP-26. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Apstiprina pieteikuma iesniegšanu.
4.	LVP-27. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
5.	LVP-28. Sistēmai jānodrošina papildus dokumentu pievienošanas funkcionalitāte iesniegumam (skat. prasību FP-33).	RŪ darbinieks sazinās ar klientu par papildus dokumentu nepieciešamību un par to veic atzīmi EDUS. Klients sagatavo elektroniskas dokumentu kopijas, autentificējas Portālā un pievieno iesniegumam papildus dokumentus. Klients apstiprina papildus dokumentu iesniegšanu.
6.	LVP-29. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS..
7.	LVP-30. Sistēmai jānodrošina datu saņemšana un attēlošana no HORIZON par līguma statusu maiņu (skat. prasību NFP-57).	RŪ darbinieki veic līguma sagatavošanu, nodod klientam parakstīšanai un RŪ paraksttiesīgā persona parakstās. Attiecīgi HORIZON tiek manuāli mainīti līguma statusi.
8.	LVP-31. Sistēmai jānodrošina apstiprināto līguma grozījumu attēlošana portālā.	RŪ darbinieks veic izmaiņas līguma saturā.
9.	LVP-32. Sistēmai jānodrošina datu apmaiņa ar EDUS saistībā ar ziņojumu attēlošanu par iesniegumu Portālā (skat. prasību NFP-58).	RŪ darbinieks sagatavo ziņojumu saistībā ar iesniegumu, to nosūtot uz klienta e-pasta adresi un veicot pieprasījumu EDUS par paziņojuma attēlošanu Portālā.

Līguma apturēšana un izbeigšana

32. tabula. Skaidrojums: Līguma apturēšana un izbeigšana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	LVP-33. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās (skat. prasību NFP-13).	Xxxxx publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
2.	LVP-34. Sistēmai jānodrošina elektroniskas pieteikuma formas iesniegumam par līguma pārtraukšanu aizpildīšana klientu portāla saskarnē (skat. prasības FP-27, FP-28, FP-29, FP-30).	Identificē sevi kā objekta īpašnieku, līgumslēdzēju vai personu, kas parakstīs līgumu. Aizpilda iesnieguma formas laukus
	LVP-35. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, klasifikators ar klienta noslēgtajiem aktīvajiem līgumiem.	elektroniski. No klasifikatora izvēlas līgumu, par kuru tiek sastādīts iesniegums.
3.	LVP-36. Portālam jānodrošina iespēja apstiprināt formas iesniegšanu.	Apstiprina pieteikuma iesniegšanu.
4.	LVP-37. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
5.	LVP-38. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS.
6.	LVP-39. Sistēmai jānodrošina datu saņemšana un attēlošana no HORIZON par līguma statusu maiņu (skat. prasību NFP-57). LVP-40. Sistēmai jānodrošina datu saņemšana no HORIZON par automatizēta ziņojuma attēlošanu saistībā ar līguma statusa maiņu.	RŪ darbinieki aptur līguma darbību, veicot līguma statusa maiņu HORIZON un veic atzīmi HORIZON par automatizēta e-pasta izsūtīšanu klientam saistībā par līguma pārtraukšanu uz nenoteiktu laiku.
		Pēc iesnieguma tālākas izvērtēšanas un lēmuma pieņemšanas par līguma darbības atjaunošanu vai izbeigšanu, RŪ darbinieks veic līguma statusa maiņu HORIZON.
7.	LVP-41. Portālam jānodrošina automātiska e-pasta nosūtīšana klientam un brīdinājuma attēlošana klienta kontā Portālā par līguma termiņa beigu tuvošanos 60 dienas pirms aktīva līguma termiņa beigām. Termiņam (dienu skaitam) jābūt modificējamam lielumam (skat. prasību FP-26).	N/A

Kontu vadība

Lietotāja konta izveide portālā

33. tabula. Skaidrojums: Lietotāja konta izveide portālā.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RGP-1. Portālam jānodrošina iespēja iniciēt klienta kontus Portālā fiziskām un juridiskām personām, izmantojot vienu no šiem pirmreizējās reģistrēšanās rīkiem: a. Izmantojot Portāla piedāvātos autentificēšanās rīkus (skat. prasību NFP- 13); b. Aizpildot reģistrācijas formu, kurā norādīta ar līgumu saistīta informācija.	Xxxxx publiskajā portāla saskarnē un izvēlas reģistrēt jaunu klienta kontu, izmantojot kādu no piedāvātajiem autentificēšanās rīkiem. Ņemot vērā veikto izvēli, vai nu autentificējas, izmantojot piedāvātos autentificēšanās rīkus, vai aizpilda formu, kurā jānorāda ar līgumu saistīta informācija. Ievada un apstiprina informāciju.
2.	RGP-2. Portālam jānodrošina datu pārbaude, ņemot vērā datus par autentificēto personu (piemēram, vārds, uzvārds un personas kods) vai arī aizpildītā autentifikācijas forma. Datu pārbaude jāveic, salīdzinot tos ar ierakstu HORIZON klientu reģistrā (skat. prasību NFP-57).	N/A
3.	RGP-3. Sistēmai jānodrošina paziņojuma attēlošana par sekmīgu vai nesekmīgu konta reģistrāciju un tālākiem soļiem gadījumos, ja persona nav tikusi identificēta HORIZON kā paraksttiesīga.	N/A
4.	RGP-4. Portālam jānodrošina datu apmaiņa ar HORIZON par RŪ rīcībā esošo klienta kontaktinformāciju (skat. prasību NFP-57). RGP-5. Portālam jānodrošina forma klienta kontaktinformācijas datu ievadei un/vai pārbaudei, ielasot HORIZON jau pieejamos datus attiecīgajos laukos. Sistēmai jānodrošina, ka klients var labot kontaktinformāciju un to apstiprināt. Visi lauki par kontaktinformāciju jāparedz kā obligāti aizpildāmi. RGP-6. Sistēmai jānodrošina Portāla lietošanas noteikumu attēlošana un iespēja klientam tos apstiprināt. Lietošanas noteikumu apstiprināšana	Apstiprina RŪ rīcībā esošos klienta kontaktinformācijas datu, tos vajadzības gadījumā pirms tam labojot. Izlasa un apstiprina Portāla lietošanas noteikumus.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
	jāparedz kā obligāts nosacījums tālākai konta izveidei.
5.	RGP-7. Sistēmai jāiniciē galvenā lietotāja kontu ar visu paredzēto saistīto funkcionalitāti (skat. FP-11).	N/A
6.	RGP-8. Tiem klientiem, kas veikuši pirmreizēju autentifikāciju, aizpildot reģistrācijas formu, Portālam jānodrošina unikālas vienreizējas paroles izveide un nosūtīšana uz norādīto e-pasta adresi. Šai parolei jābūt vienreiz lietojamai. RGP-9. Portālam brīdī, kad tiek ievadīta unikālā vienreizējā konta parole, jānodrošina klientam šo paroli nomainīt, ievadot un saglabājot sevis izvēlētu unikālu Portāla klientu konta paroli.	Klients saņem e-pastu ar unikālo vienreizējo konta paroli. Atver Portālu un ievada lietotājvārdu un unikālo vienreizējo konta paroli. Apstiprina autentifikāciju. Ievada jaunu unikālu konta paroli un to saglabā.

Lietotāja konta uzturēšana portālā

34. tabula. Skaidrojums: Lietotāja konta uzturēšana portālā.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RGP-10. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās (skat. prasību NFP-13).	Xxxxx publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem Sistēmas autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
2.	RGP-11. Sistēmai jānodrošina datu saņemšana no HORIZON par klienta kontaktinformāciju. Portālam jānodrošina šo datu attēlošana un iespēja klientam ievadīt un labot atšķirīgu kontaktinformāciju dažādiem paziņojumu veidiem (piemēram, gadījumos, ja klients vēlas paziņojumus par pakalpojumu pārtraukumiem un rēķinus saņemt uz atšķirīgām e-pasta adresēm) (skat. prasību NFP-57). RGP-12. Portālam jānodrošina prasībā FP-21 aprakstītā līgumu pārvaldības funkcionalitāte un prasībā FP-22 aprakstītā klienta profila informācijas funkcionalitāte, x.xx. sistēmai jānodrošina datu apmaiņa ar HORIZON saistībā ar līgumu un klienta profilu saistītās informācijas maiņu (gan gadījumos, kad tā tiek mainīta manuāli HORIZON, gan gadījumos, ja to maina klients Portālā (skat. prasību NFP-57). Portālam jānodrošina veikto izmaiņu attēlošana. RGP-13. Portālam jānodrošina prasībā FP-23 aprakstītā lietotāju pārvaldības funkcionalitāte.	Aplūko un labo klienta profila informāciju (kontaktinformāciju). Veic lietotāja lomu pārvaldīšanu un, ja nepieciešams, deleģē atsevišķas lietotāja funkcijas citiem lietotājiem.
3.	RGP-14. Sistēmai jānodrošina iespēju klientam iesniegt elektronisku pieteikuma formu to klienta datu izmaiņām, kuru mainīšana nav atļauta klientu portāla saskarnē (skat. prasības FP-27, FP-28, FP-29, FP- 30). RGP-15. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, klasifikators ar klienta noslēgtajiem aktīvajiem līgumiem. RGP-16. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu.	Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas līgumu, par kuru tiek sastādīts iesniegums. Apstiprina formas iesniegšanu.
4.	RGP-17. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
5.	RGP-18. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
6.	RGP-19. Sistēmai jānodrošina datu apmaiņa ar EDUS saistībā ar ziņojumu attēlošanu par iesniegumu Portālā (skat. prasību NFP-58).	RŪ darbinieks sagatavo ziņojumu saistībā ar iesniegumu, to nosūtot uz klienta e-pasta adresi un veicot pieprasījumu EDUS par paziņojuma attēlošanu Portālā.
7.	RGP-20. Sistēmai jānodrošina automātiska datu ievades funkcionalitātes atspējošana līgumam, ja HORIZON ir veikta līguma darbības apturēšana. RGP-21. Sistēmai jānodrošina automātiska datu ievades funkcionalitātes atjaunošana līgumam, ja HORIZON ir veikta līguma darbības aktivizācija.	RŪ darbinieks HORIZON veic līguma statusa maiņu, veicot tā darbības apturēšanu. RŪ darbinieks HORIZON veic līguma statusa maiņu, veicot tā darbības aktivizēšanu.

Lietotāja konta slēgšana portālā

35. tabula. Skaidrojums: Lietotāja konta slēgšana portālā.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RGP-22. Sistēmai jānodrošina datu apmaiņa un attēlošana no HORIZON par klienta līguma statusu maiņu (skat. prasību NFP-57). RGP-23. Sistēmai jānodrošina automātiska datu ievades funkcionalitātes atspējošana līgumam, ja konkrētā līguma statuss HORIZON tiek nomainīts uz tādu, kas norāda līguma darbības izbeigšanu.	RŪ darbinieks uzsāk līguma ar klientu izbeigšanas procedūru, nomainot “HORIZON” līguma statusu uz tādu, kas norāda līguma darbības izbeigšanu.
2.	RGP-24. Ja klientam nav citu aktīvu līgumu, sistēmai automātiski jāattēlo paziņojums un n e-pasts par konta dzēšanas uzsākšanu un iespēju to izmantot lasīšanas režīmā (no angļu val. read-only) vēl noteiktu laika periodu, piemēram, 90 dienas. Sistēmai jānosūta arī pieprasījums uz HORIZON par klienta konta dzēšanas uzsākšanas reģistrāciju. (skat. prasību NFP-57). RGP-25. Ja konta uzturēšanas laikā no konta dzēšanas uzsākšanas brīža no HORIZON tiek saņemti dati par citu klienta līgumu, kas ir sagataves vai apstiprināšanas statusā, Portālam jānodrošina konta uzturēšana līdz brīdim, kad šis līgums var tikt pievienots klienta kontam.	N/A
3.	RGP-26. Ja klientam ir citi aktīvi līgumi, sistēmai automātiski jāattēlo paziņojums un jānosūta klientam e-pasts par iespēju ar līgumu saistīto informāciju aplūkot lasīšanas režīmā vēl noteiktu laika periodu, piemēram, 90 dienas, pēc kura šī informācija tiks dzēsta (skat. prasību FP-26). Sistēmai jānosūta arī pieprasījums uz HORIZON par līguma dzēšanas uzsākšanu Portālā (skat. prasību NFP-57).	N/A

Rēķinu gatavošana un koriģēšana

Rēķinu gatavošana (pamatdarbības pakalpojumi)

36. tabula. Skaidrojums: Rēķinu gatavošana (pamatdarbības pakalpojumi).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RGP-1. Sistēmai jānodrošina datu saņemšana un attēlošana klienta kontā no HORIZON par izrakstīto rēķinu, rēķina apmaksas statusu un tā summu (skat. prasību NFP-57). RGP-2. Sistēmai jānodrošina šādu elementu atspoguļošana: - ziņotā rādījuma atspoguļošana; - rēķina summas un rēķina atspoguļošana klientu portāla saskarnē teksta un PDF formātā; - rēķina apmaksas statuss. Sistēmai jānodrošina prasībās FP-18 un FP-19 aprakstītā funkcionalitāte.	Klients ievada un apstiprina rādījuma vērtību Portālā. Klients aplūko rēķina summu un izrakstīto rēķinu PDF formātā. Klients veic izvēli apmaksāt rēķinu uzreiz vai veikt apmaksu citas sesijas laikā.
2.	RGP-3. Gadījumos, ja objektiem nav KUM vai klients nav noziņojis rādījumus, Portālam jānodrošina šādu datu saņemšana un HORIZON un atspoguļošana Portālā: - aprēķinātā patēriņa atspoguļošana;	Gadījumos, kas objektiem nav KUM vai klients nav noziņojis rādījumus, RŪ grāmatvedis HORIZON veic manuālu patēriņa aprēķinu un rēķina izrakstīšanu klientu grupām, iniciējot izrakstītā rēķina

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
	- rēķina summas un rēķina atspoguļošana klientu portāla saskarnē teksta un PDF formātā; - rēķina apmaksas statuss. Sistēmai jānodrošina prasībās FP-18 un FP-19 aprakstītā funkcionalitāte. RGP-4. Sistēmai jānodrošina datu saņemšana un attēlošana klienta kontā no HORIZON saistībā ar paziņojumu par patēriņa aprēķināšanu un rēķina izrakstīšanu klientam (skat. prasību NFP-57).	nosūtīšanu uz klienta e-pasta adresi un attēlošanu portālā. Klients saņem e-pastu par rēķina izrakstīšanu, autentificējas Portālā, aplūko paziņojumu par saņemto rēķinu un aprēķināto patēriņu.

Rēķina gatavošana (citi RŪ sniegtie pakalpojumi)

37. tabula. Skaidrojums: Rēķina gatavošana (citi RŪ sniegtie pakalpojumi).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RGP-5. Sistēmai jānodrošina datu saņemšana un attēlošana klienta kontā no HORIZON par rēķiniem, kas izrakstīti par citiem pieprasītajiem pakalpojumiem gadījumos, kad citus pakalpojumus pieprasījis RŪ klients ar aktīvu klienta kontu Portālā.	RŪ darbinieks izraksta rēķinu HORIZON. Klients saņem automātiski izveidotu paziņojumu Portālā un automātiski izsūtītu e-pastu par rēķina izrakstīšanu.
	RGP-6. Sistēmai jānodrošina rēķina kopējās summas atspoguļošana teksta formā, savukārt rēķins - PDF formātā, ņemot vērā prasībās FP-18 un FP-19 aprakstīto funkcionalitāti. RGP-7. Sistēmai jānodrošina datu saņemšana un attēlošana klienta kontā no HORIZON saistībā ar paziņojumu par rēķina izrakstīšanu klientam.	Klients aplūko rēķina summu un izrakstīto rēķinu teksta un PDF formātā. Klients veic izvēli apmaksāt rēķinu uzreiz vai veikt apmaksu citas sesijas laikā.

Rēķina korekcijas piemērošana klientiem

38. tabula. Skaidrojums: Rēķina korekcijas piemērošana klientiem.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RGP-8. Sistēmai jānodrošina datu saņemšana un attēlošana klienta kontā no HORIZON par koriģēto rēķinu un tā summu (skat. prasību NFP-57) gadījumos, kad rēķinam ir tikusi piemērota rēķina	RŪ darbinieks veic rēķina korekciju HORIZON. Klients saņem automātiski izveidotu paziņojumu Portālā un automātiski izsūtītu e-pastu par rēķina korekcijas piemērošanu. Klients aplūko koriģēto rēķinā un jaunā izrakstītā rēķina summu un to saturu PDF formātā. Klients veic izvēli apmaksāt jauno rēķinu uzreiz vai veikt apmaksu citas sesijas laikā.
	korekcija.
	RGP-9. Sistēmai jānodrošina datu saņemšana un attēlošana klienta kontā no HORIZON par jauno rēķinu, tā summu un apmaksas statusu (skat. prasību NFP-57) gadījumos, kad rēķinam ir tikusi piemērota rēķina korekcija. Sistēmai jānodrošina prasībās FP- 18 un FP-19 aprakstītā funkcionalitāte.
	RGP-10. Sistēmai jānodrošina datu saņemšana no HORIZON par paziņojuma attēlošanu saistībā ar rēķina korekcijas piemērošanu (skat. prasību NFP-
	57).

Rēķinu apmaksas kontrole

Maksājumu apstrāde un atpazīšana

39. tabula. Skaidrojums: Maksājumu apstrāde un atpazīšana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	CPP-1. Sistēmai jānodrošina klientiem apmaksāt izrakstīto rēķinu, izmantojot Portāla maksājumu saskarni (skat. prasību FP-20).	Klients aplūko rēķina summu un izrakstīto rēķinu PDF formātā. Klients veic izvēli apmaksāt rēķinu.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
	Sistēmai jānodrošina datu saņemšana no Portāla maksājumu saskarnes par maksājuma uzdevuma veiksmīgu pieņemšanu. Portālam jānodrošina tāda rēķina apmaksas statusa piešķiršana un attēlošana rēķinam, kas norādītu uz maksājuma pieņemšanu apstrādē. Portālam jānodrošina, ka par rēķinu ar šādu statusu nav iespējams veikt atkārtotu maksājumu.	Klients atver maksājumu saskarni un veic maksājumu, izmantojot internetbanku.
2.	CPP-2. Sistēmai jānodrošina datu saņemšana un attēlošana no HORIZON par rēķina apmaksas statusa maiņu, tai skaitā gadījumos, kad izmantoti citi RŪ piedāvātie rēķinu apmaksas kanāli (piemēram, bankas pārskaitījums) (skat. prasību NFP-57). CPP-3. Gadījumos, kad ir notikusi tikai daļēja rēķina apmaksa, sistēmai jānodrošina datu saņemšana un attēlošana no HORIZON par rēķina neapmaksāto summu un attiecīgo rēķina apmaksas statusu, kas norāda uz daļējas rēķina apmaksas veikšanu (skat. prasību NFP-57). Šādos gadījumos sistēmai jānodrošina iespēja klientam veikt atkārtotu rēķina apmaksu portālā.	Xxxxx publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju. Aplūko rēķina apmaksas statusu. Ja ir tikusi veikta tikai daļēja rēķina apmaksa, veic izvēli apmaksāt rēķinu. Atver maksājumu saskarni un veic maksājumu par atlikušo summu, izmantojot internetbanku.
3.	CPP-4. Sistēmai jānodrošina iespēja autorizētajiem klientiem izveidot un aplūkot maksājumu un patēriņa pārskatus (skat. prasību FP-25).	Izveido un apskata maksājumu un patēriņa pārskatu. Ja izvēlas, lejupielādē pārskatu XLSX vai PDF formātā.

Debitoru uzskaite un attēlošana

40. tabula. Skaidrojums: Debitoru uzskaite un attēlošana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	CPP-5. Sistēmai jānodrošina datu saņemšana no HORIZON par nokavētajiem maksājumiem (skat. prasību NFP-57). Sistēmai jānodrošina brīdinājuma paziņojuma ģenerēšana par maksājuma kavēšanu un šī paziņojuma attēlošana klientu portāla saskarnē, kā arī e-pasta nosūtīšana uz klienta e-pasta adresi, kas reģistrēta HORIZON.	Klients saņem e-pastu. Klients ieiet publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju. Klients aplūko brīdinājumu savā kontā.

Norēķinu cikla maiņas pieteikšana un attēlošana

41. tabula. Skaidrojums: Norēķinu cikla maiņas pieteikšana un attēlošana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	CPP-6. Sistēmai jānodrošina datu apmaiņa ar HORIZON par norēķinu cikla datiem (skat. prasību NFP-57). Sistēmai jānodrošina šo datu attēlošana.	Klients autentificējas Portālā. Klients aplūko datus par norēķinu ciklu saviem aktuālajiem līgumiem.
	CPP-7. Sistēmai jānodrošina klientiem veikt manuālu norēķinu cikla maiņu uz biežāku (piemēram, no ceturkšņa uz mēneša regularitāti), ja tiek izpildīti divi priekšnoteikumi: - līgums ir ticis noslēgts ar klientu, kas pieder pie RŪ iekšēji klasificētās 14. grupas klientiem; - norēķinu cikls nav ticis mainīts pēdējo 30 dienu laikā. Pirms klients apstiprina šādu maiņu, sistēmai jānodrošina paziņojuma attēlošana, ka šādu maiņu drīkst veikt ne biežāk kā reizi 30 dienu laikā. CPP-8. Klienta apstiprinātās izmaiņas ir jāattēlo Portālā un jānosūta izmaiņu reģistrēšanas pieprasījums uz HORIZON (skat. prasību NFP-57).	Klients, kuram līgums ir pieskaitāms RŪ iekšēji klasificētās 14. klientu grupas līgumiem, izvēlas veikt norēķinu cikla maiņu uz biežāku (piemēram, no ceturkšņa uz mēneša regularitāti). Klients veic atzīmi par vēlamajām izmaiņām norēķinu cikla regularitātē un tās apstiprina.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
2.	CPP-9. Sistēmai jānodrošina elektroniska pieteikuma forma norēķinu cikla maiņas pieteikšanai klientu portāla saskarnē (skat. prasības FP-27, FP- 28, FP-29, FP-30). CPP-10. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, klasifikators ar klienta noslēgtajiem aktīvajiem līgumiem, kā arī jāattēlo brīdinājums, ka norēķinu ciklu var mainīt tikai reizi 30 dienās. CPP-11. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu.	Klients izvēlas pieteikt norēķinu cikla maiņu. Klients atver un aizpilda elektronisku pieteikuma formu norēķinu cikla maiņai. Izvēlas no klasifikatora aktīvā līguma numuru par kuru klients vēlas pieteikt norēķinu cikla maiņu. Apstiprina aizpildīto formu.
3.	CPP-12. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
4.	CPP-13. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS.
5.	CPP-14. Sistēmai jānodrošina datu saņemšana no HORIZON par norēķinu cikla maiņu (skat. prasību NFP-57). Sistēmai jānodrošina datu maiņas attēlošana portālā.	RŪ darbinieki veic pieprasītās norēķinu cikla izmaiņas HORIZON.
6.	CPP-15. Sistēmai jānodrošina datu apmaiņa ar EDUS saistībā ar ziņojumu attēlošanu par iesniegumu Portālā (skat. prasību NFP-58).	RŪ darbinieks sagatavo ziņojumu saistībā ar iesniegumu, to nosūtot uz klienta e-pasta adresi un veicot pieprasījumu EDUS par paziņojuma attēlošanu Portālā.

Citu pakalpojumu pieteikšana

Pakalpojumu pieteikšana (jauni klienti)

42. tabula. Skaidrojums: Pakalpojumu pieteikšana (jauni klienti).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	CPP-1. Sistēmai jānodrošina elektronisku pieteikuma formu aizpildīšana Portāla publiski pieejamajā daļā (skat. prasības FP-27, FP-28, FP-29, FP-30).	Lietotājs ieiet publiskajā portāla saskarnē un izvēlas aizpildīt elektronisku pieteikuma formu.
2.	CPP-2. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās pirms pieteikuma veidlapas aizpildīšanas (skat. prasību NFP-13). CPP-3. Sistēmai jānodrošina informācijas ielasīšana par personu attiecīgajā iesnieguma sadaļā.	Izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentificēšanās informāciju.
3.	CPP-4. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram: a. Adrešu klasifikators; b. RŪ piedāvāto maksas pakalpojumu klasifikators; c. Klasifikators, vai iesniegumu aizpilda kā fiziska vai juridiska persona.	Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas objekta adresi. No klasifikatora izvēlas, vai iesniegumu aizpilda kā fiziska, vai kā juridiska persona.
4.	CPP-5. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus, norādot to veidu, izmantojot klasifikatoru (skat. prasības FP-30 un FP-31). CPP-6. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu. CPP-7. Sistēmai jānodrošina paziņojuma attēlošana par iesnieguma saņemšanu un citu informāciju, kas saistīta ar iesnieguma tālāku apstrādi un pakalpojuma sniegšanu.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Pārskata aizpildīto elektronisko formu skatīšanās režīmā. Apstiprina pieteikuma iesniegšanu.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
5.	CPP-8. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
6.	CPP-9. Sistēmai jānodrošina automātiska e-pasta nosūtīšana personai, kas ir iesniegusi aizpildītu veidlapu, par iesnieguma saņemšanu. E-pastā jābūt iekļautai informācijai par to, ka iesniegums ir saņemts, kā arī jābūt norādītam tā unikālajam identifikācijas numuram un iesnieguma izskatīšanas termiņam.	N/A

Pakalpojumu pieteikšana (esoši klienti)

43. tabula. Skaidrojums: Pakalpojumu pieteikšana (esoši klienti).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	CPP-10. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās (skat. prasību NFP-13).	Xxxxx publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju.
2.	CPP-11. Sistēmai jānodrošina elektronisku pieteikuma formu aizpildīšana klientu portāla saskarnē (skat. prasības FP-27, FP-28, FP-29, FP- 30). CPP-12. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram: a. Adrešu klasifikators; b. RŪ piedāvāto maksas pakalpojumu klasifikators; c. Klasifikators, vai iesniegumu aizpilda kā fiziska vai juridiska persona. CPP-13. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus, norādot to veidu, izmantojot klasifikatoru (piemēram, īpašuma tiesības, nodošanas-pieņemšanas akts, utt.) (skat. prasības FP-30 un FP-31). CPP-14. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu. CPP-15. Sistēmai jānodrošina paziņojuma attēlošana par iesnieguma saņemšanu un citu informāciju, kas saistīta ar iesnieguma tālāku apstrādi un līguma slēgšanu.	Identificē sevi kā objekta īpašnieku, līgumslēdzēju vai personu, kas parakstīs līgumu. Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas objekta adresi. No klasifikatora izvēlas, vai iesniegumu aizpilda kā fiziska, vai kā juridiska persona. Ja nepieciešams, pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Pārskata aizpildīto elektronisko formu skatīšanās režīmā. Apstiprina pieteikuma iesniegšanu.
3.	CPP-16. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
4.	CPP-17. Sistēmai jānodrošina papildus dokumentu pievienošanas funkcionalitāte iesniegumam (skat. prasību FP-33).	RŪ darbinieks sazinās ar klientu par papildus dokumentu nepieciešamību un par to veic atzīmi EDUS. Klients sagatavo elektroniskas dokumentu kopijas, autentificējas Portālā un pievieno iesniegumam papildus dokumentus. Klients apstiprina papildus dokumentu iesniegšanu.
5.	CPP-18. Sistēmai jānodrošina datu saņemšana no EDUS par iesnieguma statusu maiņu (skat. prasību NFP-58).	RŪ darbinieki veic iesnieguma izskatīšanu un attiecīgi manuāli maina iesnieguma statusus EDUS..
6.	CPP-19. Sistēmai jānodrošina rēķinu izrakstīšanas funkcionalitāte par citiem RŪ sniegtajiem pakalpojumiem (skat. nodaļu 3.4.2.), rēķinu korekcijas piemērošanas funkcionalitāte (skat.	Skat. iepriekšējās nodaļas.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
	nodaļu 3.4.3.), rēķinu apmaksas funkcionalitāte (skat. nodaļu 3.5.1.) un debitoru uzskaites un attēlošanas funkcionalitāte (skat. nodaļu 3.5.2.).
7.	CPP-20. Sistēmai jānodrošina datu saņemšana no HORIZON par darba izpildes aktu vai cita pieteiktā pakalpojuma veikšanu apstiprinošu aktu vai dokumentu (skat. prasību NFP-57NFP-57). Ja šāds dokuments ir ticis saglabāts HORIZON, Sistēmai jānodrošina šāda tipa dokumenta attēlošana.	RŪ darbinieks sniedz pieteikto pakalpojumu klientam un sastāda aktu par pakalpojuma veikšanu. RŪ darbinieks pievieno aktu HORIZON. Klients ieiet publiskajā portāla saskarnē un izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentifikācijas informāciju. Klients aplūko visus dokumentus, kas saistīti ar pieteikto maksas pakalpojumu saņemšanu.

Būvniecības dokumentācijas saskaņošana un izsniegšana

Tehniskās dokumentācijas izsniegšana un saskaņošana

44. tabula. Skaidrojums: Tehniskās dokumentācijas izsniegšana un saskaņošana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	BPP-1. Sistēmai jānodrošina elektronisku pieteikuma formu aizpildīšana Portāla publiski pieejamajā daļā (skat. prasības FP-27, FP-28, FP-29, FP-30).	Lietotājs ieiet publiskajā portāla saskarnē un izvēlas aizpildīt elektronisku pieteikuma formu.
2.	BPP-2. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās pirms pieteikuma veidlapas aizpildīšanas (skat. prasību NFP-13). BPP-3. Sistēmai jānodrošina informācijas ielasīšana par personu attiecīgajā iesnieguma sadaļā.	Izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentificēšanās informāciju.
3.	BPP-4. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram: a. Adrešu klasifikators; b. Klasifikators pieteiktajam tehniskās dokumentācijas veidam; c. Klasifikators, vai iesniegumu aizpilda kā fiziska vai juridiska persona.	Aizpilda iesnieguma formas laukus elektroniski. No klasifikatora izvēlas objekta adresi. No klasifikatora izvēlas, vai iesniegumu aizpilda kā fiziska, vai kā juridiska persona.
4.	BPP-5. Sistēmai jānodrošina iespēja iesniegumam pievienot dokumentus, norādot to veidu, izmantojot klasifikatoru (skat. prasības FP-30 un FP-31). Sistēmai jānodrošina iesnieguma izskatīšanai nepieciešamo dokumentu pievienošana kā obligāts priekšnosacījums iesnieguma iesniegšanai Portālā. BPP-6. Portālam jānodrošina iespēja lietotājam pārskatīt iesniegumu un apstiprināt tā iesniegšanu. BPP-7. Sistēmai jānodrošina paziņojuma attēlošana par iesnieguma saņemšanu un citu informāciju, kas saistīta ar iesnieguma tālāku apstrādi un pakalpojuma sniegšanu.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Pārskata aizpildīto elektronisko formu skatīšanās režīmā. Apstiprina pieteikuma iesniegšanu.
5.	BPP-8. Sistēmai jānodrošina izveidotā iesnieguma apstrāde (skat. prasību FP-32).	N/A
6.	BPP-9. Sistēmai jānodrošina automātiska e-pasta nosūtīšana personai, kas ir iesniegusi aizpildītu veidlapu, par iesnieguma saņemšanu. E-pastā jābūt iekļautai informācijai par to, ka iesniegums ir saņemts, kā arī jābūt norādītam tā unikālajam identifikācijas numuram un iesnieguma izskatīšanas termiņam.	N/A

Bojājumu pieteikšana un apstrāde

Pieteikšanās paziņojumu saņemšanai par bojājumiem

45. tabula. Skaidrojums:Pieteikšanās jaunumu saņemšanai par bojājumiem.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RDP-1. Sistēmai jānodrošina elektronisku pieteikuma formu Portāla publiski pieejamajā daļā, lai pieteiktos paziņojumu saņemšanai par bojājumiem un pakalpojumu pārtraukumiem lietotājam interesējošās adresēs. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram RŪ adrešu klasifikators. Formā jāparedz iespēja ievadīt e-pasta adresi, uz kuru saņemt paziņojumus.	Xxxxx publiskajā portāla saskarnē un izvēlas aizpildīt formu. Izvēlas adresi no adrešu klasifikatora un ievada e-pasta adresi, uz kuru saņemt paziņojumus. Apstiprina pieteikumu.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
2.	RDP-2. Kad lietotājs apstiprina formu, sistēmai jānodrošina datu pārbaude pret ziņu saņēmēju sarakstu. Gadījumos, ja uz norādīto e-pasta adresi ir piereģistrēta jaunumu saņemšana par 5 adresēm, sistēmai jāattēlo paziņojums par limita sasniegšanu attiecībā uz e-pasta adresi. Ja e-pasta adrese iepriekš nav tikusi reģistrēta vai ir piereģistrēta jaunumu saņemšanai līdz 5 adresēm, sistēmai jānodrošina e-pasta adreses validācija, uz to nosūtot saiti, kuras atvēršanas gadījumā sistēmai jānodrošina datu saglabāšana un uzglabāšana vienotā reģistrā, kā arī paziņojuma attēlošana par veiksmīgu e-pasta adreses reģistrēšanu.	Gadījumos, kad paziņojumu saņemšanas limits uz adresi nav sasniegts, saņem e-pastu, to atver un nospiež tajā iekļauto validācijas saiti uz portālu. Aplūko paziņojumu par veiksmīgu piereģistrēšanos paziņojumu saņemšanai.
3.	RDP-3. Sistēmai jānodrošina iespēja autorizētiem Portāla lietotājiem veikt abonementu administrāciju ar iespēju dzēst un rediģēt katru abonentu. RDP-4. Sistēmai jānodrošina vienota reģistra uzturēšana un pārvaldība, lai nodrošinātu klientu apziņošanu par bojājumiem un plānotajiem remontdarbiem.
4.	RDP-5. Sistēmai jānodrošina datu saņemšana no ĢIS par adresēm, kurās konstatēti bojājumi vai plānoti remontdarbi kā rezultātā sagaidāmi sniegto pakalpojumu pārtraukumi (skat. prasību NFP-59). E-pasta ziņojumu automātiska nosūtīšana jānodrošina vienas stundas laikā no brīža, kad serveris saņem Pasūtītāja autorizēta pārstāvja ziņojumu. RDP-6. Risinājumam jānodrošina ziņojuma nosūtīšanu atbilstoši klienta norādītajam laikam, ja tāds norādīts. RDP-7. Sistēmai jānodrošina automātiska e-pasta izveide un nosūtīšana vienas stundas laikā no brīža, kad ir tikuši saņemti dati no ĢIS par bojājumiem. Sistēmai jānodrošina paziņojuma nosūtīšana uz tām e-pasta adresēm, kas ir reģistrētas saņemt paziņojumus par bojājumiem konkrētajā adresē. RDP-8. Automātiski izveidotajā e-pastā jāiekļauj informācija, kā persona var atteikties no šādu e-pastu saņemšanas turpmāk.	Saņem e-pastu. Ja pieņem lēmumu pārtraukt ziņojumu saņemšanu par adresi, atver pēdējo saņemto e-pastu un atver tajā ietverto saiti pakalpojuma pārtraukšanai.
5.	RDP-9. Sistēmai jānodrošina paziņojumu nosūtīšanas pārtraukšana un saistīto datu dzēšana, ja klients atteicies no e-pastu saņemšanas. Sistēmai ir jāattēlo paziņojums, ka paziņojumu saņemšana saistībā ar konkrēto adresi uz norādīto e-pastu ir pārtraukta.	Pievieno dokumentu un norāda tā veidu, izmantojot klasifikatoru. Pārskata aizpildīto elektronisko formu skatīšanās režīmā. Apstiprina pieteikuma iesniegšanu.

Bojājumu pieteikšana

46. tabula. Skaidrojums: Bojājumu pieteikšana.

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RDP-10. Sistēmai jānodrošina iespēja Portāla publiskās daļas neautentificētajiem un autentificētajiem lietotājiem, kas ir autorizēti lietotājiem izvēlēties objekta adresi no adrešu reģistra, par kuru lietotājs vēlas pieteikt bojājumu. Papildus tam, sistēmai jānodrošina publiskas pieejamības ĢIS kartes attēlošana par bojājumiem un iespēja tajā lietotājam atzīmēt bojājuma koordinātas.	Xxxxx Xxxxxxx publisko sadaļu un izvēlas pieteikt bojājumu. Izvēlas objekta adresi no adrešu klasifikatora vai atzīmē objekta koordinātas kartē.
2.	RDP-11. Sistēmai jānodrošina datu saņemšana no ĢIS saistībā ar adresē pieteiktajiem bojājumiem (skat. prasību NFP-59). Ja norādītajā adresē jau pieteikts aktīvs un nenovērsts bojājums, tad klientam jāattēlo paziņojums par eksistējošu bojājumu, atspoguļojot vismaz pieteiktā bojājuma veidu un bojājuma reģistrācijas datumu, kā arī jādod izvēle pievienot jaunu bojājumu tajā pašā adresē.	Aplūko sarakstu ar pieteiktajiem bojājumiem adresē. Pieņem lēmumu, vai vēlas pieteikt jaunu bojājumu.
3.	RDP-12. Sistēmai jānodrošina elektroniska pieteikuma forma bojājuma pieteikšanai Portāla publiski pieejamajā daļā (skat. prasību FP-24 Bojājumu un sūdzību ziņojumu pieteikšana). Formas izveidē jāņem vērā prasībā FP-24 aprakstītā funkcionalitāte. RDP-13. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, klasifikators ar iespējamiem bojājuma tipiem, kura izvēle jāparedz kā obligāta pieteikuma iesniegšanai. RDP-14. Formā jānodrošina iespēja veikt atzīmi par to, vai vēlas saņemt ziņojumus par pieteiktā bojājuma statusu. Šīs atzīmes veikšana jāparedz iespējama tikai Portāla autorizētajiem lietotājiem. RDP-15. Sistēmai jānodrošina iespēja pieteikumam pievienot attēlu. RDP-16. Sistēmai jānodrošina iespēja lietotājam apstiprināt pieteikuma iesniegšanu un jāattēlo paziņojums par bojājuma veiksmīgu piereģistrēšanu.	Aizpilda bojājuma pieteikumu, izvēloties pieteiktā bojājuma tipu no klasifikatora. Veic atzīmi gadījumos, ja vēlas saņemt bojājuma statusa ziņojumu uz e-pastu. Ja uzskata par nepieciešamu, pievieno attēlu ar bojājumu. Apstiprina pieteikuma iesniegšanu. Aplūko paziņojumu par veiksmīgu bojājuma piereģistrēšanu.
4.	RDP-17. Sistēmai jānodrošina pieprasījums bojājuma pieteikuma reģistrēšanai ĢIS, nosūtot vismaz pieteikuma informācijas datu laukus un tajos ievadīto informāciju (skat. prasību NFP-59).	N/A
5.	RDP-18. Sistēmai jānodrošina datu saņemšana no ĢIS par pieteiktā bojājuma statusu (skat. prasībuNFP-59). Sistēmai jānodrošina automatizēta e-pasta izveide un izsūtīšana uz norādīto e-pasta adresi, ja autorizēts bojājuma pieteicējs ir veicis atzīmi par tā saņemšanu.	Ja ir veicis atzīmi par e-pasta saņemšanu, saņem e-pastu brīdī, kad RŪ darbinieks ir veicis ierakstam par bojājumu statusa maiņu.

RŪ pārstāvju izsaukšana

47. tabula. Skaidrojums:Pārstāvju izsaukšana (Rakšanas darbiem).

Solis	Prasības Portāla funkcionalitātei	Lietotāja darbības
1.	RDP-1. Sistēmai jānodrošina elektroniska pieteikuma forma Portāla publiski pieejamajā daļā, lai pieteiktos pārstāvju izsaukšanai saistībā ar rakšanas darbiem (skat. prasības FP-27, FP-28, FP-29, FP- 30).	Xxxxx publiskajā portāla saskarnē un izvēlas aizpildīt formu.
2.	RDP-2. Sistēmai jānodrošina fizisku un juridisku personu autentificēšanās pirms pieteikuma veidlapas aizpildīšanas (skat. prasību NFP-13). RDP-3. Sistēmai jānodrošina informācijas ielasīšana par personu attiecīgajā iesnieguma sadaļā, piemēram, vārds, uzvārds, personas kods.	Izvēlas kādu no piedāvātajiem autentificēšanās rīkiem. Ievada un apstiprina autentificēšanās informāciju.
3.	RDP-4. Iesnieguma formā lauku aizpildīšanai jāizmanto klasifikatori, piemēram, apsekojuma tipu klasifikators. Šāda klasifikatora vērtības izvēle un, piemēram, rakšanas atļaujas numura ievade, formā jāparedz kā obligāta. RDP-5. Portālā jāparedz laika un datuma izvēles funkcionalitāte, piesakot RŪ pārstāvja ierašanos (skat. prasību NFP-60). RDP-6. Sistēmai jāparedz iespēja apstiprināt izveidoto pieteikumu.	Izvēlas adresi no adrešu klasifikatora un ievada e-pasta adresi, uz kuru saņemt paziņojumus. Apstiprina pieteikumu.
4.	RDP-7. Sistēmai jānodrošina datu nosūtīšana par izveidoto pieteikumu uz ĢIS (skat. prasību NFP-59). RDP-8. Sistēmai jānodrošina automātiska paziņojuma izveidošana un attēlošana par pieteikuma saņemšanu (skat. prasību FP-26).	RŪ darbinieki saņem datus par izveidoto pieteikumu ĢIS, veic pieteikuma izskatīšanu un konkrēta laika saskaņošanu ar pieteikuma autoru.

Portāla grafiskās vadlīnijas

48. tabula. Potāla grafiskās vadlīnijas.

Elements	Vadlīnijas
Grafiskās zīmes - KLIENTU	Zīme: atvasināta no RĪGAS ŪDENS logotipa horizontālā varianta.
PORTĀLS vadlīnijas	Fonts: Aharoni Bold.
	Krāsa: R-61 G-183 B-228; R-0 G-60 B-105; R-195 G-217 B-215 un
	balta, otrā variantā: R-0 G-60 B-105; R-131 G-175 B-180; R-61 G-183
	B-228 un balta.
	Piemēram:
Grafisko elementu vadlīnijas	Grafiskie elementi pēc iespējas veidojami kā vektorgrafika, nodrošinot
	kvalitatīvu attēlu jebkura fiziskā izmēra un izšķirtspējas ekrānam. To
	simbolika var būt saistāma ar mikro un makro līmeņa elementu - ūdens
	molekulu un grafiski stilizētu ūdens viļņu, Rīgas silueta un citu - radošu
	izmantojumu.
	Piemēram:

Fontu lietojums Portāla tīmekļa vietnē

Izmantojama RU stila grāmata noteiktā Tahoma fontu saime vai PT Sans un Roboto fontu saimes. Xxxxx izmēram proporcionāli jāpielāgojas ekrānam, nodrošinot labu salasāmību. Virsrakstiem var tikt lietoti lielie burti (All Caps, verzāļi).

Piemēram:

Krāsu lietojums Portāla tīmekļa vietnē

Fona laukumiem izmantojama gaiša krāsu palete: balts, RŪ papildkrāsas: pelēkie: R-195 G-217 B-215; R-131 G-175 B-180 un gaiši zilais R-61 G-183 B-228.

Mazāka izmēra laukumiem izmantojamas RŪ papildkrāsas: R-0 G-154 B-217; R-0 G-60 B-105 un R-0 G-47 B-95.

Lapas apakšdaļā (kājenē) izmantojams RŪ stila grāmatā piedāvātais krāsu salikums: zilais R-0 G-84 B-159 un pelēkie: R-195 G-217 B-215; R-131 G-175 B-180.

Krāsu akcentam, piemēram, dažādās ikonās iespējams izmantot sekojošas RŪ papildkrāsas: R-254 G-209 B-0; R-255 G-161 B-0; R- 227 G-114 B-34; R-0 G-155 B-72; R-97 G-194 B-80.

Piemēram:

Informācijas izvietojums Portāla pirmajā lapā

Shematiski iespējamais Portāla zonu attēlojums parādīts attēlā.

Portāla galvene – ietver logo zonu, meklēšanas funkcionalitāti un valodas izvēli;

Portāla lapas pamatdaļa ietver šādas zonas:

• aktuālās informācijas zona;

• lietotāju funkciju izvēles zona:

o ļauj izvēlēties funkciju, kuru rezultāts tiks atspoguļots lietotāja aktivitāšu zonā

•

•

lietotāja aktivitāšu zona:

o ļauj strādāt ar izvēlēto funkcionalitāti pieslēgšanās un profila pārvaldības zona:

o ļauj pieslēgties sistēmai un pārslēgties starp vairākiem līgumiem vai objektiem

o pieslēgšanās zonā jāattēlo Portāla funkcionalitāte, kas pieejama tikai autorizētiem Portāla lietotājiem

Portāla kājene – attēlo informāciju par saziņu ar Pasūtītāju un par tīmekļa vietni.

Grafiskā dizaina piemēri Portāla sākumlapai

Prasības Tehniskā piedāvājuma sagatavošanai

Pretendentiem jāizstrādā Tehniskais piedāvājums, aprakstot katras Tehniskajā specifikācijā (turpmāk – TS) definētās prasības realizāciju. Prasību realizācijas aprakstos jāsniedz informācija, kā tiks izpildīta konkrētā prasība, x.xx. pielietotās metodes un tehnoloģiju prasības tās realizācijai. Tehniskajam piedāvājumam jāatspoguļo Pretendenta izpratne par Pasūtītāja vajadzībām. Projekta Izpildītājam jānodrošina visas TS minētās prasības.

Izpildītājam ir jāveic Portāla izstrāde un ieviešana, izmantojot autonomu izstrādes vidi, testēšanas vidi, akcepttestēšanas vidi un produkcijas vidi, integrācija ar ārējām informācijas sistēmām, sākotnējā satura ievade, datu migrācija, Pasūtītāja administratoru apmācība, dokumentācijas sagatavošana u.c. darbi, lai pilnībā nodrošinātu šīs TS prasību izpildi un Izpildītāja Tehniskajā piedāvājumā piedāvāto funkcionalitāti.

Pretendentiem Tehniskajā piedāvājumā jānodrošina šāda informācija, atbilstoši TS “Portāla prasību apraksts” nodaļā minētajām prasībām:

1. Funkcionālo prasību risinājumu apraksts – piegādājamā risinājuma apraksts, iekļaujot:

1.1. Vispārējās funkcionālās prasības;

1.2. Lietotāja saskarņu funkcionālās prasības;

1.3. Klientu portāla saskarņu funkcionālās prasības;

1.4. Administrēšanas funkcionālās prasības.

2. Nefunkcionālo prasību risinājuma apraksts – piegādājamā risinājuma apraksts, iekļaujot:

2.1. Risinājuma loģisko arhitektūru;

2.2. Portāla veiktspējas prasības. Ja esošā infrastruktūra (skat. 1.2.1. nodaļa) nenodrošina risinājuma funkcionalitāti, piedāvājumam jāpievieno nepieciešamās tehniskās infrastruktūras specifikācija, kas ir nepieciešama veiktspējas parametru izpildei un risinājumam;

2.3. Portāla drošības prasības;

2.4. Portāla lietojamības prasības;

2.5. Risinājumu ieviešanas pieeju;

2.6. Portāla integrācijas prasības;

2.7. Ieviesto risinājumu testēšanas pieeju, ietverot:

2.7.1.Drošības testēšanu; 2.7.2.Lietojamības testēšanu; 2.7.3.Veiktspējas testēšanu; 2.7.4.Akcepttestēšanu.

3. Projekta izpildes organizācijas pieeja:

3.1. Projekta komunikācijas vadības aprakstu;

3.2. Projekta izmaiņu vadības modeli;

3.3. Projekta laika grafiku (kurā ietverti tai skaitā Līguma projekta 1.3.1.-1.3.5.punktos norādītie posmi);

3.4. Projekta nodevumu prasības;

3.5. Problēmu ziņojumu pārvaldības un garantijas pakalpojumu sniegšanas pieeja.

SIA „Rīgas ūdens” SIA „Softikom”

Valdes priekšsēdētāja Xxxxxxx Xxxxxxx

Valdes locekle

Xxxxx Xxxxxxx