Common use of Изисквания за използваемост на потребителския интерфейс Clause in Contracts

Изисквания за използваемост на потребителския интерфейс. При надграждането на АИС за инвентаризация на ИКИ ресурсите трябва да се гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи. Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на Приложението, без да са необходими промени в изходния код, на контекстна помощна информация за: всяка електронна форма или стъпка от процес, за която има отделен екран/форма; всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично); всяко отделно поле за въвеждане на данни; Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета. Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини. Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития; При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Изгражданото решение за уеб приложението, реализиращо регистъра на информационните ресурси, задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал). Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни: дата/час на действието; модул на системата, в който се извършва действието; действие; обект, над който е извършено действието; допълнителна информация; IP адрес и браузър на потребителя. Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни: по време на работа на приложението потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Приложението; специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на Приложението; данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на Приложението трябва първо да възстанови архивните данни.

Изисквания за използваемост на потребителския интерфейс. При надграждането Електронните форми за подаване на АИС заявления и за инвентаризация обявяване на ИКИ ресурсите обстоятелства трябва да бъдат реализирани с AJAX или с аналогична технология, като по този начин се гарантират следните функционалности: ▪ Контекстна валидация на въвежданите данни на ниво "поле" от форма и контекстни съобщения за грешка/невалидни данни в реално време; ▪ Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скролира дълги списъци с повече от 10 стойности; В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се гарантираизвършва в реално време на сървъра, че въведените, валидираните и запазените като при успешна валидация данните от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят съответното поле следва да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи. бъдат запазени от сървъра; Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на ПриложениетоСистемата, без да са необходими промени в изходния код, на контекстна помощна информация за: ▪ всяка електронна форма или стъпка от процес, за която има отделен екран/форма; ▪ всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично); ▪ всяко отделно поле за въвеждане на данни; Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета. ; Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини. ; Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития; При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Потребителският интерфейс следва максимално да покрива ниво на достъпност според последните стандарти на World Wide Web Consortium - Web Content Accessibility Guidelines 2.0 (WCAG 2.0), като използва най-добрите практики и техники. Системен журнал Изгражданото решение за уеб приложението, реализиращо регистъра на информационните ресурси, задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал). Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни: ▪ дата/час на действието; ▪ модул на системата, в който се извършва действието; ▪ действие; ▪ обект, над който е извършено действието; ▪ допълнителна информация; ▪ IP адрес и браузър на потребителя. Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни: ▪ по време на работа на приложението Системата потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на ПриложениетоСистемата; ▪ специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на ПриложениетоСистемата; ▪ данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва да бъде достъпна информация за не повече от 2 месеца назад; при необходимост от информация за предишен период администраторът на Приложението Системата трябва първо да възстанови архивните данни; ▪ трябва да бъде предоставен достъп до системния журнал на органите на реда чрез потребителски или програмен интерфейс; за достъпа трябва да се изисква електронна идентификация.

Изисквания за използваемост на потребителския интерфейс. При надграждането Електронните форми за подаване на АИС заявления и за инвентаризация обявяване на ИКИ ресурсите обстоятелства трябва да бъдат реализирани с AJAX или с аналогична технология, като по този начин се гарантират следните функционалности: Контекстна валидация на въвежданите данни на ниво "поле" от форма и контекстни съобщения за грешка/невалидни данни в реално време; Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скорлира дълги списъци с повече от 10 стойности; В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация данните от съответното поле следва да бъдат запазени от сървъра; Системата трябва да гарантира, че въведените, валидираните и запазените от сървъра данни остават достъпни за потребителите дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса на активност потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи. ; Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на ПриложениетоСистемата, без да са необходими промени в изходния код, на контекстна помощна информация за: всяка електронна форма или стъпка от процес, за която има отделен екран/форма; всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично); всяко отделно поле за въвеждане на данни; Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета. ; Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и др. трябва да бъдат разработени като хипервръзки към съответните актуални версии на нормативни документи и/или към съответния речник/списък с акроними и термини. ; Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони микробутони с икони, разположени до/пред/след етикета на съответния елемент, за който се отнася контекстната помощ, или чрез обработка на "Mouse Hover/Mouse Over" събития; При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Изгражданото решение за уеб приложението, реализиращо регистъра на информационните ресурси, задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал). Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни: дата/час на действието; модул на системата, в който се извършва действието; действие; обект, над който е извършено действието; допълнителна информация; IP адрес и браузър на потребителя. Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни: по време на работа на приложението потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Приложението; специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на Приложението; данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва Потребителският интерфейс следва да бъде достъпна информация достъпен за не повече хора с увреждания съгласно изискванията на чл. 48, ал. 5 от 2 месеца назад; при необходимост от информация за предишен период администраторът на Приложението трябва първо да възстанови архивните данниЗОП.

Изисквания за използваемост на потребителския интерфейс. При надграждането Електронните форми за подаване на АИС заявления и за инвентаризация обявяване на ИКИ ресурсите обстоятелства трябва да бъдат реализирани с AJAX или аналогична технология, като по този начин се гарантират следните функционалности: Контекстна валидация на въвежданите данни на ниво "поле" от форма и контекстни съобщения за грешка / невалидни данни в реално време; Възможност за избор на стойности от номенклатури чрез търсене в списък по част от дума (autocomplete) и визуализиране на записи, отговарящи на въведеното до момента, без да е необходимо пълните номенклатури да са заредени в браузъра на клиента и потребителят да скорлира дълги списъци с повече от 10 стойности; В електронните форми трябва да бъде реализирана валидация на въвежданите от потребителите данни на ниво "поле" (in-line validation). Валидацията трябва да се извършва в реално време на сървъра, като при успешна валидация, данните от съответното поле следва да бъдат запазени от сървъра; Системата трябва да гарантира, че въведенитевъведени, валидираните валидирани и запазените запазени от сървъра данни данни, остават достъпни за потребителите потребителите, дори за процеси, които не са приключили, така че при волно, неволно или автоматично прекъсване на потребителската сесия поради изтичане на периода за допустима липса липсва на активност активност, потребителят да може да продължи съответния процес след повторно влизане в системата, без да загуби въведените до момента данни и прикачените до момента електронни документи. ; Трябва да бъде реализирана възможност за добавяне и редактиране от страна на администраторите на Приложениетосистемата, без да са необходими промени в изходния код, на контекстна помощна информация за: всяка електронна форма или стъпка от процес, за която има отделен екран/екран / форма; всяка група полета за въвеждане на данни (в случаите, в които определени полета от формата са групирани тематично); всяко отделно поле за въвеждане на данни; Трябва да бъде разработена контекстна помощна информация за всички процеси, екрани и електронни форми, включително ясни указания за попълване и разяснения за особеностите при попълване на различните групи полета или на отделни полета. ; Контекстната помощна информация, указанията към потребителите и информативните текстове за всяка електронна административна услуга не трябва да съдържат акроними, имена и референции към нормативни документи, които са въведени като обикновен текст (plain-text). Всички акроними, референции към нормативни документи, формуляри, изисквания и дрпр. трябва да бъдат разработени като хипервръзки хипер-връзки към съответните актуални версии на нормативни документи и/или към съответния речник/речник / списък с акроними и термини. ; Достъпът на потребителя до контекстната помощна информация трябва да бъде реализиран по унифициран и консистентен начин начин, чрез подходящи навигационни елементи, като например чрез подходящо разположени микро-бутони с икони, икони разположени до/предпреди/след етикета на съответния елемент, за който се отнася контекстната помощ, помощ или чрез обработка на "Mouse Hover/Hover / Mouse Over" събития; При проектирането и реализацията на потребителския интерфейс трябва да се отчете, че той трябва да бъде еднакво използваем и от мобилни устройства (напр. таблети), които не разполагат с мишка, но имат чувствителни на допир екрани. Изгражданото решение за уеб приложението, реализиращо регистъра на информационните ресурси, задължително трябва да осигурява проследимост на действията на всеки потребител (одит), както и версия на предишното състояние на данните, които той е променил в резултат на своите действия (системен журнал). Атрибутите, които трябва да се запазват при всеки запис, трябва да включват като минимум следните данни: дата/час на действието; модул на системата, в който се извършва действието; действие; обект, над който е извършено действието; допълнителна информация; IP адрес и браузър на потребителя. Размерът на журнала на потребителските действия нараства по време на работа на всяка система, което налага по-различното му третиране от гледна точка на организация на базата данни: по време на работа на приложението потребителският журнал трябва да се записва в специализиран компонент, който поддържа много бързо добавяне на записи; този подход се налага, за да не се забавя излишно работата на Приложението; специална фонова задача трябва да акумулира записаните данни и да ги организира в отделна специално предвидена за целта база данни, отделна от работната база данни на Приложението; данните в специализираната база данни трябва да се архивират и изчистват, като в специализираната база данни трябва Потребителският интерфейс следва да бъде достъпна информация достъпен за не повече хора с увреждания, съгласно изискванията на чл. 48, ал. 5 от 2 месеца назад; при необходимост от информация за предишен период администраторът на Приложението трябва първо да възстанови архивните данниЗОП.