Какие знаешь техники текстового документирования требований?

Какие знаешь техники текстового документирования требований

Текстовое документирование требований — процесс описания функциональности и свойств системы. Существует множество техник для разных контекстов.

1. Use Cases

Описание взаимодействия актора и системы.

Use Case: Регистрация пользователя
Актор: Новый пользователь
Предусловие: На странице регистрации

Основной поток:
1. Пользователь вводит имя, email, пароль
2. Система валидирует данные
3. Система создаёт аккаунт
4. Отправляет подтверждение на email
5. Пользователь подтверждает
6. Аккаунт активирован

Альтернативный поток:
2a. Email существует → ошибка → вернуть на шаг 1

2. User Stories

Краткое описание с фокусом на ценность.

Как [роль]
Я хочу [возможность]
Чтобы [выгода]

Пример:
Как покупатель
Я хочу добавлять товары в корзину
Чтобы купить их позже

Критерии принятия:
☐ Товар добавляется в корзину
☐ Показывается подтверждение
☐ Счётчик товаров увеличивается

3. BDD (Behavior-Driven Development)

Описание поведения на Gherkin.

Feature: Поиск товаров

Scenario: Успешный поиск
  Given пользователь на главной
  When вводит "ноутбук" в поиск
  And нажимает "Найти"
  Then показываются результаты с ноутбуками
  And результаты отсортированы

Scenario: Поиск не дал результатов
  Given пользователь на главной
  When вводит "xyz123" в поиск
  Then показывается "Не найдено"

4. Requirement Specification

Формальное подробное описание (для контрактов).

1. ВВЕДЕНИЕ
2. ОПИСАНИЕ СИСТЕМЫ
3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
   FR-001: Аутентификация
   - Описание
   - Входные данные
   - Выходные данные
   - Обработка ошибок
4. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
   - Производительность
   - Безопасность
   - Надёжность
5. ОГРАНИЧЕНИЯ

5. Acceptance Criteria

Измеримые условия завершения.

Дано: Пользователь вошёл
Когда: Кликает "Скачать отчёт"
Тогда: Начинается скачивание
И: Файл содержит все данные
И: Формат — PDF

6. MoSCoW Method

Приоритизация требований.

MUST (Обязательно):
- Аутентификация
- Базовый поиск

SHOULD (Нужно):
- Фильтры
- Сортировка

COULD (Можно):
- Рекомендации
- Сравнение

WON'T (Не будет):
- AR примерка

7. Impact Mapping

Связь целей бизнеса с требованиями.

Цель: Увеличить продажи 30%
├─ Кто: Частые покупатели
│  ├─ Что: Быстрый поиск
│  │  └─ Как: Улучшить индекс БД
├─ Кто: Редкие покупатели  
│  └─ Что: Рекомендации

8. Narrative

Рассказ о пользовательском сценарии.

Мария — менеджер. Каждый день пишет отчёт (45 мин):
1. Собирает данные из разных источников
2. Форматирует в Excel
3. Отправляет

С системой (5 мин):
1. Логинится
2. Кликает "Отчёт"
3. Система собирает автоматически
4. Отправляет

Выгода: 40 мин экономии × 250 дней = 167 часов/год

9. Mind Maps

Визуальная структура требований.

        Система
          |
    ┌─────┼─────┐
 User Auth Dashboard
   |      |     |
 Login Profile Stats
 Logout Edit   Info

10. Personas

Описание типичных пользователей.

Персона: Опытный программист
Возраст: 28-35
Опыт: 7+ лет
Цели:
- Быстро найти документацию
- Примеры кода
Боли:
- Медленный поиск
- Устаревшие примеры

Сравнение техник

Best Practices

1. Комбинируй техники
2. Используй структурированный текст
3. Включай примеры
4. Ясность > красота
5. Актуализируй требования

Значение для System Analyst

System Analyst должен:

• Выбирать подходящую технику
• Писать понятные требования
• Обучать команду
• Управлять требованиями (traceability)
• Обеспечивать качество