Описание экранной формы и логики на FE (frontend) — артефакт системного аналитика, который фиксирует наблюдаемое поведение интерфейса: экраны, поля, состояния, клиентские правила, навигацию и обработку ошибок. Он связывает бизнес-требования с реализацией и тестами, дополняет User Story / Use Case (зачем и в каких сценариях) и не подменяет спецификацию REST/SOAP API — ссылается на неё для источников данных и кодов ошибок. FE — presentation-интерфейс к API и процессу — 03.01.04 Интерфейсы и интеграционные взаимодействия. Теория прототипирования и UX-исследований — в 02.02.04 Прототипирование и UI-UX-исследования.
1. Назначение
Документ пишет системный аналитик; его читают frontend-разработка, QA, UX/UI-дизайнер и Product Owner на этапах оценки, реализации и приёмки экрана.
Шаблон закрывает четыре задачи:
- Спецификация presentation + interaction — что видит пользователь, какие элементы доступны, как реагирует UI на действия; уровень детализации, достаточный для оценки story и test-кейсов (см. DoR ниже).
- Контракт клиентской логики (FE logic) — валидации, видимость полей, wizard steps, debounce, локальные вычисления — с явным указанием источника истины (FE vs BE).
- Мост к API и процессу — mapping «поле экрана ↔ JSON path / query param» и поведение UI при каждом HTTP/business code; без копипасты OpenAPI.
- Трассировка (traceability) — Screen ID → User Story / Use Case / SRS req ID → API operations → NFR / ADR.
Один экран — один документ (или один раздел с якорями). Крупные wizard'ы: родительский Screen ID FE-{DOMAIN}-{NAME} + шаги FE-{DOMAIN}-{NAME}-STEP-01, …-STEP-02 — все ID заносятся в 10.01.15 Шаблон матрицы трассировки. Один US может покрывать несколько Screen ID — порядок и передача контекста описываются в §3.2 и §3.10.
Уровень детализации: для оценки story достаточно паспорта, зон, ключевых controls и primary actions; для merge в sprint — полный DoR «Ready» (§3.13).
2. Когда использовать
Подходит, если:
- story или use case согласованы, и нужна implementability на уровне UI: поля, состояния, кнопки, сообщения;
- экран — touchpoint в BPMN-процессе (10.01.08 Шаблон сквозной фичи (BPMN-процесс)) или шаг customer journey;
- QA готовит UI-тесты и нужна матрица «состояние × что видно/доступно»;
- есть макет (Figma), но поведение неочевидно: зависимости полей, права по ролям, обработка ошибок API;
- экран показывает статус асинхронной операции — нужно явно описать UX ожидания (polling по REST, WebSocket/SSE; см. §3.7).
Не подходит или требует дополнения, если:
- нужна только ценность для роли без детализации UI — достаточно 10.01.01 Шаблон User Story или Job Story из 04.02 Пользовательские истории (User Stories) и Job Stories;
- нужен пошаговый сценарий актор–система с ветвлениями без привязки к конкретному экрану — 10.01.02 Шаблон Use Case;
- задача сводится к контракту данных без UI — 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API;
- нужен pixel-perfect визуальный дизайн — это Design System / Figma; FE-шаблон описывает функциональное и интерактивное поведение;
- экран — чистый read-only dashboard или list-only без submit — используйте упрощённый чеклист §3.13 (ветка «read-only»); NFR по производительности — в 10.01.12 Шаблон нефункциональных требований (NFR);
- внутренняя архитектура FE (компоненты, store, state management) — только если зафиксировано в 10.01.13 Шаблон архитектурного решения (ADR); иначе фокус на наблюдаемом поведении.
Входные условия: роли согласованы (10.01.11 Шаблон ролевой модели), upstream US/UC/SRS известны, API operations для экрана определены или в draft (см. §3.7), термины — в 10.01.14 Шаблон глоссария и словаря данных.
3. Структура документа
Скопируйте блок в Confluence, Notion или ваш RM-инструмент.
Definition of Ready для UI
Три уровня готовности — не смешивайте «можно оценить story» и «можно брать в спринт»:
| Уровень | Когда | Минимум (блокеры) | Желательно |
|---|---|---|---|
| DoR-Estimate | Refinement, story points | Паспорт §3.1, цель и точки входа §3.2, зоны §3.3, ключевые controls + primary actions, draft или TBD API ref | RBAC-черновик, макет |
| DoR-Ready | Старт разработки экрана | Всё из чеклиста §3.13 «обязательно для Ready» | Полная матрица states, AC §3.11 |
| DoR-Merge | PR / приёмка | AC покрыты, открытые вопросы закрыты или вынесены в follow-up story | Test case ID в §3.11 / RTM |
Согласование DoR с командой — в контексте 05.02 Scrum и Kanban (аналитик в Agile). Качество формулировок перед Ready — 02.04.03 Управление качеством требований; общий gate перед dev — 10.04 Чеклист аналитика перед стартом разработки.
Поля с пометкой обяз. в подразделах ниже — для DoR-Ready, если не указано иное.
3.1. Паспорт экрана (метаданные)
| Поле | Обяз. | Что писать |
|---|---|---|
| Screen ID | да | Уникальный идентификатор, напр. FE-LEAVE-LIST-02. Согласуйте naming с RTM — 10.01.15 Шаблон матрицы трассировки (матрица трассирует ID, схема именования — на уровне проекта). |
| Название экрана | да | Бизнес-название: «Список заявок на согласование». |
| Маршрут / URL | да | /leave/approvals, deep link-параметры. |
| Parent / wizard group | нет* | Для шага wizard: parent Screen ID. *Обязательно для -STEP-XX. |
| Продукт / модуль | да | Система или bounded context. |
| Версия, статус, дата | да | Draft → Review → Ready → Implemented; автор последнего изменения. |
| Upstream: US / UC / SRS / BRD | да | US-0247, UC-LEAVE-015, SRS-REQ-045 — ссылки, не пересказ. |
| BPMN touchpoint | нет | Task ID процесса, напр. T-05 — 10.01.08 Шаблон сквозной фичи (BPMN-процесс). |
| Макет / прототип | да* | Ссылка на Figma или wireframe. *Обязательно, если UI не тривиален. |
| Scope UI | да | Desktop-only / responsive / mobile-first. При разной логике на breakpoints — минимум: скрытые колонки vs отдельный маршрут vs drawer вместо modal. |
3.2. Назначение и контекст
| Поле | Обяз. | Что писать |
|---|---|---|
| Цель экрана | да | 1–2 предложения: какую задачу пользователь решает на этом экране. |
| Точки входа | да | Меню, ссылка из письма, redirect после login, deep link с query params. |
| Точки выхода | да | Куда ведут primary/secondary actions после успеха или отмены. |
| Цепочка экранов (multi-screen) | нет* | Если один US → несколько Screen ID: порядок, что передаётся (route param, query, session, router state). *Обязательно при сценарии из 2+ экранов. |
| Предусловия | да | Auth (роль, SSO), данные с предыдущего шага, feature flags. |
| Постусловия | нет | Состояние системы после успешного submit (напр. «заявка в статусе Согласована»). |
| Data scope / tenant | да* | Кто фильтрует данные по отделу, tenant, org unit — BE (API query/header) или UI-only hint. *Обязательно, если видимость данных зависит от роли или контекста. Источник истины для data scoping — почти всегда BE; в RBAC-таблице UI — только проекция. |
3.3. Макет и зоны
| Поле | Обяз. | Что писать |
|---|---|---|
| Схема зон | да | Функциональное описание: header, filters, data grid, footer actions, modals — не pixel-perfect. |
| Зоны (таблица) | нет | ID зоны, назначение, состав элементов (ссылки на Control ID). |
3.4. Элементы и поля
Для каждого элемента управления (control). Control ID = {Screen ID}-{тип}-{имя}, напр. FE-LEAVE-LIST-02-FLD-status, FE-LEAVE-LIST-02-BTN-approve — префикс Screen ID обязателен для трассировки и RTM.
| Поле | Обяз. | Что писать |
|---|---|---|
| Control ID | да | Стабильный ID с префиксом Screen ID; типы: FLD, BTN, GRD, MDL и т.д. |
| Label / placeholder | да | Текст или ключ локализации (i18n key). |
| Control type | да | Input, select, date picker, checkbox, button, tab, modal, file upload, data grid и т.д. |
| Binding | да | Поле API (response.items[].status) или локальное (filterState.dateFrom). |
| Persistence | да* | Где живёт значение: URL query (shareable, back/refresh), in-memory (сессия вкладки), localStorage, API only. *Обязательно для фильтров, wizard, форм с deep link. |
| Обязательность | да | Required / optional; условная обязательность — в правилах отображения. |
| Формат / маска | нет | Regex, min/max, decimal places, date format. |
| Tooltip / help text | нет | Подсказка или ссылка на глоссарий. |
| Read-only условия | нет | Когда поле недоступно для редактирования (роль, статус заявки) — см. приоритет §3.6. |
| Default value | нет | Значение при initial load; источник (API, localStorage, query param). |
| List / grid behavior | нет* | Сортировка, пагинация (page/size), infinite scroll, row selection — для таблиц и списков. *Обязательно для list/grid экранов. |
| File upload | нет* | Max size, MIME, preview, progress bar, ошибки — ссылка на NFR и API multipart. *Для upload controls. |
Правило URL vs in-memory: если фильтр или состояние должно пережить refresh, «Назад» в браузере или шаринг ссылки — Persistence = URL query и mapping в §3.7. Чисто UI-состояние (раскрытая панель, draft modal) — in-memory, если не описано иное в §3.10.
Правило i18n: если продукт мультиязычный (NFR) — в статусе Ready Label и тексты §3.9 только как i18n key; literal допустим в Draft. RTL, плюрализация, fallback-локаль — в 10.01.12 Шаблон нефункциональных требований (NFR), не дублировать здесь.
3.5. Клиентская валидация
| Поле | Обяз. | Что писать |
|---|---|---|
| Правило | да* | Условие: «комментарий ≥ 10 символов». *Для каждого поля с проверкой на FE. |
| Момент проверки | да | on blur, on change, on submit. |
| Текст ошибки | да | Точный текст или i18n key. |
| Источник истины | да | FE / BE / оба — если дублируется BE, указать явно. |
| При расхождении FE и BE | да* | BE всегда финальный arbiter на submit: показываем текст и поле из ответа API (4xx + body), FE-ошибку снимаем. FE может быть строже до submit (ранняя обратная связь). *Если есть и FE, и BE validation. |
3.6. Бизнес-правила на UI
| Поле | Обяз. | Что писать |
|---|---|---|
| Правило отображения (display rule) | да* | Условие показа/скрытия, обязательности, default — по роли, статусу сущности, feature flag. *Для нетривиального UI. |
| Зависимости полей | нет | «При типе отпуска = Без сохранения ЗП поле «Дата окончания» скрыто». |
| Автозаполнение / вычисления | нет | Локальные формулы на FE; не дублировать серверные инварианты без пометки. |
| Wizard / steps | нет | Нумерация шагов, условия перехода «Далее» / «Назад», сохранение черновика между шагами. |
| Матрица RBAC по элементам | да | Проекция глобальной ролевой модели на controls: visible / hidden / disabled. Канон ролей и permission model — 10.01.11 Шаблон ролевой модели; здесь только per-screen, с пометкой «согласовано с 10.01.11». Data scoping («видит только свой отдел») — в §3.2 Data scope, не подменяет RBAC. |
Приоритет ограничений (если правила пересекаются, применяется более строгое):
- RBAC — hidden/disabled по роли;
- Business status — напр. заявка «Согласована» → submit hidden;
- Read-only / display rule — поле disabled по условию;
- Feature flag — experimental UI off → hidden.
При конфликте явно зафиксируйте итог в display rule или AC. Row-level disabled по business status — это display rule (п. 2–3), RBAC определяет только baseline visible/enabled по роли.
3.7. Интеграции (действия пользователя → API)
| Поле | Обяз. | Что писать |
|---|---|---|
| Действие | да | Клик «Согласовать», submit формы, смена фильтра, infinite scroll. |
| API operation | да | Contract Ref: API-LEAVE-003 или TBD-API-LEAVE-003 (draft) — 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API; не копировать весь контракт. Для GraphQL/BFF — тот же Contract Ref и mapping; контракт из 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) или 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL) по шаблону API проекта. |
| Request mapping | да* | Поле экрана → JSON path / query param / header. *Для Ready — mapping для всех primary actions; при draft API допустимы TBD-поля с владельцем и датой. |
| Response mapping | да* | JSON path → поле экрана; что обновляется в UI после ответа. *Аналогично draft. |
| HTTP method / idempotency | нет* | POST vs PATCH; double-submit: disable + loading на кнопке, повторный клик игнорируется; для POST без idempotency-key — confirm или debounce. Семантика HTTP — 07.02 Принципы работы HTTP, REST, SOAP. *Для submit actions. |
| Поведение при кодах | да | Только UX-реакция: toast, inline, redirect. Семантика HTTP и business codes — в API spec; не придумывайте коды здесь, ссылайтесь на 10.01.04 Шаблон спецификации REST API. |
| Async / long-running | нет* | Типично: GET polling, WebSocket/SSE — interval, timeout, cancel, прогресс. Фоновые job через очередь — только если UI завязан на event pipeline: 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) / 10.01.10 Шаблон описания Airflow-триггеров и автоматических процессов. *Обязательно при операциях > few seconds. |
| Refetch / cache | нет | После PATCH/POST: refetch list vs optimistic update vs stale banner; конфликт версий (409 / 412) — сообщение и действие (reload, merge). |
| Product analytics / audit | нет | ID события UI (клик, submit) или N/A; audit trail на touchpoint — ссылка на BRD/NFR; при сквозном процессе — task ID в 10.01.08 Шаблон сквозной фичи (BPMN-процесс). |
Workflow при draft API: экран может быть DoR-Ready с TBD-API-XXX для вторичных actions; primary submit блокирует Ready, если нет хотя бы draft operation в 10.01.04. Mapping обновляется при финализации контракта — строка в §3.12 «история изменений».
3.8. Состояния экрана (UI states)
Матрица «состояние × что видно/доступно» — обязательный минимум для DoR-Ready. Диаграмма состояний (03.02.04 Диаграмма состояний (State Machine Diagram)) — когда ≥5 переходов между states, параллельные регионы (wizard + async) или нужно согласование с BE state machine; иначе достаточно таблицы ниже.
| Состояние | Обяз. | Что писать |
|---|---|---|
| Initial / loading | да | Skeleton, spinner; блокировка действий. |
| Populated | да | Данные загружены; active primary actions. |
| Empty | да | Пустой список / форма; текст и CTA («Создать заявку»). |
| Validation error | да | Inline-ошибки у полей; submit заблокирован или с сообщением. |
| Business error | да | Ошибка домена от API (напр. «Заявка уже обработана»). |
| API / network error | да | Retry, offline banner, fallback UI. |
| Submit in progress | да* | Loading на primary action, блок double-submit. *Для форм с submit. |
| Session expired (401) | да* | Initial load 401 → redirect login; 401 на submit dirty form → unsaved changes §3.10 (modal / redirect, потеря данных). *Для экранов с auth; детали безопасности — 08.07 Основы кибербезопасности для системного аналитика. |
| Read-only / success | нет | После submit; экран только для просмотра. |
| Stale / version conflict | нет | Данные устарели после чужого редактирования; explicit reload / «Обновите страницу». |
| Partial load / optimistic | нет | Optimistic UI до ответа BE; rollback при ошибке — или ссылка на ADR. |
3.9. Сообщения и ошибки
| Поле | Обяз. | Что писать |
|---|---|---|
| Тип сообщения | да | Toast, inline, modal, banner. |
| Триггер | да | Успешный submit, validation fail, API error code. |
| Текст | да | Точная формулировка или i18n key. |
| Retry / dismiss | нет | Кнопки и поведение при повторе. |
| Support ID (для пользователя) | нет | Короткий код или request id в UI для обращения в поддержку — без секретов и PII — 08.07 Основы кибербезопасности для системного аналитика. |
| Логирование (для support/ops) | нет | Correlation id, trace id — что пишется в log клиента/BE, не обязательно показывать пользователю. |
3.10. Навигация
| Поле | Обяз. | Что писать |
|---|---|---|
| Primary / secondary actions | да | Кнопки, условия активности (enabled/disabled) — с учётом приоритета §3.6. |
| Переходы | да | Target route, query params, modal vs full page; target Screen ID. |
| Back behavior | да | Browser back, breadcrumb; восстановление фильтров из URL vs сброс. |
| Unsaved changes | да* | Confirm при уходе с dirty form; при 401 на submit — см. §3.8 Session expired. *Обязательно для форм редактирования; N/A для read-only list. |
| Deep links | нет | Параметры URL и ожидаемое начальное состояние; связь с Persistence §3.4. |
| Breadcrumbs / multi-step | нет* | Цепочка экранов, активный шаг wizard. *При multi-screen §3.2. |
3.11. Критерии приёмки / чек-лист QA
Формат AC — 02.04.02 Критерии приёмки (Acceptance Criteria).
| Поле | Обяз. | Что писать |
|---|---|---|
| AC / сценарии | да | Given–When–Then или таблица: happy path + границы + ошибки. |
| Привязка к SRS / US | да | ID требования в каждом сценарии. |
| Привязка к test case / RTM | нет* | ID тест-кейса в 10.01.15 Шаблон матрицы трассировки; одна строка на AC или группу сценариев. *Обязательно для DoR-Merge. |
| Accessibility smoke | нет | Ссылка на NFR; keyboard, focus, aria — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты. |
| Статическая проверка до автотестов | нет | Review спецификации по чеклисту — 08.03 Тестирование требований (статическое тестирование). |
3.12. NFR, ADR, открытые вопросы
| Поле | Обяз. | Что писать |
|---|---|---|
| Ссылки на NFR | нет | Производительность UI, локализация, a11y — 10.01.12 Шаблон нефункциональных требований (NFR). |
| Ссылки на ADR | нет | Спорные решения (optimistic UI, offline-first, polling vs websocket) — 10.01.13 Шаблон архитектурного решения (ADR). |
| Открытые вопросы | нет | Нерешённые пункты; блокеры DoR-Ready помечать явно. |
| История изменений | да | Версия, дата, автор; impact на API mapping при смене контракта. |
3.13. Чеклист качества перед Ready
Используйте полный или read-only/list-only набор — в зависимости от §2.
Обязательно для DoR-Ready (интерактивный экран):
- Уникальный Screen ID и маршрут зафиксированы; wizard steps с
-STEP-XXв RTM. - Таблица controls с binding, Persistence (URL vs memory) и Control ID с префиксом Screen ID.
- Data scope §3.2 — если данные ограничены по роли/tenant; источник истины BE.
- Матрица RBAC — проекция, согласована с 10.01.11 Шаблон ролевой модели.
- Primary actions: enabled/disabled, double-submit, HTTP method.
- UI states: load, empty, validation, business error, API error, submit in progress, session expired (если auth).
- Таблица сообщений §3.9 для toast/inline/banner primary flows.
- API: Contract Ref + mapping; TBD только с владельцем; коды ошибок — ссылка на 10.01.04, не invent.
- i18n: key vs literal по правилу §3.4, если продукт мультиязычный.
- Трассировка к US/UC/SRS; приоритет display rules §3.6 при конфликтах.
- Unsaved changes — для форм редактирования.
- Колонка «источник истины» для FE vs BE; правило расхождения §3.5.
- Multi-screen: цепочка §3.2 + навигация §3.10 — если US > 1 экрана.
- История изменений §3.12 заполнена.
Read-only / list-only (упрощённо):
- Паспорт, зоны, grid/list behavior (sort, page).
- Data scope и RBAC на просмотр.
- Load / empty / error states; без submit и unsaved changes.
- API GET mapping + refetch; без idempotency и validation §3.5 (кроме фильтров).
Перед merge: AC §3.11 с test case ID в RTM; стыковка с 10.04 Чеклист аналитика перед стартом разработки.
4. Пример заполнения
Сокращённый, но структурно полный фрагмент для HR Portal — экран «Список заявок на согласование» (данные условны). Иллюстрирует DoR-Ready; test case ID — для DoR-Merge. Связан с 10.01.01 Шаблон User Story и 10.01.08 Шаблон сквозной фичи (BPMN-процесс).
Паспорт. FE-LEAVE-LIST-02 · Список заявок на согласование · /leave/approvals · HR Portal / Leave Management · v1.1 · Ready · US US-0247 · UC UC-LEAVE-015 · SRS SRS-REQ-044, SRS-REQ-045 · BPMN PROC-LEAVE-01 / T-05 · Figma: figma.com/file/xxx · Scope: desktop + tablet (≥768px); mobile — отдельный маршрут /m/leave/approvals.
Назначение. Руководитель подразделения просматривает заявки сотрудников своего отдела и принимает решение «Согласовать» / «Отклонить».
Data scope. ROLE-MGR-01 — BE фильтрует departmentId из JWT; UI не показывает переключатель отдела. ROLE-HR-ADMIN — все отделы (BE без filter). Источник истины: BE.
Точки входа. Меню «Отпуска → На согласовании»; email-ссылка /leave/approvals?highlight={leaveRequestId}.
Цепочка экранов. List FE-LEAVE-LIST-02 → detail FE-LEAVE-DETAIL-01 (клик по строке); контекст: path param leaveRequestId.
Предусловия. Пользователь авторизован с ролью ROLE-MGR-01; SSO активен (US-0240).
Зоны. Header (заголовок, счётчик) · Filters (статус, период) · Grid (таблица заявок) · Row actions · Modal «Отклонение».
Элементы (фрагмент):
| Control ID | Label | Type | Binding | Persistence | Обяз. |
|---|---|---|---|---|---|
FE-LEAVE-LIST-02-FLD-filter-status | leave.approvals.filter.status | multi-select | query statuses[] → API | URL | нет |
FE-LEAVE-LIST-02-FLD-filter-period | leave.approvals.filter.period | date range | query dateFrom, dateTo | URL | нет |
FE-LEAVE-LIST-02-GRD-requests | — | data grid | GET …/approvals → items[] | API | — |
FE-LEAVE-LIST-02-BTN-approve | leave.approvals.action.approve | button | action → PATCH …/approve | — | — |
FE-LEAVE-LIST-02-FLD-reject-comment | leave.approvals.reject.comment | textarea | body comment | in-memory (modal) | да* |
*Обязательно только при открытом modal «Отклонить».
List behavior. Sort: колонка «Дата» desc default; pagination: page/size query → API; row click → detail.
Клиентская валидация.
| Правило | Момент | Ошибка | Источник | При расхождении |
|---|---|---|---|---|
| Комментарий ≥ 10 символов | on blur, submit | leave.approvals.reject.error.minLength | FE | BE 400 → inline из API body |
| Дата «по» ≥ «с» | on change фильтра | leave.approvals.filter.error.dateRange | FE | — |
RBAC (проекция 10.01.11):
| Control ID | ROLE-MGR-01 | ROLE-HR-ADMIN |
|---|---|---|
FE-LEAVE-LIST-02-GRD-requests | visible | visible |
FE-LEAVE-LIST-02-BTN-approve | enabled* | hidden |
*Baseline enabled по RBAC; disabled display rule при статусе заявки ≠ «На согласовании» (business status, §3.6 п. 2).
Интеграции:
| Действие | API | Request mapping | Idempotency / ошибки |
|---|---|---|---|
| Загрузка списка | API-LEAVE-002 GET | query: statuses, dateFrom, dateTo, page, size | 401 → redirect login; 5xx → banner + Retry |
| Согласовать | API-LEAVE-003 PATCH | path: leaveRequestId; body: {} | double-submit: btn loading; 409 ALREADY_PROCESSED (из 10.01.04) → toast, row refetch |
| Отклонить | API-LEAVE-004 PATCH | body: { comment } | 400 → inline у комментария; 401 на submit → modal unsaved, данные modal теряются |
UI states:
| Состояние | Поведение |
|---|---|
| Loading | Skeleton grid, кнопки disabled |
| Empty | «Нет заявок на согласовании» + ссылка «Все заявки» |
| Populated | Grid с данными; row actions по status + RBAC |
| Validation error | Inline у FE-LEAVE-LIST-02-FLD-filter-period или FE-LEAVE-LIST-02-FLD-reject-comment; submit modal заблокирован |
| Submit in progress | FE-LEAVE-LIST-02-BTN-approve loading, повторный клик ignored |
| Business error 409 | Toast, строка refetch |
| API / network error | Banner «Не удалось загрузить» + Retry |
| Session expired (401) | GET → redirect login; PATCH reject с заполненным modal → confirm, redirect без сохранения комментария |
Сообщения (§3.9):
| Тип | Триггер | Текст |
|---|---|---|
| Toast | Успешное согласование | leave.approvals.toast.approved |
| Toast | 409 ALREADY_PROCESSED | leave.approvals.toast.alreadyProcessed |
| Inline | FE validation комментария | leave.approvals.reject.error.minLength |
| Banner | 5xx при GET | leave.approvals.error.loadFailed |
Навигация. Клик по строке → /leave/approvals/{id} (FE-LEAVE-DETAIL-01). Back восстанавливает filters из URL. Unsaved changes: N/A (list-only; modal reject — локальный submit без навигации).
AC (фрагмент):
| # | Сценарий | SRS/US | Test case |
|---|---|---|---|
| 1 | Given руководитель ROLE-MGR-01, When открывает экран, Then видит только заявки своего отдела (BE scope) в статусах «На согласовании» и «Возвращена на доработку» | SRS-REQ-044 | TC-UI-LEAVE-012 |
| 2 | Given заявка «На согласовании», When двойной клик «Согласовать», Then один PATCH и loading на кнопке | US-0247 AC-3 | TC-UI-LEAVE-018 |
| 3 | Given заявка уже обработана, When «Согласовать», Then toast 409, FE-LEAVE-LIST-02-BTN-approve disabled для строки | SRS-REQ-045 | TC-UI-LEAVE-019 |
История изменений (§3.12).
| Версия | Дата | Автор | Изменение |
|---|---|---|---|
| 1.0 | 2025-11-10 | Иванова А. | Первая версия, Draft |
| 1.1 | 2026-01-15 | Петров С. | Ready: mapping API-LEAVE-003, RBAC согласован с 10.01.11 |
5. Связанные артефакты
На входе (upstream)
| Артефакт | Связь |
|---|---|
| Vision & Scope, BRD, SRS | Бизнес-контекст и REQ-ID — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) |
| 04.02 Пользовательские истории (User Stories) и Job Stories | Формат первичной документации; экран детализирует story/Job Story без дублирования формулировки |
| 10.01.01 Шаблон User Story | Ценность и AC; экран детализирует UI |
| 10.01.02 Шаблон Use Case | Пошаговый сценарий; шаги с UI → Screen ID |
| 10.01.08 Шаблон сквозной фичи (BPMN-процесс) | User Task → touchpoint экрана |
| 10.01.11 Шаблон ролевой модели | Канон ролей; FE — проекция на controls |
| 10.01.14 Шаблон глоссария и словаря данных | Label'ы, статусы, тексты ошибок |
| Figma / прототип | Визуальный слой; FE-шаблон — поведение — 02.02.04 Прототипирование и UI-UX-исследования |
Типичная цепочка: Vision/BRD → SRS (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)) → US/Job Story (04.02 Пользовательские истории (User Stories) и Job Stories / 10.01.01 Шаблон User Story) → Screen spec (этот шаблон).
На выходе (downstream)
| Артефакт | Когда создавать |
|---|---|
| 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API | Новые или изменённые operations; семантика кодов — там, не в FE |
| 10.01.12 Шаблон нефункциональных требований (NFR) | a11y, performance UI, upload limits, i18n — по ссылке из экрана |
| 10.01.13 Шаблон архитектурного решения (ADR) | Optimistic UI, offline, polling vs websocket |
| 10.01.15 Шаблон матрицы трассировки | RTM: SRS → US → Screen → API → test case |
| Test cases / чек-листы QA | Сценарии и test case ID из §3.11; статическая проверка — 08.03 Тестирование требований (статическое тестирование) |
Типичный порядок работы аналитика
- Согласовать US/UC и макет → выделить экран(ы), присвоить Screen ID; multi-screen — цепочка §3.2.
- Заполнить controls, Persistence, data scope; RBAC-проекцию согласовать с 10.01.11 Шаблон ролевой модели.
- Интеграции: mapping к 10.01.04 Шаблон спецификации REST API (или GraphQL/BFF по 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)); пробелы —
TBD-API+ draft spec. - Матрица UI states и сообщений §3.9; при сложных переходах — 03.02.04 Диаграмма состояний (State Machine Diagram).
- Review с FE/QA — 02.02.02 Воркшопы, фасилитация и совместные сессии; трассировка в 10.01.15 Шаблон матрицы трассировки; DoR — 10.04 Чеклист аналитика перед стартом разработки.
Как не дублировать соседние шаблоны
| Артефакт | В FE-шаблоне | Детали — в |
|---|---|---|
| User Story / Use Case | ID + ссылка | 10.01.01 / 10.01.02 |
| REST/SOAP/GraphQL API | Contract Ref + UX по кодам | 10.01.04 / 10.01.05 / 03.05.03 |
| Ролевая модель | Per-screen RBAC projection | 10.01.11 |
| BPMN | Task ID touchpoint | 10.01.08 |
| NFR (a11y, perf, i18n) | ID + экран-specific отклонения | 10.01.12 |
| Визуальный дизайн | Ссылка на Figma | Design System |
6. Связи с другими разделами базы
Только теория, которой нет в §5:
- Спецификация требований и место UI в цепочке Vision → SRS → экран — 02.03.03 Спецификация требований (SRS, Use Case, User Story)
- Концепция трассировки screen → API → test — 02.03.04 Трассировка требований (концепция)
- Верификация и валидация UI-требований на review — 02.04.01 Верификация и валидация (V&V)
- Классификация БТ/ФТ/НФТ для границ FE vs NFR — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
7. Источники и дополнительные материалы
Источники из отчёта исследования; URL перепроверены перед публикацией.
Книги и стандарты
- ISO/IEC/IEEE 29148:2018 — Requirements engineering (структура SRS, трассировка к UI-требованиям; §3.1, §3.11) — https://www.iso.org/standard/72089.html
- IIBA — BABOK Guide (Specify and Model Requirements, AC; §3.11) — https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
Статьи и практики
- Atlassian — Product Requirements template (связь целей и детализации экранов; §1, §5) — https://www.atlassian.com/software/confluence/templates/product-requirements
- Nielsen Norman Group — Forms (валидация, ошибки, подписи; §3.4–3.5, §3.9) — https://www.nngroup.com/topic/forms/
- Material Design 3 — Interaction / States (матрица UI states; §3.8) — https://m3.material.io/foundations/interaction/states/overview
Спецификации и руководства
- W3C — WCAG 2.2 Quick Reference (a11y smoke; §3.11) — https://www.w3.org/WAI/WCAG22/quickref/
- W3C WAI — Standards and guidelines (обзор доступности; §3.11) — https://www.w3.org/WAI/standards-guidelines/
- MDN — Learn Forms (семантика полей для AC; §3.4) — https://developer.mozilla.org/en-US/docs/Learn/Forms
- MDN — Learn Accessibility (интерактивные элементы; §3.11) — https://developer.mozilla.org/en-US/docs/Learn/Accessibility