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

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

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

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

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

В общем случае существуют 4 типа требований. Они изображены на рисунке ниже.

  • Бизнес-требования – это высокоуровневые цели организации или заказчиков системы. Они отвечают на вопрос: “Почему мы это делаем?”. Иногда – это первоначальное описание системы, чтобы понимать, что мы вообще делаем.

Пример: Сделайте мне крутой интернет-магазин.

  • Пользовательские требования – описывают задачи, которые пользователи смогут решать с помощью системы. Отвечает на вопрос: “Что могут делать пользователи?”

Пример: Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе.

  • Функциональные требования – определяют функциональность ПО, которую должны реализовать разработчики, чтобы пользователи могли выполнять требуемые задачи. Отвечают на вопрос: “Что должен сделать разработчик?”.

Пример: Автоматическое резервное копирование данных должно производиться ежедневно в указанный момент времени.

  • Нефункциональные требования – дополнительное описание продукта и\или его характеристики, важные для пользователей продукта или разработчиков. Эти требования описывают такие свойства системы как: удобство использования, безопасность, надёжность, расширяемость и т.д.

Пример: при одновременной работе с системой 1000 пользователей, минимальное время между возникновением сбоя должно быть более или равно десяти тысячам часов.

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

Пример: Формат времени для пользователей из США – ГГГГ-ДД-ММ, а для пользователей из Москвы – ДД-ММ-ГГГГ

Какими должны быть требования?

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

Можно выделить 8 свойств хороших требований:

  • Завершённость
  • Непротиворечивость
  • Корректность
  • Недвусмысленность
  • Проверяемость
  • Модифицируемость
  • Прослеживаемость
  • Проранжированность (важности, стабильности, срочности)

          Завершенность ­– каждое требование должно содержать всю информацию, необходимую разработчику, для того, что правильно спроектировать и реализовать требуемую функциональность. В идеале требование описывает: Что нужно сделать? Как оно выглядит?  Как оно себя ведет?

Все важные аспекты должны быть включены. Ничто не должно быть оставлено “для будущего определения”.

Часто возникает проблема незавершенности, когда есть скрытые предположения или используются слишком общие заявления. Пример: “Вторая версия приложения должна быть на 50% быстрее”.

Непротиворечивость – требование не должно содержать противоречий как внутри себя, так и с другими требованиями. Противоречия могут быть внутренними (внутри одного требования) и внешними (противоречия с другими требованиями).

Корректность – требование должно чётко указывать на то, что должно выполнять приложение.

Недопустимо при написании требования предполагать, что что-то окажется очевидным. Каждый человек понимает это «очевидное» по-своему, и в итоге система получится не такой, как задумывалось.

Пример не до конца определенного требования: “Не реже раза в 10 минут приложение должно отсылать уведомление о текущем статусе”.

Пример правильного требования: “Уведомление о текущем статусе должно отправляться раз в 10 минут +/- 5 секунд”.

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

Пример:

Заказчик: “Функция XYZ опциональна”

Дизайнер: “Функция XYZ опциональна, так что можно её не делать”

Покупатель: “Ого, тут есть классная функция XYZ”

Продавец: “Функция XYZ опциональная, так что мы можем её продавать за дополнительную плату”

Проверяемость – требование должно быть сформулировано так, чтобы существовали способы однозначной проверки – выполнено требование или нет.

Как правило требования могут иметь несколько недостатков. И как правило даже один недостаток ведет в итоге к тому, что требование нельзя проверить.

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

Как понять, что требование непроверяемое? Попробовать придумать несколько тестов для его проверки. Если тесты не придумываются – вот она, проблема.

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

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

Прослеживаемость – у каждого требования должен быть уникальный идентификатор, по которому на это требование можно сослаться.

Если требования не пронумерованы, не имеют чёткого оглавления, не имеют работающих перекрёстными ссылок – это хаос. А в хаосе ошибки плодятся с удивительной скоростью.

          Проранжированность – если требования не проранжированы по важности, стабильности и срочности, мы рискуем уделить основное внимание не тому, что на самом деле важно для заказчика.

Каждое требование должно иметь свою важность. Если все требования одинаково важны или 90% требований имеют наивысший приоритет, то это сигнал о том, что у нас проблема Такое представление может повлечь за собой то, что важные требования не будут реализованы в срок или будут реализованы слишком поздно.

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

Чтобы проверить требования самый лучший подход — это задавать вопросы. Особенно хорошо задавать вопросы в стиле репортера или маленького ребенка (А почему? А как? И т. д.). Такие вопросы не навязывают решение и не загоняют заказчика в рамки выбора между имеющихся вариантов.