Неявные требования

Неявные требования /Implicit Requirements – это особенности и характеристики продукта, которого ожидают клиенты (как само по себе разумеющееся). Фактически, без них рынок рассматривал бы продукт как неполноценный.

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

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

 

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

1. Явные требования: что записывает продуктовая команда.

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

• Резерв продукта
• Бэклог спринта
• Дорожная карта продукта
• Критерии приемки
• Каркас
• Макет
• Документ с требованиями к продукту (хотя в сегодняшнюю эпоху гибкого управления продуктом они встречаются реже)

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

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

2. Неявные требования: чего все ожидают и не нужно записывать.

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

Типы неявных требований (для разработки программных продуктов):

• Стабильность
• Конфиденциальность и безопасность
• Особенности, которые стали ожидаемыми среди аналогичных типов продуктов

Что такое пример неявного требования?

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

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

Добавление поля номера телефона также включало бы несколько неявных требований для команды разработчиков. Например:

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

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

Как вы проверяете неявные требования?

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

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

Как объясняется в статье StickyMinds о тестировании требований:

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

Когда программное обеспечение не соответствует неявному требованию, отчет об этом сбое должен также включать объяснение того, почему заказчик может ожидать, что программное обеспечение будет вести себя иначе. Какое влияние оказывает ошибка на качество обслуживания клиентов?»