diff --git a/labs/lab3/report.pdf b/labs/lab3/report.pdf
new file mode 100644
index 0000000..2c2d1b8
Binary files /dev/null and b/labs/lab3/report.pdf differ
diff --git a/labs/lab3/report.typ b/labs/lab3/report.typ
new file mode 100644
index 0000000..4072619
--- /dev/null
+++ b/labs/lab3/report.typ
@@ -0,0 +1,198 @@
+#set text(size: 1.3em)
+
+#show raw.where(block: false): box.with(
+ fill: luma(240),
+ inset: (x: 3pt, y: 0pt),
+ outset: (y: 3pt),
+ radius: 2pt,
+)
+
+#show raw.where(block: true): block.with(
+ fill: luma(240),
+ inset: 10pt,
+ radius: 4pt,
+)
+
+// title
+
+#align(center)[Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики]
+\
+\
+\
+#align(center)[Факультет инфокоммуникационных технологий]
+#align(center)[Направление подготовки 11.03.02]
+\
+\
+#align(center)[Лабораторная работа №3]
+#align(center)[Создание требований к разрабатываемой информационной системе]
+\
+\
+\ //#align(center)[Вариант 19]
+\
+\
+\
+\
+\
+\
+\
+#align(right)[Выполнил:]
+#align(right)[Дощенников Никита Андреевич]
+#align(right)[Группа: К3221]
+#align(right)[Проверил:]
+#align(right)[Иванов Сергей Евгеньевич]
+\
+\
+#align(center)[Санкт-Петербург]
+#align(center)[2025]
+
+#pagebreak()
+
+=== Цель работы.
+
+Изучение требований к информационной системе и использование методов их выявления для разработки проекта системы регистрации пациента в больнице.
+
+=== Результаты.
+
+==== 1. Общие сведения о требованиях
+
+Требование к системе — это условие или свойство, которому должна удовлетворять информационная система, чтобы удовлетворить потребности пользователей и соответствовать стандартам и техническим спецификациям.
+
+Стандарты для работы с требованиями:
+
+- ГОСТ 19.201-78: Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
+
+- ГОСТ 34.602-89: Информационная технология. Техническое задание на создание автоматизированной системы.
+
+Типы требований:
+
+- Функциональные — описывают действия и поведение системы при обработке информации (что система должна уметь делать).
+
+- Нефункциональные — определяют атрибуты системы или её окружения:
+
+ - требования к применению (качество ПО, документации),
+
+ - требования к производительности (время отклика, пропускная способность),
+
+ - требования к реализации (стандарты, языки программирования, операционная среда),
+
+ - требования к надежности (частота сбоев, возможности восстановления),
+
+ - требования к интерфейсу (взаимодействие с внешними сущностями и регламент этого взаимодействия).
+
+Методы выявления требований:
+
+- Собеседование (интервьюирование)
+
+- Анкетирование
+
+- Моделирование и анализ бизнес-процессов
+
+- Сессии по выявлению требований (мозговой штурм)
+
+- Создание и демонстрация работающих прототипов приложений
+
+Документы для оформления требований:
+
+- Словарь предметной области (глоссарий)
+
+- Концепция системы
+
+- Дополнительные спецификации (технические требования)
+
+==== 2. Глоссарий
+
+- Пациент — человек, обращающийся в больницу за медицинской помощью.
+
+- Регистратор — сотрудник, оформляющий приём и регистрацию пациента.
+
+- Врач — медицинский работник, назначающий лечение и процедуры.
+
+- Заведующий отделением — руководитель подразделения, контролирующий пропускную способность и отчёты.
+
+- Бухгалтерия — отдел финансового учёта больницы.
+
+- Отделение — структурная единица больницы с палатами и койками.
+
+- Палата — помещение для размещения одного или нескольких пациентов.
+
+- Эпикриз — выписной документ о состоянии пациента и проведённом лечении.
+
+==== 3. Концепция системы
+
+Цель проекта: Создать информационную систему регистрации и сопровождения пациентов в больнице, обеспечивающую автоматизацию процесса приёма, размещения, лечения и выписки пациентов, а также ведение отчётности.
+
+Основные возможности системы:
+
+- Регистрация нового пациента
+
+- Определение отделения и палаты для пациента
+
+- Перевод пациента в другое отделение
+
+- Выставление счета за услуги
+
+- Просмотр наличия свободных мест
+
+- Назначение диагноза, статуса, лечения, процедур и операций
+
+- Назначение платных услуг и выписка лекарств
+
+- Создание выписного эпикриза
+
+- Формирование отчётов по пропускной способности, среднему времени пребывания, осложнениям при операциях
+
+==== 4. Функциональные требования
+
+- Регистратура:
+ - Зарегистрировать нового пациента
+ - Определить пациента в отделение
+ - Перевести пациента в другое отделение
+ - Закрепить пациента в палате
+ - Выставить счет за услуги
+ - Просматривать наличие свободных мест (мужские/женские)
+
+- Врач:
+ - Назначить диагноз
+ - Проставить статус больного
+ - Назначить лечение
+ - Назначить процедуры
+ - Назначить дату и время процедур
+ - Назначить операцию
+ - Проставить статус операции
+ - Назначить платные услуги
+ - Выписать лекарственные средства
+ - Выписать пациента
+ - Создать выписной эпикриз
+
+- Заведующий отделением:
+ - Формировать отчёты о пропускной способности
+ - Формировать отчёты по среднему времени пребывания
+ - Формировать отчёты по операциям с осложнениями
+
+==== 5. Нефункциональные требования
+
+Производительность: Время отклика системы при регистрации не более 2 секунд; пропускная способность — до 100 регистраций в день.
+
+Надёжность: Система должна иметь резервное копирование данных; допускается не более 1 сбоя в месяц.
+
+Юзабилити: Интерфейс должен быть удобен для быстрого ввода данных регистратором и врачом.
+
+Документация: Система сопровождается руководством пользователя и технической документацией.
+
+Интерфейс: Возможность взаимодействия с внешними системами (например, финансовый учёт, склад лекарств).
+
+==== 6. Дополнительные спецификации
+
+Система реализуется в виде веб-приложения.
+
+Используемая СУБД — PostgreSQL.
+
+Язык программирования: Python (backend) и JavaScript (frontend).
+
+Поддержка многопользовательского режима с разграничением прав доступа.
+
+=== Выводы
+
+В ходе выполнения работы были изучены методы выявления требований к информационной системе, разработан глоссарий предметной области, концепция и функциональные/нефункциональные требования для проекта «Система регистрации пациента в больнице».
+
+В результате проделанной работы получен полный набор требований, позволяющий строить дальнейшие модели системы, проектировать интерфейсы и готовить техническое задание для реализации.
diff --git a/labs/lab4/assets/1.svg b/labs/lab4/assets/1.svg
new file mode 100644
index 0000000..18b06cf
--- /dev/null
+++ b/labs/lab4/assets/1.svg
@@ -0,0 +1,102 @@
+
\ No newline at end of file
diff --git a/labs/lab4/assets/2.svg b/labs/lab4/assets/2.svg
new file mode 100644
index 0000000..977eca0
--- /dev/null
+++ b/labs/lab4/assets/2.svg
@@ -0,0 +1,102 @@
+
\ No newline at end of file
diff --git a/labs/lab4/assets/3.svg b/labs/lab4/assets/3.svg
new file mode 100644
index 0000000..d1b4dae
--- /dev/null
+++ b/labs/lab4/assets/3.svg
@@ -0,0 +1,102 @@
+
\ No newline at end of file
diff --git a/labs/lab4/assets/4.svg b/labs/lab4/assets/4.svg
new file mode 100644
index 0000000..69d4fcc
--- /dev/null
+++ b/labs/lab4/assets/4.svg
@@ -0,0 +1,102 @@
+
\ No newline at end of file
diff --git a/labs/lab4/report.pdf b/labs/lab4/report.pdf
new file mode 100644
index 0000000..b2497a2
Binary files /dev/null and b/labs/lab4/report.pdf differ
diff --git a/labs/lab4/report.typ b/labs/lab4/report.typ
new file mode 100644
index 0000000..113489d
--- /dev/null
+++ b/labs/lab4/report.typ
@@ -0,0 +1,164 @@
+#set text(size: 1.3em)
+
+#show raw.where(block: false): box.with(
+ fill: luma(240),
+ inset: (x: 3pt, y: 0pt),
+ outset: (y: 3pt),
+ radius: 2pt,
+)
+
+#show raw.where(block: true): block.with(
+ fill: luma(240),
+ inset: 10pt,
+ radius: 4pt,
+)
+
+// title
+
+#align(center)[Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики]
+\
+\
+\
+#align(center)[Факультет инфокоммуникационных технологий]
+#align(center)[Направление подготовки 11.03.02]
+\
+\
+#align(center)[Лабораторная работа №4]
+#align(center)[Создание модели бизнес-процесса в нотации IDEF]
+\
+\
+\ //#align(center)[Вариант 19]
+\
+\
+\
+\
+\
+\
+\
+#align(right)[Выполнил:]
+#align(right)[Дощенников Никита Андреевич]
+#align(right)[Группа: К3221]
+#align(right)[Проверил:]
+#align(right)[Иванов Сергей Евгеньевич]
+\
+\
+#align(center)[Санкт-Петербург]
+#align(center)[2025]
+
+#pagebreak()
+
+=== Цель работы.
+
+Изучение методики создания модели бизнес-процесса в нотации IDEF0 и IDEF3 для системы регистрации пациента в больнице.
+
+=== Результаты.
+
+===== Часть 1. Моделирование в нотации IDEF0.
+
+1. Контекстная диаграмма.
+
+Главный процесс: «Регистрация и сопровождение пациента в больнице».
+Входы: данные о пациенте, запросы на отчёты, данные о счетах.
+Выходы: подтверждение регистрации, медицинские назначения, выписки, отчёты, счета на оплату.
+Механизмы: персонал регистратуры, лечащие врачи, заведующий отделением, бухгалтерия, система.
+Управляющие воздействия: внутренние регламенты больницы, стандарты оформления, нормативные документы.
+
+#align(center)[#image("assets/1.svg")]
+
+2. Основные процессы проекта IDEF0.
+
+- Регистрация пациента: приём и оформление данных, распределение по отделениям, закрепление в палате.
+
+- Медицинское сопровождение: назначение диагноза, процедур, операций, выписка.
+
+- Финансовый учёт: выставление счетов, учет платных услуг.
+
+- Формирование отчетов: пропускная способность, среднее время пребывания, количество операций с осложнениями.
+
+3. Тип бизнес-процесса.
+
+Процесс комплексный, управленческий и обслуживающий, ориентирован на автоматизацию административной и медицинской деятельности.
+
+4. Входы, выходы, механизмы и управляющие воздействия.
+
+- Входы: данные пациента, заявки на оплату, запросы на отчёты
+
+- Выходы: подтверждения, отчёты, счета, выписки
+
+- Механизмы: система, регистратура, врачи, бухгалтерия, заведующий отделением
+
+- Управляющие воздействия: внутренние регламенты, стандарты, нормативные документы
+
+5. Декомпозиция уровня А-1
+
+Подпроцессы:
+
+- A1: Регистрация пациента
+
+- A2: Медицинское сопровождение
+
+- A3: Финансовый учёт
+
+- A4: Формирование отчетов
+
+#align(center)[#image("assets/2.svg")]
+
+6. Декомпозиция уровня А-2
+
+- A1.1: Ввод данных пациента
+
+- A1.2: Размещение в отделении
+
+- A1.3: Закрепление в палате
+
+- A2.1: Назначение диагноза
+
+- A2.2: Назначение процедур и операций
+
+- A2.3: Выписка пациента
+
+#align(center)[#image("assets/3.svg")]
+
+==== Часть 2. Моделирование в нотации IDEF3.
+
+7. Диаграмма IDEF3
+
+Показана последовательность действий и информационных потоков для процесса «Регистрация и сопровождение пациента»:
+
+- Приём пациента → Проверка документов → Регистрация → Назначение диагноза → Планирование лечения → Выписка
+
+- Взаимодействие с отделом бухгалтерии для оплаты услуг
+
+- Взаимодействие с заведующим отделением для формирования отчетов
+
+#align(center)[#image("assets/4.svg")]
+
+8. Основные информационные потоки и отношения
+
+- Пациент передаёт персональные данные и заявления → регистратура
+
+- Регистратура вводит данные в систему → врач, бухгалтерия
+
+- Врач назначает процедуры → регистратура, система
+
+- Система формирует отчёты → заведующий отделением
+
+9. Перекрестки логики
+
+- Решение о направлении пациента в отделение (A1.2) зависит от наличия свободных мест и категории палаты
+
+- Назначение процедур/операций (A2.2) зависит от диагноза и статуса пациента
+
+- Оплата услуг (A3) зависит от выставленного счёта и выбора пациента
+
+=== Выводы
+
+В ходе выполнения работы были построены модели бизнес-процессов в нотациях IDEF0 и IDEF3 для информационной системы регистрации пациента в больнице.
+
+- Сформированы контекстная диаграмма, декомпозиции уровней А-1 и А-2
+
+- Определены входы, выходы, механизмы и управляющие воздействия процессов
+
+- Построена диаграмма информационных потоков и логики процессов в нотации IDEF3
+
+В результате получены полные модели, позволяющие визуализировать последовательность действий, информационные потоки и взаимодействие участников системы, что обеспечивает основу для дальнейшей автоматизации и проектирования интерфейсов.