Задание к модулю 03: Документирование требований

Цель задания

Закрепить навыки документирования требований, полученные в модуле: написание User Stories с критериями приёмки (Gherkin), приоритизацию требований по MoSCoW и построение матрицы трассировки. Задание имитирует реальную задачу аналитика на старте проекта в регулируемой отрасли.

Легенда / Контекст

Компания: Сеть частных медицинских клиник «Здоровье+» (5 клиник в трёх городах, ~200 сотрудников).

Проблема: Пациенты жалуются, что не могут:

• записаться к врачу онлайн (только по телефону, телефон занят часами);
• посмотреть свои анализы и результаты обследований (приходится ехать в клинику за бумажной копией);
• отменить или перенести запись без звонка (забывают — 20% записей — no-show, клиника теряет деньги).

Проект: Разработка личного кабинета пациента (веб + мобильное приложение).

Ключевые стейкхолдеры:

• Главный врач — заинтересован в снижении no-show и повышении лояльности
• Администраторы регистратуры — будут работать с интеграцией записи
• Пациенты — пользователи личного кабинета
• Юрист клиники — напоминает про 152-ФЗ (персональные данные), медицинскую тайну
• ИТ-директор — отвечает за интеграцию с существующей МИС (медицинской информационной системой)

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

---

Задача 1. User Stories с Acceptance Criteria

Контекст

На основе опроса пациентов и интервью с администраторами вы выделили три ключевые пользовательские потребности:

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

Задание

Напишите 3 User Stories (по одной на каждую потребность). Для каждой User Story укажите:

Часть A — User Story (шаблон Connextra):

Как [роль], я хочу [действие], чтобы [ценность]

Часть B — Acceptance Criteria в формате Gherkin:

Для каждой User Story напишите 3 Gherkin-сценария:

1. Happy Path — успешный сценарий (всё идёт хорошо)
2. Error Path — что-то пошло не так (ошибка, граничный случай, отказ системы)
3. Alternative Path — другой способ достичь цели (альтернативный поток)

Требования к Gherkin:

• Используйте ключевые слова: Дано (Given) / Когда (When) / Тогда (Then) / И (And) / Но (But)
• Указывайте конкретные данные, а не абстракции («врач-терапевт Иванова А.С.», «10:30», «анализ крови №12345»)
• Каждый сценарий — законченный, независимый поток

Формат:

### User Story №1: Онлайн-запись к врачу

**Как** зарегистрированный пациент, **я хочу** записаться на приём к врачу онлайн через личный кабинет, **чтобы** не тратить время на звонок в регистратуру.

**Сценарий 1: Успешная запись к свободному врачу**
    Дано пациент авторизован в личном кабинете
    Когда пациент выбирает врача-терапевта Иванову А.С.
    И выбирает дату "20.06.2026"
    И выбирает свободное время "10:30"
    И нажимает кнопку "Записаться"
    Тогда в личном кабинете отображается запись на 20.06.2026 в 10:30 к врачу Ивановой А.С.
    И на email пациента приходит подтверждение записи

**Сценарий 2: Ошибка — выбранное время уже занято**
    ...

**Сценарий 3: Запись через выбор свободного времени (без выбора конкретного врача)**
    ...

---

Задача 2. Приоритизация требований методом MoSCoW

Контекст

Главный врач предоставил список из 8 требований к системе. Ресурсы ограничены: команда из 4 разработчиков, срок — 4 месяца на MVP. Вам необходимо распределить требования и аргументировать решение перед заказчиком.

Исходные требования (от главного врача и опроса пациентов):

№	Требование	Источник
1	Пациент может записаться на приём к врачу онлайн с выбором даты и времени	Интервью с пациентами (топ-1 жалоба)
2	Пациент может просмотреть историю своих записей (дата, врач, специальность)	Интервью с пациентами
3	Пациент может отменить запись онлайн (не позднее 2 ч до приёма)	Главный врач (no-show 20%)
4	Система отправляет push-уведомление / email за 24 часа до приёма (напоминание)	Интервью с пациентами (забывают)
5	Пациент может прикрепить скан полиса ОМС / ДМС к своему профилю	Требование юриста (152-ФЗ)
6	Система интегрируется с существующей МИС (медицинской информационной системой) для синхронизации расписания врачей	ИТ-директор (иначе запись не имеет смысла)
7	Пациент может просмотреть результаты анализов (скан PDF, загруженный лабораторией)	Интервью с пациентами (топ-3 жалобы)
8	Пациент может оценить врача (звёзды + отзыв) после приёма	Главный врач (хочет KPI по врачам)

Задание

Распределите 8 требований по категориям MoSCoW для MVP (релиз 1.0, 4 месяца).

Для каждого требования укажите:

№	Категория MoSCoW	Обоснование (почему именно эта категория)
1	M / S / C / W	...

Обоснование должно включать:

• Для Must: «Без этого требования MVP не имеет смысла, потому что...» или «Нет workaround — пациенты не могут записаться иначе»
• Для Should: «Важно, но есть workaround: ...»
• Для Could: «Добавляет ценность, но её отсутствие не повлияет на запуск, потому что...»
• Для Won't (в MVP): «Сознательно отложено на релиз 2.0, потому что...»

Дополнительное задание (анализ по Кано)

Для каждого из 8 требований предположите его категорию по модели Кано:

• Базовое (Must-be)
• Линейное (One-dimensional)
• Восторгающее (Attractive)

Добавьте колонку «Категория по Кано» в вашу таблицу и одним предложением объясните, почему вы так классифицировали.

---

Задача 3. Матрица трассировки (фрагмент)

Контекст

Вам нужно показать главному врачу и ИТ-директору, как требования связаны между собой — от бизнес-целей до тест-кейсов. Составьте фрагмент RTM.

Дано

Бизнес-требования (BR):

• BR-001: Снизить долю несостоявшихся приёмов (no-show) с 20% до 5%
• BR-002: Повысить удовлетворённость пациентов качеством сервиса (NPS ≥ 70)
• BR-003: Обеспечить соответствие требованиям 152-ФЗ (персональные данные пациентов)

Функциональные требования (FR) — возьмите любые 5 из 8 требований предыдущей задачи и присвойте им ID (FR-001 — FR-005).

Нефункциональные требования (NFR):

• NFR-001: Время загрузки страницы с расписанием врачей — не более 2 секунд (Performance)
• NFR-002: Передача данных между ЛК и МИС — по защищённому каналу (TLS 1.3) (Security)

Компоненты системы:

• Frontend (Web) — веб-версия личного кабинета
• Mobile App — мобильное приложение
• Auth Service — сервис авторизации и управления профилем
• Appointment Service — сервис записи на приём
• Integration Gateway — шлюз интеграции с МИС
• Notification Service — сервис отправки уведомлений

Тест-кейсы (гипотетические, придумайте по смыслу):

• TC-001 — Запись к врачу — успешный сценарий
• TC-002 — Запись к врачу — выбранное время занято
• TC-003 — Отмена записи менее чем за 2 часа до приёма
• TC-004 — Напоминание о приёме приходит за 24 часа
• TC-005 — Загрузка PDF с результатами анализов
• TC-006 — Интеграция с МИС: расписание синхронизировано
• TC-007 — Оценка врача — успешная отправка

Задание

Составьте матрицу трассировки (Markdown-таблица) со следующими колонками:

ID требования	Описание	Источник (BR / Stakeholder)	Приоритет (M/S/C/W)	Компонент	Тест-кейсы	Статус

Включите в таблицу:

• 5 FR (из задачи 2)
• 2 NFR
• Все 6 компонентов должны быть задействованы хотя бы раз
• Не менее 6 тест-кейсов из списка должны быть привязаны к требованиям

Статусы проставьте произвольно, но реалистично:

• ✅ — реализовано / PASS
• 🟡 — в разработке
• 🔴 — не начато / FAIL
• ❌ — не тестировалось

После таблицы напишите 2–3 предложения «Анализа покрытия»:

• Какие требования не покрыты тестами? (если есть)
• Какие тест-кейсы избыточны? (если есть)
• Какие риски вы видите на основе RTM?

---

Критерии оценки

Задача	Критерий	Баллы
Задача 1	3 User Story в формате Connextra (роль + действие + ценность)	1,5
	По 3 Gherkin-сценария на каждую (Happy Path + Error + Alternative)	3
	Корректный синтаксис Gherkin (Given/When/Then/And), конкретные данные	1,5
Задача 2	Распределение 8 требований по MoSCoW с обоснованием	2
	Категория по Кано для каждого требования с обоснованием	1
Задача 3	RTM-таблица: 5 FR + 2 NFR, колонки, тест-кейсы	1
	Анализ покрытия (риски, пробелы)	1
Максимум		10

---

Формат сдачи

• Файл: module03-Фамилия.md
• Структура: 3 чётко озаглавленных раздела
• Таблицы в Markdown

---

Подсказки

Для Задачи 1 (User Stories):

• Помните про медицинскую тайну — в Gherkin не используйте реальные ФИО пациентов, но врачей — можно
• Для Error Path подумайте: что, если врач заболел? Что, если приём через 1 час, а пациент хочет отменить? Что, если анализа ещё нет в системе?
• Alternative Path: запись не через врача, а через «свободное окно»; просмотр анализов не через ЛК, а через QR-код из клиники

Для Задачи 2 (MoSCoW + Кано):

• Интеграция с МИС — это, скорее всего, Must, потому что без неё запись не работает
• Оценка врача — типичный Could (приятно, но не для MVP)
• 152-ФЗ — Must по юридическим причинам
• По Кано: просмотр анализов — в 2026 году это уже не восторг, а база (все так делают). А вот оценка врача — всё ещё линейная (не восторг, но влияет на удовлетворённость)

Для Задачи 3 (RTM):

• Не обязательно все тест-кейсы привязывать — какие-то требования могут оказаться без тестов (это нормально для RTM, главное — подсветить это в анализе)
• NFR обычно тестируются не функциональными тестами, а нагрузочными / security-аудитом — укажите это