Карьера в IT. Системный аналитик, часть 1.1. Практика

Всем привет.

Штож, обойтись без того, чтобы тебя обозвали душнилой (пусть и косвенно, спасибо за это), когда ты рассказываешь теорию про что-нибудь - невозможно.

Именно поэтому на своих обучениях, я очень настаиваю на том, чтобы мои менти делали домашние задания (а у меня их много, больше, чем многим хотелось бы) - потому что без практики чтение теории бесполезно (хотя всё также необходимо, как минимум ее спрашивают на собеседованиях - поэтому уж простите, но буду душнить и дальше).

Как это происходит - мы выбираем какую-нибудь систему, на которую менти хотел бы написать ТЗ и после каждой пройденной темы закрепляем ее на практике. Прошли виды требований - написали требования, прошли UC\US - написали UC\US, прошли REST - описали пару микросервисов и всё это для одной системы, а не на рандомные темы. По итогу получается очень даже неплохой документ для портфолио.

Поэтому буду тут делать тоже самое. Давайте в качестве системы, которую мы будем описывать, возьмем ITSM-систему (ближайшие аналоги: JIRA, NAUMEN service desk). Это такой подвид систем, которые позволяют управлять IT-услугами.

Обычно, они предоставляют возможность заказчику заводить бизнес-инициативы/запросы на улучшения системы/запросы на устранение багов в качестве заявок в системе и отслеживать их жизненный путь. Также они позволяют самой команде разработки заводить задачи для себя, отслеживать их, приоритезировать, управлять и так далее.

Сейчас напишем небольшое ТЗ для такой системы.

Глоссарий

Не пренебрегайте этим разделом, пожалуйста. ТЗ вы пишете не для себя, помните это.

Заявка – сущность системы, которая содержит информацию о запросе пользователя (как заказчика, так и члена команды разработки). Основная бизнес-сущность системы.

SLA (Service Level Agreement) - договор между заказчиком услуги и ее поставщиком, определяющий права и обязанности сторон и согласованный уровень качества предоставления услуги.

В формате service desk системы, как правило, это количество времени, за которое должна быть решена заявка в разрезе приоритетов. Условно, баг с критичным приоритетом должен решиться за 24 часа.

Введение

На данный момент связь с командой разработки осуществляется посредством почты, через которую отправляются запросы на внедрения нового функционала, либо исправления различных дефектов. Нередкий случай - когда такое письмо теряется\игнорируется и задача долго не решается. Отсутствует прозрачность процесса и понимание того, на каком этапе сейчас находится запрос.

Бизнес-требования.

БТ1: Увеличить прозрачность процесса внесения изменений в систему\исправления дефектов.

В каждый момент времени заказчик должен понимать на каком этапе жизненного цикла находится заявка. Должна быть возможность оставлять комментарии\вопросы внутри сущности "Заявка", для оперативной коммуникации с командой разработки.

БТ2: Система должна вести статистику и отчетность по всем заявкам с целью отслеживания количества выполненных вовремя\просроченных\отмененных\отложенных заявок для определения результативности команды разработки. Необходимо для проверки того, выполняет ли она заявки в срок, согласно SLA.

... Что-то еще.

Системные требования.

Тут миллион возможных фичей, мы возьмем для примера парочку из них:

1. Краеугольный камень такого рода систем - создание заявки;

2. И поиск заявок по различным фильтрам.

Создание заявки

Требуется реализовать процесс создания заявки следующим образом: по нажатию на кнопку "Создать заявку", открывается диалоговое окно создания заявки, согласно макету:

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

Пикабу не умеет в таблицы, да?

Таблица 1. Состав элементов формы диалогового окна создания заявки.

По нажатию на кнопку "Создать" требуется проверять были ли заполнены все обязательные поля:

• Если нет, то не заполненные обязательные поля подсвечиваются красным и отображается подсказка с стандартным текстом.

• Если все обязательные поля были заполнены, то инициируется процесс создания заявки (когда будем проходить интеграцию front-to-back распишем детально этот момент. Так же опишем модель данных объекта task (заявка) и всё остальное необходимое, для разработчиков).

Поиск заявок

Требуется реализовать возможность поиска заявок по различным параметрам фильтрации, таким как (тут я уже фронт и фильтры рисовать не буду):

1. Приоритет;

2. Исполнитель;

3. Описание заявки;

4. Статус;

5. Дата создания с\Дата создания по;

6. Просроченные заявки

7. Куча других вариантов

Если был выбран фильтр по приоритету, то найти все заявки, у которых priority (приоритет) = выбранному значению.

Если был выбран фильтр по исполнителю, то найти все заявки, у которых assignee (исполнитель) = выбранному значению (представим, что там выпадающий список всех сотрудников).

Если был выбран фильтр по описанию заявки, то требуется выполнить поиск по подстроке и найти все заявки, у которых в полях topic, shortDescription и description найдено введенное значение.

Описание логики фильтрации для кучи других вариантов)

Все фильтры могут работать одновременно через условие ИЛИ. Если в результате поиска не было найдено ни одной заявки, то отобразить сообщение с текстом "По вашему запросу ни одной заявки не найдено".

Итого

Примерно в таком формате за несколько человекодней можно описать вполне себе хорошее ТЗ на различные функции нашей предполагаемой системы.

Само собой, я учел не все моменты, не все ограничения\необходимые требования и вот это всё - поэтому приветствую критиков в комментариях.

Однако, это и не было целью - целью было показать то, как нужно писать ТЗ и требования (чтобы показать тем, кто их не видел - как они вообще выглядят). Ну и для закрепления на практике примером рассказанный ранее материал - чтобы это не было просто очередной "скучной лекцией или рефератом".

P.S. Спасибо @himen.ru, за дельные и конструктивные комментарии.

P.P.S.: Уже по традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.