Как QA-инженеру собрать требования к программному продукту и не сойти с ума: шесть шагов

Шаг 1. Изучаем бизнес-контекст

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

Ключевые темы для изучения:

1. Бизнес-модель — способ генерации дохода, основные затраты, а также тип клиентов заказчика.
2. Понимание отрасли — выявление тенденций, основных игроков отрасли, определение правил, которых необходимо придерживаться.
3. Цели — определение цели заказчика в отношении программного продукта. Хочет ли он автоматизировать определенные процессы, повысить эффективность или обеспечить лучший пользовательский опыт?
4. Уязвимые места — выявление болевых точек (текущие процессы, выполняемые вручную и отнимающие много времени, а также задачи подверженные повышенным рискам и ошибкам).

Читайте по теме: Шаблон восприятия: как донести до клиента, что его ожидания не всегда соответствуют реальности

Шаг 2. Проводим интервью

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

Определение заинтересованных сторон

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

Подготовка вопросов

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

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

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

Проведение интервью

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

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

Альтернативой служат такие онлайн-сервисы транскрибирования как Otter, Gong, Express Scribe, Reduct, Airgram. Таким образом, никакая информация не теряется и к ней можно вернуться позже.

Динамическое транскрибирование разговоров в Teams

Шаг 3. Выявляем требования

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

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

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

Шаг 4. Документируем требования

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

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

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

Применяйте наглядные материалы. Они облегчают понимание и выделяют взаимосвязи между различными требованиями. Диаграммы, блок-схемы и другие наглядные средства полезны для иллюстрации сложных требований. Например, диаграмма вариантов использования (Use Case Diagram) поможет суммировать сведения о пользователях вашей системы и их взаимодействиях с ней.

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

Шаг 5. Проверяем требования

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

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

Шаг 6. Контролируем изменения

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

Здесь важно:

1. Установить процесс контроля, включающий в себя выявление изменений, оценку, утверждение или их отклонение. Этот процесс должен быть согласован со всеми заинтересованными сторонами в начале проекта.
2. Информировать об изменениях всех заинтересованных лиц. Это гарантирует то, что программный продукт продолжает соответствовать потребностям и ожиданиям заказчика.
3. Проводить регулярный анализ изменений для выявления тенденций, оценки влияния на проект и внесения необходимых коррективов в план проекта.
4. Вести историю, содержащую причины изменений, влияние на проект и любые необходимые правки. Такие приложения как ReqView, REQCHECKER, Micro Focus Dimensions RM позволяют фиксировать, управлять и отслеживать историю изменений требований.

Пример отслеживания истории изменений в приложении ReqView

Читайте также:

Рецепт преодоления «синдрома безработного»

Работа удаленно = работа 24/7?

Вывод

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

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

Фото в статье предоставлены автором

Фото на обложке: Unsplash