Разумные требования: что общего у бизнес-аналитиков и тестировщиков

28 января 2025

4 мин.

Требования можно назвать “кирпичиками” будущего продукта, который вы создаете. Как и кирпичи на стройке они сопровождают нас на протяжении всего жизненного цикла разработки — от идеи до финальной реализации. Из плохих кирпичей не получится хороший дом.

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

Что такое жизненный цикл продукта

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

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

Зачем тестировать требования?

Как подготовиться для тестирования требований

Какие критерии для отбора требований существуют

Примеры качественных требований

Зачем тестировать требования?

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

Убедиться, что требования корректно отражают потребности бизнеса
Проверить, что требования понятны и реализуемы
Выявить недочёты или противоречия
Убедиться, что требования согласованы между всеми заинтересованными сторонами

Существует множество критериев для отбора требований. Так BABOK — главный свод знаний бизнес-аналитики — предусматривает, что качество собранных требований в конечном итоге определяют стейкхолдеры (заинтересованные стороны) в число которых входят сам бизнес-аналитик, руководители компаний, заказчики, разработчики, клиенты и другие лица.

“Наиболее важной характеристикой требований … является пригодность для использования. Они должны отвечать потребностям заинтересованных сторон, которые будут использовать их для определенной цели. Качество (требований — Прим. Автора) в конечном итоге определяется заинтересованными сторонами”, — говорится в документе.

Как подготовиться для тестирования требований

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

Назовите ваши требования: как превратить идеи в работающий IT-продукт

Какие критерии для отбора требований существуют

BABOK не ограничивает качество требований конечным списком. Но определенные примеры и критерии качества для требований в нем имеются:

Атомарность (Atomic): Самодостаточное и способное быть понятым независимо от других требований или дизайнов.
Полнота (Complete): Достаточное для дальнейшей работы и представленное с таким уровнем детализации, который позволяет продолжать работу. Требуемый уровень полноты зависит от точки зрения, методологии и этапа жизненного цикла, на котором рассматривается или представляется требование.
Согласованность (Consistent): Соответствует выявленным потребностям заинтересованных сторон и не противоречит другим требованиям.
Краткость (Concise): Не содержит избыточного или ненужного контента.
Осуществимость (Feasible): Разумное и выполнимое в рамках согласованных рисков, сроков и бюджета либо достаточно реализуемое для дальнейшего исследования через эксперименты или прототипы.
Однозначность (Unambiguous): Требование должно быть сформулировано так, чтобы было ясно, удовлетворяет ли решение соответствующей потребности или нет.
Тестируемость (Testable): Возможность проверки выполнения требования или дизайна. Как раз здесь гораздо лучше привлекать профессиональных тестировщиков, которые изучат функционал и смогут заранее сказать, смогут ли протестировать “фичу” после разработки. Сразу же можно разработать тестовые сценарии. Если у требования нет тест-кейса или вы не можете сразу придумать тест для него, то это “плохое” требование, считает QA-инженер Мария Голубева. Например, вы можете проверить user story (пользовательскую историю):
- В user story присутствуют критерии приёмки (acceptance criteria).
- Критерии приёмки точны и недвусмысленны.
- QA-инженер может написать чек-лист или тест-кейсы для этой user story.
Приоритизация (Prioritized): Оценено по важности и ценности относительно других требований, может быть ранжировано, сгруппировано или согласовано.
Понятность (Understandable): Представлено с использованием общепринятой терминологии целевой аудитории.
Прослеживаемость (Traceability): Возможность отслеживать взаимосвязи между наборами требований и проектов от первоначальной потребности заинтересованных сторон до фактически реализованного решения.

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

Примеры качественных требований

Чаще всего требования для продукта оформляются в виде коротких User story — пользовательских историй. Рассмотрим User story, которые отвечают требованиям качества из BABOK.