Nefunkcionālās prasības

__.__.2020 Pakalpojumu līguma Nr.____________________

Par programmatūras izstrādi un pielāgošanu

2.pielikums

Nefunkcionālās prasības

Saturs

1. Vispārīgās nefunkcionālās prasības 2

1.1. NFP-01 Pieteikumu, uzdevumu reģistrēšana 2

1.2. NFP-02 Elektroniskā kopdarbības vide 2

1.3. NFP-03 Nodevumu iesniegšana 2

1.4. NFP-04 Prasības Nodevumu dokumentācijai 3

1.5. NFP-05 Programmatūras koda dokumentēšana 4

1.6. NFP-06 Nodevumu pieņemšana un akceptēšana 4

1.7. NFP-07 Pieteikumu pieteikšana, risināšana un reakcijas laiki 4

2. Prasības Nodevuma arhitektūrai 5

2.1. NFP-08 Klienta-servera lietojumprogramma 5

2.2. NFP-09 Datu glabāšana Nodevumā 6

2.3. NFP-10 Veiktspējas un ātrdarbības prasības 6

2.4. NFP-11 Nodevuma mērogojamība 6

3. Lietotāja saskarnes prasības 7

3.1. NFP-12 Vispārīgās lietotāju saskarnes prasības 7

3.2. NFP-13 HTML un CSS standarti 7

3.3. NFP-14 Pārlūkprogrammu atbalsts 7

3.4. NFP-15 Valodas atbalsts lietotāja saskarnei 7

4. Drošības prasības 8

4.1. NFP-16 Vispārējās drošības prasības Nodevumam 8

4.2. NFP-17 Neautentificētam lietotājam atļautās darbības 8

4.3. NFP-18 Lietotāja identificēšana un autentificēšana 8

4.4. NFP-19 Identificēšanas un autentificēšanas mehānisms 8

4.5. NFP-20 Lietotāju lomas 8

4.6. NFP-21 Sesijas pārtraukšana 9

4.7. NFP-22 Aizsardzība pret automatizētiem datu iegūšanas rīkiem 9

4.8. NFP-23 Informācijas aizsardzības principi 9

4.9. NFP-24 Auditācijas pierakstu veidošana 9

4.10. NFP-25 Auditācijas pierakstā iekļaujamā informācija 9

4.11. NFP-26 Par serveri izpaužamās informācijas minimizācija 10

4.12. NFP-27 Aizsardzība pret SQL injekciju uzbrukumiem 10

5. Prasības uzturamībai 10

5.1. NFP-28 Prasības tehnoloģiju atbalstam 10

5.2. NFP-29 Drošība uzturēšanas darbu laikā 10

1.Vispārīgās nefunkcionālās prasības

1.1.NFP-01 Pieteikumu, uzdevumu reģistrēšana

Pieteikumi (vai uzdevumi) tiks reģistrēti Pasūtītāja rīcībā esošajā elektroniskajā kopdarbības vidē, kas izveidota izmantojot Microsoft Team Foundation Server (TFS). Izpildītāja pienākums ir Pasūtītāja elektroniskās kopdarbības vides sistēmā reģistrētos pieteikumus pārņemt savā elektroniskajā kopdarbības vidē, taču tālākā pieteikumu saskaņošana un risināšana tiek veikta, izmantojot Pasūtītāja elektroniskās kopdarbības vides sistēmu. Pasūtītāja pienākums ir nodrošināt automātisku e-pastu nosūtīšanu par pieteikumiem Izpildītājam.

1.2.NFP-02 Elektroniskā kopdarbības vide

Izpildītājam jānodrošina visu nodevumu reģistrēšana Pasūtītāja elektroniskajā koplietošanas vidē TFS, kas pieejama Izpildītājam līguma izpildes laikā un garantijas periodā. Elektroniskajā koplietošanas vidē jānodrošina šādas Pasūtītāja un Izpildītāja kopdarbības, kas ļaus:

1. plānot un uzturēt projekta grafikus, rezervēt resursus un veidot darba vienumus un to hierarhijas;

2. izsekot projekta darba vienumus: prasības, lietotāju stāstus, darba uzdevumus, kļūdas, tehniskos risinājumus, testpiemērus, kā arī šo darba vienumu savstarpējās saites un katra darba vienuma pilnu izmaiņu vēsturi; jābūt iespējai izmantot MS Excel vai MS Project darba vienumu izsekošanai un atjaunošanai;

3. centrālā repozitorijā glabāt programmatūras izejas kodu un dokumentāciju, pielietojot paņemt/atdot procedūras (Check-out/Check-in) un asociējot tās ar darba vienumiem;

4. iegūt pilnu programmatūras izejas koda un dokumentācijas komplektu uz jebkuru, Pasūtītāja izvēlētu datumu;

5. iegūt informāciju par konkrēta koda apgabala (līdz pat rindiņai) autoru, kā arī pēdējo veikto izmaiņu datumu un laiku, kā arī darba vienumus, ar ko šīs izmaiņas saistītas;

6. veikt iespējami agrīnas testēšanas plānošanu;

7. veikt būvējumu automātisku pārvaldību, nodrošinot programmatūras kompilēšanu un automātisku būvējuma uzstādīšanu Pasūtītāja rīcībā esošās Sistēmas testa un produkcijas vidēs;

8. darba izpildes rezultāta glabāšanu un saskaņošanu;

9. iegūt pārskatus par projekta un konkrētas iterācijas norisi un aktuālo situāciju uz doto brīdi, analizēt komandas retrospekcijas, vērtēt izstrādes kvalitāti, būvējumu izpildes statusus, izejas koda izmaiņas, patērētos resursus un to izmantošanas efektivitāti, reālā laikā atainot rezultatīvos rādītājus kontroles panelī, balstoties uz kopdarbības vides datu noliktavā uzkrātajiem projekta datiem;

10. nodrošināt interviju pierakstu, demonstrāciju materiālu un citu darba dokumentu glabāšanu ar versiju kontroli un visu citu nepieciešamo projekta informācijas glabāšanu un pārvaldību.

1.3.NFP-03 Nodevumu iesniegšana

Līguma ietvaros darbu izpildes rezultātā, kā arī pēc jebkādu izmaiņu veikšanas garantijas laikā, Izpildītājs sagatavo un nodod Pasūtītājam šādus nodevumus:

1. Programmatūras projektējuma aprakstu, papildinot tā saturu ar uzturēšanas periodā Nodevumā veikto izmaiņu aprakstu,

2. Administratora rokasgrāmatu, papildinot tās saturu ar uzturēšanas periodā Nodevumā veikto izmaiņu aprakstu

3. Lietotāju rokasgrāmatu, papildinot tās saturu ar uzturēšanas periodā Nodevumā veikto izmaiņu aprakstu,

4. Izstrādāto Nodevuma un gatavās programmatūras pielāgojumu pirmkodi, izpildkodi un konfigurācijas datnes (skriptus).

Ja objektīvu iemeslu dēļ kāds no nodevumiem nav iespējams vai nav nepieciešams, tad to atzīmē izpilddokumentācijā.

Dokumentācijai jābūt noformētai latviešu valodā.

Atbilstoši nodevuma saturam, Pasūtītājs veic instalācijas testus, uzstādot piegādāto versiju Pasūtītāja testa vidē. Izpildītājs nodrošina instalācijas atbalstu pēc Pasūtītāja pieprasījuma. Ja testi ir neveiksmīgi, tālāka nodevuma akceptēšana tiek pārtraukta.

1.4.NFP-04 Prasības Nodevumu dokumentācijai

Nodevuma izstrādātājiem ir jānodrošina šāda IS dokumentācija par izpildītajiem darbiem:

1. Programmatūras projektējuma aprakstu, iekļaujot:

   1. Nodevuma uzbūves un darbības principus,

   2. informācija par Xxxxxxxx darbības iespējām un ierobežojumiem,

   3. izmantoto tehnoloģiju un to komponentu aprakstus,

   4. detalizēts datu moduļa apraksts, iekļaujot detalizāciju līdz konkrētu reģistru lauku līmenim,

   5. lietotāja saskarnes projektējumu grafiskā formātā,

   6. lietotāju lomu un tiesību aprakstu.

2. Administratora rokasgrāmatu, iekļaujot:

   1. Nodevumā iekļauto izmaiņu aprakstu,

   2. Infrastruktūras topoloģija un konfigurācijas parametri, lai nodrošinātu nefunkcionālo prasību izpildi,

   3. instalācijas apraksts, norādot nepieciešamos instalācijas un konfigurācijas parametrus, nodrošinot pasūtītājam iespēju bez izpildītāja līdzdalības veikt risinājuma uzstādīšanu un konfigurēšanu Pasūtītāja infrastruktūrā,

   4. versijas izveides un uzstādīšanas instrukciju, izmantojot elektroniskās kopdarbības vides automātiskos būvējuma procesus,

   5. jāiekļauj visau Nodevuma moduļu saskarņu, protokolu un portu aprakstu,

   6. Nodevuma konfigurācijas aprakstu,

   7. Datu bāzes uzbūves struktūru (datu modeļus ar aprakstiem, datu vārdnīcu ar validācijas kārtulām).

   8. Iespējamās darbības Nodevuma ietvaros noteiktas informācijas izmaiņu veikšanai gadījumos, ja tiek ievadīta neprecīza informācija.

   9. Lietotāju pārvaldības procesu, iekļaujot pieejas tiesību piešķiršanas un administrēšanas aprakstu.

   10. Nodevuma rezerves kopiju veidošana un datu vai visas sistēmas darbības atjaunošanas process,

   11. auditācijas žurnalēšanas ierakstu parametru aprakstu.

3. Lietotāju rokasgrāmatu, iekļaujot:

   1. Nodevumā veikto izmaiņu aprakstu

   2. informācija par IS lietotāju iespējām veikt noteiktas informācijas ievadi, tās papildināšanu un labošanu un dzēšanu, iekļaujot, detalizētus lietošanas scenāriju aprakstus ar ekrānšāviņiem un komentāriem par veicamajām darbībām katra soļa ietvaros,

   3. atskaišu veidošanu,

   4. dažādām lietotāju lomām.

4. Ja objektīvu iemeslu dēļ kāda no prasībām nav iespējama vai nav nepieciešama, tad to atzīmē izpilddokumentācijā.

1.5.NFP-05 Programmatūras koda dokumentēšana

Izpildītājam viss programmatūras izejas kods ir jākomentē un jādokumentē atbilstoši labajai programmatūras izstrādes praksei. Programmatūras pirmkoda komentāriem jāsatur vismaz šāda informācija: funkcijas atribūtu apraksts, tai skaitā tās uzdevumu, parametru, paredzamo kļūdu, iespējamo rezultātu uzskaitījums un detalizējums (metožu līmenī).

1.6.NFP-06 Nodevumu pieņemšana un akceptēšana

Izpildītājs Pakalpojumus Pasūtītājam:

1. katrā atsevišķā pasūtījumā sniedz pēc vienošanās, iepriekš savstarpēji saskaņojot konkrētu Pakalpojumu pieņemšanas – nodošanas vietu un laiku.

2. sniedz, izmantojot sekojošu pasūtījuma apstrādes kārtību:

   1. Pēc saņemtā pasūtījuma, Izpildītājs veic tā novērtējumu un divu darba dienu laikā informē Pasūtītāju par nepieciešamo darba apjomu un iespējamo pasūtījuma izpildes termiņu. Pamatojoties uz Izpildītāja sniegto novērtējumu, Pasūtītājs apstiprina vai neapstiprina pasūtījuma izpildes uzsākšanu.

   2. Jebkādas izmaiņas ar Pakalpojumu saistītajā darba uzdevumā, pēc šāda uzdevuma iesniegšanas Izpildītājam, notiek tikai abpusēji vienojoties un fiksējot to kā pielikumu pie konkrētā pasūtījuma.

3. Par pasūtījuma piegādes brīdi tiek uzskatīts brīdis, kad Izpildītājs izpilda “NFP-03 Nodevumu iesniegšana” prasību.

4. Pasūtījuma pieņemšana notiek 20 (divdesmit) darba dienu laikā pēc pasūtījuma piegādes, to pieņemot vai reģistrējot Izpildītājam konstatētās neatbilstības pasūtījumam.

5. Pasūtījuma pārcelšanu uz produkcijas vidi, pēc testēšanas un akceptēšanas veic Pasūtītājs, vajadzības gadījumā pieaicinot Izpildītāju kā konsultantu.

6. Kļūdas, kuras konstatētas testēšanas laikā, tiek nodotas visas vienā pieprasījumā, ja vien tās nav kritiskas kļūdas, dēļ kurām nav iespējams veikt vai turpināt testēšanu kā tādu. Kritiskās kļūdas tiek nodotas pa vienai vienā pieprasījumā, pievienojot arī visas nekritiskās kļūdas, kas konstatētas līdz kritiskās kļūdas rašanās brīdim.

7. Pakalpojumu pieņemšana – nodošana tiek noformēta ar Pakalpojumu pieņemšanas – nodošanas akta vai Izpildītāja izrakstīta rēķina, kas apliecina Pakalpojumu pieņemšanu – nodošanu, abpusēju parakstīšanu. Ja pieņemšanas – nodošanas ietvaros tiek konstatētas kādas neatbilstības prasībām, Izpildītājam tās jānovērš bez papildus samaksas.

8. Pakalpojumu izpilde, ja Pasūtītājs to akceptē, var tikt sadalīta pa posmiem atbilstoši veicamajiem uzdevumiem un sasniedzamajiem rezultātiem, par katru no posmiem Izpildītājs izpilda “NFP-03 Nodevumu iesniegšana” prasības un Puses sastāda atsevišķu Pakalpojumu pieņemšanas – nodošanas aktu.

9. Jautājumi par Pakalpojumu atbilstību šī Līguma noteikumiem tiek risināti Pusēm savstarpēji vienojoties. Ja vienoties neizdodas, Pasūtītājs ir tiesīgs pieaicināt ekspertu ar atbilstošo kompetenci.

1.7.NFP-07 Pieteikumu pieteikšana, risināšana un reakcijas laiki

Garantijas uzturēšanas, atbalsta un uzturēšanas pakalpojumi tiek pieteikti, izmantojot sekojošas kategorijas:

1. Avārija – Nodevuma vai atsevišķas tās funkcionalitātes darbības atteikums, tādējādi liedzot Pasūtītājam tajā veikt biznesa procesus pilnā apmērā.

2. Kļūda, neprecizitāte – Nodevuma kādas atsevišķas funkcionalitātes nekorekta darbība, tādējādi liedzot vai apgrūtinot Pasūtītājam tās izmantošanu pilnā apmērā;

3. Konsultācija – Pasūtītāja pieprasījums sniegt palīdzību Nodevuma lietošanā, izmaiņu pieprasījuma sagatavošanā u.tml.

Xxxxxx Xxxxxxxxxx uzturēšanas, atbalsta un uzturēšanas pakalpojuma pieteikumam (turpmāk – uzturēšanas pieteikums) tiek noteikta prioritāte:

1. Kritisks – problēma lietojumprogrammatūrā, kas apstādina IS vai tās kritiskas daļas darbību un kuras seku rezultātā IS lietošana vai datu transportēšana nav iespējama līdz problēmas novēršanai.

2. Steidzams – apzīmē problēmu lietojumprogrammatūrā, kas negatīvi ietekmē IS funkciju izpildi, taču ir zināms problēmas pagaidu risinājums, vai apzīmē izmaiņu pieprasījumu, kuru nepieciešams steidzīgi izpildīt.

3. Parasts – jebkura veida uzdevums, kas saistīts ar IS darbības nodrošināšanu.

Pieteikumiem ar kategoriju “Avārija” vienmēr tiek piešķirta prioritāte “Kritisks”.

Izpildītājam Nodevuma izstrādāšanas, garantijas un uzturēšanas fāzēs jānodrošina šāda pakalpojumu pieejamība:

1. darba dienās no plkst. 8:30 līdz plkst. 17:15

2. „Kritiskas” prioritātes pieteikuma gadījumā darba dienās no plkst. 8:00 līdz plkst.20:00

3. “Avārijas” kategorijas ar “kritisku” prioritāti gadījumā – 24/7 režīmā līdz problēmas novēršanai

Reakcijas un izpildes laikiem darba dienās uz dažādu kategoriju uzdevumiem jābūt šādiem:

Prioritāte	Reakcijas laiks	Izpildes laiks
Kritisks	Ne vairāk kā 4 darba stundas	Ne vairāk kā 12 darba stundas vai abpusēji saskaņotā termiņā
Steidzams	Ne vairāk kā 8 darba stundas	Ne vairāk kā 3 darba dienas vai abpusēji saskaņotā termiņā
Parasts	Ne vairāk kā 24 darba stundas	Ne vairāk kā 5 darba dienas vai abpusēji saskaņotā termiņā

Reakcijas laiks – laiks, kurā Izpildītājam ir jāpaziņo Pasūtītājam par pieteikuma saņemšanu, pieteiktās problēmas novēršanas aprakstu un plānoto novēršanas laiku.

Izpildes laiks – laiks, kurā Izpildītājam ir jāizpilda un jāpiegādā Pasūtītājam pieteikuma risinājums. Izpildes laiku ir iespējams pārskatīt, Izpildītājam un Pasūtītājam attiecīgi par to vienojoties.

2.Prasības Nodevuma arhitektūrai

2.1.NFP-08 Klienta-servera lietojumprogramma

Nodevumam jābūt realizētai balstoties uz web bāzētu klienta-servera lietojumprogrammu modeli, t.i., vienota un centralizēta lietojuma programmatūra un/vai datu bāze, ar iespēju tai pieslēgties daudziem vienlaicīgiem, teritoriāli izkliedētiem, lietotājiem, kuri pieslēgumam izmanto TCP/IP veida tīkla savienojumu, standarta interneta pārlūkprogrammu un HTTP/HTTPS datu pārraides protokolu.

Ja Nodevuma realizācijai nav nepieciešama klienta-servera arhitektūra, tad detalizētas analīzes laikā, racionāli pamatojot šādu lēmumu, Izpildītājs var vienoties ar Pasūtītāju par savādākas arhitektūras izvēli.

2.2.NFP-09 Datu glabāšana Nodevumā

Datu glabāšanai Nodevumā jāizmanto relāciju datu bāzu vadības sistēma un relāciju datu modelis. Relāciju datu modelim kopumā jābūt normalizētā veidā. Ir pieļaujamas atsevišķas atkāpes no datu modeļa normalizācijas (datu modeļa denormalizācija), kā arī datu glabāšanas principi specializētiem nolūkiem (piemēram, meklēšanas risinājuma funkcionalitātes nodrošināšanai u.tml.). Katrai šādai atkāpei ir jābūt argumentētam un racionālam pamatojumam, kas dokumentēts Nodevuma tehniskajā dokumentācijā. Normalizēta datu modeļa lietošanas mērķis ir:

1. izvairīties no liekas datu glabāšanas, x.xx. liekas datu dublēšanās;

2. nodrošināt ciešāku datu modeļa atbilstību ar reālās pasaules objektiem, procesiem un to attiecībām (relācijām), tādejādi padarot to vieglāk saprotamu;

3. strukturēt datus tā, lai datu modelis būtu elastīgs.

Ja Nodevuma realizācijai datu glabāšanai nav nepieciešama relāciju datu bāzu vadības sistēma, tad detalizētas analīzes laikā, racionāli pamatojot šādu lēmumu, Izpildītājs var vienoties ar Pasūtītāju par savādākas datu glabāšanas izvēli.

2.3.NFP-10 Veiktspējas un ātrdarbības prasības

Nodevumam normālas noslodzes apstākļos ir jānodrošina:

1. datu izvadformas ielādes vidējais laiks ne ilgāk par 2 sekundēm;

2. datu ievadformā ievadīto datu saglabāšana Nodevumā ne ilgāk par 5 sekundēm;

3. sinhrono Web servisu pieprasījumu apstrāde nedrīkst pārsniegt 2 sekundes;

4. informācijas attēlošana Nodevuma meklēšanas sarakstos ar specifisku meklēšanas parametru/atslēgu ievadu – ne ilgāk par 5 sekundēm;

5. interaktīvas atskaites sagatavošanai uz ekrāna ir jāizpildās ne ilgāk kā 10 sekundes.

Nodevumam ekstremālos noslodzes apstākļos ir jānodrošina:

1. datu izvadformas ielādes vidējais laiks ne ilgāk par 3 sekundēm;

2. datu ievadformā ievadīto datu saglabāšana Nodevumā ne ilgāk par 8 sekundēm;

3. sinhrono Web servisu pieprasījumu apstrāde nedrīkst pārsniegt 3 sekundes;

4. informācijas attēlošana Nodevuma meklēšanas sarakstos ar specifisku meklēšanas parametru/atslēgu ievadu – ne ilgāk par 8 sekundēm;

5. interaktīvas atskaites sagatavošanai uz ekrāna ir jāizpildās ne ilgāk kā 15 sekundes.

Gadījumos, kad kāda procesa, kurš ietekmē lietotāja saskarnes elementu attēlošanu, plānotais izpildes laiks ir lielāks par 3 sekundēm lietotājs jāinformē ar attiecīgu paziņojumu vai grafisku elementu.

Minētā ātrdarbība jānodrošina, ņemot vērā reālu datu bāzu aizpildījumu ražošanas režīmā.

Detalizētās analīzes laikā Izpildītājs var, saskaņojot ar Pasūtītāju, precizēt atsevišķu Nodevuma funkciju izpildes laikus, kas ir atšķirīgi no šajā prasībā minētajiem, ja ir racionāls pamatojums tam, ka attiecīgajām funkcijām ir nepieciešami atšķirīgi izpildes laiki.

Veicot ātrdarbības mērījumus, tie jāveic no klienta darbstacijas, kas Nodevumam pieslēgta lokālajā datortīklā un uz kuras tiek veiktas (simulētas) viena lietotāja darbības ar Nodevumu. Pasūtītājs ātrdarbības mērījumu veikšanai nodrošina tehnisko infrastruktūru atbilstoši Nodevuma platformas izstrādātāja minimālajām tehniskajām rekomendācijām.

2.4.NFP-11 Nodevuma mērogojamība

Projektējot un ieviešot Nodevumu, lai nodrošinātu augstu pieejamību un veiktspēju, Izpildītājam ir jāņem vērā nepieciešamība atbalstīt Nodevuma darbināšanai izmantotā infrastruktūras mērogojamību, paredzot, ka var tikt veikta gan vertikāla (Scale-Up - palielinot esošo komponenšu jaudu/kapacitāti), gan horizontāla (Scale-Out - pievienojot jaunas papildus komponentes, piemēram - papildus serveri pieprasījumu apstrādei) infrastruktūras mērogojamību.

3.Lietotāja saskarnes prasības

3.1.NFP-12 Vispārīgās lietotāju saskarnes prasības

Nodevuma lietotāju saskarnei jāatbilst šādām prasībām:

1. Lietotāji darbam ar Nodevumu izmanto interneta pārlūkprogrammu, detalizētas analīzes laikā Izpildītājs ar Pasūtītāju var vienoties par cita veida Nodevuma lietotāja saskarni.

2. Lietotāju saskarnes jāveido vizuāli pievilcīgas, ērtas lietošanā, pieskaņotas Nodevuma lietošanas scenārijiem, lai ar minimālu darbību skaitu panāktu nepieciešamo rezultātu.

3. Veidojot lietotāju saskarnes dizainu, saskaņojot ar Pasūtītāju, lieto Pasūtītāja logo un citus korporatīvās identitātes elementus atbilstoši Pasūtītāja stila grāmatai.

Nodevuma lietotāja interfeisam ir jābūt orientētam uz lietotāju:

1. Ekrānformās ir jāizmanto lietotājam viegli saprotama terminoloģija, piemērojot nozares „labās prakses” pieredzi;

2. Apzīmējot vienu un to pašu elementu vai datu lauku dažādās ekrānformās, jābūt izmantotiem vieniem un tiem pašiem terminiem un grafiskajām zīmēm;

3. Ekrānformās ir jāiekļauj lietotāja pamācības, kā konkrēto lauku vai formu aizpildīt un kādas ir tajā pieļaujamās ievades vērtības;

4. Datu ievades un apstrādes secībai ir jāatbilst tipiska lietotāja darba procesam;

5. Visos gadījumos ir jābūt skaidri norādītai konkrētai darbībai, kuru veic lietotājs, kā arī skaidri saprotamas norādes, kā pārtraukt vai pabeigt iesākto darbību;

6. Kļūdu un ārkārtas situāciju aprakstiem ir jābūt skaidriem un lietotājam saprotamiem, tieši norādot, kāda darbība tiek sagaidīta no lietotāja.

3.2.NFP-13 HTML un CSS standarti

Kodam ir jābūt veidotam saskaņā ar HTML un CSS standartiem. Lietotāja funkcionalitātes izstrādē ieteicams lietot HTML5, CSS3, jQuery, jQueryUI, AJAX un citas populāras un atzītas tehnoloģijas, kas uzlabo lietotāja saskarni un rada ērtu darba vidi.

Ja Nodevumu paredzēts izmantot arī uz mobilajām iekārtām ar mobilajām pārlūkprogrammām, Nodevuma lietotāja saskarne izstrādājama, izmantojot reaģējošu tīmekļa lapas dizainu (responsive web design). Nodevuma detalizētas analīzes laikā, sagatavojot tehnisko dokumentāciju, skaidri jānorāda, vai Nodevumu paredzēts lietot mobilajās iekārtās un kuras Nodevuma daļas tiek sagatavotas šādām vajadzībām.

3.3.NFP-14 Pārlūkprogrammu atbalsts

Tīmekļa vietnes uzlabojumiem ir jānodrošina šādu pārlūkprogrammu pēdējos divos gados izdoto versiju atbalstu:

1. Internet Explorer vai Microsoft Edge;

2. Mozilla Firefox;

3. Google Chrome;

4. Safari.

Ja lietotājs izmanto citu pārlūkprogrammu vai tās versiju kā norādīts augstāk minētā sarakstā, tad lietotājam jāparāda pamanāms paziņojums ar atbalstītajām pārlūkprogrammām un funkcionalitātes iespējamiem ierobežojumiem.

3.4.NFP-15 Valodas atbalsts lietotāja saskarnei

Nodevumam ir jānodrošina daudzvalodu atbalsts (x.xx., sagatavota tulkojuma pievienošana Nodevumam kā arī pārslēgšanās starp Nodevumā pievienotajām valodām) lietotāja saskarnē, par pamatu (bāzes versiju) un kā noklusēto valodu Nodevuma gala lietotāju saskarnei izmantojot latviešu valodu (Nodevuma administrēšanas lietotāja saskarne var būt angļu valodā, atbilstoši izvēlētajai Nodevuma platformai). Nodevuma lietotāja saskarnē ir jāizmanto UTF-8 kodējums.

Daudzvalodu atbalstam jābūt realizētām vismaz attiecībā uz sekojošiem elementiem:

1. virsrakstiem, izvēlnēm un lauku nosaukumiem (aprakstiem, uzaicinājumiem) ievadformās un dialogos;

2. ekrāna uzziņas (palīdzības) aprakstiem, neatkarīgi no to attēlošanas veida/vietas (statusa rindā, kā 'peldošais' teksts, atsevišķā logā u.tml.), kā arī kļūdu, brīdinājumu un informatīvajiem vai jebkura cita veida paziņojumiem, ko Nodevums rāda lietotājiem.

Sekojošos gadījumos ir pieļaujamas sekojošas atkāpes no šīs prasības:

1. atsevišķu kļūdu un brīdinājumu gadījumā – atsevišķi un īpaši izceļot, ir pieļaujams attēlot detalizētu informāciju par kļūdu citā valodā (kas ir atšķirīga no lietotāja izvēlētās valodas); šīs atkāpes gadījumā lietotājam lietotāja izvēlētajā saskarnes valodā ir jāsaņem arī norādes par nepieciešamo tālāko rīcību;

2. ja kādā no programmatūras vienībām izmanto operētājsistēmas koplietošanas lietotāja saskarnes resursus (piemēram, 'Save As' dialogu, 'Print' dialogu u.tml.), tad šiem resursiem lietotāja saskarnes elementi var būt tādā valodā, kāda uzstādīta operētājsistēmā lietotāja saskarnei.

Izpildītājam ir jāpiegādā viens Nodevuma gala lietotāju saskarnes valodas komplekts - latviešu valodā (administrēšanas saskarnes var būt angļu valodā, atbilstoši izvēlētajai Nodevuma platformai).

Daudzvalodu atbalsts var netikt nodrošināts, par to vienojoties ar Pasūtītāju detalizētas analīzes laikā, atbilstoši Nodevuma realizācijai izvēlētās platformas īpatnībām.

4.Drošības prasības

4.1.NFP-16 Vispārējās drošības prasības Nodevumam

Nodevuma saskarnēm jābūt izveidotām tā, lai nevarētu apiet autentifikācijas un autorizācijas procedūras un nesankcionēti lietot Nodevuma informāciju vai datnes. Lietotāji nedrīkst piekļūt Nodevumam glabājamai informācijai, apejot drošības kontroles programmas, piemēram, operētājsistēmas, failu Nodevuma vai datu bāzes līmenī.

Nodevuma arhitektūrai jābūt izveidotai tā, lai samazinātu potenciālos drošības apdraudējuma riskus. Nodevumā jāizveido pietiekami kontroles mehānismi, lai nodrošinātu, ka konfidenciāla informācija, kas uzticēta Nodevumam gan tās pārraides, gan glabāšanas laikā, netiks atklāta personām vai programmām, kurām nav attiecīgas autorizācijas.

4.2.NFP-17 Neautentificētam lietotājam atļautās darbības

Izpildītājam detalizētās analīzes laikā jāizveido un ar Pasūtītāju jāsaskaņo saraksts ar darbībām, kuras Nodevumam atļauj veikt neidentificētam un neautentificētam lietotājam.

4.3.NFP-18 Lietotāja identificēšana un autentificēšana

Nodevumam jānodrošina, ka lietotājs tiks sekmīgi identificēts un autentificēts, pirms tiek atļauta jebkāda cita darbība ar Nodevumu, kas nav minēta prasībā "Neautentificētam lietotājam atļautās darbības" minētajā sarakstā.

4.4.NFP-19 Identificēšanas un autentificēšanas mehānisms

Lietotāju identificēšanai un autentificēšanai ir jāizmanto Pasūtītāja rīcībā esošā infrastruktūra, kas realizēta, izmantojot Microsoft Active Directory, x.xx. Single-Sign-On scenāriju nodrošināšanai – Active Directory Federation Service (ADFS), kas nodrošina vienotu lietotāju identifikāciju un autentifikāciju.

4.5.NFP-20 Lietotāju lomas

Nodevumam ir jāatbalsta lietotāju lomu (grupu) uzturēšana un izmantošana. Detalizētās analīzes laikā iespējams noteikt Microsoft Active Directory izmantošanu atbilstošu lietotāju lomu (grupu) uzturēšanai.

4.6.NFP-21 Sesijas pārtraukšana

Nodevumam jānodrošina, ka lietotāja sesija tiks pārtraukta:

1. ja lietotājs pats iniciē sesijas pārtraukšanu (Log Out), x.xx. citas Sistēmas ietvaros, ja Nodevums izmanto Pasūtītāja vienotu Single-Sign-On servisu (piemēram, ADFS).

2. Nodevums automātiski pārtrauc lietotāja sesiju, ja lietotājs nav veicis nekādas darbības ar Nodevumu noteiktu laiku (noteiktais laiks ir jāuztur kā maināms Nodevuma konfigurācijas parametrs), x.xx. jāveic Sign-Out no Single-Sign-On nodrošinātāja servisa (piemēram, ADFS), ja Nodevums izmanto Single-Sign-On servisu.

Pēc lietotāja sesijas pārtraukšanas (neatkarīgi no tā, kas to izraisījis), attiecīgais lietotājs kļūst par neautentificētu lietotāju, lietotāja darbs ar Nodevumu tiek pārtraukts un lietotāja iesāktās, bet nesaglabātās izmaiņas datos tiek atceltas (tiek pārtraukta transakciju izpilde). Lai kļūtu par autentificētu lietotāju un atsāktu darbu ar Nodevumu, lietotājam jāveic identifikācijas un autentifikācijas procedūra.

4.7.NFP-22 Aizsardzība pret automatizētiem datu iegūšanas rīkiem

Nodevumā ir jābūt iestrādātai aizsardzībai pret automatizētiem datu iegūšanas un iesūtīšanas rīkiem (robotiem).

Izpildītājam detalizētās analīzes laikā jānosaka un ar Pasūtītāju jāsaskaņo aizsargājamās funkcijas un aizsardzības principi un algoritmi (piemēram, CAPTCHA un tās sarežģītības pielietošana).

4.8.NFP-23 Informācijas aizsardzības principi

Nodevumam jānodrošina apstrādājamās informācijas aizsardzība, lai neautorizētas personas vai sistēmas nevarētu izgūt vai modificēt informāciju, kas nav publiski pieejama.

Īstenojot informācijas aizsardzību Nodevumā, ir jāvadās pēc šādiem principiem:

1. „Zina tikai tas, kuram jāzina” (need-to-know);

2. „Ir jānodrošina minimālās tiesības pienākumu pildīšanai” (least privilege);

3. jābūt nodrošinātai lietotāju darbību uzskaitei (accountability).

4. Nodevuma konfigurācijai un drošības arhitektūrai ir jānodrošina aizsardzība pret OWASP Top 10 2013 norādītajiem apdraudējumiem (xxxxx://xxx.xxxxx.xxx/xxxxx.xxx/Xxx_00_0000-Xxx_00)

4.9.NFP-24 Auditācijas pierakstu veidošana

Nodevumam ir automātiski jāizveido un jāsaglabā audita pieraksti par sekojošiem notikumiem:

1. auditācijas funkcijas ieslēgšana un izslēgšana;

2. xxxx xxxxxxxx (vienuma) izveide;

3. datu ieraksta (vienuma) modifikācija;

4. datu ieraksta (vienuma) dzēšana;

5. lietotāja tieši vai pastarpināti izraisīts pieprasījums Nodevumam;

6. par citiem notikumiem, kas var sniegt noderīgu informāciju Xxxxxxxx darbības uzraudzībai un drošības incidentu izmeklēšanai.

Auditācijas pieraksti jāveido gan par veiksmīgām operācijām, gan par neveiksmīgām operācijām. Audita datus nedrīkst uzglabāt tajās pašās datu bāzes tabulās, kurās tiek uzglabāti pamatdati.

Izpildītājam detalizētās analīzes laikā jānosaka un ar Pasūtītāju jāsaskaņo:

1. citu notikumu saraksts, kuram nepieciešama auditācijas pierakstu veidošana;

2. katram sarakstā iekļautajam notikumam specifiskā informācija, kura iekļaujama audita pierakstā.

4.10.NFP-25 Auditācijas pierakstā iekļaujamā informācija

Katrā auditācijas pierakstā Nodevums jāiekļauj vismaz sekojoša informācija par auditējamo notikumu:

1. notikuma datums un laiks (minimums ar precizitāti līdz sekundei; vēlams - līdz sekundes 1/100 daļai);

2. notikuma veids;

3. ar notikumu saistītā subjekta identitāte - identifikācijas dati (vismaz šādi lietotāja parametri: lietotāja vārds);

4. notikuma objekts, kurš tiek identificēts vismaz attiecīgā datu apmaiņas saskarnē noteiktajā apjomā;

5. notikuma iznākums – sekmīga vai nesekmīga darbība;

6. cita, attiecīgajam notikumam specifiska, informācija, kura definēta citās prasībās vai detalizētās analīzes laikā.

4.11.NFP-26 Par serveri izpaužamās informācijas minimizācija

Izpildītājām, izmantojot konfigurācijas uzstādījumus, pēc iespējas jāminimizē informācijas apjomu, kas tiek izplatīts par Nodevuma serveriem un aplikācijām, tajās izmantoto programmatūru (tehnoloģijas, versijas u.tml.). Šī prasība attiecas uz vismaz šādiem Nodevuma darbības aspektiem:

1. HTTP/HTTPS protokola lietošanas ietvaros;

2. Nodevuma kļūdu/avārijas situācijās ārpus servera izplatītais informācijas apjoms (lietotājam jāsaņem minimāls informācijas apjoms - fakts par notikumu un rekomendācija tālākai rīcībai; detalizēta informācija par notikumu jāsaglabā servera žurnālfailos un/vai Nodevuma auditācijas pierakstos).

Izpildītājam šīs prasības ietvaros ir jāpiegādā vismaz divi atšķirīgi konfigurācijas uzstādījumu komplekti:

1. konfigurācija maksimāli minimizētas informācijas izpaušanai, kas pielietojama ekspluatācijas un mācību vidēs;

2. konfigurācija normālas vai paplašinātas informācijas izpaušanai, kas pielietojama testu vidē.

4.12.NFP-27 Aizsardzība pret SQL injekciju uzbrukumiem

Nodevumā jābūt realizētai aizsardzībai pret SQL injekciju uzbrukumiem. Nodevumam ir jānodrošina, ka visi no lietotāja saņemtie ievaddati tiks stingri validēti un apstrādāti tādā veidā, lai Nodevumam nevarētu realizēt SQL injekciju uzbrukumus.

5.Prasības uzturamībai

5.1.NFP-28 Prasības tehnoloģiju atbalstam

Nodevuma izveidē ir jāizmanto tehnoloģijas un izstrādes rīki, kuriem ražotājs nodrošina, ka izmantotās tehnoloģijas tiks uzturētas vēl vismaz 3 (trīs) gadus no to ražotāju puses, un Nodevuma funkcionalitāte šajā periodā varēs tikt papildināta pēc Pasūtītāja vēlmes. Iepriekšējā teikumā minētā prasība nav attiecināma uz tehnoloģijām, kas tika izmantotas esošo sistēmu izveidē un kas jau tiek lietotas esošajā Pasūtītāja infrastruktūrā.

Nodevuma ekspluatācijā nedrīkst izmantot komponentes, kuras ražotājs pozicionē kā „Beta”, „Pre-release”, „Release candidate”, „obsolete”, „deprecated” vai arī kādā citā veidā nerekomendē izmantošanai sistēmās.

5.2.NFP-29 Drošība uzturēšanas darbu laikā

Veicot Nodevuma garantijas uzturēšanas un uzturēšanas darbus, nedrīkst samazināties drošība, kas ļautu neautorizētiem lietotājiem piekļūt Nodevumā uzglabātajiem datiem, funkcijām un saskarnēm. Nodevuma pilnveidojumi nedrīkst samazināt Nodevuma drošību.

Veicamie pasākumi šīs prasības ievērošanai var ietvert neatkarīgu izejas koda pārskatīšanu, kā arī kā prasība Nodevumam vai tās daļas uzbūves procesu veikt Pasūtītāja vai tā nozīmētas trešās puses kontrolē. Izpildītājam ir jāpiegādā programmatūras pirmkodi un instalācijas komandfaili, kas var tikt izmantoti Nodevuma instalēšanā/uzstādīšanā bez Izpildītāja klātbūtnes.

Pasūtītājs: Rīgas Stradiņa universitāte
Rektors Xxxxxx Xxxxxxxxx

__________________________ ^(paraksts) Izpildītājs:





__________________________ ^(paraksts)

1