1.11 Анализ требований

Источники и пути выявления требований

Требование (requirement) - условие, которое включает обязательные для выполнения критерии [ISTQB Glossary]

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

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

Уровни и типы требований

Существует 3 основных уровня требований:

1. Уровень бизнес-требований - цель, ради которой создается продукт (для чего, какая польза, как получим прибыль)ю
2. Уровень пользовательских требований - задачи, которые пользователь может выполнять с помощью продукта.
3. Уровень продуктных требований - то, как все будет реализовано в продукте с точки зрения разработки, учитывая контекст бизнес-требований и пользовательских требований.
   Уровень продуктных требований разделяется на:

• Функциональные требования (что должна делать система)
• Нефункциональные требования (как система должна это делать)

Способы выявления требований

Чаще всего, выявлением требований занимаются бизнес-аналитики, но в небольших компаниях функцию аналитиков могу выполнять QA-инженеры.

Пути выявления требований:

1. Интервью: с заказчиком, с пользователями, с фокус-группой, которые будут работать с продуктом и узнать, что они хотят увидеть в нем.
2. Наблюдение: например, уже существует какой-либо продукт у заказчика и мы наблюдаем за тем, какой продукт сейчас и вносим необходимые улучшения на основании наблюдения за имеющимся пользователем, выявление что его интересует, чтобы хотели улучшить.
3. Самостоятельное описание: самостоятельное описание требований, учитывая фазу интервью и наблюдения.
4. Прототипирование: найти прототип (допустим, сайт конкурентов), перейти на него, посмотреть функционал у прототипа, посмотреть как реализованы те или иные функции и прописать их в требованиях.

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

1. Завершенность (completeness)

Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно».

Примеры:

1. Пароли должны храниться в зашифрованном виде
2. Экспорт осуществляется в форматы PDF, PNG и т.д.

2. Атомарность, единичность (atomicity)

Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.

Примеры:

1. Кнопка “Restart” не должна отображаться при остановленном сервисе, окно “Log” должно вмещать не менее 20-ти записей о последних действиях пользователя
2. Если пользователь подтверждает заказ и редактирует заказ или откладывает заказ, должен выдаваться запрос на оплату

3. Непротиворечивость, последовательность (consistency)

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

Примеры:

1. После успешного входа в систему пользователя, не имеющего права входить в систему...
2. “712.a Кнопка “Close” всегда должна быть красной” и “36452.x Кнопка “Close” всегда должна быть синей” - противоречия в разных требованиях

4. Недвусмысленность (unambiguousness, clearness)

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

Примеры:

1. «Доступ к ФС осуществляется посредством системы прозрачного шифрования» и «ФС предоставляет возможность фиксировать сообщения в их текущем состоянии с хранением истории всех изменений» - что такое ФС?

5. Выполнимость (feasibility)

Требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта.

Примеры:

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

6. Обязательность, нужность (obligatoriness) и актуальность (up-to-date).

Если требование необязательное, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть неактуальные требования

Примеры:

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

7. Прослеживаемость (traceability)

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

Примеры:

1. Требования не пронумерованы, не структурированы, не имеют оглавления, не имеют работающих перекрёстных ссылок.
2. При разработке требований не были использованы инструменты и техники управления требованиями.

8. Модифицируемость (modifiability)

Это свойство характеризует простоту внесения изменений в отдельные требования и в набор требований.

Примеры:

1. Требования неатомарны и непрослеживаемы, а потому их изменение с высокой вероятностью порождает противоречивость.
2. Требования изначально противоречивы. В такой ситуации внесение изменений (не связанных с устранением противоречивости) только усугубляет ситуацию, увеличивая противоречивость и снижая прослеживаемость.

9. Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority)

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

10. Корректность (correctness) и проверяемость (verifiability)

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

Как упростить работу с требованиями

1. Написать тест-кейсы: Если не получается написать тест-кейсы, то нужно подумать, а подходят ли требования под пункт Проверяемость. Если не получается - нужно обратиться к аналитику, чтобы он связался с заказчиком и переформулировал требование.
2. Задать вопросы: Аналитику или заказчику
3. Нарисовать схему: Интеллект-карты (Mind Map) и Use-cases(Use Case — это описание взаимодействия с системой в виде последовательности действий для достижения конкретного результата. По сути, это метамодель, которая иллюстрирует не саму систему, а набор функциональных требований к ней.).
4. Рецензирование.

Способы представления требований

1. Use-cases — представляют собой сценарии взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Человечками на схеме обозначаются акторы (не опечатка), которые используют систему. Прямоугольником обозначается система, а сам вариант использования (функция) овалом. Это так называемая use case диаграмма.

2. User Story (применяется в Scrum) - общее описание функций программы, написанное как бы от имени пользователя. на современных проектах чаще используют именно ее для документирования требований.

3. UI mackup - реалистичная модель нашего приложения, которая помогает показать, как дизайн будет выглядеть на frontend.

В тестировании макеты используются для проверки frontend и именно согласно им мы проверяем наличие определенных элементов, их размер, стиль, поведение.

4. Спецификации.

Алгоритм работы с требованиями со стороны тестировщика

Идеальный процесс

1. Требования создают бизнес-аналитики или владельцы продукта. Обычно они содержат в себе дизайнерские макеты.
2. Требования попадают к тестировщику, которые проверяет их на соответствие свойствам качественных требований. Дополнительно в Scrum есть Backlog Refinement, где требования обсуждаются и уточняются командой на отдельном собрании.
3. В случае обнаружения неточностей, требования отправляются бизнес-аналитику на доработку, например, оставляется комментарий в системе.
4. Пункты 2-3 повторяются до тех пор, пока не будут устранены несоответствия. Параллельно требования могут изучать другие участники команды: разработчики, дизайнеры
5. После того как требования согласованы, они берутся в разработку, а тестировщики создают тестовую документацию для дальнейших проверок. Важно: тест-кейсы и чек-листы создаются до того, как функциональность из требования будет разработана.
6. Вносить изменения в требования после начала разработки не рекомендуется и по-хорошему должно быть запрещено.

Неидеальный процесс

1. Анализ требований не всегда осуществляется до этапа разработки и уточнения могут вноситься уже во время нее
2. Тестовая документация может создаваться уже после разработки функциональности
3. Требования могут вообще не документироваться и быть на проекте в неявном виде