Мы продолжаем рассказывать про тестирование требований в бизнес-аналитике. В предыдущем материале мы обсудили зачем это нужно делать, как и по каким критериям проводить тестирование. В этой статье мы расскажем о прослеживаемости требований и почему бизнес-аналитикам нужно заранее создавать “черный ящик”.
Почему важно прослеживать требования
Какие еще инструменты можно использовать для проверки собранных требований
Практические советы для тестирования требований
Почему важно прослеживать требования
Требования — это фундамент продукта, но без четкой связи между ними и конечным решением легко потерять логику разработки. Если команда не может отследить, как и зачем появилось то или иное требование, велика вероятность ошибок, дублирования работы и несоответствия ожиданиям. Разберемся, почему прослеживаемость требований — это не просто формальность, а ключевой инструмент управления качеством продукта.
В контексте бизнес-анализа “черный ящик” — это способ управления сложностью требований, когда внутри системы происходят изменения, но входные и выходные данные остаются прозрачными и контролируемыми. Прослеживаемость требований помогает аналитикам не терять связь между исходными бизнес-целями и техническими решениями, а также отслеживать влияние изменений. Это особенно важно при масштабных проектах, где любое изменение может повлиять на десятки взаимосвязанных элементов. Без этого «черного ящика» требования легко превращаются в хаотичный набор пожеланий, а продукт — в непредсказуемый результат.
Полноценная документация в самом начале позволит эффективно управлять требованиями в середине проекта и на завершающих стадиях. Всегда хорошо иметь возможность найти источник и автора каждой “фичи” и информацию о том, почему, когда и как она менялась со временем. Команде в середине, а особенно в конце процесса разработки и во время неизбежных изменений будет (при наличии вовремя записанной истории) понятно, почему некоторый функционал не был добавлен в систему, или, наоборот, расширен и кто принял это решение.
Прослеживаемость требований определяет и документирует происхождение каждого требования, включая его обратную прослеживаемость, его прямую прослеживаемость и его связь с другими требованиями. Важно понимать и то, что прослеживаемость требований нередко входит в личный KPI бизнес-аналитика — так, в числе прочего, оценивается его работа.
С нуля до лида: как выглядит карьера бизнес-аналитика
Что еще обеспечивает прослеживаемость:
- помогает выявить отсутствующую функциональность, либо уже реализованные “фичи”, которые не задокументированы.
- более быстрый и простой анализ воздействия (что произойдет с остальным софтом, если мы изменим одну “фичу”?)
- более надежное обнаружение несоответствий и пробелов в требованиях
- более глубокое понимание области действия и сложности изменения
- надежную оценку того, какие требования были учтены, а какие нет
Какие еще инструменты можно использовать для проверки собранных требований
Анализ на соответствие SMART:
- Требования должны быть специфичными (Specific), измеримыми (Measurable), достижимыми (Achievable), релевантными (Relevant) и ограниченными по времени (Time-bound). Подробнее об этом методе можно почитать здесь.
Прототипирование:
- Многим людям гораздо проще анализировать визуальную информацию, чем тексты. Создайте простые прототипы или wireframes для визуализации требований.
- Используйте их для получения обратной связи от пользователей и заказчиков.
Разбираем Wireframe «по косточкам»: что это такое?
Методология Six Sigma
Изначально Six Sigma разработана для повышения качества продуктов и процессов, однако ее можно применить и при сборе требований. Основной инструмент — цикл DMAIC (Define, Measure, Analyze, Improve, Control), который позволяет оценить требования с точки зрения полноты, согласованности и измеримости.
- Define (Определение) – чёткое формулирование бизнес-проблемы и целей, выявление всех заинтересованных сторон и их ожиданий. На этом этапе аналитик тестирует требования, проверяя, соответствуют ли они бизнес-целям.
- Measure (Измерение) – сбор данных о процессе формирования требований. Используется для оценки их качества: насколько они детализированы, насколько их легко интерпретировать и возможно ли их проверить.
- Analyze (Анализ) – выявление пробелов и противоречий в требованиях. Здесь можно применять диаграммы Исикавы (Fishbone) или анализ 5 почему, чтобы понять корневые причины потенциальных проблем.
- Improve (Улучшение) – исправление выявленных недочетов, уточнение требований и работа с заинтересованными сторонами для устранения возможных несоответствий.
- Control (Контроль) – внедрение стандартов проверки требований, чек-листов и автоматизированных инструментов, чтобы предотвратить повторение ошибок на следующих этапах.
Проверка по CRUDL
Проверьте каждый объект по схеме CRUDL (Create, Read, Update, Delete/Deactivate, List — создать, читать, обновлять, удалять/деактивировать, посмотреть список). CRUDL – это набор самых важных действий, которые обычно выполняют над любым объектом в компьютерных системах. Под объектом может подразумеваться что угодно: например, пользовательская запись в соцсети, задание на сайте для школы, файл на компьютере и т.д.
Подумайте, что может пойти не так, какие негативные сценарии и граничные условия могут возникнуть (то есть разные варианты использования).
Если в системе есть сложные условия в формате “если–то” (if–then), убедитесь, что перечислены все возможные варианты (составьте таблицу решений).
Практические советы для тестирования требований
- Используйте чек-листы. Создайте список вопросов для проверки требований, например: «Отражает ли это требование цель проекта?» или «Понятно ли, как измерить выполнение данного требования?».
- Не бойтесь задавать вопросы. Если что-то кажется неясным, уточняйте у команды или заказчиков.
- Автоматизация. Используйте инструменты для управления требованиями, такие как Jira, Confluence или другие, чтобы отслеживать изменения и согласования.
- Ведение журнала изменений. Документируйте любые правки и их причины.
Итогом работы по тестированию требований, что удивительно, будут требования. Но уже проверенные, которые можно продемонстрировать заинтересованным сторонам, которые соответствуют бизнес-целям и задачам проекта.
“Если требование или проект не могут быть проверены, они либо не приносят пользы организации, либо не попадают в область решения, либо и то, и другое”, — говорится в BABOK.Кроме того, уже после разработки софта, собранные требования станут основой для работы тестировщиков — на этапе пользовательского тестирования. Их будут использовать для создания тестовых сценариев. Для этого еще на этапе сбора требований продуктовая команда должна согласовать с ключевыми стейкхолдерами критерии приемки.
