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

Атрибуты требований

Требования – это нечто большее, чем "просто" предложения. Не стоит забывать про обоснование документирования, приоритеты, типы требований, связанные с этим варианты использования и т.д. Атрибуты требований – это их свойства. Они охватывают важную дополнительную информацию о системном требовании. Обычно атрибуты требований реализуются в форме карточки (например, карточка пользовательских историй), используемой в проекте или организации. Не переусердствуйте, определите для себя практический набор атрибутов, имеющих дополнительное значение.

Приемочные критерии

Приемочные критерии (также называется критерием соответствия) завершают определение требования. Мы должны уметь делать выводы и определять, полностью ли решение удовлетворяет или соответствует указанному требованию. Приемочные критерии делают требования количественно описываемыми. Всегда намного легче добавить конкретный критерий, чем написать на 100% однозначное требование. Критерий приемлемости в какой-то степени детализирует требование.

Правила разработки и документирования требований

Дискуссии на тему “какое требование можно считать хорошим?” безграничны. Разумеется, все зависит от контекста, но важнее всего иметь решения. Необходимо определить конкретный и применимый набор правил по созданию требований, что приведет к появлению “достаточно хороших” требований в вашем контексте. Обсуждайте и определяйте правила, касающиеся таких вопросов, как идентификация, аннотации, изменения, согласованность, язык, краткость, однозначность, обоснование, квантифицируемость и использование составных требований.

Шаблоны требований

Вместо того чтобы каждый раз заново изобретать колесо, используйте шаблоны для определения функциональных и нефункциональных требований. Они обеспечивают согласованность и в значительной мере способствуют созданию высокого уровня ясности. Это еще более эффективно, так почему бы и не завтра? Как правило, для пользовательских историй применяется следующий формат: “В качестве <роль>, я хочу <цель/желание> с тем, чтобы <выгода>”.

Другие распространенные шаблоны включают:

• <Пользователь> должен иметь <возможность>, например, “Служащий по приему заказов должен иметь возможность выставлять счета”;
• <Продукт> должен иметь возможность <действие> <понятие>, например, “Модуль запуска должен иметь возможность запустить ракету”;
• <Продукт> должен <функция> <предмет> каждые <объем> <единица>, например, “Кофейный аппарат должен производить горячий напиток каждые 10 секунд”.

Ревью требований

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

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

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

--

Автор: Erik van Veenendaal

Оригинал статьи: http://re-magazine.ireb.org/issues/2014-[...]ly/requirements-engineering-for-testers/

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile