Требования к ПО | часть 1

Photo by Eric Muhr on Unsplash

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

Требование — слово, которое часто встречается в книгах, статьях, на конференциях, при общении с коллегами, заказчиками, в общем много где, но значимость которого часто недооценивается, так как все “понимают, о чем речь”.

НО, как показывает практика, это совсем не так.

Давайте разбираться!

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

Коротко и понятно, идем дальше.

Зачем нужны требования?

Вопрос, который часто можно услышать от заказчиков / менеджеров / ПО, которые знают :) определение, но не понимают его значимости.

На этот вопрос есть несколько ответов.

Требования необходимы, потому что они:

  • Позволяют понять что система должна делать
  • Являются основой для формирования плана проекта
  • Помогают предотвращать и разрешать конфликтные ситуации
  • Упрощают расстановку приоритетов
  • Дают возможность оценить масштаб изменений
  • Позволяют оценить степень прогресса в разработке

Требования — это “скелет” каждого проекта. Проект без требований — это эквивалент амёбы. Надеюсь нет такого заказчика, который хотел бы, чтоб его продукт был таким :)

Итак,

  1. Что такое — разобрались
  2. Зачем нужны — разобрались
  3. Предположим написали — …

Дефекты в требованиях

7 раз отмерь, один раз отрежь. Поспешишь — людей насмешишь. Ну вы поняли… :)

Наличие требований, которые написаны не правильно не спасет вас от проблем, а может их только усугубить.

Многие не уделяют внимания написанию требований, откладывают их на потом или пишут их “на коленке за 5 минут”. Из-за этого в таких требованиях часто встречаются ошибки, а как все понимают — ошибки стоят денег.

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

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

На первый взгляд — ничего страшного не произошло.

Одним форматом больше, одним меньше — какая разница. Ведь это быстро делается.

Заказчик

Давайте проверять, на сколько эта ошибка страшна на самом деле.

Рассмотрим 3 варианта:

1) Если дефект в требованиях найден на раннем этапе разработки (можно назвать его подготовительным этапом) — стоимость исправления будет эквивалентна сумме:

  • стоимости исправления требования (указать верные форматы)
  • стоимости оповещения об исправлении требования

2) Если дефект в требованиях найден на позднем этапе разработки (какая-то часть требований уже реализована)— стоимость исправления будет эквивалентна сумме:

  • стоимости исправления требования
  • стоимости оповещения об исправлении требования
  • стоимости исправления дизайна (замена сообщений на сайте, в нотификациях, кнопках и т.д.)
  • стоимости исправления кода (реализация поддержки новых форматов + правки по дизайну)
  • стоимости исправления тестов (исправление связанных тест-кейсов)
  • стоимости повторного тестирования

3) В самом худшем сценарии, ошибка приведет к:

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

Итоги:

  1. Требования нужно писать, и писать их нужно внимательно и вдумчиво.
  2. Требования нужно тестировать, и как можно раньше.

Техники тестирования требований

Тестирование требований относится к нефункциональному тестированию (non-functional testing).

Основными техниками являются:

  1. Взаимный просмотр. Требования вдумчиво перечитывают несколько человек, высказывая вопросы, замечания.
  2. Вопросы. Уточняющие вопросы. Любая неточность или размытость в требованиях может содержать основу для будущих дефектов. Вопросы нужно задавать до тех пор, пока требование не будет точным, понятным и однозначным.
  3. Продумывание тест-кейсов (чек-листов). По ходу прочтения требований нужно представлять, как их нужно будет проверять. Если в голову ничего не приходит — значит с требованием что то не так. Нужно задавать вопросы.
  4. Исследование системы. Иногда требования могут быть противоречивыми, по этому нужно “представлять” систему и пытаться сопоставлять требования между собой.
  5. Визуализация. Если существуют алгоритмы работы системы, будущие бизнес процессы, UML диаграммы — их тоже нужно анализировать. Они помогают определять места, которые не продуманы, либо не стыкуются между собой.
  6. Прототипирование. Анализ прототипов дает те же результаты, что и визуализация, только со стороны конечного пользователя системы.

Выбор техник зависит от проекта, по этому их набор может изменяться.

Главное не забывать, что они существуют, и что ими нужно пользоваться.

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

Дальше рассмотрим типы и источники требований.

Удачи! :)

🔥 Интересуешься тестированием и хочешь получать актуальную информацию?

👉 Присоединяйся к 3,000+ тестировщикам в Телеграм!

Тебе не хватает практики по тестированию?
👉 Получи практическое задание!

Хочешь расти быстрей, как профессионал?
👉 Оставляй заявку на менторство!

QA Lead. Love My Family, JavaScript and Quality Products

QA Lead. Love My Family, JavaScript and Quality Products