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

Photo by Eric Muhr on Unsplash

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

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

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

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

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

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

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

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

7 years in IT. SDET, QA Lead. Love My Family, JavaScript and Quality Products

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