Стратегическая аналитика: отвечаем на вопрос «Что и зачем?»
Сначала нужно сформулировать общее видение продукта и его границы. Это позволит понять, какой результат ожидается и где эти границы пролегают.
- Vision and Scope (Видение и границы проекта): 1-2 страницы, описывающие контекст, цели и ограничения. Документ отвечает на вопрос: «Зачем мы это делаем и как поймем, что получилось?».
- Спецификация требований к ПО (Software Requirements Specification, SRS): Это уже полноценный, структурированный документ (иногда до 300 страниц), который служит единым источником правды для всей команды. Он детализирует функциональные и нефункциональные требования.
Пользовательские сценарии: взгляд глазами пользователя
Чтобы разработчики поняли задачи пользователей, их описывают на простом и понятном языке.
- User Story (Пользовательская история): Короткое описание функции с точки зрения пользователя по формуле: «Я, как (роль), хочу (действие), чтобы (результат)»..
- Use Case (Вариант использования): Более детальный сценарий со списком шагов и альтернативными потоками.
Моделирование процессов: как все работает на практике
Здесь мы переходим к визуализации логики, используя общепринятые нотации и диаграммы.
- BPMN 2.0 (Business Process Model and Notation): Нотация для моделирования бизнес-процессов «как есть» (as-is) и «как должно быть» (to-be).
- UML (Unified Modeling Language): Богатый язык для визуализации архитектуры ПО. Среди множества типов диаграмм особенно выделяются:
- Диаграмма деятельности (Activity Diagram): Показывает алгоритмы и потоки управления внутри системы.
- Диаграмма последовательности (Sequence Diagram): Идеальна для детализации временных сценариев (например, оплата заказа).
- Диаграмма состояний (State Machine Diagram): Описывает жизненный цикл объекта (от «Создан» до «Выполнен»).
- ER-диаграмма (Entity-Relationship Diagram): Служит для проектирования структуры базы данных, показывая сущности и связи между ними.
Техническое проектирование: пишем код требований
И, наконец, самая техническая часть, определяющая реализацию.
- Техническое задание (ТЗ): Часто основано на внутренних шаблонах компании, описывает функциональные и нефункциональные требования.
- Проектирование API: Документация по эндпоинтам REST API с указанием методов, форматов JSON и статусов ответов.
- Макеты интерфейсов (UI/UX): Чертежи будущего экрана в инструментах вроде Figma.
Зачем все это нужно и почему учиться этому стоит именно в ИТМО?
Все эти документы и диаграммы — это не бюрократия, а самые настоящие активы проекта. Они:
- Снижают риски: помогают выявить противоречия и логические ошибки до начала разработки.
- Экономят деньги: каждая ошибка, найденная на стадии требований, в десятки раз дешевле ошибки, найденной в готовом продукте.
- Создают основу для тестирования: тестировщики пишут свои проверки именно на основе этих документов.
- Обеспечивают преемственность: при уходе или временном отсутствии члена команды, новый специалист быстро вникнет в суть проекта.
Для специалиста с техническим опытом это идеальный карьерный апдейт. Ваше понимание “кухни” разработки позволит вам сразу мыслить системно, на порядок эффективнее новичков.
В Центре ДПО Университета ИТМО разработана практическая программа «Системный аналитик» (длительность — 2 месяца, старт — 13 октября, занятия 2 раза в неделю с 19 до 22), на которой вы под руководством Михаила Ильина (более 20 лет практического опыта) научитесь создавать все перечисленные выше артефакты. После обучения вы получите удостоверение о повышении квалификации и сможете начать работу в новой роли.
Узнайте подробности о программе и запишитесь на на программу на сайте → Центр ДПО ИТМО, программа «Системный аналитик»