Образцы технических заданий

Система управления кабинетом врача - Doctor Management System

Предлагаем разработку проекта на платформе Doctor Management System - Система управления кабинетом врача в виде веб-портала (веб-приложение).

Подробнее

1. ТРЕБОВАНИЯ К СИСТЕМЕ

1.1. ОБЩИЕ ТРЕБОВАНИЯ

Основной интерфейс должен по структуре разбиваться на 4 части:

• Шапка портала
• Левое боковое меню
• Центральная часть – лента новостей и сообщений
• Правое меню для возможных виджетов и дополнительного меню

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

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

• Главная страница
• Сотрудники
• Расписание кабинетов
• Оснащение центра
• Реестры
• Персональный диск

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

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

 Для правого меню необходимо отвести место для настройки возможных виджетов или меню при дальнейшем развитии Системы.

1.2.      ПЕРЕЧЕНЬ ПОДСИСТЕМ

Система должна содержать нижеописанные подсистемы.

1.3.      СВЕДЕНИЯ О ПОДСИСТЕМАХ

1.3.1. Подсистема «Регистрация/авторизация»

Назначение:

Подсистема предназначена для контроля предоставления доступа пользователей в системе.

Подсистема должна позволять:

• Верификацию зарегистрированного пользователя.
• Авторизацию пользователя.
• Настройку доступа к функционалу на базе типа пользователя.

1.3.2. Подсистема «Иерархическая структура организации»

Назначение:

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

Подсистема должна позволять:

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

1.3.3. Подсистема «Личный кабинет пользователя»

Назначение:

Подсистема предназначена для персонализации системы и ведения личных данных пользователя.

Подсистема должна позволять:

• Просмотреть личные данные пользователя: ФИО, отдел, должность, адрес электронной почты, контактный телефон, квалификация.
• Изменять личную информацию о пользователе (каждый пользователь может менять только свои данные, администратор может менять данные любого пользователя).
• Загружать сертификат специалиста (для мед.работников) формате PDF или JPEG с указанием даты действия сертификата.
• Загружать в систему персональные рабочие файлы и материалы.
• Предоставлять доступ к собственным файлам для других пользователей внутри системы.

1.3.4. Подсистема «Оснащение центра»

Назначение:

Подсистема предназначена для осуществления контроля состояния кабинетов, техническом оснащении, графиком работы и плана развитии кабинета

Подсистема должна позволять:

• Просматривать имеющуюся информацию по каждому кабинету любому пользователю Системы
• Вносить изменения в текущее описание кабинета (только для администратора)

 1.3.5. Подсистема «Расписание работы кабинетов»

Назначение:

Подсистема предназначена для ведения информации по проводимым процедурам в центре.

Подсистема должна позволять:

• Назначить время и врача для проведения процедуры конкретному пациенту
• Предоставить специалисту развернутую информацию о том в какое время какой врач проводит процедуру
• Показать занятость врачей ОСМС

 1.3.6. Подсистема «Реестры»

Назначение:

Подсистема предназначена для просмотра информации по пациентам центра

Подсистема должна позволять:

• Просмотреть информацию по пациенту (-ам) центра в соответствии с запрашиваемыми данными
• Фильтровать информаций при помощи настраиваемых фильтров по полям реестра
• Осуществлять поиск конкретных данных при помощи поисковой строки

1.4. ДЕТАЛИЗАЦИЯ ТРЕБОВАНИЙ К СИСТЕМЕ

1.4.1. Подсистема «Регистрация/авторизация»

Участвующие роли: Администратор.

Задачи подсистемы:

1. Добавление пользователей в систему
2. Назначение прав пользователей

1.4.1.1. Функциональные требования к задаче: «Добавление пользователя в систему»

Описание: Данное функциональное требование описывает последовательность действий по добавлению пользователя в Систему.

Предусловия

1. Пользователь с ролью «Администратор» осуществил авторизацию в административной части Системы

Входные данные

Последовательность действий

1. Администратор нажатием кнопки инициирует создание нового пользователя в системе.
2. В появившемся окне создания пользователя администратор вводит обязательные данные (согласно входным данным).
3. Для выпадающего списка «отдел» необходимо использовать следующий справочник:
   1. Руководство
   2. Фонд БУ
   3. Технический отдел
   4. Бухгалтерия
   5. Методический отдел
   6. Медицинская реабилитация
   7. Психолого-педагогическая коррекция
   8. Социальная работа
   9. АРТ
4. Для активации дочернего подразделения администратор выбирает отдел «медицинская реабилитация», активирует чек-бокс напротив наименования «Сестринский блок», после чего система дает возможность назначить сотрудников в это подразделение
5. Для выпадающего списка «должность» необходимо использовать следующий справочник:
   1. Руководство
      1. Председатель
      2. Директор

• Директор ОРЦ

1. Главврач

2. Технический отдел

1. 1. Ресепшн
   2. Охрана

• Водитель

1. Сотрудник ЖКХ

1. Бухгалтерия
   1. Главный бухгалтер
   2. Бухгалтер
2. Медицинская реабилитация
   1. Врач-невролог
   2. Врач-ортопед

• Врач-физиотерапевт

1. Старшая медсестра

1. Сестринский блок
   1. Медсестра
   2. ЛФК

• Механотерапия

1. Массажист
2. Сестра-хозяйка
3. Кухонный работник

1. Психолого-педагогическая коррекция
   1. Логопед
   2. Психолог

• Дефектолог

1. Эрготерапевт

1. Социальная работа
   1. Адаптационный спорт
   2. Профориентация
2. Методический отдел
   1. Программный менеджер
   2. Менеджер
3. АРТ

6. Администратор сохраняет введенные данные.

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

Выходные данные

Создан новый пользователь в системе.

Исполнители

Пользователь с ролью «Администратор»

1.4.1.2. Функциональные требования к задаче: «Назначение прав пользователей»

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

Предусловия

1. Пользователь с ролью «Администратор» осуществил авторизацию в административной части Системы, открыл страницу созданного пользователя

Входные данные

Последовательность действий

1. Администратор открывает перечень прав для пользователя:

• Руководство
• Технический отдел
• Бухгалтерия
• Методический отдел
• Медицинская реабилитация
• Психолого-педагогическая коррекция
• Социальная работа
• Администратор

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

Выходные данные

Настроены права пользователя в системе.

Исполнители

Пользователь с ролью «Администратор»

1.4.2. Подсистема «Иерархическая структура организации»

 Участвующие роли: Администратор.

Задачи подсистемы:

1. Определение структуры организации
2. Графическое и функциональное распределение сотрудников центра по должностной иерархии
3. Быстрый поиск интересующего сотрудника организации

 1.4.2.1. Функциональные требования к задаче: «Определение структуры организации»

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

 Структура центра должна выглядеть согласно приложению 1 настоящего Технического задания.

 1.4.2.2. Функциональные требования к задаче: «Графическое и функциональное распределение сотрудников центра по должностной иерархии»

Описание: Данное функциональное требование описывает возможности, доступные на экране должностной иерархии.

 Предусловия

1. Пользователь осуществил авторизацию, в боковом меню выбрал пункт «Сотрудники»

 Последовательность действий

1. Система показывает пользователю всю структуру центра, согласно приложению 1 настоящего ТЗ
2. Пользователь из группы Администраторы должен иметь возможность менять структуру, добавлять и удалять подразделения.
3. В каждом блоке отображаются иконки сотрудников, относящиеся к этому подразделению. Принадлежность к подразделению устанавливается при заведении пользователя в систему и может быть изменено администратором по запросу от пользователя.
4. При нажатии на иконку сотрудника должно выходить всплывающее окно с краткой личной информацией выбранного сотрудника – ФИО, название подразделения, должность, e-mail и контактный телефон.

 Исполнители

Любой пользователь системы 

1.4.2.3. Функциональные требования к задаче: «Переместить пользователя из одной части структуры в другую»

 Описание: Данное функциональное требование описывает возможность изменения иерархической структуры.

 Предусловия

1. Пользователь с ролью «Администратор» осуществил авторизацию в Системе

 Основная последовательность действий:

1. Пользователь заходит в административную часть Системы.
2. Пользователь открывает окно с учетной записью нужного пользователя.
3. В пользовательских данных администратор меняет значения выпадающих списков «Отдел» и «Должность».
4. Администратор сохраняет введенные изменения.
5. Система автоматически меняет положение сотрудника на графическом отображении иерархической структуре.

 Альтернативная последовательность действий:

1. Администратор заходит в пользовательскую часть Системы, открывает меню «Сотрудники».
2. Администратор находит нужного пользователя в графической структуре организации.
3. Зажав мышкой иконку пользователя, администратор перетаскивает иконку в новое подразделение.
4. После того, как администратор наведет иконку на нужный отдел и отпустит кнопку мыши, Система автоматически выставляет у данного пользователя новое значение полей «Отдел» и «Должность» и сохраняет изменения.

 Выходные данные:

Настроено представление пользователя в структуре организации

Исполнители

Пользователь группы Администраторы

 1.4.3. Подсистема: «Личный кабинет»

 Участвующие роли: администратор, обычный пользователь.

Задачи подсистемы:

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

 1.4.3.1. Функциональные требования к задаче: «Ввод, корректировка и просмотр личных данных пользователя»

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

 Предусловия

1. Пользователь осуществил авторизацию в Системе

 Входные данные:

 Последовательность действий:

1. Пользователь в верхнем блоке экрана нажимает на кнопку для входа в личный кабинет.
2. Система отображает введенные при заведении пользователя данные.
3. Нажатием на кнопку «Изменить» пользователь инициирует изменение персональных данных
4. Пользователь вводит желаемые данные и нажимает кнопку «Сохранить»
5. Система должна проверить все ли обязательные поля остались заполненными и в случае корректных данных сохранить введенные изменения
6. В случае если какое-либо из обязательных полей не заполнено, то Система должна вывести соответствующую ошибку и предложить заполнить обязательное поле.

Выходные данные:

Отредактированные данные в личном кабинете пользователя

Исполнители

Любой пользователь системы

 1.4.3.2. Функциональные требования к задаче: «Загрузка сертификата специалиста»

 Описание: Данное функциональное требование описывает действия по загрузке сертификата пользователя

 Предусловия

1. Пользователь осуществил авторизацию в Системе
2. Пользователь открыл личный кабинет

 Входные данные:

 Последовательность действий:

1. Пользователь в личном кабинете нажимает на кнопку «Вложить файл сертификата» и Система предлагает выбрать файл с компьютера для загрузки файла (формат PDF, JPEG, PNG)
2. Пользователь после загрузки выставляет срок начала и срок окончания действия своего сертификата
3. Пользователь сохраняет настройки

Выходные данные:

Загружен сертификат пользователя в систему

Исполнители

Пользователь Системы

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

 1.4.3.3. Функциональные требования к задаче: «Загрузка персональных рабочих файлов и материалов»

 Описание: Данное функциональное требование описывает работу с персональными файлами в системе

 Предусловия

1. Пользователь осуществил авторизацию в Системе

 Последовательность действий:

1. Пользователь на боковом меню нажимает на раздел «Персональный диск».
2. В персональном диске отображаются все имеющиеся файлы, загруженные пользователем. По умолчанию у пользователя диск абсолютно пуст.
3. Работа с файлами осуществляется по такому же принципу, как в гугл диске: хранение, просмотр, скачивание, предоставление доступа.
4. Для предоставления доступа Система либо предоставляет ссылку на скачивание файла, либо открывает окно для ввода имени того, кому предоставить доступ к файлу внутри центра.
5. После предоставления доступа к файлу у получившего пользователя на личном диске должен появиться данный файл.

 Исполнители

Любой пользователь Системы

 1.4.4. Подсистема «Оснащение центра»

Участвующие роли: пользователь, администратор.

Задачи процесса: 

• Просмотр имеющейся информации по каждому кабинету центра любому пользователю Системы
• Редактирование паспорта кабинета. Заведение нового кабинета.
• Функциональные требования к задачам подсистемы «Просмотр имеющейся информации по кабинетам центра»

Описание: Данные функциональные требования описывают отображение информацию по оснащению центра.

 Предусловия

1. Пользователь осуществил авторизацию и открыл меню «Оснащение центра»

Входные данные:

Последовательность действий:

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

Выходные данные:

Пользователь просмотрел информацию по кабинету центра

Исполнители

Любой пользователь Системы

• Функциональные требования к задачам подсистемы «Редактирование паспорта кабинета. Заведение нового кабинета»

Описание: Данные функциональные требования описывают добавление информации в паспорт кабинета пользователем группа Администраторы.

Предусловия

1. Администратор осуществил авторизацию и открыл меню «Оснащение центра»

Входные данные:

Последовательность действий:

1. Система отображает перед пользователем сетку, состоящую из плиток. Каждая плитка соответствует своему кабинету в центре. Плитка имеет подпись-идентификатор, для того чтобы пользователь мог понять информацию по какому кабинету он будет просматривать.
2. Для пользователя из группы Администратор Система отображает кнопку для добавления нового кабинета к списку существующих.
3. Формат шаблона заполнения данных по кабинету представлен в приложении 2 настоящего ТЗ.
4. После нажатия кнопки «Сохранить» новый кабинет добавляется к списку для отображения пользователям.
5. При нажатии на плитку кабинета Система открывает пользователю окно с существующей информацией по данному кабинету согласно входным данным и примеру в приложении 2 настоящего ТЗ.
6. Для редактирования существующих данных напротив каждого поля в паспорте кабинета для пользователя из группы Администратор Система отображает соответствующую кнопку. При нажатии на кнопку редактирования поле становится свободным для ввода и редактирования имеющегося текста. После ввода и/или корректировки данных в поле Администратор должен подтвердить свои изменения
7. Система сохраняет введенные изменения в паспорт кабинета

Выходные данные:

Создан и/или отредактирован паспорт кабинета

Исполнители

Администратор Системы

 1.4.5. Подсистема «Расписание работы кабинетов»

• • Функциональные требования к задачам подсистемы «Предоставление информации о проводимых процедурах»

Описание: Данные функциональные требования описывают отображение информацию по занятости кабинетов и специалистов центра.

Предусловия

1. Пользователь осуществил авторизацию и открыл меню «Расписание кабинетов»

Входные данные:

Последовательность действий:

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

 Выходные данные:

Пользователь просмотрел информацию по процедурам центра

Исполнители

Любой пользователь Системы: 

• Функциональные требования к задачам подсистемы «Назначение времени и врача для проведения процедуры»

Описание: Данные функциональные требования описывают внесение в Систему данных для регистрации процедуры у конкретного врача в конкретное время.

Предусловия

1. Пользователь осуществил авторизацию и открыл меню «Расписание кабинетов»

Входные данные:

Последовательность действий:

1. Система отображает перед пользователем сетку, Представляющую собой расписание занятости кабинетов на текущий день.
2. Для регистрации новой процедуры Система отображает кнопку «Добавить процедуру» над таблицей расписания кабинетов.
3. После нажатия кнопки Система открывает окно для ввода информации: дата процедуры, время, кабинет (процедура), специалист (выбор из списка), ФИО пациента.
4. Пользователь сохраняет введенные данные.

Выходные данные:

Зарегистрирована новая процедура в Системе

Исполнители

Пользователь из группы методического отдела

• Функциональные требования к задачам подсистемы «Показ занятости врачей ОСМС»

Описание: Данные функциональные требования описывают отображение информацию по занятости кабинетов и специалистов ОСМС.

 Предусловия

1. Пользователь осуществил авторизацию и открыл меню «Расписание кабинетов»

 Входные данные:

 Последовательность действий:

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

 Выходные данные:

Пользователь просмотрел информацию по процедурам центра

Исполнители

Любой пользователь Системы

 1.4.6. Подсистема «Реестры»

Назначение:

Подсистема предназначена для просмотра информации по пациентам центра

Подсистема должна позволять:

• Создавать реестры инструментом по типу конструктора
• Просматривать данных в реестре и заполнять реестр данными
• Осуществлять поиск конкретных данных при помощи поисковой строки

 1.4.6.1 Функциональные требования к задачам подсистемы «Создавать реестры инструментом по типу конструктора»

 Описание: Данные функциональные требования описывают создание реестра в Системе.

 Предусловия

1. Пользователь группы Администратор осуществил авторизацию и открыл меню «Реестры»

 Входные данные:

 Последовательность действий:

1. Система отображает перед пользователем сетку, представляющую собой отображение существующих в системе реестров.
2. Администратор нажимает на кнопку «Добавить реестр».
3. Система открывает окно для добавления нового реестра
4. Администратор заполняет данные
5. Администратор сохраняет реестр

Выходные данные:

Пользователь просмотрел информацию по процедурам центра

Исполнители

Любой пользователь Системы

1.4.6.2 Функциональные требования к задачам подсистемы «Просматривать данных в реестре и заполнять реестр данными»

 Описание: Данные функциональные требования описывают просмотр данных реестра в Системе.

 Предусловия

1. Пользователь осуществил авторизацию и открыл меню «Реестры»

 Входные данные:

 Последовательность действий:

1. Система отображает перед пользователем сетку, представляющую собой отображение существующих в системе реестров.
2. Пользователь нажимает на кнопку «Добавить 1 запись в реестр» или «загрузить Excel».
3. При добавлении 1 записи Система открывает окно для заполнения существующих полей
4. Пользователь заполняет данные
5. Пользователь сохраняет данные
6. При выборе загрузки Excel, Система открывает стандартное окно Windows для загрузки файла. Пользователь должен выбрать на компьютере нужный файл Excel, который должен полностью совпадать по графам с выбранным реестром. Если файл не совпадает с реестром, должна выходить ошибка «Файл не подходит к выбранному реестру. Проверьте загружаемый файл»
7. Система сохраняет загруженный файл

Выходные данные:

Пользователь просмотрел информацию по процедурам центра

Исполнители

Любой пользователь Системы

Приложение 1

технического задания

к договору № __ от «__» ___ 2020г.

Иерархическая структура

Приложение 2

технического задания

к договору № __ от «__» ___ 2020г.

Пример паспорта кабинета

Ответственный за кабинет <название процедуры>: __------------------------------

1. Описание процедуры {текстовое поле}:

2. Цель и задачи <название процедуры>

{текстовое поле} Цель специалиста

{текстовое поле} Задачей специалиста

3. Материально техническое состояние кабинета <название процедуры>:

4. Оборудование и оснащение кабинета:

5. График работы кабинета <название процедуры>:

7. План развития эрготерапии:

Купить систему управления медицинским учреждением