Требование — слово, которое часто встречается в книгах, статьях, на конференциях, при общении с коллегами, заказчиками, в общем много где, но значимость которого часто недооценивается, так как все “понимают, о чем речь”.
НО, как показывает практика, это совсем не так.
Давайте разбираться!
Требование (requirement) — описание функции и/или условия, которое должно соблюдаться приложением в процессе решения пользовательской задачи.
Коротко и понятно, идем дальше.
Зачем нужны требования?
Вопрос, который часто можно услышать от заказчиков / менеджеров / ПО, которые знают :) определение, но не понимают его значимости.
На этот вопрос есть несколько ответов.
Требования необходимы, потому что они:
- Позволяют понять что система должна делать
- Являются основой для формирования плана проекта
- Помогают предотвращать и разрешать конфликтные ситуации
- Упрощают расстановку приоритетов
- Дают возможность оценить масштаб изменений
- Позволяют оценить степень прогресса в разработке
Требования — это “скелет” каждого проекта. Проект без требований — это эквивалент амёбы. Надеюсь нет такого заказчика, который хотел бы, чтоб его продукт был таким :)
Итак,
- Что такое — разобрались
- Зачем нужны — разобрались
- Предположим написали — …
Дефекты в требованиях
7 раз отмерь, один раз отрежь. Поспешишь — людей насмешишь. Ну вы поняли… :)
Наличие требований, которые написаны не правильно — не спасет вас от проблем, а может их только усугубить.
Многие не уделяют внимания написанию требований, откладывают их на потом или пишут их “на коленке за 5 минут”. Из-за этого в таких требованиях часто встречаются ошибки, а как все понимают — ошибки стоят денег.
Давайте рассмотрим на примере, к чему может привести и сколько будет стоить одна и та же ошибка в требованиях, найденная на разных этапах разработки.
Предположим, заказчик не верно указал перечень поддерживаемых форматов файлов для проверки их содержимого.
На первый взгляд — ничего страшного не произошло.
Одним форматом больше, одним меньше — какая разница. Ведь это быстро делается.
Заказчик
Давайте проверять, на сколько эта ошибка страшна на самом деле.
Рассмотрим 3 варианта:
1) Если дефект в требованиях найден на раннем этапе разработки (можно назвать его подготовительным этапом) — стоимость исправления будет эквивалентна сумме:
- стоимости исправления требования (указать верные форматы)
- стоимости оповещения об исправлении требования
2) Если дефект в требованиях найден на позднем этапе разработки (какая-то часть требований уже реализована)— стоимость исправления будет эквивалентна сумме:
- стоимости исправления требования
- стоимости оповещения об исправлении требования
- стоимости исправления дизайна (замена сообщений на сайте, в нотификациях, кнопках и т.д.)
- стоимости исправления кода (реализация поддержки новых форматов + правки по дизайну)
- стоимости исправления тестов (исправление связанных тест-кейсов)
- стоимости повторного тестирования
3) В самом худшем сценарии, ошибка приведет к:
- невозможности реализации исправленного требования при помощи выбранных технологий, что эквивалентно полной переработке продукта — все ресурсы потрачены зря. (указанный формат не может быть проверен при помощи выбранной технологии)
- не полной реализации требования, отказа от него или отказа от его части, что ухудшает продукт с точки зрения клиента, особенно если он ждет, что требование будет реализовано. В таком случае часть ресурсов, которая пошла на анализ, подготовку, реализацию, потрачена зря + получаем не довольного клиента.
Итоги:
- Требования нужно писать, и писать их нужно внимательно и вдумчиво.
- Требования нужно тестировать, и как можно раньше.
Техники тестирования требований
Тестирование требований относится к нефункциональному тестированию (non-functional testing).
Основными техниками являются:
- Взаимный просмотр. Требования вдумчиво перечитывают несколько человек, высказывая вопросы, замечания.
- Вопросы. Уточняющие вопросы. Любая неточность или размытость в требованиях может содержать основу для будущих дефектов. Вопросы нужно задавать до тех пор, пока требование не будет точным, понятным и однозначным.
- Продумывание тест-кейсов (чек-листов). По ходу прочтения требований нужно представлять, как их нужно будет проверять. Если в голову ничего не приходит — значит с требованием что то не так. Нужно задавать вопросы.
- Исследование системы. Иногда требования могут быть противоречивыми, по этому нужно “представлять” систему и пытаться сопоставлять требования между собой.
- Визуализация. Если существуют алгоритмы работы системы, будущие бизнес процессы, UML диаграммы — их тоже нужно анализировать. Они помогают определять места, которые не продуманы, либо не стыкуются между собой.
- Прототипирование. Анализ прототипов дает те же результаты, что и визуализация, только со стороны конечного пользователя системы.
Выбор техник зависит от проекта, по этому их набор может изменяться.
Главное не забывать, что они существуют, и что ими нужно пользоваться.
Теперь у Вас есть базовое понимание, что такое требования, зачем они нужны, к чему приводят ошибки в требованиях, и как их можно минимизировать.
Дальше рассмотрим типы и источники требований.
Удачи! :)
🔥 Интересуешься тестированием и хочешь получать актуальную информацию?
👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!
Тебе не хватает практики по тестированию?
👉 Получи практическое задание!
Хочешь расти быстрей, как профессионал?
👉 Оставляй заявку на менторство!
