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

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

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

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

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

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

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

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

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

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