Пользовательская история (User Story) — краткая формулировка ценности для роли: единица бэклога и точка согласования «зачем / для кого / что считается готовым». Этот шаблон фиксирует поля, которые вы заполняете в спецификации; он не заменяет теорию нотации — см. 04.02 Пользовательские истории (User Stories) и Job Stories. В иерархии БТ/ФТ story — единица функциональных требований на уровне поставки — 02.03.01 Классификация требований (БТ, ФТ, НФТ).

1. Назначение

Документ описывает одну поставляемую ценность для конкретной роли (или enabler / spike — см. §3.1). Его читает Product Owner, команда разработки, QA и заказчик на refinement и приёмке.

Шаблон закрывает три задачи:

• Согласование ценности — роль, действие и business outcome в одной формулировке (формула Connextra: «Как [роль], я хочу [действие], чтобы [результат]»).
• Контракт приёмки — проверяемые критерии приёмки (Acceptance Criteria, AC), по которым story считается выполненной.
• Точка трассировки — связь с BRD (и SRS, если есть) и ссылками на детализирующие спецификации (API, БД, экраны, интеграции), без подмены их содержимым.

Story — верхний слой декомпозиции в разделе 10.01: детали сценариев, контрактов и процессов уходят в соседние артефакты.

2. Когда использовать

Подходит, если:

• нужна единица бэклога, которую можно оценить, приоритизировать и принять по AC;
• business goal зафиксирован в BRD / Vision, и вы декомпозируете его на поставляемые outcomes;
• команда готова согласовать формулировку и AC до начала разработки (Definition of Ready, DoR).

Не подходит или требует дополнения, если:

• нужен пошаговый сценарий актор–система с альтернативами — 10.01.02 Шаблон Use Case или 04.03 Use Case vs User Story — выбор подхода;
• story описывает весь BPMN-процесс или эпик целиком — декомпозируйте; сквозные фичи — 10.01.08 Шаблон сквозной фичи (BPMN-процесс);
• формулировка сводится к техническому заданию («сделать POST /orders») — детали API в 10.01.04 Шаблон спецификации REST API.

Входные условия: известна роль из 10.01.11 Шаблон ролевой модели (для user-facing story), есть ссылка на business objective в BRD, границы scope согласованы.

Иерархия на проекте: в корпоративной схеме story обычно вложена в Epic / Feature. Enabler, technical story и spike могут жить без epic — укажите тип в §3.1 и привязку к инициативе или ADR.

3. Структура документа

Ниже — пояснение полей (§3.1–3.11). Готовый скелет для копирования — в §3.12. Поля с пометкой обяз. нужны для DoR; остальные — по контексту проекта. RM-инструмент — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence).

3.1. Метаданные

Дополнительно для типа Spike:

3.2. Контекст и business objective

3.3. User Story

3.4. Роли и права

3.5. Критерии приёмки (Acceptance Criteria)

Граница AC и NFR: в AC — бизнес-проверяемые исходы, видимые заказчику или PO (статус заявки, обязательность поля, факт доставки уведомления). Согласованные бизнес-SLA («уведомление в течение N минут» как обязательство процесса) допустимы в AC, если их можно проверить на приёмке. Технические метрики качества сервиса (RPS, p99 latency под нагрузкой, масштабирование, отказоустойчивость) — только в 10.01.12 Шаблон нефункциональных требований (NFR); в story — ссылка на NFR-ID.

Качество AC — 02.04.02 Критерии приёмки (Acceptance Criteria), 02.04.03 Управление качеством требований, 08.03 Тестирование требований (статическое тестирование). При AC > 7–10 пунктов или оценке > 3–5 дней — split; эвристики декомпозиции — 04.02 Пользовательские истории (User Stories) и Job Stories.

3.6. Границы, допущения, ограничения

3.7. Зависимости

3.8. NFR и архитектура

3.9. Трассировка и downstream-артефакты

3.10. Приёмка и согласование

3.11. Чеклист INVEST перед Ready

Перед передачей в спринт проверьте (10.04 Чеклист аналитика перед стартом разработки):

• Independent — story можно поставить без неразрешённых блокеров (blocked by в §3.7). Зависимости requires допустимы, если результат другой story уже есть или параллельная работа согласована.
• Negotiable — AC зафиксированы, детали реализации обсуждаемы.
• Valuable — ценность для роли (или enabler-outcome) явна и связана с BRD goal.
• Estimable — команда может оценить (есть AC, макеты, зависимости).
• Small — укладывается в один спринт / 3–5 дней.
• Testable — каждый AC проверяем без домыслов.

3.12. Блок для копирования

Скопируйте целиком в Confluence, Jira или markdown-репозиторий. Заполните поля; удалите неиспользуемые секции (Spike — только для типа Spike).

# User Story: [Заголовок]
 
## Метаданные
 
| Поле | Значение |
|------|----------|
| **ID** | US- |
| **Тип story** | User / Enabler / Technical / Spike |
| **Продукт / модуль** | |
| **Epic / Feature** | |
| **Приоритет** | |
| **Оценка** | |
| **Статус документа** | Draft |
| **Автор, версия, дата** | |
 
### Spike (заполнить только для типа Spike)
 
| Поле | Значение |
|------|----------|
| **Timebox** | |
| **Research question** | |
| **Expected artifact** | |
 
## Контекст и business objective
 
**Проблема / контекст:**
 
**Business objective:** BRD-GOAL-
 
**Ссылка на инициативу:**
 
## User Story
 
**Формулировка (Connextra):**
Как [роль], я хочу [действие], чтобы [результат].
 
**Альтернативная формулировка (Job Story):**
 
**Краткое описание:**
 
**Implementation notes:**
 
## Роли и права
 
**Персона / роль:**
 
**Права и ограничения:**
 
## Критерии приёмки
 
1.
2.
3.
 
### Gherkin (для ветвлений и ошибок)
 
    Scenario: [название]
      Given [предусловие]
      When [действие]
      Then [результат]
 
## Границы, допущения, ограничения
 
**Out of scope:**
-
 
**Assumptions:**
-
 
**Constraints:**
-
 
## Зависимости
 
**Зависимости от других stories:**
-
 
**Зависимости от систем / интеграций:**
-
 
**Readiness checklist:**
- [ ]
 
## NFR и архитектура
 
**Ссылки на NFR:**
 
**Ссылки на ADR:**
 
## Трассировка
 
**Upstream:** BRD-GOAL- · SRS-REQ- (если есть формальный SRS)
 
**Downstream: impact:**
 
**Test cases / coverage:**
 
**Макеты / прототипы:**
 
**Процесс BPMN:**
 
## Приёмка и согласование
 
**Definition of Done (DoD):**
 
**Stakeholder sign-off:**
- Ready:
- Приёмка (UAT):
 
**Открытые вопросы:**
 
**Риски:**
 
## История изменений
 
| Версия | Дата | Автор | Изменение |
|--------|------|-------|-----------|
| 0.1 | | | Черновик |

4. Пример заполнения

Заполненный экземпляр того же скелета (§3.12). Контекст примера: корпоративный проект с формализованным SRS; в чистом agile достаточно BRD-GOAL-012 + Epic EP-015 без SRS-REQ-xxx.

User Story: Согласовать заявку на отпуск руководителем

Метаданные

Контекст и business objective

Проблема / контекст: Сотрудники подают заявки, но руководители узнают о них только по email; заявки теряются, согласование затягивается.

Business objective: BRD-GOAL-012 — сократить среднее время согласования с 3 до 1 рабочего дня.

Ссылка на инициативу: Epic EP-015 «Цифровизация HR-процессов».

User Story

Формулировка (Connextra): Как руководитель подразделения, я хочу видеть список заявок на отпуск сотрудников моего отдела и принимать решение в портале, чтобы не терять заявки в почте и согласовывать отпуск в срок.

Implementation notes: Список — таблица с сортировкой по дате подачи (по умолчанию — новые сверху).

Роли и права

Персона / роль: Руководитель подразделения (ROLE-MGR-01) — ролевая модель RM-HR-v3.

Права и ограничения: Видит только заявки своего отдела; не может редактировать даты отпуска сотрудника.

Критерии приёмки

1. Руководитель видит только заявки сотрудников своего отдела в статусах «На согласовании» и «Возвращена на доработку».
2. При нажатии «Согласовать» заявка переходит в «Согласована»; сотрудник получает уведомление in-app и по email с текстом «Заявка на отпуск согласована».
3. При «Отклонить» обязателен комментарий (мин. 10 символов); заявка → «Отклонена», сотрудник видит комментарий.
4. Если заявка уже обработана, система показывает «Заявка уже обработана» без изменения статуса.

NFR (отдельно): NFR-NOTIF-003 — доставка уведомлений p99 ≤ 30 с при нагрузке до 500 msg/min.

Gherkin (ветвление для AC-3)

Scenario: Отклонение без комментария
  Given руководитель открыл заявку REQ-8891 в статусе «На согласовании»
  When он нажимает «Отклонить» и оставляет комментарий пустым
  Then кнопка «Подтвердить отклонение» неактивна
  And отображается подсказка «Укажите причину отклонения»

Границы, допущения, ограничения

Out of scope:

• Делегирование заместителю — отдельная story US-0251
• Интеграция с 1С:ЗУП — 10.01.04 Шаблон спецификации REST API / отдельный epic
• Мобильная версия

Assumptions: Справочник отделов и привязка сотрудник→отдел загружены в HR Portal.

Constraints: Релиз v2.1 до 2026-04-30.

Зависимости

Зависимости от других stories: blocked by US-0240 (SSO)

Зависимости от систем / интеграций: requires контракт API-LEAVE-003 (должен быть Approved до старта)

Readiness checklist:

• Макет FE-LEAVE-LIST-02
• OpenAPI API-LEAVE-003 v0.9

NFR и архитектура

Ссылки на NFR: NFR-NOTIF-003

Ссылки на ADR: —

Трассировка

Upstream: BRD-GOAL-012 → SRS-REQ-044, SRS-REQ-045

Downstream: impact: REST API-LEAVE-003, FE FE-LEAVE-LIST-02, BPMN PROC-LEAVE-01 / task «Согласование руководителем`

Test cases / coverage: TC-LEAVE-112 … TC-LEAVE-115

Макеты / прототипы: FE-LEAVE-LIST-02

Процесс BPMN: PROC-LEAVE-01, lane «Руководитель»

Приёмка и согласование

Definition of Done (DoD): Код в main, unit-тесты, регресс по модулю Leave, demo PO.

Stakeholder sign-off:

• Ready: PO Смирнов, 2026-03-10
• Приёмка (UAT): HR-директор Кузнецова (план), 2026-03-25

Открытые вопросы: —

Риски: Задержка SSO (US-0240) сдвигает спринт.

История изменений

5. Связанные артефакты

На входе (upstream)

На выходе (downstream)

Типичный порядок работы аналитика

1. Выделить outcome из BRD → сформулировать story по INVEST.
2. Согласовать AC с PO/заказчиком.
3. Детализировать SRS и спецификации интерфейсов там, где нужна implementability.
4. Проверить DoR перед передачей в разработку.
5. На приёмке — верификация по AC, DoD и связанным NFR.

6. Связи с другими разделами базы

Куда идти за теорией и углублёнными практиками — без дублирования полей шаблона:

• Нотация, Job Stories, split и INVEST — 04.02 Пользовательские истории (User Stories) и Job Stories
• Story vs Use Case — 04.03 Use Case vs User Story — выбор подхода
• Место story в цепочке Vision → BRD → SRS → спецификации — 02.03.03 Спецификация требований (SRS, Use Case, User Story)
• Отмена scope или смена требований после Done — 02.05.02 Управление изменениями (Change Control Board)
• Регуляторика и security constraints в Constraints — 08.06 Юридические и регуляторные требования РФ (PCI-DSS), 08.07 Основы кибербезопасности для системного аналитика
• Кто и как валидирует на UAT vs demo — 02.04.01 Верификация и валидация (V&V)
• Зависимости и приоритеты между stories — 02.05.01 Управление зависимостями между требованиями, 02.05.02 Управление приоритетами в условиях изменчивости

7. Источники и дополнительные материалы

Статьи и практики

• Atlassian — User stories (Agile) — https://www.atlassian.com/agile/project-management/user-stories
• Scrum.org — What is a User Story? — https://www.scrum.org/resources/conversation-starter/what-is-a-user-story
• Agile Alliance — User Stories (glossary) — https://www.agilealliance.org/glossary/user-stories/
• Martin Fowler — User Story (bliki) — https://martinfowler.com/bliki/UserStory.html
• Mountain Goat Software — User Stories (Mike Cohn) — https://www.mountaingoatsoftware.com/agile/user-stories
• Roman Pichler — 10 Tips for Writing Good User Stories — https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/

Спецификации и форматы AC

• Cucumber — Gherkin reference (Given/When/Then) — https://cucumber.io/docs/gherkin/reference/

Стандарты и своды знаний

• IEEE 29148-2018 — Systems and software engineering — Life cycle processes — Requirements engineering — https://standards.ieee.org/standard/29148-2018.html
• IIBA — Business Analysis Body of Knowledge (BABOK) — https://www.iiba.org/standards-and-resources/babok/