# Документирование требований | Грейд | Роль | | --------- | ------- | | 🟢 Junior | BA + SA | > **Хорошо задокументированные требования — это мост между идеей и реальностью**. ## Почему документирование важно? Требования существуют только в голове людей, пока их не запишут. Документирование: * Обеспечивает единый источник истины * Позволяет всем работать в одном направлении * Упрощает передачу знаний * Служит основой для тестирования и трассировки * Дает возможность отследить историю изменений ## Пять основных способов документирования ### 1️⃣ Спецификация требований (SRS) **Определение:** Полный документ со всеми требованиями системы. **Структура SRS:** ``` 1. Введение - Цель документа - Область применения - Определения и сокращения 2. Общее описание - Контекст продукта - Функции продукта - Характеристики пользователей 3. Функциональные требования - Требование 1 (REQ-001) - Требование 2 (REQ-002) - ... 4. Нефункциональные требования - Производительность - Безопасность - Надежность 5. Другие требования - Легальные и регуляторные - Стандарты и протоколы 6. Приложения (диаграммы, примеры, глоссарий) ``` **Пример требования в SRS:** ``` REQ-001: Аутентификация пользователя Тип: Функциональное требование Приоритет: Критичное Версия: 1.2 Автор: Ivan Petrov (аналитик) Дата: 2026-04-01 Описание: Система должна позволить пользователю пройти аутентификацию с помощью email и пароля. Базовый сценарий: 1. Пользователь на странице логина 2. Вводит email (например, user@example.com) 3. Вводит пароль (не видно на экране) 4. Нажимает кнопку "Войти" 5. Система проверяет credentials в БД 6. Если верно: создает сессию, редирект на главную 7. Если неверно: показывает "Email или пароль неверный" Альтернативный сценарий (забыл пароль): 1. Пользователь нажимает "Забыл пароль?" 2. Вводит email 3. Система отправляет письмо со ссылкой для сброса 4. Пользователь переходит по ссылке 5. Вводит новый пароль 6. Система обновляет пароль в БД Нефункциональные требования: - NFR-001: Время отклика < 500 мс - NFR-002: Пароль хранится в виде хеша (bcrypt, cost=12) - NFR-003: HTTPS для всех запросов Критерии приемки: ✓ Успешная аутентификация с правильными credentials ✓ Отказ при неправильном пароле ✓ Email + пароль не передаются по незащищённому каналу ✓ Сессия живет 30 минут (затем нужен новый логин) Связанные требования: - REQ-002: Восстановление пароля - REQ-003: Двухфакторная аутентификация (опциональное) Комментарии: - Разработано на основе интервью с операторами (02.04.2026) - Согласовано с командой безопасности (03.04.2026) ``` **Инструменты:** * Microsoft Word, Google Docs (простой вариант) * Confluence, Notion (коллаборативный вариант) * GitHub Wiki, GitBook (для tech-savvy команд) ### 2️⃣ Диаграммы и визуализация **Когда использовать:** * Процессы сложнее 5 шагов * Много взаимодействий между компонентами * Нужно показать систему нетехническому аудитории **Основные типы диаграмм:** ``` Use Case Diagram (UML): - Актеры (пользователи, внешние системы) - Use cases (функции) - Взаимодействия между ними → Показывает: ЧТО система делает с точки зрения пользователя Sequence Diagram (UML): - Объекты/компоненты системы - Сообщения между ними - Порядок выполнения → Показывает: КАК компоненты взаимодействуют во времени BPMN (Диаграмма процесса): - События (Event) - Задачи (Task) - Шлюзы (Gateway) — условия и ветвления → Показывает: БизнЕС-процесс и принимаемые решения DFD (Диаграмма потоков данных): - Процессы - Потоки данных - Хранилища данных - Внешние сущности → Показывает: Как движутся данные через систему Class Diagram (UML): - Классы, атрибуты, методы - Связи между классами → Показывает: Структуру данных системы ``` **Инструменты:** * draw\.io (бесплатно, простой) * PlantUML (текстовые диаграммы) * Lucidchart (красиво, платно) * Enterprise Architect (мощный, дорого) * Miro (коллаборативный, для фасилитации) ### 3️⃣ Use Cases **Определение:** Детальное описание взаимодействия актера с системой для достижения цели. **Структура Use Case:** ``` USE CASE: Оформление заказа Актор: Клиент (Customer) Предусловия: - Клиент авторизован - Товары добавлены в корзину Постусловия: - Заказ создан в системе - Клиент получил подтверждение по email ОСНОВНОЙ СЦЕНАРИЙ: 1. Клиент переходит в корзину 2. Система показывает список товаров и итоговую сумму 3. Клиент нажимает "Оформить заказ" 4. Система проверяет наличие товаров (шаг 2.1) 5. Клиент выбирает адрес доставки (из сохраненных или новый) 6. Система рассчитывает стоимость доставки 7. Клиент выбирает способ оплаты 8. Система запрашивает обработку платежа (шаг 2.2) 9. Клиент получает подтверждение с номером заказа АЛЬТЕРНАТИВНЫЕ СЦЕНАРИИ: Сценарий 2.1: Товар закончился - Если на шаге 4 товар не в наличии: 2.1.1. Система показывает "Товар недоступен" 2.1.2. Клиент может выбрать аналогичный товар 2.1.3. Вернуться к основному сценарию шаг 4 Сценарий 2.2: Платеж отклонен - Если платеж не прошел: 2.2.1. Система показывает "Платеж отклонен" 2.2.2. Клиент может выбрать другой способ оплаты 2.2.3. Вернуться к основному сценарию шаг 8 ИСКЛЮЧЕНИЯ (Ошибки): - Сетевая ошибка: Показать "Попробуйте позже" - Timeout: Перезагрузить страницу ``` **Когда использовать:** * Сложные процессы с много ветвлениями * Нужно описать не только счастливый путь, но и ошибки * Много актеров или систем взаимодействуют ### 4️⃣ User Stories **Определение:** Краткое описание функции с точки зрения пользователя. **Формат:** ``` TITLE: [Короткое имя] STORY: Как [роль пользователя], я хочу [действие], чтобы [получить выгоду]. ACCEPTANCE CRITERIA: ☐ Критерий 1 ☐ Критерий 2 ☐ Критерий 3 NOTES / COMMENTS: - Дополнительная информация - Ссылки на другие требования - Дизайн в Figma: [ссылка] ESTIMATE: 5 story points PRIORITY: High ``` **Пример:** ``` TITLE: Быстрый чекаут STORY: Как клиент интернет-магазина, я хочу заполнить только ФИО и телефон для заказа, чтобы заказать товар за 2 минуты и не потерять интерес. ACCEPTANCE CRITERIA: ☐ Форма видна на странице товара ☐ Форма содержит 3 поля: Имя, Отчество, Телефон ☐ Все поля обязательны ☐ После заполнения можно нажать "Оформить" ☐ Оператор получит заявку в течение 10 сек NOTES: - Похоже на Wildberries "Быстрый заказ" - Дизайн: https://figma.com/file/quick-checkout - Требование FR-001 из SRS - Может быть интегрирована с Telegram ботом ``` **Инструменты:** * Jira (планирование спринтов) * Azure DevOps (Microsoft) * Trello, Asana (управление проектом) * Обычный текстовый документ (на стартапе) ### 5️⃣ Прототипы и макеты **Низкодетализированные (Wireframes):** ``` ┌─────────────────────────────────────┐ │ HEADER / LOGO │ ├─────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ │ │ │ Product │ │ Product │ ... │ │ │ Image │ │ Image │ │ │ └──────────┘ └──────────┘ │ │ ┌─────────────────────────────────┐ │ │ │ Quick Order Form: │ │ │ │ Name: [______________] │ │ │ │ Patr: [______________] │ │ │ │ Phone: [______________] │ │ │ │ [Order Button] │ │ │ └─────────────────────────────────┘ │ ├─────────────────────────────────────┤ │ FOOTER │ └─────────────────────────────────────┘ ``` **Высокодетализированные (Mock-ups):** * Figma, Adobe XD, Sketch * Интерактивные прототипы (InVision, Framer) * Рабочая версия (разработка) **Преимущества:** * Люди сразу видят, как это будет выглядеть * Меньше недоразумений * Легче обсуждать детали интерфейса ## Выбор способа документирования | Документ | Когда | Для кого | Инструмент | | ------------ | ----------------- | ----------------------- | ------------------ | | SRS | Формальный проект | Вся команда | Confluence, Word | | Use Cases | Сложные процессы | Разработчики, тестеры | Draw\.io, SRS | | User Stories | Agile проект | Разработчики, PM | Jira, Azure DevOps | | Диаграммы | Визуализация | Все | Draw\.io, PlantUML | | Прототипы | Перед разработкой | Дизайнеры, разработчики | Figma, Adobe XD | ## Практический пример: Быстрый заказ **Документирование в проекте:** ``` УРОВЕНЬ 1 - Стратегия (Бизнес): └─ Бизнес-план: "Увеличить конверсию на 15%" └─ Документ: Google Docs (1 страница) УРОВЕНЬ 2 - Планирование (Аналитик): └─ SRS (Спецификация): ├─ Функциональные требования (FR-001, FR-002, ...) ├─ Нефункциональные требования (NFR-001, NFR-002, ...) └─ Документ: Confluence (8-10 страниц) УРОВЕНЬ 3 - Дизайн: └─ Макеты в Figma: ├─ Desktop вариант ├─ Mobile вариант └─ Интерактивный прототип УРОВЕНЬ 4 - Разработка: └─ User Stories в Jira: ├─ Story 1: Форма быстрого заказа (5 pts) ├─ Story 2: Валидация полей (3 pts) ├─ Story 3: Отправка на сервер (5 pts) └─ Story 4: Интеграция с CRM (8 pts) УРОВЕНЬ 5 - Тестирование: └─ Тест-кейсы: ├─ TC-001: Успешное оформление ├─ TC-002: Валидация ФИ └─ TC-003: Ошибки сервера ``` ## Поддержание актуальности **Когда требования меняются:** ``` 1. Нужно изменить требование? → Зафиксировать в Change Request → Обсудить с заинтересованными сторонами → Утвердить PM/стейкхолдеры 2. Обновить документацию: → Изменить SRS (отметить версию) → Обновить диаграммы → Обновить User Stories в Jira → Уведомить команду 3. Трассировка изменений: → История версий (SRS v1.0, v1.1, v1.2) → Комментарии в Jira (почему изменилось) → Письмо для команды (что изменилось) ``` ## 📚 Ресурсы для изучения * BABOK Guide v3.0 — документирование требований * IEEE 29148 (ISO/IEC) — стандарт SRS * "Разработка требований к ПО" — Вигерс, Битти * "Writing Effective Use Cases" — Кокберн * Практика в реальных проектах --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://rema.gitbook.io/it-business-system-analyst/basic_knowledge/requirements/dokumentirovanie-trebovanii.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.