Требования к ПО | часть 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 Ukraine, my Family, Javascript and Quality Products.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrii Ievtukhov

Andrii Ievtukhov

QA Lead. Love Ukraine, my Family, Javascript and Quality Products.