Привет, меня зовут Юлия Новикова и я системный аналитик. Сегодня обсудим критерии качества требований и как их применять

О чём пойдёт речь:

• зачем соблюдать критерии качества при написании требований;

• как проверить хорошее требование или нет с помощью критериев качества;

• как исправить требование

Для кого эта статья:

• джуны аналитики научатся писать понятные требования;

• мидлы убедятся, что всё делают правильно;

• сеньоры могут поделиться опытом в комментариях, что будет полезно всем грейдам

Озвучила организационную информацию, переходим к сути

Зачем соблюдать критерии качества при написании требований?

Критерии качества — принципы, которые гарантируют, что требования будут понятны всем

Понятные требования помогут создать нужный для заказчика продукт и уменьшить шансы на появление той самой страшной ошибки аналитики при сдаче проекта, когда клиент говорит «А мы хотели по‑другому»

Характеристики качества требований:

1. Атомарность

2. Полнота

3. Краткость

4. Консистентность

5. Выполнимость

6. Приоритизированность

7. Тестируемость

8. Однозначность

9. Понятность

Как проверить требование?

Прогоните его по каждому критерию и поправьте, если нужно

Атомарность

Требование атомарно, если его нельзя декомпозировать без потери завершённости

Полнота

Требование полное, если содержит всю информацию, необходимую для реализации задачи

Краткость

Требование краткое, если не содержит лишнюю информацию

Как сделать требование кратким:

1. Определите основную мысль

2. Задайте вопрос «Можно ли убрать без потери смысла?» к каждому слову в требовании. Если да — убирайте

Консистентность

Требование консистентно, если не противоречит другим требованиям проекта

Внимательно отнеситесь к описанию БД и маппингов. Часто здесь встречаются ошибки

Как написать консистентное требование:

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

2. Поговорите с командой. Обсудите новое требование, вопросы покажут что дописать

3. Проиллюстрируйте требование на примере и уточните похож ли он на ожидаемый результат. Иллюстрацию для примера выбирайте по ситуации, но вот распространённые варианты: макет, сценарий, схема или excel файл

Выполнимость

Оцените ресурсы:

1. Бюджет. Сколько времени денег нужно для реализации и укладывается ли хотелка в бюджет

2. Квалификация команды. Сможет ли команда выполнить требование или нужно нанимать новых людей

3. Технологии. Можно ли реализовать требование чисто технически? Обсудите с командой

Приоритизированность

Выставить приоритет получится, если требование атомарное, полное и непротиворечивое. Этот пункт особенно полезен, когда продукт развивается итерациями

Пример приоритизируемых требований:

• Приложение поддерживает авторизацию через социальные сети (VK, Telegram)

• Приложение поддерживает двухфакторную аутентификацию

Тестируемость

Напишите базовые тест‑кейсы для QA даже если требование «понятно, как проверить». Будет достаточно одного успешного кейса и 2–3 с ошибкой. Это ускорит погружение команды в задачу и создание unit‑тестов со стороны разработки

Однозначность и понятность

Уточните требование с заказчиком и обсудите с командой. Убедитесь, что участники процесса понимают требования одинаково. От заказчика важно получить письменное подтверждение

Вот и всё. Теперь требование хорошее, поздравляю с прохождением этого пути :)

Какими правилами вы руководствуетесь для написания требований? Поделитесь опытом в комментариях

P.S.: в моём телеграм канале Шерлок в IT делюсь мнением о технологиях и полезными инструментами для аналитика. Буду рада познакомиться поближе и обсудить другие темы