Данный текст является обзорной статьей и преимущественно ориентирован на новичков в IT-индустрии, предназначен для желающих познакомиться с профессией, узнать о ее содержании, основных принципах, практиках и инструментах, используемых в ней.

• Системный аналитик. Краткий гайд по профессии. Часть 1. Основы сетевых взаимодействий.

• Системный аналитик. Краткий гайд по профессии. Часть 2. Сбор, анализ и документирование требований.

Из этой статьи вы узнаете какие бывают требования к создаваемым системам и как их собирать, познакомитесь с основными методами их сбора, а также со способами и инструментами их документирования.

Что такое требования и какие они бывают.

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

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

Выделяют три уровня требований: 

• Бизнес-требования. Обычно это описание целей, задач и желаемых для заказчика результатов.

• Пользовательские требования. Это потребности пользователей и других заинтересованных сторон, которые нужно удовлетворить, чтобы выполнить бизнес-требования.

• Функциональные требования, которые определяют конкретные функции, которые система должна осуществлять. Функциональные требования обычно выражаются в виде списка конкретных задач, которые система должна выполнить.

Также выделяют такой тип требований как нефункциональные.

• Нефункциональные требования описывают то, каким образом система должна работать и могут включать характеристики системы, которые не связаны непосредственно с ее функциональностью: производительность, безопасность, масштабируемость, удобство использования и т.д., зачастую выражаясь в виде ограничений или критериев качества.

На изображении ниже приведен пример оформления требований на разработку.

В зависимости от подходов, принятых в команде, требования на разработку состоят из изложения всех перечисленных видов требований, а также могут включать в себя описание API, различные схемы и диаграммы, ссылки на стандарты, документацию смежных систем и иные артефакты.
Спецификация требований может быть представлена в виде документа (например в формате .doc или .pdf) или оформлена в wiki-системах, например в Confluence. Шаблон оформления зависит от команды и принятых в ней правил.

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

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

Этапы разработки программного обеспечения

1. Анализ и формирование требований. Сбор бизнес-требований и подготовка пользовательских требований.

2. Этап проектирования. Определение архитектуры приложения, подготовка функциональных и нефункциональных требований.

3. Разработка. Написание кода.

4. Тестирование ПО на соответствие требованиям к нему.

5. Приёмка результатов (приемо-сдаточные испытания). Демонстрация результатов бизнес-заказчику, проверка на соответствие пользовательским и бизнес-требованиям.

6. Эксплуатация и сопровождение. Установка ПО, обучение пользователей (при необходимости), поддержка работы ПО командой сопровождения.

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

Более подробно методологии разработки будут рассмотрены в следующих частях статьи.

Как собирать требования?

Процесс сбора требований - итеративный процесс, который может неоднократно повторяться, особенно, если вы работаете в гибких методологиях типа Scrum.

1. Понимание бизнес-целей. Прежде всего, необходимо понять бизнес-цели и задачи, которые должна решать система. Это поможет определить, какие функции и возможности должны быть включены в систему, а также продумать верхнеуровневую реализацию (high-level design - HLD) разрабатываемой системы, выбрать архитектурный стиль и типы интеграционных взаимодействий в случае необходимости.

   Зачастую для этого аналитику необходимо изучить домен, для которого вы разрабатываете решение. Подход, который позволяет значительно ускорить процесс проектирования системы в незнакомой предметной области называется Domain-driven-design (DDD).

   Подход DDD заключается в том, чтобы представить предметную область (домен) в виде набора ограниченных контекстов (bounded context), каждый из которых содержит набор сущностей и связей между ними. Внутри одного контекста все сущности должны иметь одинаковую интерпретацию.

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

   При разработке в целях реализации концепции DDD используются принципы объектно-ориентированного программирования для представления содержимого контекста в виде классов и их атрибутов и методов.

2. Опрос стейкхолдеров (заказчиков). Это включает в себя их интервьюирование и анализ потребностей. На основе полученной информации системный аналитик формулирует требования к системе.
   Требования должны быть как можно более подробными и исключать наличие двусмысленных трактовок.

3. Документирование требований. После формулирования требований системный аналитик документирует их в виде спецификации.
   Спецификация должна содержать все необходимые детали и быть понятной для всех заинтересованных сторон.

4. Обсуждение требований. После составления требования обсуждаются с заинтересованными сторонами, включая разработчиков, тестировщиков и всех членов команды. 
   В случае работы по scrum это, как правило, происходит на одной из командных церемоний по уточнению задач (PBR - product backlog refinement, grooming). 

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

5. Уточнение и корректировка требований: В процессе разработки системы могут возникать новые требования или изменения в уже существующих требованиях. 
   Системный аналитик должен быть готов к уточнению и корректировке требований в соответствии с изменениями, а также с оповещением об этом всех заинтересованных сторон и повторным согласованием с ними.

6. Разработка, тестирование и приемо-сдаточные испытания. В процессе разработки аналитик помогает разработчикам ориентироваться в домене и описанных им требованиях. При выявлении недостаточности требований для реализации функциональности, выявленные гэпы (пробелы) отправляются аналитику на уточнение и корректировку требований.
   После завершения разработки системы, аналитик участвует (опционально) в тестировании системы, чтобы убедиться, что она соответствует всем требованиям и функционал корректно работает.

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

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

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

• Интервью. Самый очевидный и эффективный способ. Помогает быстро понять потребности заказчиков/пользователей и подготовить предварительные требования для дальнейшего обсуждения.
  Интервью проще проводить в формате "один на один", особенно, если наладить доверительные отношения с интервьюируемыми, так как люди легче делятся своими мыслями в таком формате, чем в небольшой группе.

• Анкетирование. Подходит для сбора информации от широкого круга заинтересованных лиц. Результаты анкетирования можно использовать как основу для подготовки требований с использованием других методов сбора требований, например интервью.
  В процессе анкетирования важно правильно построить вопросы в анкете.

• Анализ документов. Хороший способ разобраться в новом домене - изучить документацию к системам, находящимся в нем, а также ознакомиться со стандартами. Важно отметить, что есть риск наткнуться на устаревшую документацию.
  Результаты можно использовать для подготовки к интервью или анкетированию.

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

Документирование требований.

UML-диаграммы.

UML (Unified Modeling Language — унифицированный язык моделирования) это язык графического описания для объектного моделирования в области разработки программного обеспечения. Его также используют для моделирования бизнес-процессов, системного моделирования и отображения организационных структур.

Все UML диаграммы по своей сущности делятся на два вида:

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

2. Диаграммы поведения - иллюстрируют взаимодействие с системой и процесс её работы.

Для составления UML диаграмм наиболее удобно использовать специальный инструмент - PlantUML. По ссылке доступно подробное описание с примерами создания каждой диаграммы.

Ниже речь пойдет только о диаграммах, используемых, на мой взгляд, в 90% случаев при проектировании систем. Основываясь на моем опыте, скажу, что команде разработки было достаточно этих схем (зачастую даже не всех, а только нескольких из них, например ER-diagram, State и Sequence), чтобы наглядно воспринимать планируемую к реализации функциональность.

Описание пользовательских историй (UML Use Cases)

Диаграмма сценариев использования (Use Case) является частью диаграммы прецедентов и представляет детальное описание того, как пользователь взаимодействует с системой, включая различные сценарии, условия и результаты, отталкиваясь от понятия User Story - пользовательской истории.

User Story — краткое описание того, что хочет достичь пользователь, используя систему.
Они обычно начинаются со слов «я, как пользователь, хочу…» или «мне, как заказчику, необходимо…», и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.

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

Каждая функция системы изображается в виде эллипса, внутри которого записывается ее название. Этот эллипс и является Use Case'ом.

Для обозначения связей между элементами используются линии, называемые отношениями.
Выделяют несколько типов отношений:

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

• отношение включения - обозначается пунктирной стрелкой с надписью "include", показывает, что один вариант использования включает другой вариант использования, являющийся его частью.

• отношение расширения - обозначается пунктирной стрелкой с надписью "extends", показывает, что основной вариант взаимодействия может расширен дополнительными функциями.

• отношения обобщения - обозначается стрелкой с закрашенным или прозрачным треугольником на конце, показывает, что конкретный вариант использования наследует поведение от общего варианта.

Также Use Case можно описывать в текстовом виде, как показано на изображении ниже.

В текстовом описании указывается:

• название кейса;

• участники (группы участников);

• предусловие - в каком состоянии должны находиться участники, перед выполнением кейса;

• триггер - то, что запускает выполнение кейса;

• результат успешного выполнения кейса;

• основной сценарий - то, что должно произойти в процессе выполнения кейса;

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

Диаграмма последовательности (UML Sequence-diagram)

Называемая в народе "сиквенс" диаграмма изображает последовательные во времени действия, которые называют сценариями.

Дабы не плодить одинаковый материал здесь будет ссылка на замечательную статью с Хабра, в которой коллега по цеху рассказывает из чего состоит диаграмма последовательности и приводит наглядные примеры.

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

Объекты это взаимодействующие друг с другом сущности разного типа. Например, пользователь, микросервис, база данных и т.д. Каждый объект на схеме должен иметь название.

Линии жизни это вертикальная линия, отображающая исполнение функций объекта.

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

Одним из важных понятий являются группировки сообщений, накладывающие определенные правила взаимодействия. Их существует несколько типов:

• Alt - группировка для демонстрации альтернативных кейсов взаимодействия.

• Opt - группировка для демонстрации опционального (необязательного) кейса взаимодействия.

• Par - группировка для демонстрации параллельно выполняемых кейсов взаимодействия.

• Loop - группировка для демонстрации циклов с условием.

• Group - группировка сообщений по смыслу.

Диаграмма состояний (UML State diagram)

Отображает состояния объекта и связи между ними.

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

Диаграмма классов (UML Class diagram)

Отображает структуру системы, содержащей различные объекты и классы.

Чаще всего используется, чтобы спроектировать систему, реализованную на принципах объектно-ориентированного подхода, при котором вся программа рассматривается как набор взаимодействующих друг с другом объектов (классов) и продемонстрировать иерархию классов внутри программы.

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

Описание структуры данных (ER-diagram)

Схема «сущность-связь» (также ERD или ER-диаграмма) - это разновидность блок-схемы, где показано, как разные «сущности» связаны между собой внутри системы. ER-диаграммы чаще всего применяются для проектирования реляционных баз данных.

Выделяют три уровня ER-моделей: концептуальный, логический, физический.

• Концептуальная ER-модель - это высокоуровневое представление сущностей. Она содержит наименьшее количество деталей и отражает общий объём модели, то есть количество сущностей и связей в ней.

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

• Физическая ER-модель - это описание того, как логическая ER-модель может быть разработана с помощью определённой технологии (СУБД).

Существует две нотации ERD: нотация Питера-Чена и нотация Crow's Foot. Наиболее популярной и используемой из них является последняя, поэтому она и будет рассмотрена далее.

На изображении ниже показан пример логической модели ER-диаграммы в нотации Crow's Foot (она же известна, как "Воронья лапка").

Основные положения нотации:

• Сущности изображаются в виде прямоугольников с названием.
  Сущность в базе данных может рассматриваться как таблица.

• Атрибуты сущности перечисляются в нижней части прямоугольника. Первичный ключ выделяется звездочкой.
  Атрибуты сущностей в базе данных должны рассматриваться как поля таблицы. Для каждого поля нужно определить:
  

  • Имя на английском языке.

  • Тип данных и размерность.

  • Допустимость пустых значений.

  • Значение по умолчанию (если требуется).

  • Правила валидации значений (если требуется).

  • Связи между таблицами отражаются через внешний ключ.

• Связь между сущностями изображается линией.
  У связи в нотации Crow'’s Foot есть две характеристики - модальность и кардинальность.
  

  • Модальность показывает какое минимальное количество связей должно быть у такой сущности (ноль или минимум одна).
    Обязательная связь (минимум одна) обозначается вертикальной чертой.
    Опциональная связь (может быть ноль) обозначается кругом.

  • Кардинальность показывает какое максимальное количество связей может быть между экземплярами разных сущностей (одна или много).
    Если максимальное количество связей — одна, то кардинальность обозначается вертикальной чертой.
    Если связей может быть несколько, то кардинальность обозначается как та самая «воронья лапка».

  • Обозначения характеристик связи располагаются на линии именно в таком порядке: сначала модальность (минимум), потом кардинальность (максимум).

Логическую ER-модель можно перевести в физическую за пять шагов. Для этого нужно:

1. Преобразовать сущности в таблицы.

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

3. Добавить первичные ключи.

4. Добавить внешние ключи.

5. Добавить системные таблицы и поля.

Описание бизнес-процесса (BPMN)

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

Чтобы попрактиковаться в составлении диаграмм есть хороший бесплатный инструмент bpmn.io в открытом доступе.

И снова оставлю ссылку на прекрасную статью с Хабра, в которой рассказано о BPMN-диаграммах с наглядными иллюстрациями.

Если кратко - BPMN диаграмма состоит из следующих основных артефактов:

• Дорожки - необязательные элементы, используемые для объединения объектов в рамках одной функциональности/роли (обычно используют для наглядности отображения взаимодействий между смежными системами/ролями).

• Действия (задачи) используются для отображения выполняемых процессов/подпроцессов.

• Шлюзы - элементы, используемые для введения в процесс развилок, условий или дополнительной логики. Чаще всего используются три типа шлюзов: «исключающее ИЛИ», «И» и «включающее ИЛИ».

• Потоки - стрелки, отображающие последовательность действий.

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

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

Эту и другие статьи по системному анализу и IT-архитектуре, вы сможете найти в моем небольшом уютном Telegram-канале: Записки системного аналитика