Как написать хорошее ТЗ?
Привет, меня зовут Юлия Новикова и я системный аналитик. Сегодня обсудим критерии качества требований и как их применять
О чём пойдёт речь:
- зачем соблюдать критерии качества при написании требований;
- как проверить хорошее требование или нет с помощью критериев качества;
- как исправить требование
Для кого эта статья:
- джуны аналитики научатся писать понятные требования;
- мидлы убедятся, что всё делают правильно;
- сеньоры могут поделиться опытом в комментариях, что будет полезно всем грейдам
Озвучила организационную информацию, переходим к сути
Зачем соблюдать критерии качества при написании требований?
Критерии качества — принципы, которые гарантируют, что требования будут понятны всем
Понятные требования помогут создать нужный для заказчика продукт и уменьшить шансы на появление той самой страшной ошибки аналитики при сдаче проекта, когда клиент говорит «А мы хотели по‑другому»
Характеристики качества требований:
- Атомарность
- Полнота
- Краткость
- Консистентность
- Выполнимость
- Приоритизированность
- Тестируемость
- Однозначность
- Понятность
Как проверить требование?
Прогоните его по каждому критерию и поправьте, если нужно
Атомарность
Требование атомарно, если его нельзя декомпозировать без потери завершённости
Как проверить требование на атомарность:
- Прочитайте требование
- Если в тексте нет перечислений, условий или союзов — переходим к проверке на полноту
- Если есть — проверьте по чек‑листу ниже
- Если пункт применим, декомпозируйте требование и вернитесь на первый шаг
- Если пункт неприменим — пропустите его
Чек‑лист:
- Разделены функциональные и нефункциональные требования
- Каждая функция описана отдельно
- Разграничены этапы процесса
- Требования четко разделены по направлениям деятельности
Полнота
Требование полное, если содержит всю информацию, необходимую для реализации задачи
Инструкция
- Проверьте описание. Убедитесь, что учли все возможные сценарии
Например, если описали создание пользователя, не забудьте о редактировании и удалении - Оцените детализацию. Прочитайте ещё раз и дополните требование, если возникают уточняющие вопросы
- Исследуйте граничные условия
К примеру, числовые поля и строки. Пропишите ограничение количества символов. Установите ограничение размера в мб для загрузки файла, количество записей на странице для настройки пагинации - Определите критерии успеха. Убедитесь, что указаны четкие и измеримые критерии приемки
Было требование «Покупатель быстро заказывает товар». Измерим скорость в шагах. Стало: «Покупатель заказывает товар за 3 клика». Уже лучше - Оцените как новые требования изменят систему и поправьте документацию
- Посмотрите на требования под другим углом: продумайте интерфейс и напишите требования для дизайнера, составьте user story, нарисуйте диаграммы UML или BPMN
Краткость
Требование краткое, если не содержит лишнюю информацию
Как сделать требование кратким:
- Определите основную мысль
- Задайте вопрос «Можно ли убрать без потери смысла?» к каждому слову в требовании. Если да — убирайте
Консистентность
Требование консистентно, если не противоречит другим требованиям проекта
Внимательно отнеситесь к описанию БД и маппингов. Часто здесь встречаются ошибки
Как написать консистентное требование:
- Сравните с другими требованиями. Посмотрите, не противоречит ли оно тому, что уже есть на проекте. Возможно, стоит поправить связанные статьи
- Поговорите с командой. Обсудите новое требование, вопросы покажут что дописать
- Проиллюстрируйте требование на примере и уточните похож ли он на ожидаемый результат. Иллюстрацию для примера выбирайте по ситуации, но вот распространённые варианты: макет, сценарий, схема или excel файл
Выполнимость
Оцените ресурсы:
- Бюджет. Сколько времени денег нужно для реализации и укладывается ли хотелка в бюджет
- Квалификация команды. Сможет ли команда выполнить требование или нужно нанимать новых людей
- Технологии. Можно ли реализовать требование чисто технически? Обсудите с командой
Приоритизированность
Выставить приоритет получится, если требование атомарное, полное и непротиворечивое. Этот пункт особенно полезен, когда продукт развивается итерациями
Пример приоритизируемых требований:
- Приложение поддерживает авторизацию через социальные сети (VK, Telegram)
- Приложение поддерживает двухфакторную аутентификацию
Тестируемость
Напишите базовые тест‑кейсы для QA даже если требование «понятно, как проверить». Будет достаточно одного успешного кейса и 2–3 с ошибкой. Это ускорит погружение команды в задачу и создание unit‑тестов со стороны разработки
Однозначность и понятность
Уточните требование с заказчиком и обсудите с командой. Убедитесь, что участники процесса понимают требования одинаково. От заказчика важно получить письменное подтверждение
Вот и всё. Теперь требование хорошее, поздравляю с прохождением этого пути :)
Какими правилами вы руководствуетесь для написания требований? Поделитесь опытом в комментариях
P.S.: в моём телеграм канале Шерлок в IT делюсь мнением о технологиях и полезными инструментами для аналитика. Буду рада познакомиться поближе и обсудить другие темы
Все написано правильно - проблема только в том, чтобы на всех этапах производственной цепочки все всё соблюдали, а вот с этим во многих конторах плохо.
Зы некоторые даже примитивный канбан считают избыточным )
Всё классно, только так никто не делает.