Фундаментальное описание требований к ПО и подходов к их выявлению и сбору от тестировщика Noveo Вадима: пост освещает все аспекты этой области знаний, структурирует информацию и не оставляет ни малейшего шанса недопониманиям и «темным» местам. Приятного прочтения!
Вадим, Noveo Test Engineer
Мы с вами как тестировщики каждый день работаем с требованиями. Суть нашей работы — выяснять, соответствует ли разрабатываемая система требованиям заказчика, рынка и отраслевым стандартам. Более того, в наши обязанности входит проверка требований на соответствие критериям качества. В идеальном мире мы с вами были бы просто гарантом качества — судьями, дающими объективную оценку. Но, к сожалению, мир не идеален, и строгое распределение участников проекта на роли чаще всего не представляется возможным. В эпоху повсеместного использования гибких методологий разработки мы с вами должны обладать знаниями, позволяющими выполнять задачи не только контроля качества.
Цели этого поста заключаются в следующем:
- Определить, что такое требование, какие типы и уровни требований выделяют.
- Понять, какие существуют методы сбора и выявления требований.
- Предоставить почву для дальнейшего изучения сферы системного и бизнес-анализа.
ПОЛНАЯ ВЕРСИЯ СТАТЬИ НА НАШЕМ САЙТЕ
Требования
Начнем с требований как таковых:
- Что они из себя представляют?
- Какие виды требований выделяются?
- Как они согласуются?
- Какие источники требований можно выделить?
Определение требования
Прежде чем погрузиться в теорию разработки требований к ПО, попробуйте, основываясь на своих знаниях и опыте, ответить на вопрос: как вы определяете термин «требование»?
Вопрос, что считать требованием к ПО, является сугубо дискуссионным. Но так или иначе нам с вами необходима отправная точка для изучения темы, поэтому обратимся к уже устоявшимся определениям:
Требования к ПО — это спецификация того, что должно быть реализовано. В них описано поведение системы, свойства системы или ее атрибуты. Они могут служить ограничениями в процессе разработки системы (Ian Sommerville и Pete Sawyer, 1997).
Требования к ПО — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению (ПО), в результате анализа требований (Википедия).
Из определений можно выделить следующие пункты, которые относятся к требованиям:
- Спецификация — документ, устанавливающий требования.
- Реализация — интерпретация требований в виде разработанной системы (одни и те же требования можно реализовать различными способами).
- Описание поведения системы (то, как система должна работать при различных входных условиях).
- Описание свойств / атрибутов / качеств системы.
Как видно выше, устоявшиеся термины не отражают всю полноту понятия «требование к ПО», поэтому также стоит отметить следующее: требования охватывают как видение пользователя, так и внешнее поведение системы, а также представление разработчика о некоторых внутренних характеристиках. Они включают как поведение системы в определенных условиях, так и свойства, которые делают систему полезной и удовлетворяющей конечных пользователей.
Термин «требование» охватывает довольно широкую предметную область. Поэтому возникает вопрос типизации и классификации требований.
Уровни и типы требований
Требования к ПО состоят из трех уровней:
- Бизнес-требования.
- Пользовательские требования.
- Функциональные требования.
Отдельно вне иерархии выделяют нефункциональные требования. Они так или иначе всегда представлены на всех уровнях требований и прямо или косвенно влияют также на все из них. Далее подробнее разберем каждый уровень требований отдельно.
ПОЛНАЯ ВЕРСИЯ СТАТЬИ НА НАШЕМ САЙТЕ
Бизнес-требования BRQ
Бизнес-требование (business requirements) — высокоуровневая бизнес-цель организации или заказчиков системы.
Бизнес-требования описывают, почему организации нужна такая система, то есть цели, которые организация намерена достичь с ее помощью. Основное их содержание — бизнес-цели организации или клиента, заказывающих систему.
Бизнес-требования — это верхний уровень абстракции требований к системе. Они не относятся напрямую к реализации проекта, а в первую очередь отражают цели бизнеса, абстрагированные от реализации системы. В конечном итоге бизнес-требования формируют документ концепции и границ.
Если кратко, документ содержит определение следующих понятий:
- Бизнес-возможности, бизнес-проблемы — факты и события, формирующие бизнес-цели, то есть грубо — причины инициации проекта.
- Бизнес-цели — цели, которые должны быть решены разработкой и вводом в эксплуатацию системы. Являются критериями успеха проекта.
- Концепция продукта (Vision) — сжато описывает конечный продукт, который достигнет заданных бизнес-целей.
- Границы проекта (scope) — показывают, на какую часть конечной концепции продукта будет направлен текущий проект или итерация.
Примеры бизнес-требований:
Облачная автоматизация RPA на примере UiPath
tproger.ru
Сократить время обработки заказа на 50% (цель) — система должна предоставить интерфейс, упрощающий создание заказа (концепция).
Увеличить клиентскую конверсию до 35% (цель) — в системе должны быть представлены механизмы побуждения клиента к заказу (концепция).
Говоря о сборе и выявлении требований, нельзя опускать вопрос, в каких источниках искать требования. Под источниками требований подразумевается любой источник информации, используя который мы можем сформулировать требование.
Источники бизнес-требований (где искать?):
- Внутренняя документация компании (положения, инструкции, приказы).
- Документация по предметной области (профильные литература и статьи, исследования).
- Нормативная документация (законы и иные правовые акты, государственные стандарты).
- Продукты конкурентов.
Стейкхолдеры (у кого спрашивать?):
- Инициатор проекта.
- Руководитель проекта (менеджер проекта).
- Руководитель структурного подразделения заказчика (коммерческий директор, директор по маркетингу).
- Бизнес-аналитик.
P.S. Список стейкхолдеров меняется от проекта к проекту, для каждого проекта необходимо отдельно определять список заинтересованных/ответственных лиц. Списки, представленные мной, являются сугубо примерами из моей практики.
QA и разработчики, как правило, не участвуют в сборе и анализе бизнес-требований. Но нам важно понимать верхнеуровневые цели, которые преследует проект, так как пользовательские и функциональные требования — это следствие выявления, анализа и декомпозиции бизнес-требований. Работая с бизнес-требованиями, вы в первую очередь погружаетесь в предметную область заказчика. На мой взгляд, это очень важно для всех участников проекта. Если член команды погружен в предметную область заказчика, существенное количество вопросов отпадет, а следовательно, сокращается и время, потраченное на коммуникации.
Пользовательские требования URQ
Пользовательские требования (user requirements) описывают цели или задачи, которые пользователи должны иметь возможность выполнять с помощью продукта, который в свою очередь должен приносить пользу кому-то. Область пользовательских требований также включает описания атрибутов или характеристик продукта, которые важны для удовлетворения пользователе (Карл Вигерс, «Разработка требований к программному обеспечению»).
Пользовательские требования определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе (Википедия).
Пользовательские требования также часто именуются фичами.
Фича (функциональность) — функционально обобщенные части системы, решающие отдельные задачи пользователей или интерпретирующие бизнес-процессы (и их артефакты), которые будут реализованы в рамках системы.
Исходя из вышеописанных определений, пользовательские требования содержат:
- Цели и задачи пользователей.
- Сценарии использования — способ решения задачи пользователей.
- Как следствие, описание самих пользователей системы:
- пользовательские роли,
- уровни доступа.
В конечном итоге пользовательские требования формируют «Документ пользовательских требований». Пользовательские требования могут быть представлены в виде:
- текстового описания,
- вариантов использования, сценариев использования (Use Case),
- пользовательских историй (User Story),
- диаграммы вариантов использования.
Как правило, пользовательские требования описываются по следующему шаблону:
Пользователь должен иметь возможность + {тезис}.
Пример пользовательского требования:
Пользователь должен иметь возможность добавить объект в избранное (функциональность).
Источники пользовательских требований требований (где искать?):
- Анализ и декомпозиция бизнес-требований.
- Описание бизнес-процессов.
- Артефакты бизнес-процессов:
- документы входные/выходные,
- стандарты,
- регламенты,
- обрабатываемые данные,
- иная информация, используемая и/или производимая в бизнес-процессе.
- Отраслевые стандарты.
- Реализованные проекты, проекты конкурентов.
Стейкхолдеры (у кого спрашивать?):
- Бизнес-аналитик, системный-аналитик.
- Конечные пользователи — люди, взаимодействующие с системой напрямую.
- Косвенные пользователи — люди, использующие результаты работы системы, не взаимодействуя с ней напрямую.
- Представители пользователей.
- Менеджер проекта.
- Руководитель структурного подразделения заказчика.
Этот уровень требований напрямую входит в круг обязанностей QA-инженера. В задачи QA на этом уровне входит:
- Определение соответствия описания требований критериям качества.
- Анализ требований для проработки сценариев тестирования.
- При достаточном уровне компетенций в предметной области:
- определение соответствия требований устоявшимся отраслевым стандартам (например: системе не достаёт фичи, которая в рамках предметной области системы является обязательной);
- определение соответствия требований с утвержденными бизнес-требованиями. Ответ на вопрос: «Решает ли пользовательское требование бизнес-цели проекта и задачи пользователей?«.
Функциональные требования FRQ
Функциональные требования (functional requirements) — описание требуемого поведения системы в определенных условиях.
Функциональные требования определяют, каким должно быть поведение продукта в тех или иных условиях. Они определяют, что разработчики должны создать, чтобы пользователи смогли выполнить свои задачи (пользовательские требования) в рамках бизнес-требований.
Функциональные требования самые низкоуровневые. Являются результатом декомпозиции верхнеуровневых требований и описывают атомарные функции, которые должны быть реализованы в системе.
Пример функциональных требований:
Пользователь должен иметь возможность добавить объект в избранное (URQ):
FRQ 1 — Добавить в избранное.
FRQ 2 — Удалить из избранного.
FRQ 3 — Редактирование дополнительных атрибутов.
FRQ 4 — Обращение к объекту из меню избранного.
Источники требований (где искать?):
- Анализ пользовательских требований.
- Таски.
- Прототипы интерфейса (мокапы).
- Отраслевые стандарты.
- Внешние системы и документация к ним (интеграции).
Стейкхолдеры (у кого спрашивать?):
- Бизнес-Аналитик.
- Системный аналитик.
- Архитектор.
- Менеджер проекта.
- Разработчики.
Нефункциональные требования NFRQ
Нефункциональное требование (non-functional requirements) — описание свойства или особенности, которым должна обладать система, или ограничение, которое должна соблюдать система.
На мой взгляд, это крайне исчерпывающее определение. Как вы могли заметить, нефункциональные требования не входят в основную иерархию требований. Их выделяют от других типов требований, так как нефункциональные требования:
- Выявляются и формулируются на всех уровнях иерархии требований.
- Напрямую или косвенно влияют на формирование каждого уровня требований.
Совет: Чаще всего нефункциональные требования отвечают на вопрос «Как? Каким образом?».
Пример нефункциональных требований, которые являются основной идеей проекта: Тик Ток.
С точки зрения разработки функциональный скоуп проекта не является уникальным:
- смотреть контент,
- предлагать ротацию контента на основе алгоритмов,
- создавать контент.
Все эти фичи так или иначе были представлены в других проектах. Ключом успеха проекта в данном случае является его UI/UX. А UI/UX сам по себе не отвечает за функции системы, а отвечает за то, каким образом будут реализованы эти функции.
