Тестирование программного обеспечения: 1.3 Типы и уровни требований. Выявление требований

Требование (requirement) — описание функции и/или условия, которое должно соблюдаться приложением в процессе решения пользовательской задачи.

Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как.

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

Источники требований

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

Для выявления требований чаще всего используются следующие техники:

Интервью (либо переписка) – опрос, часто в формате вопрос ответ между аналитиком и заказчиком / пользователем
Фокусные группы – расширенное интервью с несколькими пользователями
Мозговой штурм – позволяет за короткий промежуток времени собрать большое количество идей, которые в дальнейшем изучаются и анализируются
Наблюдение – позволяет выявить процессы, о которых не упомянули в интервью, занимает много времени
Прототипирование – один из лучших способов понять и уточнить требования

Так же существуют более сложные методы, при котором аналитик должен «сам во всем разобраться», и уточнить собранную информацию у заказчиков:

Анализ документов
Моделирование процессов
Самостоятельное описание

Классификация требований (типы и уровни требований)

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

Почти в каждом проекте существует 3 заинтересованных стороны:

Заказчики продукта
Пользователи продукта
Разработчики продукта

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

Уровень заказчика (бизнес-требований)

На этом уровне находится только один тип требований – бизнес требования (business requirements).

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

Основываясь на этих требованиях можно получить общее видение проекта.

Уровень пользователя

Описывают “взгляд” на продукт глазами пользователя.

Включает в себя:

Пользовательские требования (user requirements) — описание задач, которые может выполнять пользователь при помощи системы. Оформляются в виде пользовательских историй (user stories, cases, scenarios). Эти требования могут быть использованы для оценки времени, сложности, стоимости разработки.
Бизнес правила (business rules) — описывают особенности принятых в предметной области процессов, ограничений, правил.
Атрибуты качества (quality attributes) — описывают ключевые показатели качества продукта.

Уровень разработки (продуктных требований)

Содержит наиболее детализированное описание функций продукта, которые должны быть реализованными.

Конечным документом, содержащим все требования уровня разработки является Спецификация требований (software requirements specification, SRS). Часто это объемный документ, содержащий сотни страниц.

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

Функциональные требования (functional requirements) — описывают что должна и что НЕ должна делать система.
Нефункциональные требования (non-functional requirements) — требования, которые определяют критерии работы системы в целом, а не отдельные сценарии поведения. Нефункциональные требования определяют системные свойства такие как производительность, удобство сопровождения, расширяемость, надежность, средовые факторы эксплуатации.

Примеры:

«API метод должен возвращать список ресторанов в короткой форме: id, название, адрес» или «Никакая личная информация пользователя (логин, пароль, номера телефонов, и тд.) не должна отображаться в отчетах» - это функциональные требования, они описывают поведение системы.
«Объем используемой оперативной памяти не должен превышать 256 Мб» или «Все данные системы должны храниться в БД под управлением СУБД MySQL» - это нефункциональные требования, они описывают свойства системы.

Разработка и управление требованиями (выявление требований)

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

Выявление и сбор требований (elecitation)

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

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

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

Этот этап подразумевает получение более обширного и точного понимания всех требований и представление наборов требований в различном виде. Основными действиями на этом этапе будут:

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

Документирование

Представление и хранение знаний о требованиях определенным способом. Например в письменные требования, диаграмы пригодные для дальнейшего использования.

Утверждение требований

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

Нельзя создать идеальные требования. Если смотреть с практической точки зрения, то цель разработки требований — накопить общее понимание требований необходимое для разработки очередной порции продукта.

Управление требованиями

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

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

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

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

Источники: