Пример функциональных требований. ФТ - СППВР ЛОР IEEE. Цели 4 Соглашения о терминах 4 Предполагаемая аудитория и последовательность восприятия 5 Масштаб проекта 5 Ссылки на источники 5

• Название: Цели 4 Соглашения о терминах 4 Предполагаемая аудитория и последовательность восприятия 5 Масштаб проекта 5 Ссылки на источники 5
• Анкор: Пример функциональных требований
• Дата: 15.05.2022
• Размер: 49.3 Kb.
• Имя файла: ФТ - СППВР ЛОР IEEE.docx
• Тип: Реферат; #531247
• страница: 6 из 6

3. Требования к внешним интерфейсам

3.1. Интерфейсы пользователя (UX)

Интерфейс пользователя должен удовлетворять следующим требованиям:

- цветовая схема не должна содержать ярких или тусклых цветов (приводить к излишней утомляемости глаз);

- расположение элементов в интерфейсе должно интуитивно способствовать максимально эффективному выполнению доступных пользователю операций;

- структура интерфейса должна соответствовать современным подходам к его организации и реализации;

- все надписи, а также сообщения, выдаваемые пользователю (за исключением системных сообщений), должны быть на русском языке;

- интерфейс должен быть «гибким», т.е. поддерживать различное разрешение монитора, но не менее 1280х1024.

Эргономическое обеспечение системы должно удовлетворять следующим требованиям:

- весь перечень доступных операций должен быть представлен в меню;

- операции в меню должны быть объединены в логические группы;

- наиболее часто используемые операции должны быть представлены в виде кнопок, объединенных в панели управления и размещаться под панелью меню;

- при выполнении операций, требующих длительного временного интервала, должно выводиться информационное окно, на котором должна отображаться следующая информация:

- предварительное рассчитанное время, необходимое для выполнения операции;

- текущее действие;

- прошедшее время с начала операции;

- перед выводом значительного объема информации, должно выдаваться сообщение, содержащее следующие элементы:

- информация о количестве сведений, которое предлагается отобразить;

- кнопка подтверждения вывода данных;

- кнопка отказа от вывода данных.

Для представления данных, хранящихся в системе должен быть доступен один из следующих видов:

- табличный;

- информационная карточка;

- графический;

- шаблон отчета (если он определен для данного набора данных).

Средства системы должны обеспечивать возможность фильтрации данных по любому из доступных показателей.

Средства системы должны обеспечивать возможность сортировки и упорядочивания данных по показателям, формат хранения которых позволяет это реализовать.

Представление (визуализация) данных должна обеспечивать возможность отображения в одном из следующих видов:

- табличный;

- информационная карточка;

- графический;

- шаблон отчета (если он определен для данного набора данных);

- витрина данных.

Для табличного вида должна быть реализована возможность цветового выделения данных по заданным условиям.

Для вида «Витрина данных» должна быть реализована возможность отображения нескольких групп информации (графики и таблицы).

Для вида «Графический» должна быть реализована возможность перехода к первичной информации (данным, на основе которых построен график).

3.2. Программные интерфейсы

Взаимодействие системы с внешними системами должно осуществляться по программным интерфейсам этих систем в соответствии с их реализацией в этих системах и требованиями, предъявляемыми ими для информационной интеграции с ними.

Взаимодействие пользователей с системой напрямую (без МИС МО) должно осуществляться через браузеры. Система должна поддерживать возможность работы с ней через следующие браузеры:

- Firefox 34;

- Chrome 38;

- Яндекс.Браузер 20.

Программные интерфейсы для интеграции с системой должны быть реализованы через API –интерфейсы. Взаимодействие с API – интерфейсами должно осуществляться с использованием REST – запросов.

Внутрисистемные интерфейсы должны быть реализованы в виде запросов к подсистеме хранения и виде управляющих операций по вызову сервисов системы (работа сервисов может инициироваться другим сервисом и/или пользователем при вызове необходимой операции).

3.3. Интерфейсы оборудования

Так как разработка системы не предусматривает разработку оборудования, а функционирование системы будет осуществляться в облаке, то требования к интерфейсам оборудования не предъявляются.

3.4. Интерфейсы связи и коммуникации

Так как функционирование системы будет осуществляться в облаке, то требования к интерфейсам связи и коммуникациям не предъявляются.

4. Нефункциональные требования

4.1. Требования к производительности

Реализация системы должна обеспечивать следующие показатели производительности:

- отклик системы на действия пользователя не должен превышать 3-х секунд;

- количество одновременно работающих пользователей не менее 10000;

- время реакции на действия пользователя не должно зависеть от сервиса, через который осуществляется работа с системой (сервис интеграции с МИС или сервис АРМов – через браузер);

- запас производительности системы должен составлять 30% от значений показателей производительности системы;

- подсистема хранения должна обеспечивать хранение и обработку не менее 200000 записей без потери производительности системы в целом;

- увеличение производительности технических средств в 2 раза должно обеспечивать увеличение производительности системы не менее чем на 75%;

- при увеличении количества пользователей в 2 и более раз время отклика системы не должно увеличиваться;

- при увеличении объема хранимых и обрабатываемых данных в 2 раза, производительность подсистемы хранения не должна уменьшаться более чем 2 раза, и данная тенденция должна сохраняться.

4.2. Требования к сохранности (данных)

В процессе ввода системы в действие, должно быть выполнено мероприятие по включению программного обеспечения системы в систему резервного копирования.

Архивы системы должны располагаться в местах, обеспечивающих их максимальную защиту от различного рода негативных воздействий.

Программные средства должны обеспечивать сохранность введенных данных, если операция по их вводу и сохранению была завершена успешно (за исключением случаев выхода из строя носителя или массива носителей информации).

СУБД, применяемая для реализации подсистемы хранения должна обеспечивать ведение журнала выполненных операций с данными, которые должны храниться отдельно от данных.

Подсистема хранения должна размещаться на дисковых массивах, обеспечивающих их отказоустойчивость массива.

Попытки пользователей выполнить операции, результат выполнения которых приведет к нарушению информационной целостности данных, должны блокироваться средствами системы и СУБД.

4.3. Требования к качеству программного обеспечения

Качество программного обеспечения должно быть обеспечено соблюдением требований настоящих функциональных требований.

Качество программного обеспечение также должно обеспечиваться соблюдением требований НПА, регулирующих разработку МИС и качество программного обеспечения.

4.3.1. Требования по защите от ошибочных действий пользователей

Программные средства системы должны обеспечивать следующие действия, по защите от ошибочных действий пользователей:

- осуществлять временную блокировку процесса аутентификации пользователя в системе, в случае количества неудачных попыток, соответствующих настройкам системы;

- осуществлять отображение информации только тех информационных объектов, доступ к которым разрешен пользователям;

- блокировать попытки ввода данных, тип которых данных не соответствует типу данных поля;

- ввод данных в поля, значения которых являются значениями справочников, должен осуществляться только через справочники;

- блокировать попытки ввода неполного набора обязательных значений записи базы данных;

- для полей, значения которых являются числовым типом данных, должен осуществляться контроль на разрядность вводимых данных;

- осуществлять вывод соответствующих сообщений, при ошибочных действиях пользователей;

- средства автоматизированной загрузки данных должны осуществлять проверку наличия в базе данных информации, которую необходимо загрузить и блокировать попытки ее повторной загрузки.

4.3.2. Требования к надежности системы

Функционирование системы должно осуществляться в следующих режимах:

- штатный режим – функционируют все подсистемы и их сервисы в соответствии с предъявляемыми к ним требованиями;

- режим частичной потери функциональности подсистемы – в пределах подсистемы не функционирует один сервис. Все остальные подсистемы функционируют в штатном режиме. Логическая взаимосвязь с подсистемой не нарушена;

- режим полной потери функциональности подсистемы – в пределах подсистемы не функционирует несколько сервисов. Все остальные подсистемы функционируют в штатном режиме. Логическая взаимосвязь с подсистемой не нарушена;

- режим фатальной потери функциональности подсистемы - в пределах подсистемы не функционирует ни один сервис. Все остальные подсистемы функционируют в штатном режиме. Логическая взаимосвязь с подсистемой нарушена;

- режим частичной потери функциональности – в каком-либо виде не функционирует одна подсистема;

- режим критической потери функциональности – в каком-либо виде не функционирует две подсистемы;

- режим повышенной критической потери функциональности – в каком-либо виде не функционирует более половины подсистем;

- режим фатальной потери функциональности – не функционирует ни одна подсистема.

Не зависимо от режима функционирования подсистемы или (если режим не вызван аппаратным сбоем оборудования), данные подсистем и в целом, не должны быть подвержены даже частичной потере.

В штатном режиме должна функционировать не менее шести месяцев (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования в режиме частичной потери функциональности не более 48 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования в режиме критической потери функциональности – в каком-либо виде не функционирует две подсистемы не более 24 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования в режиме повышенной критической потери функциональности не более 12 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования в режиме фатальной потери функциональности не более 8 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования подсистемы в режим частичной потери функциональности подсистемы не более 48 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования в режиме полной потери функциональности подсистемы не более 24 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Допустимое время функционирования в режиме фатальной потери функциональности подсистемы не более 12 часов (за исключением случаев аппаратного сбоя или функционирования общесистемного программного обеспечения).

Количество допустимых нарушений в штатном режиме функционирования за 1 год не должно превышать 16 раз.

4.3.3. Требования к тестированию программного обеспечения

Тестирование программного обеспечения должно включать в себя:

1. Тестирование сервиса – осуществляется проверка полноты реализованных функциональных возможностей сервиса функциональным требованиям, тестирование корректности работы функциональных возможностей сервиса и их соответствия предъявляемых к сервису требованиям, оценка необходимых доработок и возможность принятия решения о готовности сервиса.

2. Тестирование подсистемы – тестирование начинается при реализации 2-х сервисов, имеющих логическую связь между собой в пределах подсистемы и завершается после реализации всех сервисов подсистемы и принятия решения о готовности подсистемы. Постоянное тестирование сервисов подсистемы осуществляется по мере их реализации с целью оценки корректности реализации механизма (ов) взаимодействия друг с другом. В процессе тестирования подсистемы в целом, осуществляется комплексная проверка взаимодействия сервисов между собой в пределах подсистемы и реализации механизмов взаимодействия подсистемы с другими подсистемами.

3. Сквозное тестирование – является 1-й частью тестирования alpha – версии системы и проводится при реализации всех подсистем. При данном тестировании осуществляется:

- проверка функционирования всех сервисов во всех подсистемах;

- проверка реализации механизмов взаимодействия подсистем между собой;

- взаимодействия с внешними ресурсами (для внешних ресурсов осуществляется эмуляция их работы);

- проверка соответствия системы предъявляемым к ней требованиям;

- оценка возможности перехода к нагрузочному тестированию.

4. Нагрузочное тестирование – является 2-й частью тестирования alpha – версии системы и проводится при положительных результатах сквозного тестирования. При данном виде тестирования осуществляется проверка соответствия системы предъявляемым к ней характеристикам производительности, наличие у нее резерва производительности, выявление возможностей по оптимизации работы сервисов системы за счет оптимизации программного кода.

Также при данном виде тестирования оценивается возможность повышения производительности при увеличении производительности технических средств и различных технических решениях.

По результатам тестирования осуществляется оценки возможности присвоения системе beta- версии и переходу к опытной эксплуатации.

5. Опытная эксплуатация – осуществляется размещение системы на ресурсах, на которых она будет функционировать при промышленной эксплуатации, подключение к внешним ресурсам и проверка работоспособности системы внешними пользователями (так как система является медицинским изделием, то по сути для нее проводятся клинические испытания).

Внешними пользователями осуществляется проверка эффективности практического применения, удобство интерфейса, полноты необходимых в практической деятельности операций и других характеристик, оказывающих влияние на практическую деятельность.

По результатам опытной эксплуатации формируется перечень доработок и предложений по улучшению системы.

6. Комплексное тестирование – тестирование осуществляется совместно с внешними пользователя и направлено на:

- тестирование устранения выявленных замечаний;

- реализацию предложений внешних пользователей;

- оценку производительности системы после реализованных доработок;

- оценку возможности внедрения системы в практическую деятельность МО.

4.4. Требования к безопасности системы

Доступ к системе может осуществляться только через сервисы, функционал которых это предусматривает. Доступ должен осуществляться только путем аутентификации пользователя. Попытки неудачной аутентификации должны блокироваться при достижения числа таких попыток, установленных в системе. При успешной аутентификации пользователю должны быть доступны только те функциональные возможности, доступ к которым разрешен ролевой моделью.

Передача данных при аутентификации и взаимодействию системы с внешними ресурсами должна осуществляться с помощью протоколов, поддерживающих шифрование и с применением шифрования.

Система должна поддерживать возможность дополнительного подтверждения регистрации в системе с помощью кода, получаемого пользователями в СМС на телефон.

Все операции, выполняемыми пользователем должны фиксироваться в системном журнале с помощью специального сервиса, доступ к которому имеет только администратор системы.

4.5. Требования на интеллектуальную собственность

Исключительные права на результаты интеллектуальной деятельности (РИД) (право на изобретение, полезную модель или промышленный образец, селекционные достижения, топологии интегральных микросхем, программы для электронно-вычислительных машин, базы данных и секреты производства (ноу-хау)), полученные при выполнении настоящего соглашения, определяются в соответствии с Частью четвертой Гражданского Кодекса Российской Федерации и Главой 38 Части второй Гражданского Кодекса Российской Федерации и принадлежат автору (соавторам).

Приложение А

Глоссарий

Браузер - программа, предназначенная для просмотра сайтов, гипертекстовых документов в Интернете.

Облачная технология - это услуга, с помощью которой вы получаете через сеть вычислительные ресурсы (процессорное время, оперативная память, дисковое пространство, сетевые соединения), сервисы или программы и можете пользоваться ими для решения своих IT-задач.

СУБД с открытым кодом – СУБД с открытым кодом ориентированы на решение тех же задач, что и традиционные коммерческие СУБД, однако в них используется иная схема лицензирования, дающая возможность бесплатно загружать продукт и открывающая доступ к его исходному коду.