Как написать хорошее ТЗ?28.06.2024 20:30

60f962fa66768fcf574ca60082a8e52d

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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 делюсь мнением о технологиях и полезными инструментами для аналитика. Буду рада познакомиться поближе и обсудить другие темы

© Habrahabr.ru