Памятка Системного Аналитика

Что делать при получении задачи

Когда системный аналитик получает задачу, рекомендуется следовать этому алгоритму:

Определение требований - анализ бизнес-процессов, пользовательских сценариев
Исследование и анализ - изучение документации, интервью с пользователями
Моделирование и проектирование - создание моделей данных, диаграмм
Разработка требований - технические спецификации, документация
Взаимодействие с командой - согласование требований с разработчиками
Контроль и мониторинг - отслеживание реализации проекта

Профессиональный совет: Всегда начинайте с понимания бизнес-целей задачи. Задавайте вопросы "Зачем?" и "Какую проблему решает?" прежде чем переходить к техническим деталям.

Ключевые компетенции системного аналитика

▢ Бизнес-анализ ▢ Системный анализ ▢ Работа с данными ▢ UX/UI ▢ Технические знания ▢ Коммуникация

Приоритизация задач

Матрица приоритезации (Value vs Effort)

Низкая ценность Высокая сложность	Высокая ценность Высокая сложность
Низкая ценность Низкая сложность	Высокая ценность Низкая сложность

✓ Сделать в первую очередь | ✓ Планировать | ✓ Возможно позже | × Избегать

Артефакты в системном анализе

Артефакты - это документы, модели и информация, создаваемые в процессе анализа системы:

Требования (функциональные и нефункциональные)
Диаграммы (BPMN, UML, последовательности)
Пользовательские истории (User Stories)
Сценарии использования (Use Cases)
Прототипы интерфейсов
Глоссарий терминов
Отчеты об анализе

Требования Use Cases User Stories

Виды требований

Функциональные требования

Определяют, что система должна делать:

Основные функции системы (регистрация, авторизация)
Бизнес-процессы и сценарии использования
Требования к обработке данных
Взаимодействие с другими системы

Пример

"Система должна позволять пользователям регистрироваться и входить с использованием учетных записей в социальных сетях"

Нефункциональные требования

Определяют характеристики системы:

Производительность (скорость обработки запросов)
Масштабируемость
Надежность
Безопасность
Удобство использования

Пример

"Система должна обеспечивать скорость обработки запросов не менее 1000 запросов в секунду"

Критерии требований

Релевантность - требование должно быть связано с целью
Четкость - однозначная формулировка
Измеримость - возможность оценки выполнения
Выполнимость - реалистичность реализации
Приоритетность - важность для проекта
Атомарность - неделимость требования
Тестируемость - возможность проверки выполнения

Чеклист для проверки требований:

Все требования измеримы?
Есть критерии приемки?
Учтены все сценарии использования?
Соответствуют бизнес-целям?
Нет противоречий с другими требованиями?

Стейкхолдеры

Стейкхолдеры - это лица или организации, которые имеют интерес в проекте и могут повлиять на его успех или неудачу:

Заказчики - определяют бизнес-требования и финансируют проект
Пользователи - непосредственно работают с системой
Разработчики - реализуют техническое решение
Тестировщики - обеспечивают качество продукта
Руководство - отвечает за стратегические решения
Технические эксперты - предоставляют предметную экспертизу

Как взаимодействовать со стейкхолдерами:

Идентификация - составьте полный список всех заинтересованных сторон
Анализ влияния - оцените уровень влияния каждого стейкхолдера
План коммуникации - определите частоту и формат взаимодействия
Управление ожиданиями - четко формулируйте что возможно, а что нет
Обратная связь - регулярно собирайте и анализируйте мнения

Совет: Используйте матрицу влияния/заинтересованности для приоритизации работы со стейкхолдерами. Регулярно обновляйте карту стейкхолдеров по мере развития проекта.

UX/UI принципы

Основные принципы проектирования пользовательского опыта:

Юзабилити - простота и понятность интерфейса
Интуитивность - понятность без обучения
Обратная связь - реакция системы на действия
Адаптивность - работа на разных устройствах
Минимизация ошибок - предотвращение ошибок пользователя
Эстетика - приятный внешний вид

Отличия UI от UX:

UI (User Interface) - то, как выглядит и ощущается интерфейс (дизайн, цвета, шрифты)

UX (User Experience) - опыт пользователя при использовании интерфейса (удобство, время отклика, ошибки)

Методы сбора информации

Эффективные методы сбора информации для системного аналитика:

Опрос - интервью, анкеты, телефонные опросы
Наблюдение - прямое или косвенное изучение процессов
Эксперимент - тестирование гипотез в контролируемых условиях
Анализ документов - изучение существующей документации
Фокус-группы - обсуждение темы с группой людей
Глубинное интервью - детальное изучение мнений респондентов
Вторичный анализ данных - использование существующих данных

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

Use Cases

Use case (случай использования) - описание сценария взаимодействия пользователя с системой:

Как пишутся Use Cases:

Определение контекста использования
Описание основных сценариев использования
Детализация сценариев использования
Документирование use case

Пример: Заказ такси

Контекст: Пользователь хочет заказать такси

Основной сценарий:

Пользователь вводит начальную и конечную точку маршрута
Система предлагает выбрать тип автомобиля и тариф
Пользователь выбирает тариф и автомобиль
Пользователь подтверждает заказ
Система отображает информацию о заказе

Альтернативный сценарий: Если пользователь не находит подходящий тариф, он может изменить параметры поиска

User stories

User story (история пользователя) - это краткое описание функциональности с точки зрения конечного пользователя:

Формат user story

"Как [роль пользователя], я хочу [функция], чтобы [получить пользу/решить проблему]"

Критерии хорошей user story (INVEST):

Independent - независимая от других историй
Negotiable - подлежит обсуждению и уточнению
Valuable - предоставляет ценность для пользователя
Estimable - может быть оценена по сложности
Small - достаточно мала для реализации за один спринт
Testable - имеет четкие критерии приемки

Примеры:

"Как покупатель, я хочу фильтровать товары по цене, чтобы быстрее находить подходящие варианты"

"Как менеджер, я хочу экспортировать отчет в Excel, чтобы анализировать данные"

BPMN (Business Process Model and Notation)

BPMN - стандартная нотация для моделирования бизнес-процессов:

Основные элементы:

Элемент	Обозначение	Описание
Задача		Единица работы в процессе
Событие		Что-то, что происходит в процессе
Шлюз		Точка принятия решений и ветвления

Преимущества BPMN: Стандартизация нотации, наглядное представление процессов, возможность исполнимых моделей, интеграция с системами управления процессами.

Техники оценки задач

Planning Poker

Оценка сложности задач с помощью карточек

1 2 3 5 8 13

T-Shirt Sizing

Оценка по размерам одежды

XS S M L XL

Факторы для учета:

Сложность

Объем

Неопределенность

Зависимости

API (Application Programming Interface)

API - набор правил и протоколов для взаимодействия между программными компонентами.

Типы API:

Web API - доступ через сеть (обычно HTTP)
Библиотечное API - набор функций/классов внутри приложения
Операционная система API - для взаимодействия с ОС

// Пример REST API запроса
GET /api/books?author=J.K.%20Rowling HTTP/1.1
Host: example.com
Accept: application/json
            

REST (Representational State Transfer)

REST - архитектурный стиль для распределенных систем, основанный на 6 принципах:

Единообразие интерфейса - стандартные методы и форматы
Отсутствие состояния (Stateless) - каждый запрос самодостаточен
Кэширование - явное указание возможности кэширования
Клиент-сервер - разделение ответственности
Многоуровневая система - иерархия компонентов
Код по требованию (опционально) - возможность расширения функциональности

Статус коды REST:

2xx (Успех): 200 OK, 201 Created, 204 No Content
3xx (Перенаправление): 301 Moved, 304 Not Modified
4xx (Ошибка клиента): 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx (Ошибка сервера): 500 Internal Error, 503 Service Unavailable

SOAP (Simple Object Access Protocol)

SOAP - протокол для обмена структурированной информацией в распределенных системах. Основные характеристики:

XML-based - все сообщения в формате XML
Протоколо-независимый - может работать поверх HTTP, SMTP, TCP
Строгая типизация - использует WSDL для описания интерфейсов
Встроенная безопасность - WS-Security стандарт

SOAP vs REST:

Характеристика	SOAP	REST
Формат данных	XML	JSON, XML, текст
Протокол	HTTP, SMTP, TCP	HTTP
Стандарты	WS-*, строгие	Нет официальных
Производительность	Ниже из-за XML	Выше

Когда использовать SOAP: Для высокозащищенных систем (банки, госсектор), при работе с устаревшими системами, когда нужны встроенные транзакции.

GraphQL

GraphQL - язык запросов для API, позволяющий клиентам точно запрашивать только необходимые данные.

Основные концепции:

Схема (Schema) - строго типизированное описание возможных запросов
Запросы (Queries) - получение данных
Мутации (Mutations) - изменение данных
Подписки (Subscriptions) - получение обновлений в реальном времени

Пример запроса:

{
  user(id: "789") {
    name
    email
    posts(limit: 5) {
      title
      createdAt
    }
  }
}
            

Преимущества:

Точная выборка данных (недополучение/переполучение)
Единая конечная точка
Строгая типизация
Автоматическая документация
Гибкие отношения между данными

Микросервисная архитектура

Микросервисы - архитектурный подход, при котором приложение разбивается на небольшие, независимые сервисы.

Преимущества микросервисов:

Гибкая разработка и масштабирование
Лучшая изоляция ошибок
Возможность использования разных технологий
Более простая поддержка и развертывание

Когда переходить на микросервисы:

При увеличении масштаба проекта
Для улучшения масштабируемости
Для повышения гибкости разработки
Для улучшения отказоустойчивости

DDD (Domain Driven Design)

Domain Driven Design - подход к разработке сложных систем через глубокое погружение в предметную область:

Основные концепции DDD:

Домен (Domain) - предметная область системы
Модель (Model) - абстракция ключевых концепций домена
Ограниченный контекст (Bounded Context) - четкие границы моделей
Универсальный язык (Ubiquitous Language) - единая терминология
Агрегаты (Aggregates) - кластеры связанных объектов

Пример DDD в банковской сфере

Домен: Банковские операции
Ограниченные контексты: Платежи, Кредитование, Счета
Агрегаты: БанковскийСчет (включая баланс, историю операций)
События: СчетОткрыт, ПлатежПроведен, ЛимитПревышен

Базы данных

Типы баз данных:

Реляционные (SQL): MySQL, PostgreSQL, Oracle - данные в таблицах со строгой схемой
Документные (NoSQL): MongoDB, Couchbase - хранение JSON-документов
Ключ-значение: Redis, Memcached - быстрый доступ по ключу
Колоночные: Cassandra, HBase - оптимизированы для аналитики
Графовые: Neo4j, Amazon Neptune - хранение связей между объектами

Нормализация баз данных:

Нормальная форма	Требование
1NF	Атомарность значений, отсутствие повторяющихся групп
2NF	Выполнение 1NF + отсутствие частичных зависимостей
3NF	Выполнение 2NF + отсутствие транзитивных зависимостей

Моделирование данных

Конструктор ER-диаграмм

Используйте панель инструментов для создания диаграммы

Примеры моделей:

Генератор SQL

-- SQL-код появится здесь после создания диаграммы

Пример нормализации

1NF: Первая нормальная форма

Атомарность значений, отсутствие повторяющихся групп

2NF: Вторая нормальная форма

Отсутствие частичных зависимостей от составного ключа

3NF: Третья нормальная форма

Отсутствие транзитивных зависимостей

Kanban vs Scrum

Scrum

Фиксированные итерации (спринты 1-4 недели)
Роли: Scrum Master, Product Owner, Команда
Артефакты: Бэклог продукта, Бэклог спринта
Церемонии: Планирование, Дейли, Обзор, Ретроспектива
Изменения в процессе спринта запрещены

Kanban

Непрерывный поток работы
Визуализация (Kanban-доска)
Ограничение WIP (Work In Progress)
Управление потоком (flow management)
Изменения возможны в любой момент

Когда использовать: Scrum - для проектов с относительно стабильными требованиями. Kanban - для поддержки и оперативных задач с частыми изменениями приоритетов.

Таймер для митинга

15:00

CI/CD (Непрерывная интеграция и доставка)

Автоматизация процессов разработки и развертывания:

Continuous Integration

Автоматическая сборка при коммите
Запуск тестов
Статический анализ кода
Раннее обнаружение ошибок

Continuous Delivery

Автоматическое развертывание
Пайплайны поставки
Канареечные релизы
Blue-Green деплойменты

Основы безопасности

OWASP Top 10:

Инъекции (SQL, NoSQL, OS)
Некорректная аутентификация
Раскрытие чувствительных данных
XXE (XML External Entities)
Некорректный контроль доступа

Принципы безопасности:

Принцип минимальных привилегий
Глубинная защита (Defense in Depth)
Не доверяй пользовательскому вводу
Регулярные аудиты безопасности

Чеклист: Безопасность

Чеклист по обеспечению безопасности

Определены ли требования к аутентификации пользователей?
Проверены ли требования к авторизации (роли, доступы)?
Разработаны ли механизмы защиты данных в транзите (TLS/SSL)?
Обеспечена ли защита данных в состоянии покоя (шифрование)?
Проверены ли уязвимости ввода данных (SQL-инъекции, XSS)?

Ключевые метрики для аналитика

Проектные метрики

Velocity - скорость выполнения задач
Lead Time - время от запроса до реализации
Cycle Time - время выполнения задачи
Burndown Rate - скорость закрытия задач

Бизнес-метрики

ROI - возврат инвестиций
User Adoption Rate - уровень принятия пользователями
Feature Usage - использование функционала
CSAT - удовлетворенность пользователей

Типичные ошибки аналитика

                Топ-10 ошибок:
                Недостаточное вовлечение стейкхолдеров
Фокус на решениях вместо проблем
Игнорирование нефункциональных требований
Недостаточная детализация требований
Отсутствие приоритизации
Плохая трассируемость требований
Игнорирование edge cases
Переоценка технических возможностей команды
Недостаточное тестирование требований
Плохая коммуникация изменений

            

Шаблоны документов

Основные артефакты с примерами:

Карьерный путь аналитика

                    Junior Analyst →
                    Сбор требований
Документирование процессов
Поддержка тестирования

                

                    Middle Analyst →
                    Проектирование решений
Управление бэклогом
Координация команды

                

                    Senior Analyst →
                    Архитектурные решения
Стратегия продукта
Менторство

                

Быстрые инструменты

Конвертер величин

Выбор методологии

Проект имеет четкие требования?

Шаблоны писем и сообщений

Swagger/OpenAPI

OpenAPI - стандарт описания REST API, Swagger - набор инструментов для работы с OpenAPI:

Преимущества использования:

Автогенерация документации API
Интерактивная песочница для тестирования
Автогенерация клиентских SDK и серверных заглушек
Валидация запросов и ответов
Упрощение процесса разработки API

Пример описания метода в OpenAPI:

openapi: 3.0.0
info:
  title: User API
  version: 1.0.0
paths:
  /users:
    get:
      summary: Get all users
      responses:
        '200':
          description: List of users
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/User'
            

Интеграция с API

Ответ появится здесь...

                 Примеры публичных API для тестирования:
                JSONPlaceholder: https://jsonplaceholder.typicode.com/posts
ReqRes: https://reqres.in/api/users

            

Чеклист для проведения интервью

Подготовка к интервью:

Определить цели интервью
Выбрать участников
Подготовить вопросы
Запланировать время и место

Во время интервью:

Представиться и объяснить цель
Задать открытые вопросы
Активно слушать
Уточнять непонятные моменты

Проверка знаний

Выберите раздел для тестирования:

Количество вопросов

Карта компетенций системного аналитика

Эта карта компетенций поможет вам оценить свои навыки и определить области для развития. Отмечайте освоенные компетенции для отслеживания прогресса.

0%

Освоено: 0 из 0 компетенций

Бизнес-анализ

Выявление и анализ требований
Анализ бизнес-процессов (BPMN)
Определение KPI и метрик успеха

Системный анализ

Проектирование архитектуры решений
Разработка спецификаций требований
Моделирование данных (ER-диаграммы)

Ваш прогресс сохраняется локально в браузере

Глоссарий терминов

Основные понятия системного анализа

Артефакты (Artifacts): Рабочие продукты, создаваемые в процессе анализа - документы, модели, диаграммы
Стейкхолдеры (Stakeholders): Лица и организации, заинтересованные в проекте и влияющие на требования
Функциональные требования: Что система должна делать - описание функций и возможностей системы

Архитектура и технологии

REST (Representational State Transfer): Архитектурный стиль для API, основанный на стандартных HTTP-методах
SOAP (Simple Object Access Protocol): Протокол обмена структурированными XML-сообщениями для веб-сервисов
GraphQL: Язык запросов для API, позволяющий клиентам запрашивать только необходимые данные

Полезные ресурсы

Блоги и сообщества

Курсы и обучение

Инструменты

База знаний и заметки

Расширенный поиск

Введите поисковый запрос для отображения результатов

Интерактивные чеклисты

Чеклист анализа требований

Прогресс выполнения

0/8 (0%)

0%

Подготовка

Определены все стейкхолдеры проекта

Понятны бизнес-цели и ожидаемые результаты

Сбор требований

Проведены интервью с ключевыми пользователями

Документированы пользовательские истории

Инструменты моделирования данных

Конструктор ER-диаграмм

Используйте панель инструментов для создания диаграммы

Генератор SQL

-- SQL-код появится здесь после создания диаграммы

Пример нормализации

1NF: Первая нормальная форма

Атомарность значений, отсутствие повторяющихся групп

2NF: Вторая нормальная форма

Отсутствие частичных зависимостей от составного ключа

3NF: Третья нормальная форма

Отсутствие транзитивных зависимостей

Генератор документов

SRS Document

Спецификация требований к программному обеспечению

User Stories

Пользовательские истории с критериями приемки

API Specification

Спецификация REST API в OpenAPI формате

Test Cases

Тестовые сценарии и кейсы

Что делать при получении задачи

Приоритизация задач

Артефакты в системном анализе

Виды требований

Функциональные требования

Нефункциональные требования

Критерии требований

Чеклист для проверки требований:

Стейкхолдеры

Как взаимодействовать со стейкхолдерами:

UX/UI принципы

Отличия UI от UX:

Методы сбора информации

Use Cases

Как пишутся Use Cases:

User stories

Критерии хорошей user story (INVEST):

Примеры:

BPMN (Business Process Model and Notation)

Основные элементы:

Техники оценки задач

Planning Poker

T-Shirt Sizing

Факторы для учета:

Сложность

Объем

Неопределенность

Зависимости

API (Application Programming Interface)

Типы API:

Популярные методы REST:

REST (Representational State Transfer)

Статус коды REST:

SOAP (Simple Object Access Protocol)

SOAP vs REST:

GraphQL

Основные концепции:

Пример запроса:

Преимущества:

Микросервисная архитектура

Преимущества микросервисов:

Когда переходить на микросервисы:

DDD (Domain Driven Design)

Основные концепции DDD:

Базы данных

Типы баз данных:

Нормализация баз данных:

Моделирование данных

Конструктор ER-диаграмм

Примеры моделей:

Генератор SQL

Пример нормализации

1NF: Первая нормальная форма

2NF: Вторая нормальная форма

3NF: Третья нормальная форма

Kanban vs Scrum

Scrum

Kanban

Таймер для митинга

CI/CD (Непрерывная интеграция и доставка)

Continuous Integration

Continuous Delivery

Популярные инструменты:

Основы безопасности

OWASP Top 10:

Принципы безопасности:

Чеклист: Безопасность

Чеклист по обеспечению безопасности

Ключевые метрики для аналитика

Проектные метрики

Бизнес-метрики

Типичные ошибки аналитика

Топ-10 ошибок:

Шаблоны документов

Основные артефакты с примерами:

Карьерный путь аналитика

Junior Analyst →

Middle Analyst →

Senior Analyst →

Быстрые инструменты