Штож, обойтись без того, чтобы тебя обозвали душнилой (пусть и косвенно, спасибо за это), когда ты рассказываешь теорию про что-нибудь - невозможно.
Именно поэтому на своих обучениях, я очень настаиваю на том, чтобы мои менти делали домашние задания (а у меня их много, больше, чем многим хотелось бы) - потому что без практики чтение теории бесполезно (хотя всё также необходимо, как минимум ее спрашивают на собеседованиях - поэтому уж простите, но буду душнить и дальше).
Как это происходит - мы выбираем какую-нибудь систему, на которую менти хотел бы написать ТЗ и после каждой пройденной темы закрепляем ее на практике. Прошли виды требований - написали требования, прошли UC\US - написали UC\US, прошли REST - описали пару микросервисов и всё это для одной системы, а не на рандомные темы. По итогу получается очень даже неплохой документ для портфолио.
Поэтому буду тут делать тоже самое. Давайте в качестве системы, которую мы будем описывать, возьмем ITSM-систему (ближайшие аналоги: JIRA, NAUMEN service desk). Это такой подвид систем, которые позволяют управлять IT-услугами.
Обычно, они предоставляют возможность заказчику заводить бизнес-инициативы/запросы на улучшения системы/запросы на устранение багов в качестве заявок в системе и отслеживать их жизненный путь. Также они позволяют самой команде разработки заводить задачи для себя, отслеживать их, приоритезировать, управлять и так далее.
Сейчас напишем небольшое ТЗ для такой системы.
Глоссарий
Не пренебрегайте этим разделом, пожалуйста. ТЗ вы пишете не для себя, помните это.
Заявка – сущность системы, которая содержит информацию о запросе пользователя (как заказчика, так и члена команды разработки). Основная бизнес-сущность системы.
SLA (Service Level Agreement) - договор между заказчиком услуги и ее поставщиком, определяющий права и обязанности сторон и согласованный уровень качества предоставления услуги.
В формате service desk системы, как правило, это количество времени, за которое должна быть решена заявка в разрезе приоритетов. Условно, баг с критичным приоритетом должен решиться за 24 часа.
Введение
На данный момент связь с командой разработки осуществляется посредством почты, через которую отправляются запросы на внедрения нового функционала, либо исправления различных дефектов. Нередкий случай - когда такое письмо теряется\игнорируется и задача долго не решается. Отсутствует прозрачность процесса и понимание того, на каком этапе сейчас находится запрос.
Бизнес-требования.
БТ1: Увеличить прозрачность процесса внесения изменений в систему\исправления дефектов.
В каждый момент времени заказчик должен понимать на каком этапе жизненного цикла находится заявка. Должна быть возможность оставлять комментарии\вопросы внутри сущности "Заявка", для оперативной коммуникации с командой разработки.
БТ2: Система должна вести статистику и отчетность по всем заявкам с целью отслеживания количества выполненных вовремя\просроченных\отмененных\отложенных заявок для определения результативности команды разработки. Необходимо для проверки того, выполняет ли она заявки в срок, согласно SLA.
Системные требования.
Тут миллион возможных фичей, мы возьмем для примера парочку из них:
Краеугольный камень такого рода систем - создание заявки;
И поиск заявок по различным фильтрам.
Создание заявки
Требуется реализовать процесс создания заявки следующим образом: по нажатию на кнопку "Создать заявку", открывается диалоговое окно создания заявки, согласно макету:
Я максимально не дизайнер, поэтому если у вас это вызывает кровотечение из глаз - просьба не вызывать археологов и не кидаться тапками.
Пикабу не умеет в таблицы, да?
Таблица 1. Состав элементов формы диалогового окна создания заявки.
По нажатию на кнопку "Создать" требуется проверять были ли заполнены все обязательные поля:
Если нет, то не заполненные обязательные поля подсвечиваются красным и отображается подсказка с стандартным текстом.
Если все обязательные поля были заполнены, то инициируется процесс создания заявки (когда будем проходить интеграцию front-to-back распишем детально этот момент. Так же опишем модель данных объекта task (заявка) и всё остальное необходимое, для разработчиков).
Поиск заявок
Требуется реализовать возможность поиска заявок по различным параметрам фильтрации, таким как (тут я уже фронт и фильтры рисовать не буду):
Приоритет;
Исполнитель;
Описание заявки;
Статус;
Дата создания с\Дата создания по;
Просроченные заявки
Куча других вариантов
Если был выбран фильтр по приоритету, то найти все заявки, у которых priority (приоритет) = выбранному значению.
Если был выбран фильтр по исполнителю, то найти все заявки, у которых assignee (исполнитель) = выбранному значению (представим, что там выпадающий список всех сотрудников).
Если был выбран фильтр по описанию заявки, то требуется выполнить поиск по подстроке и найти все заявки, у которых в полях topic, shortDescription и description найдено введенное значение.
Описание логики фильтрации для кучи других вариантов)
Все фильтры могут работать одновременно через условие ИЛИ. Если в результате поиска не было найдено ни одной заявки, то отобразить сообщение с текстом "По вашему запросу ни одной заявки не найдено".
Итого
Примерно в таком формате за несколько человекодней можно описать вполне себе хорошее ТЗ на различные функции нашей предполагаемой системы.
Само собой, я учел не все моменты, не все ограничения\необходимые требования и вот это всё - поэтому приветствую критиков в комментариях.
Однако, это и не было целью - целью было показать то, как нужно писать ТЗ и требования (чтобы показать тем, кто их не видел - как они вообще выглядят). Ну и для закрепления на практике примером рассказанный ранее материал - чтобы это не было просто очередной "скучной лекцией или рефератом".
P.S. Спасибо @himen.ru, за дельные и конструктивные комментарии.
P.P.S.: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.