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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Полнота

  3. Краткость

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

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

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

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

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

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

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

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

Атомарность

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

Инструкция

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

  1. Прочитайте требование

  2. Если в тексте нет перечислений, условий или союзов — переходим к проверке на полноту

  3. Если есть — проверьте по чек‑листу ниже

  4. Если пункт применим, декомпозируйте требование и вернитесь на первый шаг

  5. Если пункт неприменим — пропустите его

Чек‑лист:

  1. Разделены функциональные и нефункциональные требования

  2. Каждая функция описана отдельно

  3. Разграничены этапы процесса

  4. Требования четко разделены по направлениям деятельности

Полнота

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

Инструкция

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

  2. Оцените детализацию. Прочитайте ещё раз и дополните требование, если возникают уточняющие вопросы

  3. Исследуйте граничные условия

    К примеру,

    • числовые поля и строки. Пропишите ограничение количества символов

    • файлы. Установите ограничение размера в мб для загрузки

    • количество записей на странице для настройки пагинации

  4. Определите критерии успеха. Убедитесь, что указаны четкие и измеримые критерии приемки
    Было требование «Покупатель быстро заказывает товар». Измерим скорость в шагах. Стало: «Покупатель заказывает товар за 3 клика». Уже лучше

  5. Оцените как новые требования изменят систему и поправьте документацию

  6. Посмотрите на требования под другим углом: продумайте интерфейс и напишите требования для дизайнера, составьте user story, нарисуйте диаграммы UML или BPMN

Краткость

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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