Требования: что это и какие бывают виды
Всем привет! В телеграм-канале я провела небольшую викторину по требованиям и их видам, и пообещала разобрать в дальнейшем, что такое требования, какие есть виды, как собирать и обрабатывать их. В первой статье про сами требования поговорим и разберем на примерах типы, а во второй — процесс работы с требованиями, сбор и обработку, тоже на примерах разберем.
Давайте здесь еще немного уточним, что я здесь в первую очередь говорю именно о диджитал сфере, и о роли менеджера проектов при взаимодействии с требованиями, если проект можно отнести к продуктовой разработке в ИТ, маркетингу, финансовым инструментам, дизайнерским проектам. Потому что данная сфера ближе к сферам моего опыта, и там в целом есть схожие процессы, даже если используются разные подходы к управлению (гибкие или линейные).
Поэтому когда будем говорить про процесс работы с требованиями, я буду делать отступления и приводить примеры в разных сферах и в разных подходах именно чтобы показать, где зона применения навыка работы с требованиями у менеджера проектов. Стей тюнед, как говорится.
Что такое требования в проекте / продукте?
Если очень сильно упростить, то требования — конкретное описание потребностей заказчика, на основании которого создается продукт / услуга / работа, что могло бы закрыть эту потребность.
Мне больше нравится определение, которое дает Институт инженеров по электротехнике и электронике (IEEE):
Требование — это
- Условие или способность, необходимая пользователю для решения проблемы или достижения цели.
- Условие или способность, которое должно быть выполнено или которым должна обладать система или компонент системы для выполнения контракта, стандарта, спецификации или другого формально установленного документа.
- Документированное представление условия или способности, как в (1) или (2).
Вот это вот «условие или способность» оно очень полное и очень, я бы сказала, комплексное описание. Почему? Потому что если рассматривать виды требований, то они прям так вот и делятся очень легко на условия, в рамках которых мой продукт / работа / услуга (то есть конечный результат проекта) должны реализоваться, и на способности, которыми, опять же, мой конечный результат проекта должен обладать.
Типы требований
Если говорить про академическую дисциплину (бизнес-анализ), то в рамках какого-нибудь университетского курса по бизнес-анализу и работе с требованиями обычно рассмотрены следующие типы требований:
- Бизнес-требования (Business Requirements) — высокоуровневые цели и задачи проекта с точки зрения бизнеса, которые необходимо достичь для успешного завершения проекта.
- Бизнес-правила (Business Rules) — ограничения или условия, которые должны соблюдаться в процессе выполнения бизнес-процессов, чаще именно государственные политики, регламенты (например, требования о контроле персональных данных пользователей).
- Требования пользователей (User Requirements) — функции и возможности, которые конечные пользователи ожидают от продукта / конечного результата проекта.
- Функциональные требования (Functional Requirements) — конкретные функции и задачи, которые должен выполнять продукт.
- Нефункциональные требования (Non-functional Requirements) — характеристики и ограничения, не связанные напрямую с функциями продукта, но важные для его работы, к ним относят требования точности, надежности, безопасности, эффективности, производительности, поддерживаемости, удобства использования.
- Внешние интерфейсы (External Interfaces) — описывают, как продукт будет взаимодействовать с другими системами и пользователями.
- Физические настройки (Physical Setting Requirements) — как продукт должен быть спроектирован, чтобы функционировать в своей физической среде. Например, если фотокамера для подводных съемок, она должна быть водонепроницаемой.
- Ограничения разработки (Development Constraints) — касаются ограничений, связанных с созданием продукта, таких как поддерживаемые устройства или платформы, а также ограничения по объему памяти, пропускной способности или мощности. Также включают в себя ограничения, накладываемые на процесс разработки, такие как временные рамки, бюджет и ресурсы.
Давайте тут разберем немножечко на примере двух разных проектов. Пускай один проект будет про разработку мобильного приложения на Android, например, какой-нибудь это будет у нас интернет-магазин. А второй проект — научная конференция, такой ивент на пару дней с очным участием, онлайн-регистрацией, докладами.
Бизнес-требования
- Мобильное приложение: Приложение должно увеличить лояльность клиентов и повысить продажи на 20% в течение первого года.
- Научная конференция: Конференция должна привлечь не менее 500 участников и обеспечить высокий уровень взаимодействия между учеными и индустриальными партнерами.
Бизнес-правила
- Мобильное приложение: Приложение должно учитывать правила налогообложения (НДС) для разных категорий продуктов.
- Научная конференция: Все представленные доклады должны проходить через процесс двойного слепого рецензирования.
Требования пользователей
- Мобильное приложение: Пользователи должны иметь возможность регистрироваться и входить в систему с использованием своих аккаунтов в социальных сетях.
- Научная конференция: Участники конференции должны иметь возможность подавать заявки и оплачивать регистрационные взносы онлайн.
Функциональные требования
- Мобильное приложение: Приложение должно поддерживать поиск товаров по ключевым словам и фильтрацию по категориям.
- Научная конференция: Система регистрации должна позволять участникам регистрироваться онлайн и получать подтверждение по электронной почте.
Нефункциональные требования
- Мобильное приложение: Приложение должно загружаться не более чем за 10 секунд.
- Научная конференция: Система регистрации должна обрабатывать не менее 100 регистраций в час без снижения производительности.
Внешние интерфейсы
- Мобильное приложение: Приложение должно интегрироваться с сервисом карт / геопозиции для отображения местоположения при выборе доставки покупок.
- Научная конференция: Система регистрации должна интегрироваться с платежной системой для онлайн-оплаты регистрационных взносов.
Физические настройки
- Мобильное приложение: __
- Научная конференция: Все конференц-залы должны быть оборудованы современными проекторами и системами звука.
Ограничения разработки
- Мобильное приложение: Приложение должно поддерживаться на устройствах с Android версии 12.0 и выше.
- Научная конференция: Организация конференции должна быть завершена за четыре месяца с бюджетом не более 500 тыс. руб.
Обратите внимание, пожалуйста, что у нас вылезла в организации конференции ее технологическая составляющая, для которой применимы именно технические требования (здесь я больше про нефункциональные, внешние интерфейсы говорю). Потому что можно и полу-ручном режиме организовать приемку заявок (дать адрес почты и присылать ссылки или реквизиты на оплату участия, а потом получать и собирать квитанции об оплате), но есть интеграция, какое-то требование об онлайн-системе и уже вырисовывается минимальный лендинг с приемом заявок, докладов, и т. д.
Или вот, другой момент, что у приложения физических настроек нет, потому что приложение зависит здесь от устройства и его физических настроек, выстоит телефон на морозе, значит и в приложение можно будет войти.
Разумеется, не все требования между собой равны по значимости, бизнес-требования и бизнес-правила могут влиять на проект, но наиболее важными считаются требования пользователей, функциональные и нефункциональные требования. Внешние интерфейсы, физические настройки и ограничения разработки добавляют контекст для проектирования и реализации проекта. Поэтому в целом все собранные требования должны давать нам полную картину того, а какой результат мы хотим получить по итогу, на каких условиях и с какими способностями / возможностями.
И вот тут как раз появляется процесс работы с требованиями, который мы рассмотрим в следующей статье.
Задавайте вопросы, приводите свои примеры наиболее удачных требований, ловите меня на горячем, что хотите, вот мой канал, велком: