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

Анализ требований имеет:

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

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

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



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

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

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

1. Нотация моделирования бизнес-процессов (BPMN).
   
2. UML (унифицированный язык моделирования).
   
3. Техника блок-схемы.
   
4. Схема потока данных.
5. Диаграммы ролевой деятельности (RAD).
   
6. Диаграммы Ганта.
   
7. IDEF (интегрированное определение для моделирования функций).
   
8. Цветные сети Петри (CPN).
   
9. Техника рабочего процесса.
   
10. Объектно-ориентированные методы.
    
11. Анализ расхождений.

Что ж, давайте рассмотрим эти примеры подробнее.

1. Нотация моделирования бизнес-процессов (BPMN)
   
   

BPMN (Business Process Modeling & Notation) – это графическое представление вашего бизнес-процесса с использованием простых объектов, которое помогает организации общаться с заказчиком программного обеспечения. Различные объекты, используемые в BPMN, включают:

• Объекты потока
  
• Соединение объектов
  
• Дорожки (Swimlane)
  
• Артефакты
  
  

Модель BPMN проектирования должна содержать подробную информацию о действиях, выполняемых в процессе, например:

• Кто выполняет эти действия?
  
• Какие элементы данных необходимы для этих действий?
  

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

2. UML (унифицированный язык моделирования)

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

• Состояние
• Объект
• Мероприятия
• Диаграмма классов

Существует 14 диаграмм UML, которые помогают в моделировании, такие как:

• диаграмма вариантов использования;
• диаграмма взаимодействия;
• диаграмма классов;
• диаграмма компонентов;
• диаграмма последовательности;
• и т. д.

Модели UML важны в сегменте ИТ, поскольку они становятся удобным средством коммуникации между всеми заинтересованными сторонами. Бизнес-модель на основе UML может быть напрямую экспортирована в инструмент управления требованиями. Диаграмма UML может быть двух типов: поведенческая модель и структурная модель. Поведенческая модель содержит информацию о том, что делает система, структурная модель — информацию о том, из чего состоит система.

3. Техника блок-схемы

Блок-схема – это визуальное представление последовательного потока и логики управления набором связанных шагов и действий. Существуют разные форматы блок-схем: линейные, нисходящие и кросс-функциональные (swimlanes). Блок-схема может использоваться для различных действий, таких как представление потоков данных, взаимодействия с системой и т. д. Преимущество использования блок-схемы заключается в том, что ее легко читать и писать даже для нетехнических членов команды, и она может отображать параллельный процесс по функциям. , критические атрибуты процесса и т. д.

4. Схема потока данных

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

• Процесс
  
• Поток
  
• Магазин
  
• Терминатор
  
  

Диаграмма логического потока данных показывает действия системы, а диаграмма физического потока данных показывает инфраструктуру системы. Диаграмма потока данных может быть разработана на раннем этапе процесса выявления требований, на этапе анализа в рамках SDLC (жизненного цикла разработки системы) для определения объема проекта. Для упрощения анализа диаграмму потока данных можно детализировать до ее подпроцессов, известных как «выровненный DFD».

5. Диаграммы ролевой деятельности (RAD)

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

• Деятельность
  
• Внешние события
  
• Состояния
  

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

Внешние события – это точки, в которых происходят изменения состояния.

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

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


6. Диаграммы Ганта

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

7. IDEF (интегрированное определение для моделирования функций)

IDEF или интегрированное определение для моделирования функций – это общее название, относящееся к классам языков моделирования предприятия. Он используется для моделирования действий, необходимых для поддержки системного анализа, проектирования или интеграции. Для IDEF существует около 16 методов, наиболее полезными версиями IDEF являются IDEF3 и IDEF0.

8. Цветные сети Петри (CPN)

IDEF или интегрированное определение для моделирования функций – это общее название, относящееся к классам языков моделирования предприятия. Он используется для моделирования действий, необходимых для поддержки системного анализа, проектирования или интеграции. Для IDEF существует около 16 методов, наиболее полезными версиями IDEF являются IDEF3 и IDEF0.

Объекты сетей Петри имеют особую надпись, например:

• Места: Имеются надписи типа .Name, .Color Set, .Initial marking и т. д.;
  
• Переход: имеет надписи типа .Name (для идентификации) и .Guard (логическое выражение состоит из некоторых переменных);
  

Дуги: На нем есть надпись типа .Arc. Когда выражение дуги оценивается, оно дает несколько наборов цветов токенов.


9. Техника рабочего процесса

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

• Сбор информации
  
• Моделирование рабочего процесса
  
• Моделирование бизнес-процессов
  
• Внедрение, проверка и выполнение
  

10. Объектно-ориентированные методы

Метод объектно-ориентированного моделирования использует объектно-ориентированную парадигму и язык моделирования для проектирования системы. Это упор на поиск и описание объекта в проблемной области. Обычно объектно-ориентированный метод используется, чтобы:

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

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

У объекта есть состояние, а изменения состояния представлены поведением. Итак, когда объект получает сообщение, состояние изменяется в зависимости от поведения.


11. Объектно-ориентированные методы

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

• как текущее состояние проекта?
  
• где мы хотим быть? и т. д.
  
  

Различные этапы анализа пробелов включают:

• Система обзора
  
• Требования к развитию
  
• Сравнение
  
• Подразумеваемое
  
• Рекомендации
  

Ресурсы:

• https://www.guru99.com/
  
• https://reqtest.com/requirements-blog/requirements...
  
• https://www.mindtools.com/