|
|
Общи изисквания за реализация на програмни интерфейси (API)
|
Общи изисквания за реализация на програмни интерфейси (API)
|
| -
|
Съгласно подзаконовата нормативна уредба към ЗЕУ, достъпът до програмни интерфейси (APIs) трябва да се осъществява през HTTPS през защитена сесия с протокол TLS версия 1.2 или по-висока.
Допустимо е изключение за програмни интерфейси (API) за публикуване на набори с отворени данни, по реда на ЗДОИ.
|
|
| -
|
Всички публични и служебни (вътрешни) онлайн интерфейси трябва да бъдат реализирани с поддръжка на режими “push” и „pull”, в асинхронен и синхронен вариант – практическото прилагане на всяка от комбинациите трябва да бъде определена на етап бизнес-анализ и да бъдат съобразени реалните казуси (use cases), които всеки интерфейс обслужва;
|
|
| -
|
Всеки програмен интерфейс (API) трябва да поддържа механизъм за ограничаване на броя заявки за секунда (т.нар. "rate-limiting") получени от отделен заявител (клиент), до определен праг (threshold). При надвишаване стойността над зададения за даден клиент праг, на извикващата клиентска система трябва да бъде върнат съответния статус код / код за грешка. Стойността на прага трябва да може да бъде конфигурирана от администратори, включително с възможност за различни лимити за различни потребители (клиенти), включително и чрез служебен потребителски интерфейс (UI) за приложна администрация, където е приложимо.
|
|
| -
|
Когато е нормативно допустимо, всеки програмен интерфейс (API) трябва да поддържа кеширане на определени често връщани резултати с цел избягване на излишно четене от перманентен източник на данни (Persistent Storage). Преди изпълнение на транзакция за промяна на даден запис / данна в перманентния източник на данни, съответният елемент в кеш буфера трябва да бъде инвалидиран, за да се избегне некохерентност на данни. Детайлни изисквания за прилагане на системи за разпределено кохерентно кеширане са посочени в т. Error: Reference source not found от ТС.
|
|
| -
|
Всеки програмен интерфейс (API) и информационните обекти трябва задължително да поддържат атрибут за версия.
Версията на програмните интерфейси (APIs), представени чрез уеб-услуги, трябва да поддържат версията по един или няколко от следните начини:
-
Като част от URL-а
-
Като GET параметър
-
Като HTTP header (Accept или друг)
|
|
| -
|
Всеки програмен интерфейс (API) трябва да бъде документиран автоматизирано чрез API Blueprint (https://github.com/apiaryio/api-blueprint), Swagger (http://swagger.io) или аналогична технология.
Аналогично документиране и представяне трябва да бъде реализирано и за SOAP интерфейсите, където е приложимо.
|
|
|
|
Общи изисквания към ползваемостта (UX) на потребителските интерфейси
|
Общи изисквания към ползваемостта (UX) на потребителските интерфейси
|
| -
|
При проектирането и разработката на софтуерните компоненти и потребителските интерфейси трябва да се спазват стандартите за достъпност на потребителския интерфейс (UI) за хора с увреждания WCAG 2.0, съответстващ на ISO/IEC 40500:2012;
|
|
| -
|
За постигане на съответствие с изискванията на Пътната карта за изпълнение на Стратегията за развитие на електронното управление в Република България 2016 – 2020 г. Участникът следва да предвиди в техническото си предложение фаза на проучване, по време на която да се дефинират потребителските нужди, да се проведат предварителни тестове с потребители и да се изработи план, по който да се адресират нуждите.
|
|
| -
|
Изпълнителят трябва да предложи мерки за използваемост на системата за електронна идентификация по отношение на:
-
Продуктивността на системата (пр. време за извършване на една задача, време на изчакване за зареждане на данни/страница, т.н.);
-
Удовлетвореността чрез провеждане на Usability Testing (пр. чрез A/B Testing, expert review, др.), като тестовите сценарии и резултатите от проведените тестове трябва да се приложат към изпълнението на обществената поръчка, включително хранилището за изходния код;
-
Методология и план за провеждане на тестовете с потребители, както и начин за формиране на фокус-групата.
|
|
| -
|
В рамките на изпълнението на договора следва да бъдат провеждани периодични продуктови тествания (не по-малко от три) по време на разработката с извадка (фокус-група) от бъдещите потребители на електронната услуга (администрация и граждани), чрез които да се установи използваемостта на услугата и да бъдат отстранени затруднения и несъответствия с ТС.
|
|
|
|
Специфични изисквания към ползваемостта (UX) на потребителските интерфейси
|
Специфични изисквания към ползваемостта (UX) на потребителските интерфейси
|
| -
|
Командите трябва да са групирани в менюта, така че да позволяват лесно и удобно използване.
|
|
| -
|
Във визуалния интерфейс на изгражданите приложения да се предвиди възможност потребителят да види пътя, по който е минал, за да достигне до екранната форма, която в даден момент е активна и той работи с нея. В това изискване под „път” се разбира описание на стъпките за достигане до съответната екранна форма, тръгвайки от главното меню, а не хронологическо описание на всички действия, които е извършил потребителят, преди да достигне до екранната форма. Това описание не трябва да ограничава видимостта на потребителя по отношение на останалите обекти във визуалния интерфейс.
|
|
| -
|
Всяка екранна форма да има наименование, което да се изписва в горната част на екранната форма. Наименованията да подсказват на потребителя какво е предназначението на формата.
|
|
| -
|
Взаимодействието човек-компютър трябва да бъде реализирано в съответствие с приетите международни стандарти (цветове на екрани, шрифт, екранни форми). Екранните форми трябва да са консистентни и близки по вид, с цел бързо възприемане и удобство на работа.
|
|
| -
|
Потребителският интерфейс (UI) трябва да е ориентиран към изпълняваните задачи, като осигурява нужната за задачата информация.
|
|
| -
|
При разработката на екранните форми трябва да се реализират минимален брой преходи между екранни форми за реализиране на желаната функционалност.
|
|
| -
|
За диалози с решението за електронна идентификация трябва да се използват потребителски бутони с унифициран размер и лесни за разбиране текстове в еднакъв стил.
|
|
| -
|
Полета, опции от менюта и командни бутони, които не са разрешени конкретно за влезлия в приложението потребител, не трябва да са достъпни за този потребител – същите трябва да са неактивни или изобщо да не се показват.
|
|
| -
|
Когато в резултат на търсене или друго действие се върне само един отговор, тогава данните за резултата трябва да се показват автоматично. Във всички останали случаи трябва да се извежда списък.
|
|
| -
|
Ако потребител въведе форма, изискваща едно или друго действие, в която форма липсва задължителна информация, на потребителя да се изпраща съобщение, което го информира коя точно информация липсва (кое поле). Екранната форма трябва да не се обновява и данните в полетата да не се изчистват.
|
|
| -
|
Ако потребител въведе форма, изискваща едно или друго действие и информацията не отговаря на правилата за валидиране, тогава на потребителя да се връща първоначално изпратената екранна форма със съобщение за грешка, указващо коя точно информация е невалидна. Екранната форма да не се обновява и данните в полетата да не се изчистват.
|
|
| -
|
Термините, изискванията по отношение на екранните форми и справките, трябва да се съгласуват с Възложителя.
|
|
| -
|
Чувствителност към малки и главни букви:
-
Всички търсения трябва да са индиферентни (нечувствителни) към малки и главни букви;
-
За потребителски имена и пароли задължително трябва да се следи съответствие на малки и главни букви;
-
Главните и малки букви на въвежданите данни да се запазват непроменени (данните да се записват така, както са въведени). Това правило не се прилага в случаите, когато при детайлизацията на изискванията Възложителят е дал друго изискване към конкретни данни.
|
|
| -
|
Потребителският интерфейс (UI) трябва да бъде придружен от онлайн помощна информация на съответните изискуеми езици.
|
|
|
|
Други изисквания касаещи ползваемостта (UX)
|
Други изисквания касаещи ползваемостта (UX)
|
| -
|
Не се допуска използване на капча (Captcha) като механизъм за ограничаване на достъпа до страници, документи и/или услуги, освен при идентифициране на много последователни опити за достъп, за кратък период от време, от предполагаем „бот“;
|
|
| -
|
Всички уеб ресурси трябва да бъдат достъпни чрез GET заявка на уникален адрес (URL). Не се допуска използване на POST заявки за достигане до формуляр за подаване не заявление, за генериране на справка и други
|
|
| -
|
Съгласно действащата нормативна уредба в ЕС, всички публично-достъпни интернет страници трябва да визуализират по подходящ начин нотификация за прилаганата политика за използване на "cookies" и ненатрапчиво да изискват потвърждение за съгласие от потребителя.
|
|
| -
|
Всички публично-достъпни интернет страници трябва да бъдат проектирани и оптимизирани за ефективно и бързо индексиране от търсещи машини, с цел популяризиране сред потребителите и по-добра откриваемост при търсене по ключови думи и фрази.
|
|
| -
|
Всички уеб-базирани страници, независимо дали са публично-достъпни или част от вътрешни потребителски интерфейси, трябва да бъдат оптимизирани чрез инструменти за минимизиране на размера на изходния код (HTML, JavaScript и пр.), с оглед намаляване на обема на файловете и по-бързо зареждане на страниците. Прилагането на инструментите за оптимизация може да бъде реализирано и като част от процеса по разгръщане на съответната система.
|
|
| -
|
При разработката на публични уеб-базирани страници трябва да се реализира поддръжка на следните стандарти:
Стандартните семантични елементи на HTML5 (HTML Semantic Elements)
JSON-LD 1.0 (http://www.w3.org/TR/json-ld/)
Open Graph Protocol (http://ogp.me) за осигуряване на поддръжка за качествено споделяне на ресурси в социални мрежи и мобилни приложения
Публичните уеб-базирани страници трябва да използват семантичните елементи и формати и да предоставят чрез тях използваеми мета-данни, които са коректни и валидни (коректно структурирани според съответната схема, ако е приложимо).
|
|
|
|
|
