Работа с требованиями. ТЗ

1.

Управление программными
проектами
Работа с требованиями.
От требований к Техническому Заданию (ТЗ)

2.

Путь от идеи к коду
Было:
Бизнес-требования
Функциональные требования
Нефункциональные требования
Сегодня: МАГИЯ ТРАНСЛЯЦИИ
Как структурировать требования в ТЗ?
Кто и что делает в проекте?
Как писать, чтобы все поняли одинаково?
ТЗ — это единственный источник правды для команды

3.

Активность 1: «Переводчик с бизнеса на технозвук»
Голосовое сообщение от заказчика:
«Нужно, чтобы список могла вести вся семья. Ну, вот муж добавил
колбасу, жена это увидела и купила. И чтобы не было дублей, если
уже купили! И чтобы это было просто, как в вотсапе.»
Ваша задача:
● Составить список уточняющих вопросов
● Сформулировать предположения для ТЗ

4.

Что такое хорошее ТЗ?
ТЗ — это мост между бизнесом и разработкой
Ключевые свойства:
● Полнота (отвечает на 95% вопросов)
● Однозначность (исключает разночтения)
● Проверяемость (можно написать тесты)
● Структурированность (легко найти информацию)
Плохое ТЗ = Бесконечные переделки + Срыв сроков + Недовольный
заказчик

5.

Структура ТЗ: основа документа
1. Введение (Цель и миссия проекта)
2. Глоссарий (Определение терминов)
3. Роли и пользователи (Кто взаимодействует с системой)
4. Функциональные требования (Ядро ТЗ - Use Cases)
5. Нефункциональные требования (Качество системы)
6. Модели и диаграммы (Визуальное представление)

6.

Use Case: сценарий использования
Название: Добавить товар в список
Актор: Пользователь
Предусловия: Пользователь авторизован
Основной поток:
1. Нажимает "Добавить товар"
2. Система показывает поле ввода
3. Вводит название → нажимает "ОК"
4. Система добавляет товар
Альтернативный поток: Выбор из готового списка
Постусловия: Товар отображается в списке

7.

Активность 2: «Пишем первый Use Case»
Задание: Опишите сценарий
«Поделиться списком с другим пользователем»
Шаблон для заполнения:
Название: ...
Актор: ...
Предусловия: ...
Основной поток: ...
Альтернативный поток: ...
Постусловия: ...

8.

Принципы ясного ТЗ
Однозначность:
❌ Плохо: "Быстрая загрузка"
✅ Хорошо: "Загрузка за 2 сек при 3G"
Проверяемость:
❌ Плохо: "Красивый интерфейс"
✅ Хорошо: "Соответствует макету Figma #123"
Атомарность:
Одна функция = один Use Case
Полнота:
Ответы на 95% вопросов команды

9.

Важность глоссария
Проблема без глоссария:
Разработчик: "Реализовал корзину"
Аналитик: "Это же был список!"
Тестировщик: "А я проверял покупки..."
Решение — глоссарий:
Список покупок = Сущность для учета товаров
Корзина = Сущность для оформления заказа
Набор продуктов = Группа связанных товаров
Один термин = одно значение во всем проекте

10.

Активность 3: «Инспекция ТЗ»
Найдите ошибки в требованиях:
1. "Разработать красивый экран авторизации"
2. "Товары должны грузиться быстро"
3. "Пользователь может удалять списки"
Перепишите правильно, используя принципы:
● Однозначность
● Проверяемость
● Полнота

11.

Диаграммы в ТЗ: UML Диаграмма состояний
UML-диаграмма — это визуальная схема, созданная с
помощью нотации Unified Modeling Language (UML), для
описания, проектирования и документирования
программных систем и других процессов.
Что показывает UML диаграмма состояний?
Жизненный цикл одной сущности (объекта) и то, как
она переходит из одного состояния в другое под
действием событий.
Когда используется?
Когда у сущности есть четкие статусы и правила их
смены.

12.

Диаграммы в ТЗ: UML Диаграмма активности
Что это показывает?
Последовательность шагов в бизнеспроцессе, потоки данных и то, кто
выполняет каждое действие (разделение
по "дорожкам").
Когда используется?
Для описания сложных процессов с
участием нескольких ролей или систем.

13.

Диаграммы в ТЗ: ER-диаграмма (Сущность-Связь)
ER-модель (от англ. Entity-Relationship model,
модель «сущность — связь») представляет собой
физическую модель взаимосвязей между объектами.
Она позволяет визуализировать то, как объекты
связаны друг с другом
Что показывает ER-модель?
Структуру данных в системе: какие сущности
(таблицы) есть, какие у них атрибуты (поля) и
как они связаны между собой.
Когда используется?
Почти всегда. Это основа для проектирования
базы данных.

14.

Диаграммы в ТЗ: ER-диаграмма (Сущность-Связь)

15.

Что дает качественное ТЗ?
Для команды:
Четкое понимание задач
Минимум уточняющих вопросов
Эффективная работа
Для проекта:
Соблюдение сроков
Соответствие ожиданиям заказчика
Предсказуемый результат
Время на ТЗ = инвестиция в успех проекта

16.

Ключевые выводы
1. ТЗ — это рабочий инструмент, а не формальность
2. Use Cases — лучший способ описания функциональности
3. Принципы ясности и проверяемости — основа качества
4. Глоссарий и диаграммы предотвращают недопонимание
5. Аналитик — ключевое звено между бизнесом и разработкой
Хорошее ТЗ отвечает не на вопрос "Что делать?", а на вопрос "Как
проверить?"