Статья:

АНАЛИЗ ТРЕБОВАНИЙ К ПО: МЕТОДЫ И ИНСТРУМЕНТЫ

Конференция: CCXCVIII Студенческая международная научно-практическая конференция «Молодежный научный форум»

Секция: Технические науки

Выходные данные
Емельянова В.С. АНАЛИЗ ТРЕБОВАНИЙ К ПО: МЕТОДЫ И ИНСТРУМЕНТЫ // Молодежный научный форум: электр. сб. ст. по мат. CCXCVIII междунар. студ. науч.-практ. конф. № 19(298). URL: https://nauchforum.ru/archive/MNF_interdisciplinarity/19(298).pdf (дата обращения: 07.06.2025)
Лауреаты определены. Конференция завершена
Эта статья набрала 0 голосов
Мне нравится
Дипломы
лауреатов
Сертификаты
участников
Дипломы
лауреатов
Сертификаты
участников
на печатьскачать .pdfподелиться

АНАЛИЗ ТРЕБОВАНИЙ К ПО: МЕТОДЫ И ИНСТРУМЕНТЫ

Емельянова Валерия Сергеевна
студент, Ульяновский государственный технический университет, РФ, г. Ульяновск

 

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

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

Требования к ПО принято делить на несколько типов [4, с. 14-20]:

  • Функциональные – описывают конкретные возможности системы (например: "Приложение должно предоставлять возможность онлайн-оплаты").
  • Нефункциональные – определяют характеристики работы системы (производительность, безопасность, удобство использования).
  • Бизнес-требования – отражают стратегические цели организации ("Внедрение системы должно сократить время обработки заказов на 30%").

Наиболее распространённые подходы включают [5, с. 51-67]:

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

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

  1. Наблюдение за рабочими процессами в реальных условиях.

Этот метод предполагает изучение действий пользователей в их естественной среде (офис, производство, магазин и т. д.) без вмешательства.

  1. Совместные работы с ключевыми стейкхолдерами.

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

  1. Анализ существующей документации и регламентов.

Изучение внутренних документов компании для понимания текущих процессов, стандартов и ограничений.

Для визуализации часто используют [1, с. 98-112]:

  1. Диаграммы UML (Use Case, Sequence, Activity).
  2. Нотацию BPMN для описания бизнес-процессов.

3) Прототипы интерфейсов в Figma или аналогичных инструментах.

Для управления требованиями используют современные инструменты [3, с. 47]

  • Jira + Confluence – популярное сочетание для хранения и согласования требований.
  • IBM DOORS – профессиональное решение для сложных проектов.
  • Modern Requirements – специализированный инструмент для работы в DevOps-среде.

Для моделирования:

  • Enterprise Architect – мощный инструмент для работы с UML.
  • Lucidchart – облачное решение для создания диаграмм.

Для прототипирования:

  • Figma – лидер среди инструментов дизайна интерфейсов.
  • Axure RP – позволяет создавать интерактивные прототипы.

Требования к программному продукту являются основой любого проекта по разработке программного обеспечения. Они формируют как проектное задание, так и саму разработку проекта. Качество создаваемого программного обеспечения во многом определяется тем, насколько оно будет соответствовать требованиям. Однако требования меняются, и эта изменчивость должна отражаться в развивающейся системе. Какие существуют проблемы управления требованиями при анализе [2, с. 40-45]?

  1. Требования имеют множество источников.

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

  1. Требования не всегда очевидны.

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

Требования не всегда легко выразить словами.

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

  1. Требования всегда уникальны.

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

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

 

Список литературы:
1. Вигерс К., Битти Дж. Разработка требований к программному обеспечению. – 3-е изд. – М. : Русская редакция, 2014. – 576 с.
2. Горелиц Н. К., Кильдишев Д. С., Хорошилов А. В. Управление требованиями к ответственным системам. Обзор решений // Труды ИСП РАН. – 2019. – Т. 31, вып. 1. – С. 25–48.
3. Зубкова С. В., Ястребов Р. А. Управление требованиями в ИТ-проектах: проблемы и способы решения // Информационные технологии. – 2020. – № 5. – С. 45–52.
4. Коберн А. Современные методы описания функциональных требований к системам. – М. : Лори, 2002. – 256 с.
5. Фитцпатрик Р. Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут? – М. : Альпина Паблишер, 2016. – 198 с.