Comments 7
Пару вопросов:
Зачем так усложнять, если можно не усложнять?
Детально в use case описывать реализацию на этапе BA - ну такое себе
Спецификация полей (обычно называют спекой FE), фильтров, их доступности и обязательности предпочитаю выносить в отдельный документ и его вставлять уже в нужные сценарии по блокам.
Раз беретесь описывать ошибки, описывайте и валидации если они требуются, но это часть СА
В каждой компании да и даже в каждой команде все пишут по своему, как удобно им. Мне как СА достаточно просто самого бизнес процесса, нужного атрибутивного состава, который хочет бизнес и примерного макета согласованного, ибо БА или дизайнер может не знать (и не должен) всех технических нюансов.
Описание поведения фронта (плейсхолдеры, иконки и прочее) все есть на макете - в вашей документации это читать излишне, тем более, что это дефолтное поведение.
Резюмирую - не плохо, а избыточно, что ведет в перспективе к бОльшим затратам по времени и сложности поддержания в актуальном виде (все это имхо, из собственного опыта)
p.s. сводит скулы от таблиц конфлюенса и изображениях в ячейках
Ну дайте человеку самому поменять какой-нибудь кусочек юая, через который проходит куча кейсов и который сделает невалидным тонну доки, а потом искать все кейсы где указана конкретная реализация. Поймёт почему реализацию в юскейсах не указывают.
Графоманство в ТЗ больше для юридических вопросов. Например, исполнитель что-то не так сделал, тогда конкретно начинают тыкать в такой-то пункт сто страничного ТЗ.
Я тоже сторонник макетов, схем, таблиц. И только в случае необходимости письменных пояснений.
Здравствуйте! Спасибо, что прочитали статью.
Как вы и написали, в каждой компании и команде документы пишут по-своему.
Ниже отвечу, почему я пишу именно так, а не иначе.
____________________
В местах, где я работала, реализация продумывалась сразу на этапе макетов и БА. И задача БА – проверить дизайн, и как можно подробнее написать требования.
Доку обязательно ревьюит команда, а также проводится груминг, где СА и разработка может подсветить технические тонкости.
При написании ТТ, СА копнёт ещё глубже и подсветит, что не сработает. Тогда мы поправим доку и макет. Командная работа. На практике, это происходит не часто из-за качественного ревью.
____________________
Валидации обязательно описываем в альтернативных сценариях. Либо выносим в отдельную доку, если валидации одинаковые для части системы.
____________________
Про описание иконок – на мой взгляд это даёт полноту документу, т.к. мы можем зафиксировать их особую бизнес-логику, если она есть.
Например, что какая-то иконка становится заблокированной в одном из кейсов. Такую логику фиксируют либо в макетах, либо в доке БА.
А было ли у тебя такое, что одно исключение триггерит другое исключение, и в итоге в альтернативных сценариях появляется вложенность? Как думаешь, правильно ли это? Я в своей работе не встречал, но видел у некоторых людей
Когда ТЗ — не боль, а удовольствие: Use Case